Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The assignment of map to itself is redundant and can be removed.
Detected with Coccinelle.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Here is the big USB and PHY driver update for 4.16-rc1.
Along with the normally expected XHCI, MUSB, and Gadget driver patches,
there are some PHY driver fixes, license cleanups, sysfs attribute
cleanups, usbip changes, and a raft of other smaller fixes and
additions.
Full details are in the shortlog.
All of these have been in the linux-next tree for a long time with no
reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWnL0Bg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymg8gCeLg/FMtc0S/xRR/56N/sbthEebcUAnROr9Sg3
55hDLdkyi93o9R86YOAJ
=8d2q
-----END PGP SIGNATURE-----
Merge tag 'usb-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/PHY updates from Greg KH:
"Here is the big USB and PHY driver update for 4.16-rc1.
Along with the normally expected XHCI, MUSB, and Gadget driver
patches, there are some PHY driver fixes, license cleanups, sysfs
attribute cleanups, usbip changes, and a raft of other smaller fixes
and additions.
Full details are in the shortlog.
All of these have been in the linux-next tree for a long time with no
reported issues"
* tag 'usb-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (137 commits)
USB: serial: pl2303: new device id for Chilitag
USB: misc: fix up some remaining DEVICE_ATTR() usages
USB: musb: fix up one odd DEVICE_ATTR() usage
USB: atm: fix up some remaining DEVICE_ATTR() usage
USB: move many drivers to use DEVICE_ATTR_WO
USB: move many drivers to use DEVICE_ATTR_RO
USB: move many drivers to use DEVICE_ATTR_RW
USB: misc: chaoskey: Use true and false for boolean values
USB: storage: remove old wording about how to submit a change
USB: storage: remove invalid URL from drivers
usb: ehci-omap: don't complain on -EPROBE_DEFER when no PHY found
usbip: list: don't list devices attached to vhci_hcd
usbip: prevent bind loops on devices attached to vhci_hcd
USB: serial: remove redundant initializations of 'mos_parport'
usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc()
usb: gadget: compress return logic into one line
usbip: vhci_hcd: update 'status' file header and format
USB: serial: simple: add Motorola Tetra driver
CDC-ACM: apply quirk for card reader
usb: option: Add support for FS040U modem
...
Pull libata updates from Tejun Heo:
"Nothing too interesting. Several patches to convert mdelay() to
usleep_range(), removal of unused pata_at32, and other low level
driver specific changes"
* 'for-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
ata: pata_pdc2027x: Replace mdelay with msleep
ata: pata_it821x: Replace mdelay with usleep_range in it821x_firmware_command
ata: sata_mv: Replace mdelay with usleep_range in mv_reset_channel
ata: remove pata_at32
phy: brcm-sata: remove unused variable
phy: brcm-sata: fix semicolon.cocci warnings
ata: ahci_brcm: Recover from failures to identify devices
phy: brcm-sata: Implement calibrate callback
ahci: Add Intel Cannon Lake PCH-H PCI ID
ata_piix: constify pci_bits
libata:pata_atiixp: Don't use unconnected secondary port on SB600
ata: ahci_brcm: Avoid clobbering SATA_TOP_CTRL_BUS_CTRL
ahci: Allow setting a default LPM policy for mobile chipsets
ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
ahci: Annotate PCI ids for mobile Intel chipsets as such
Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.
However, it turns out that making the usb-nop-xceiv device compatible with
the generic-phy binding changes the phy_get() return code from -EINVAL to
-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
-EPROBE_DEFER from its probe function rather than ignoring the failure,
breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
function, so a reasonable assumption would be that many other platforms
are affected as well.
I have reviewed all the related patches and concluded that "usb-nop-xceiv"
is the only USB phy that is affected by the change, and since it is by far
the most commonly referenced phy, all the other USB phy drivers appear
to be used in ways that are are either safe in DT (they don't use the
'phys' property), or in the driver (they already ignore -EPROBE_DEFER
from generic-phy when usb-phy is available).
To work around the problem, this adds a special case to _of_phy_get()
so we ignore any PHY node that is compatible with "usb-nop-xceiv",
as we know that this can never load no matter how much we defer. In the
future, we might implement a generic-phy driver for "usb-nop-xceiv"
and then remove this workaround.
Since we generally want older kernels to also want to work with the
fixed devicetree files, it would be good to backport the patch into
stable kernels as well (3.13+ are possibly affected), even though they
don't contain any of the patches that may have caused regressions.
Fixes: 014d6da6cb ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
Fixes: c5bbf358b7 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Fixes: 44e5dced2e arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
Fixes: f568f6f554 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
Fixes: d745d5f277 ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
Fixes: 915fbe59cb ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Link: https://patchwork.kernel.org/patch/10158145/
Cc: stable@vger.kernel.org
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The newly introduced calibrate function has a variable
that has never been used and needs to be removed to avoid
this harmless warning:
drivers/phy/broadcom/phy-brcm-sata.c: In function 'brcm_stb_sata_calibrate':
drivers/phy/broadcom/phy-brcm-sata.c:514:24: error: unused variable 'priv' [-Werror=unused-variable]
Fixes: 3e507769d1 ("phy: brcm-sata: Implement calibrate callback")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Implement the calibration callback to allow turning on the Clock-Data
Recovery module clamping when necessary, e.g: during failure to identify
a SATA hard drive from ahci_brcm.c::brcm_ahci_read_id.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
*) Fix in exynos5-usbdrd to enumerate SuperSpeed devices on Odroid XU3
*) Fix in Broadcom USB PHY to get Dell Low Speed keyboards working
*) Fix in Broadcom USB PHY to power down the PHY when XHCI disabled
to save power
*) Fix in Broadcom USB PHY to prevent abort in DRD mode
*) Fix in Broadcom USB PHY to use the correct dt properties
*) Fix in Mediatek PHY to detect device connection
*) Make getting resource optional for Mediatek V1 TPHY
*) Cleanup in Mediatek PHY
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJaSzimAAoJEA5ceFyATYLZrCUP/3f02fVtkF+OAL3e+ZwgCWy/
xoGIHffTcrYFimPeHh7INbeA16o2qNcN8JxJqQFFpZtZIoBR60az6ql7P2CZomXv
Z4S8ftKl8cOEI6O6AmLgRFuxaHSG24IxD54rHwCa6bDAoq36VnHM2CG+EEB6Yd3M
4eYoS1hQuwFCKeWSmHo4Uq8zyvTwIaxfKhOBlonXZu3/Tt34ZR0sGr3FC2OIamTN
Isrx/BsdHsfg+mTElos9jnc5/Uhwy/r7JFmRotn06cWGw2EGoM6EOXBrp3WXHD/f
jQnSSP3ZKmDvq0zY7QywXVo+fVWddZYx3fsbd26A5bUsarcj2VWlbHWyAWtYty3N
HOuucYbMHSXTFxP/0j6pwONzQIIucisGgNdUc4Zc7nzwcF8A/BWrEMkGqZLit45q
NalvVz/+lk0be3zZngm/vbaztHbHMQDvKe0U5QbHH9h47MybmydocrPgs7JbDcFd
P0vHJ1be5CMItcElC0w+fkrRf3tk5IYQb4nZFDaTRSiuLU+S+mgLfYjbGH4lXtnQ
USsGRv827wFqQVEzay2WvazvviBautoneh2+YDMg7R1cSOh9kQkunPl9ePOig/DR
Cgy1MEZH8GZIIhIOBshnLQ2FiQbtnn0NkDTOajLNyJssFbE+9XXYKJr/cUvCOArP
W9GjMMvI06gI7T+sDylY
=f9so
-----END PGP SIGNATURE-----
Merge tag 'phy-for-4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next
Kishon writes:
phy: for 4.16
*) Fix in exynos5-usbdrd to enumerate SuperSpeed devices on Odroid XU3
*) Fix in Broadcom USB PHY to get Dell Low Speed keyboards working
*) Fix in Broadcom USB PHY to power down the PHY when XHCI disabled
to save power
*) Fix in Broadcom USB PHY to prevent abort in DRD mode
*) Fix in Broadcom USB PHY to use the correct dt properties
*) Fix in Mediatek PHY to detect device connection
*) Make getting resource optional for Mediatek V1 TPHY
*) Cleanup in Mediatek PHY
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
reduce the boilerplate code to get the specific data
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
V1 TPHY for SATA doesn't have shared banks if it isn't shared
with PCIe or USB, so make it optional.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
When system is running, if usb2 phy is forced to bypass utmi signals,
all PLL will be turned off, and it can't detect device connection
anymore, so replace force mode with auto mode which can bypass utmi
signals automatically if no device attached for normal flow.
But keep the force mode to fix RX sensitivity degradation issue.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This is caused by a bug in the BDC core. When the BDC core comes
out of reset and it's not selected, it gets a backup clock. When
the BDC core is selected, it get's the main clock. If HOST mode
is then selected the BDC core has the main clock shut off but
the backup clock is not restored.
The failure scenario and cause are as follows:
- DRD mode is active
- Device mode is selected first in bootloader
- When host mode is now selected, the clock to the BDC is cut off.
- BDC registers are inaccessible and therefore the BDC driver
crashes upon Linux boot.
The fix is to have the phy driver always force a BDC reset on
startup.
Fixes: 49859e55e3 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Set PHY3_IDDQ_OVERRIDE in the xhci uninit routine. This will save
additional power when the XHCI driver is not enabled.
Fixes: 49859e55e3 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Enable the the Low Speed Keep Alive signal on the 7271b0 by setting
the LS_KEEP_ALIVE bit in the USB CTRL OBRIDGE register otherwise
some Dell Low Speed keyboards fail.
Also do a little cleanup of the EBRIDGE ESTOP_SCB_REQ bit. Since
this is only used on one platform, remove it from the platform
tables and just use "if (family == ").
Fixes: 49859e55e3 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Change "brcm,has_xhci" and "brcm,has_eohci" device tree properties
to the preferred "brcm,has-xhci" and "brcm,has-eohci". This also
matches the existing device tree bindings document.
Fixes: 49859e55e3 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.
We are using CR_port for this purpose to send required data
to override the LOS values.
On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd
[Also removed unnecessary extra lines in the register macro definitions]
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
[adapted to use phy_calibrate as entry point]
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
When USB is disabled, we get a link error for this driver
because of the added OTG support
drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function `rcar_gen3_phy_usb2_probe':
phy-rcar-gen3-usb2.c:(.text+0x250): undefined reference to `of_usb_get_dr_mode_by_phy'
Other phy drivers select USB_COMMON for this, so let's do the same
here.
Fixes: 7e0540f413 ("phy: rcar-gen3-usb2: check dr_mode for otg mode")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add pm_runtime_disable in err case to make the pm_runtime_enable/disable
is invoked balanced.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The platform_get_irq_byname() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq_byname() error
checking for zero is not correct.
Fixes: 6d6ce40f63 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Fix child-node lookups during probe, which ended up searching the whole
device tree depth-first starting at the parents rather than just
matching on their children.
To make things worse, some parent nodes could end up being being
prematurely freed (by tegra_xusb_pad_register()) as
of_find_node_by_name() drops a reference to its first argument.
Fixes: 53d2a715c2 ("phy: Add Tegra XUSB pad controller support")
Cc: stable <stable@vger.kernel.org> # 4.7
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Here is the big set of USB and PHY driver updates for 4.15-rc1.
There is the usual amount of gadget and xhci driver updates, along with
phy and chipidea enhancements. There's also a lot of SPDX tags and
license boilerplate cleanups as well, which provide some churn in the
diffstat.
Other major thing is the typec code that moved out of staging and into
the "real" part of the drivers/usb/ tree, which was nice to see happen.
All of these have been in linux-next with no reported issues for a
while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWgm/Vw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yktXwCdGgpInfOEvOGFd83EPDL7a1ncyc4AoM5wI8yl
1CeLipqVIN3IsMMJptvb
=zvDI
-----END PGP SIGNATURE-----
Merge tag 'usb-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/PHY updates from Greg KH:
"Here is the big set of USB and PHY driver updates for 4.15-rc1.
There is the usual amount of gadget and xhci driver updates, along
with phy and chipidea enhancements. There's also a lot of SPDX tags
and license boilerplate cleanups as well, which provide some churn in
the diffstat.
Other major thing is the typec code that moved out of staging and into
the "real" part of the drivers/usb/ tree, which was nice to see
happen.
All of these have been in linux-next with no reported issues for a
while"
* tag 'usb-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (263 commits)
usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
USB: usbfs: compute urb->actual_length for isochronous
usb: core: message: remember to reset 'ret' to 0 when necessary
USB: typec: Remove remaining redundant license text
USB: typec: add SPDX identifiers to some files
USB: renesas_usbhs: rcar?.h: add SPDX tags
USB: chipidea: ci_hdrc_tegra.c: add SPDX line
USB: host: xhci-debugfs: add SPDX lines
USB: add SPDX identifiers to all remaining Makefiles
usb: host: isp1362-hcd: remove a couple of redundant assignments
USB: adutux: remove redundant variable minor
usb: core: add a new usb_get_ptm_status() helper
usb: core: add a 'type' parameter to usb_get_status()
usb: core: introduce a new usb_get_std_status() helper
usb: core: rename usb_get_status() 'type' argument to 'recip'
usb: core: add Status Type definitions
USB: gadget: Remove redundant license text
USB: gadget: function: Remove redundant license text
USB: gadget: udc: Remove redundant license text
USB: gadget: legacy: Remove redundant license text
...
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Detailed description for this pull request:
1. Split out extcon header file for consumer and provider device
: The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect
the state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API
for both provider and consumer device driver. To clarify the meaning
of header file and to remove the wrong use-case on consumer device.
- include/linux/extcon-provider.h includes API for the provider device driver.
- include/linux/extcon.h includes the API for the consumer device driver.
2. Support the SmartDock accessory on extcon-max77843.c device driver
- Support the SmartDock accessory which detects following connectors
at the same time.
: USB host throught USB hub for mouse, keyboard and so on.
: MHL connector for video output.
: Charger connector for battery charging.
- It tested with Unitek Y-2165 MHL+OTG Hub Smart Phone Dock.
3. Fix the minor issue of extcon driver
- Delete the unneeded initialization in extcon-max14577.
- Make extcon_info static const in order to fix the warning.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZ8bQaAAoJEJzN3yze689Tc8IP/RTxI/35eP0RIyxwIH93PcPT
H7yup4tJDmQtp2+aH8qyCxrjiy9Tb+eu45A+UroM8RHyBb47BiiDC5J4/H9I+Wed
jU/aoPp6NN4HocYSqtgkG+6DiyyA3ibbKPZHCeUKgf3Us1LZAL1pMPqZVpnfJIIX
nnW4LdJ7ociY31N3UYepRmMly4LejUO1HLNsd8WFfFv+KM7bSkqmAIViw/dtteCa
DL3SVbqzWXN226BtxiZoKZTHsz9QUQ9ZUvJe22d19fIkmP9FqJ5/ujxSUKgzOFe6
qRpF8HGKkgy6lwQ8XJzwY53bQw1NiG/KU+fXpMRL0mkoe3MNvBPIl+GTr0Ts6jrH
e0So0aIWZTtoPAxvs6mc0wl4P9zkESZ0PoxH8Ulo+rxKYau2ES3GRBofNzr1FHLu
4iQ7UikAIS33oyhYjJn/zm0nShKzWJxjQDXIx57CiHn4XKxGlwBz+wsLrfvdt1Me
WJ1yvhpL5F3B08RfmzIIpsrXwsS/IhTlfEHcbI/gAscpcALSgG5MZoZBwwm7IC7F
l0V81Z4jGNjztf0ZgTiBStN5KM0ntNH6AZAdrFigCtu9HzI4Egi45P7Gm7+Lxlic
sHI3d7I6g+L9V5Um6GmLPjzo6epNkYp46ws6YhAqjqM7HZ4YXFtCcm6YM4s/qlV5
6ubXPN/bRI7S5hWSkUTH
=gWvl
-----END PGP SIGNATURE-----
Merge tag 'extcon-next-for-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into usb-next
Chanwoo writes:
Update extcon for 4.15
Detailed description for this pull request:
1. Split out extcon header file for consumer and provider device
: The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect
the state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API
for both provider and consumer device driver. To clarify the meaning
of header file and to remove the wrong use-case on consumer device.
- include/linux/extcon-provider.h includes API for the provider device driver.
- include/linux/extcon.h includes the API for the consumer device driver.
2. Support the SmartDock accessory on extcon-max77843.c device driver
- Support the SmartDock accessory which detects following connectors
at the same time.
: USB host throught USB hub for mouse, keyboard and so on.
: MHL connector for video output.
: Charger connector for battery charging.
- It tested with Unitek Y-2165 MHL+OTG Hub Smart Phone Dock.
3. Fix the minor issue of extcon driver
- Delete the unneeded initialization in extcon-max14577.
- Make extcon_info static const in order to fix the warning.
Some quirky UDCs (like dwc3 on Exynos) need to have their phys calibrated e.g.
for using super speed. This patch adds a new phy_calibrate() method.
When the calibration should be used is dependent on actual chip.
In case of dwc3 on Exynos the calibration must happen after usb_add_hcd()
(while in host mode), because certain phy parameters like Tx LOS levels
and boost levels need to be calibrated further post initialization of xHCI
controller, to get SuperSpeed operations working. But an hcd must be
prepared first in order to pass it to usb_add_hcd(), so, in particular, dwc3
registers must be available first, and in order for the latter to happen
the phys must be initialized. This poses a chicken and egg problem if
the calibration were to be performed in phy_init(). To break the circular
dependency a separate method is added which can be called at a desired
moment after phy intialization.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Refactor ufs_qcom_power_up_sequence() to get rid of ugly
exported phy APIs and use the phy_init() and phy_power_on()
to do the phy initialization.
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Adding support to set desired UFS phy mode that can be set
from the host controller.
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Update the PCIe phy settings based on new settings available
in AM572x Technical Reference Manual[1] Revision I, revised
April 2017 in Table 26-62 "Preferred PCIe_PHY_RX SCP Register
Settings".
[1] http://www.ti.com/lit/ug/spruhz6i/spruhz6i.pdf
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[nsekhar@ti.com: commit message updates]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Parse the DT properties brcm,rxaeq-mode and brcm,rxaeq-value to
correctly configure the RX equalizer of the PHY. This may be required to
resolve specific signal integrity issues.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Split the functional code in brcm_stb_sata_init() to a separate function
that actually does configure spread spectrum: brcm_stb_sata_ssc_init()
and make that function return void, since that function cannot fail.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch adds SoC-specific parameter to avoid reading/writing
specific registers wrongly if this driver runs on a SoC which doesn't
have dedicated pins (e.g. R-Car D3). This patch also changes the
value "has_otg" to "has_otg_pins" for slightly easier reading of
the code.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch modifies the role_store() to use "enum phy_mode" instead
of the local "bool" for host/device mode selection.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The previous code assumed a channel has otg capability if a channel
has interrupt property. But, it is not good because:
- Battery charging feature also needs interrupt property.
- Some R-Car Gen3 SoCs (e.g. R-Car D3) don't have OTG capability.
So, this patch checks whether usb 2.0 host node has dr_mode property or
not. If it has 'dr_mode = "otg";', this driver enables otg capability.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Allwinner V3s SoC also features the dual route of the first USB PHY.
Enable it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Calculate the calibration code as per the docs. The docs talk about
reading and averaging the pullup and pulldown calibration codes. They
also talk about adding in some adjustment codes. Let's do what the
docs say.
In practice this doesn't seem to matter a whole lot. On a device I
tested the pullup and pulldown codes were nearly the same (0x23 and
0x24) and the adjustment codes were 0.
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
NOTE: nothing is known to be fixed by this change, but it does enforce
some delays that are documented to be necessary. Possibly this could
fix some corner cases.
The function tcphy_dp_aux_calibration(), like most of the functions in
the type C PHY, is mostly undocumented and filled with mysterious,
hardcoded numbers.
Let's attempt to try to document some of these numbers and clean the
function up a little bit. Here's the actual cleanup that happened
here:
1. All magic numbers were replaced with bit definitions.
2. For registers that we modify multiple times I now keep track of the
value of the register rather than randomly doing a
read/modify/write or just hardcoding a new number based on knowing
what the old number was.
3. Delay 10 ms (vs 1 ms) after writing the calibration code. No idea
if this is important but it matches the example in the docs.
4. Whenever setting a "delayed" version of a signal always put an
explicit delay in the code. No known problems were seen without
this delay but it seems wise to have it. Whenever a delay of "at
least 100 ns" was specified I used a delay of 1 us.
5. Added comments to some of the bits of code.
6. Removed duplicate setting of TX_ANA_CTRL_REG_5 (to 0)
7. Moved setting of TX_ANA_CTRL_REG_3 to the same place it was in the
sample code. Note that TX_ANA_CTRL_REG_3 ought to be initted to 0
(and elsewhere we assume that we just got a reset), but it seems
fine to be explicit.
8. Treats the calibration code as a 7-bit two's complement number.
This isn't strictly required, but seems slightly cleaner. The docs
say "treat this as a two's complement number, but it should never
be negative". If we ever read the "adjustment" codes as documented
then perhaps the two's complement bit will matter more.
There are still a few weird / mysterious things around aux init and
this doesn't attempt to fix all of them. Mostly it's aimed at doing
changes that should be _very_ safe and add a lot of clarity. Things
specifically not done:
A) Resolve the fact that some registers are read/modify/write and
others are explicitly initted to a value. We always call
tcphy_dp_aux_calibration() right after resetting the PHY so it's
probably not critical, but it's a little weird that the code is
inconsistent.
B) Fully resolve the documented init sequence with the current one.
We still have a few mystery steps and we also leave out turning on
TXDA_DRV_LDO_BG_FB_EN and TXDA_DRV_LDO_BG_REF_EN, which is in the
sample code.
C) Clean things up to read all the bits of the calibration code. This
will hopefully come in a followup change.
This also doesn't attempt to document any of the other parts of the
PHY--just the aux init which is all I got docs for.
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This is used to force PHY with USB OTG function to enter a specific
mode, and override OTG IDPIN(or IDDIG) signal.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The 'modes' member of the mvebu_comphy_priv structure is not used.
Remove it.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect the
state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API for
both provider and consumer device driver. To clarify the meaning of
header file and to remove the wrong use-case on consumer device,
this patch separates into extcon.h and extcon-provider.h.
[Description for include/linux/{extcon.h|extcon-provider.h}]
- extcon.h includes the extcon API and data structure for extcon consumer
device driver. This header file contains the following APIs:
: Register/unregister the notifier to catch the change of extcon device
: Get the extcon device instance
: Get the extcon device name
: Get the state of each external connector
: Get the property value of each external connector
: Get the property capability of each external connector
- extcon-provider.h includes the extcon API and data structure for extcon
provider device driver. This header file contains the following APIs:
: Include 'include/linux/extcon.h'
: Allocate the memory for extcon device instance
: Register/unregister extcon device
: Set the state of each external connector
: Set the property value of each external connector
: Set the property capability of each external connector
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
The function tcphy_phy_init() could return an error but the callers
weren't checking the return value. They should. In at least one case
while testing I saw the message "wait pma ready timeout" which
indicates that tcphy_phy_init() really could return an error and we
should account for it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
When the usb phy device mode is set to "drd", the USB port will
switch between device and host modes depending on what's plugged
into the port. Customers have asked for the ability to force
host or device mode from software. This commit adds sysfs
entries to the phy device that allow this. The sysfs for the phy
device can be found at:
/sys/bus/platform/drivers/brcmstb-usb-phy/*.usb-phy
The following sysfs entries were added:
- "dr_mode" (RO) - The current phy "dr_mode" setting.
It will be set to one of the following values:
- "host" - host mode
- "peripheral " - device mode
- "drd" - switch between device and host mode based on
installed device
- "typec-pd" - device/host mode is controller by the USB
Type-C PD protocol.
If "dr_mode" is "drd"
- "drd_select" (RW) -
It will be set to one of the following values:
- "host" - force host mode
- "device" - force device mode
- "auto" - allow normal auto selection of host/device based on
inserted USB device
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add a new USB Phy driver for Broadcom STB SoCs. This driver
supports Broadcom STB ARM SoCs. This driver in
combination with the Broadcom STB ohci, ehci and xhci
drivers will enable USB1.1, USB2.0 and USB3.0 support.
This Phy driver also supports the Broadcom BDC gadget
driver.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
On rk3399-gru-kevin there are some cases where we're seeing AUX CH
failures when trying to do DisplayPort over type C. Problems are
intermittent and don't reproduce all the time. Problems are often
bursty and failures persist for several seconds before going away.
The failure case I focused on is:
* A particular type C to HDMI adapter.
* One orientation (flip mode) of that adapter.
* Easier to see failures when something is plugged into the _other
type C port at the same time.
* Problems reproduce on both type C ports (left and right side).
Ironically problems also stop reproducing when I solder wires onto the
AUX CH signals on a port (even if no scope is connected to the
signals). In this case, problems only stop reproducing on the port
with the wires connected.
From the above it appears that something about the signaling on the
aux channel is marginal and any slight differences can bring us over
the edge to failure.
It turns out that we can fix our problems by just increasing the
voltage swing of the AUX CH, giving us a bunch of extra margin. In DP
up to version 1.2 the voltage swing on the aux channel was specced as
.29 V to 1.38 V. In DP version 1.3 the aux channel voltage was
tightened to be between .29 V and .40 V, but it clarifies that it
really only needs the lower voltage when operating at the highest
speed (HBR3 mode). So right now we are trying to use a voltage that
technically should be valid for all versions of the spec (including
version 1.3 when transmitting at HBR3). That would be great to do if
it worked reliably. ...but it doesn't seem to.
It turns out that if you continue to read through the DP part of the
rk3399 TRM and other parts of the type C PHY spec you'll find out that
while the rk3399 does support DP 1.3, it doesn't support HBR3. The
docs specifically say "RBR, HBR and HBR2 data rates only". Thus there
is actually no requirement to support an AUX CH swing of .4 V.
Even if there is no actual requirement to support the tighter voltage
swing, one could possibly argue that we should support it anyway. The
DP spec clarifies that the lower voltage on the AUX CH will reduce
cross talk in some cases and that seems like it could be beneficial
even at the lower bit rates. At the moment, though, we are seeing
problems with the AUX CH and not on the other lines. Also, checking
another known working and similar laptop shows that the other laptop
runs the AUX channel at a higher voltage.
Other notes:
* Looking at measurements done on the AUX CH we weren't actually
compliant with the DP 1.3 spec anyway. AUX CH peek-to-peek voltage
was measured on rk3399-gru-kevin as .466 V which is > .4 V.
* With this new patch the AUX channel isn't actually 1.0 V, but it has
been confirmed that the signal is better and has more margin. Eye
diagram passes.
* If someone were truly an expert in the Type C PHY and in DisplayPort
signaling they might be able to make things work and keep the
voltage at < .4 V. The Type C PHY seems to have a plethora of
tuning knobs that could almost certainly improve the signal
integrity. Some of these things (like enabling tx_fcm_full_margin)
even seem to fix my problems. However, lacking expertise I can't
say whether this is a better or worse solution. Tightening signals
to give cleaner waveforms can often have adverse affects, like
increasing EMI or adding noise to other signals. I'd rather not
tune things like this without a healthy application of expertise
that I don't have.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
On some DP monitors we found that setting the wrong flip state on the
AUX channel could cause the monitor to stop asserting HotPlug Detect
(HPD). Setting the right flip state caused these monitors to start
asserting HotPlug Detect again.
Here's what we believe was happening:
* We'd plug in the monitor and we'd see HPD assert
* We'd quickly see HPD deassert
* The kernel would try to init the type C PHY but would init it in USB
mode (because there was a peripheral there but no HPD)
* Because the kernel never set the flip mode properly we'd never see
the HPD come back.
With this change, we'll still see HPD disappear (we don't think
there's anything we can do about that), but then it will come back.
Overall we can say that it's sane to set the AUX channel flip state
even when HPD is not asserted.
NOTE: to make this change possible, I needed to do a bit of cleanup to
the tcphy_dp_aux_calibration() function so that it doesn't ever
clobber the FLIP state. This made it very obvious that a line of code
documented as "setting bit 12" also did a bunch of other magic,
undocumented stuff. For now I'll just break out the bits and add a
comment that this is black magic and we'll try to document
tcphy_dp_aux_calibration() better in a future CL.
ALSO NOTE: the old function used to write a bunch of hardcoded
values in _some_ cases instead of doing a read-modify-write. One
could possibly assert that these could have had (beneficial) side
effects and thus with this new code (which always does
read-modify-write) we could have a bug. We shouldn't need to worry,
though, since in the old code tcphy_dp_aux_calibration() was always
called following the de-assertion of "reset" the the type C PHY.
...so the type C PHY was always in default state. TX_ANA_CTRL_REG_1
is documented to be 0x0 after reset. This was also confirmed by
printk.
Suggested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
devm_ioremap_resource() never returns NULL, it only returns error
pointers so this test needs to be changed.
Fixes: d0438bd6aa ("phy: add the mvebu cp110 comphy driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The pipe selector is used to select some modes (such as USB or PCIe).
Otherwise it must be set to 0 (or "unconnected"). This patch does this
to ensure it is not set to an incompatible value when using the
supported modes (SGMII, 10GKR).
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The mux value is retrieved from the mvebu_comphy_get_mux() function
which returns an int. In mvebu_comphy_power_on() this int is stored to a
u32 and a check is made to ensure it's not negative. Which is wrong.
This fixes it.
Fixes: d0438bd6aa ("phy: add the mvebu cp110 comphy driver")
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Chip bank of version-1 is initialized as NULL, but it's used
by pcie_phy_instance_power_on/off(), so assign it a right
address.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
kasprintf() can fail and it's return value must be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
