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>
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.
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>
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>
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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZsr8cAAoJEFmIoMA60/r8lXYQAKViYIRMJDD4n3NhjMeLOsnJ
vwaBmWlLRjSFIEpag5kMjS1RJE17qAvmkBZnDvSNZ6cT28INkkZnVM2IW96WECVq
64MIvDijVPcvqGuWePCfWdDiSXApiDWwJuw55BOhmvV996wGy0gYgzpPY+1g0Knh
XzH9IOzDL79hZleLfsxX0MLV6FGBVtOsr0jvQ04k4IgEMIxEDTlbw85rnrvzQUtc
0Vj2koaxWIESZsq7G/wiZb2n6ekaFdXO/VlVvvhmTSDLCBaJ63Hb/gfOhwMuVkS6
B3cVprNrCT0dSzWmU4ZXf+wpOyDpBexlemW/OR/6CQUkC6AUS6kQ5si1X44dbGmJ
nBPh414tdlm/6V4h/A3UFPOajSGa/ZWZ/uQZPfvKs1R6WfjUerWVBfUpAzPbgjam
c/mhJ19HYT1J7vFBfhekBMeY2Px3JgSJ9rNsrFl48ynAALaX5GEwdpo4aqBfscKz
4/f9fU4ysumopvCEuKD2SsJvsPKd5gMQGGtvAhXM1TxvAoQ5V4cc99qEetAPXXPf
h2EqWm4ph7YP4a+n/OZBjzluHCmZJn1CntH5+//6wpUk6HnmzsftGELuO9n12cLE
GGkreI3T9ctV1eOkzVVa0l0QTE1X/VLyEyKCtb9obXsDaG4Ud7uKQoZgB19DwyTJ
EG76ridTolUFVV+wzJD9
=9cLP
-----END PGP SIGNATURE-----
Merge tag 'pci-v4.14-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas:
- add enhanced Downstream Port Containment support, which prints more
details about Root Port Programmed I/O errors (Dongdong Liu)
- add Layerscape ls1088a and ls2088a support (Hou Zhiqiang)
- add MediaTek MT2712 and MT7622 support (Ryder Lee)
- add MediaTek MT2712 and MT7622 MSI support (Honghui Zhang)
- add Qualcom IPQ8074 support (Varadarajan Narayanan)
- add R-Car r8a7743/5 device tree support (Biju Das)
- add Rockchip per-lane PHY support for better power management (Shawn
Lin)
- fix IRQ mapping for hot-added devices by replacing the
pci_fixup_irqs() boot-time design with a host bridge hook called at
probe-time (Lorenzo Pieralisi, Matthew Minter)
- fix race when enabling two devices that results in upstream bridge
not being enabled correctly (Srinath Mannam)
- fix pciehp power fault infinite loop (Keith Busch)
- fix SHPC bridge MSI hotplug events by enabling bus mastering
(Aleksandr Bezzubikov)
- fix a VFIO issue by correcting PCIe capability sizes (Alex
Williamson)
- fix an INTD issue on Xilinx and possibly other drivers by unifying
INTx IRQ domain support (Paul Burton)
- avoid IOMMU stalls by marking AMD Stoney GPU ATS as broken (Joerg
Roedel)
- allow APM X-Gene device assignment to guests by adding an ACS quirk
(Feng Kan)
- fix driver crashes by disabling Extended Tags on Broadcom HT2100
(Extended Tags support is required for PCIe Receivers but not
Requesters, and we now enable them by default when Requesters support
them) (Sinan Kaya)
- fix MSIs for devices that use phantom RIDs for DMA by assuming MSIs
use the real Requester ID (not a phantom RID) (Robin Murphy)
- prevent assignment of Intel VMD children to guests (which may be
supported eventually, but isn't yet) by not associating an IOMMU with
them (Jon Derrick)
- fix Intel VMD suspend/resume by releasing IRQs on suspend (Scott
Bauer)
- fix a Function-Level Reset issue with Intel 750 NVMe by waiting
longer (up to 60sec instead of 1sec) for device to become ready
(Sinan Kaya)
- fix a Function-Level Reset issue on iProc Stingray by working around
hardware defects in the CRS implementation (Oza Pawandeep)
- fix an issue with Intel NVMe P3700 after an iProc reset by adding a
delay during shutdown (Oza Pawandeep)
- fix a Microsoft Hyper-V lockdep issue by polling instead of blocking
in compose_msi_msg() (Stephen Hemminger)
- fix a wireless LAN driver timeout by clearing DesignWare MSI
interrupt status after it is handled, not before (Faiz Abbas)
- fix DesignWare ATU enable checking (Jisheng Zhang)
- reduce Layerscape dependencies on the bootloader by doing more
initialization in the driver (Hou Zhiqiang)
- improve Intel VMD performance allowing allocation of more IRQ vectors
than present CPUs (Keith Busch)
- improve endpoint framework support for initial DMA mask, different
BAR sizes, configurable page sizes, MSI, test driver, etc (Kishon
Vijay Abraham I, Stan Drozd)
- rework CRS support to add periodic messages while we poll during
enumeration and after Function-Level Reset and prepare for possible
other uses of CRS (Sinan Kaya)
- clean up Root Port AER handling by removing unnecessary code and
moving error handler methods to struct pcie_port_service_driver
(Christoph Hellwig)
- clean up error handling paths in various drivers (Bjorn Andersson,
Fabio Estevam, Gustavo A. R. Silva, Harunobu Kurokawa, Jeffy Chen,
Lorenzo Pieralisi, Sergei Shtylyov)
- clean up SR-IOV resource handling by disabling VF decoding before
updating the corresponding resource structs (Gavin Shan)
- clean up DesignWare-based drivers by unifying quirks to update Class
Code and Interrupt Pin and related handling of write-protected
registers (Hou Zhiqiang)
- clean up by adding empty generic pcibios_align_resource() and
pcibios_fixup_bus() and removing empty arch-specific implementations
(Palmer Dabbelt)
- request exclusive reset control for several drivers to allow cleanup
elsewhere (Philipp Zabel)
- constify various structures (Arvind Yadav, Bhumika Goyal)
- convert from full_name() to %pOF (Rob Herring)
- remove unused variables from iProc, HiSi, Altera, Keystone (Shawn
Lin)
* tag 'pci-v4.14-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (170 commits)
PCI: xgene: Clean up whitespace
PCI: xgene: Define XGENE_PCI_EXP_CAP and use generic PCI_EXP_RTCTL offset
PCI: xgene: Fix platform_get_irq() error handling
PCI: xilinx-nwl: Fix platform_get_irq() error handling
PCI: rockchip: Fix platform_get_irq() error handling
PCI: altera: Fix platform_get_irq() error handling
PCI: spear13xx: Fix platform_get_irq() error handling
PCI: artpec6: Fix platform_get_irq() error handling
PCI: armada8k: Fix platform_get_irq() error handling
PCI: dra7xx: Fix platform_get_irq() error handling
PCI: exynos: Fix platform_get_irq() error handling
PCI: iproc: Clean up whitespace
PCI: iproc: Rename PCI_EXP_CAP to IPROC_PCI_EXP_CAP
PCI: iproc: Add 500ms delay during device shutdown
PCI: Fix typos and whitespace errors
PCI: Remove unused "res" variable from pci_resource_io()
PCI: Correct kernel-doc of pci_vpd_srdt_size(), pci_vpd_srdt_tag()
PCI/AER: Reformat AER register definitions
iommu/vt-d: Prevent VMD child devices from being remapping targets
x86/PCI: Use is_vmd() rather than relying on the domain number
...
Here is the big char/misc driver update for 4.14-rc1.
Lots of different stuff in here, it's been an active development cycle
for some reason. Highlights are:
- updated binder driver, this brings binder up to date with what
shipped in the Android O release, plus some more changes that
happened since then that are in the Android development trees.
- coresight updates and fixes
- mux driver file renames to be a bit "nicer"
- intel_th driver updates
- normal set of hyper-v updates and changes
- small fpga subsystem and driver updates
- lots of const code changes all over the driver trees
- extcon driver updates
- fmc driver subsystem upadates
- w1 subsystem minor reworks and new features and drivers added
- spmi driver updates
Plus a smattering of other minor driver updates and fixes.
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-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWa1+Ew8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yl26wCgquufNylfhxr65NbJrovduJYzRnUAniCivXg8
bePIh/JI5WxWoHK+wEbY
=hYWx
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big char/misc driver update for 4.14-rc1.
Lots of different stuff in here, it's been an active development cycle
for some reason. Highlights are:
- updated binder driver, this brings binder up to date with what
shipped in the Android O release, plus some more changes that
happened since then that are in the Android development trees.
- coresight updates and fixes
- mux driver file renames to be a bit "nicer"
- intel_th driver updates
- normal set of hyper-v updates and changes
- small fpga subsystem and driver updates
- lots of const code changes all over the driver trees
- extcon driver updates
- fmc driver subsystem upadates
- w1 subsystem minor reworks and new features and drivers added
- spmi driver updates
Plus a smattering of other minor driver updates and fixes.
All of these have been in linux-next with no reported issues for a
while"
* tag 'char-misc-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (244 commits)
ANDROID: binder: don't queue async transactions to thread.
ANDROID: binder: don't enqueue death notifications to thread todo.
ANDROID: binder: Don't BUG_ON(!spin_is_locked()).
ANDROID: binder: Add BINDER_GET_NODE_DEBUG_INFO ioctl
ANDROID: binder: push new transactions to waiting threads.
ANDROID: binder: remove proc waitqueue
android: binder: Add page usage in binder stats
android: binder: fixup crash introduced by moving buffer hdr
drivers: w1: add hwmon temp support for w1_therm
drivers: w1: refactor w1_slave_show to make the temp reading functionality separate
drivers: w1: add hwmon support structures
eeprom: idt_89hpesx: Support both ACPI and OF probing
mcb: Fix an error handling path in 'chameleon_parse_cells()'
MCB: add support for SC31 to mcb-lpc
mux: make device_type const
char: virtio: constify attribute_group structures.
Documentation/ABI: document the nvmem sysfs files
lkdtm: fix spelling mistake: "incremeted" -> "incremented"
perf: cs-etm: Fix ETMv4 CONFIGR entry in perf.data file
nvmem: include linux/err.h from header
...
Reconstruct the whole driver to support per-lane PHYs. Note that we could
also support the legacy PHY if you don't provide argument to
rockchip_pcie_phy_of_xlate().
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
[bhelgaas: use postincrement/decrement when order doesn't matter, uninline
to_pcie_phy() so decl fits on one line]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
In order to silent the 'W=1' compile warning:
drivers/phy/rockchip/phy-rockchip-typec.c: In function 'tcphy_get_mode':
drivers/phy/rockchip/phy-rockchip-typec.c:625:7: warning: variable 'dfp'
set but not used [-Wunused-but-set-variable]
Cc: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This adds support usb2-phy for rv1108 SoCs and amend phy Documentation.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The otg-id/otg-bvalid/linestate interrupts are multiplexed together
in otg-port on some Rockchip SoC (e.g RV1108), this patch add support
for it.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The registers of usb-phy are distributed in grf and usbgrf on some
Rockchip SoCs (e.g RV1108), this patch add a new rockchip,usbgrf
property to support this companion grf design.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
- extcon_set_cable_state_() -> extcon_set_state_sync()
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
This adds support usb2-phy for rk3228 SoCs and amend phy Documentation.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
At the current rockchip-inno-usb2 phy driver framework, it can
only support usb2-phy which comprises with one otg-port and one
host-port.
However, some Rockchip SoCs' (e.g RK3228, RK3229) usb2-phy comprises
with two host-ports, so we use index of otg id for one host-port
configuration, and make it work the same as otg-port host mode.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
In rockchip-inno-usb2 phy driver, we use otg_sm_work to
dynamically manage power consumption for phy otg-port.
If the otg-port works as peripheral mode and does not
communicate with usb host, we will suspend phy.
But once suspend phy, the phy no longer has any internal
clock running, include the utmi_clk which supplied for
usb controller. So if we suspend phy before usb controller
init, it will cause usb controller fail to initialize.
Specifically, without this patch, the observed order is:
1. unplug usb cable
2. start system, do dwc2 controller probe
3. dwc2_lowlevel_hw_enable()
- phy_init()
- rockchip_usb2phy_init()
- schedule otg_sm_work after 2s
put phy in suspend, and close utmi_clk
4. dwc2_hsotg_udc_start() - fail to initialize the usb core
Generally, dwc2_hsotg_udc_start() can be called within 5s
after start system on Rockchip platform, so we increase the
the first schedule delay time to 6s for otg_sm_work afer usb
controller calls phy_init(), this can make sure that the usb
controller completes initialization before phy enter suspend.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
When resume phy, it need about 1.5 ~ 2ms to wait for
utmi_clk which used for USB controller to become stable.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Chris Zhong