<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.9.254</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.254</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.254'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-01-30T12:27:16+00:00</updated>
<entry>
<title>net: dsa: b53: fix an off by one in checking "vlan-&gt;vid"</title>
<updated>2021-01-30T12:27:16+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-01-19T14:48:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=24c1a3d010531ebaa08f8da46f3506829d29ae9a'/>
<id>urn:sha1:24c1a3d010531ebaa08f8da46f3506829d29ae9a</id>
<content type='text'>
commit 8e4052c32d6b4b39c1e13c652c7e33748d447409 upstream.

The &gt; comparison should be &gt;= to prevent accessing one element beyond
the end of the dev-&gt;vlans[] array in the caller function, b53_vlan_add().
The "dev-&gt;vlans" array is allocated in the b53_switch_init() function
and it has "dev-&gt;num_vlans" elements.

Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sh_eth: Fix power down vs. is_opened flag ordering</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2021-01-18T15:08:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b134423811ec5f9ce4ca062b66a88f152b66790'/>
<id>urn:sha1:2b134423811ec5f9ce4ca062b66a88f152b66790</id>
<content type='text'>
commit f6a2e94b3f9d89cb40771ff746b16b5687650cbb upstream.

sh_eth_close() does a synchronous power down of the device before
marking it closed.  Revert the order, to make sure the device is never
marked opened while suspended.

While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as
there is no reason to do a synchronous power down.

Fixes: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Sergei Shtylyov &lt;sergei.shtylyov@gmail.com&gt;
Reviewed-by: Niklas Söderlund &lt;niklas.soderlund+renesas@ragnatech.se&gt;
Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+renesas@glider.be
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: tegra: Delay for disabling LFPS detector</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>JC Kuo</name>
<email>jckuo@nvidia.com</email>
</author>
<published>2021-01-15T16:19:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20089f3284b27eb24362725778264e4148c61f8c'/>
<id>urn:sha1:20089f3284b27eb24362725778264e4148c61f8c</id>
<content type='text'>
commit da7e0c3c2909a3d9bf8acfe1db3cb213bd7febfb upstream.

Occasionally, we are seeing some SuperSpeed devices resumes right after
being directed to U3. This commits add 500us delay to ensure LFPS
detector is disabled before sending ACK to firmware.

[   16.099363] tegra-xusb 70090000.usb: entering ELPG
[   16.104343] tegra-xusb 70090000.usb: 2-1 isn't suspended: 0x0c001203
[   16.114576] tegra-xusb 70090000.usb: not all ports suspended: -16
[   16.120789] tegra-xusb 70090000.usb: entering ELPG failed

The register write passes through a few flop stages of 32KHz clock domain.
NVIDIA ASIC designer reviewed RTL and suggests 500us delay.

Cc: stable@vger.kernel.org
Signed-off-by: JC Kuo &lt;jckuo@nvidia.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20210115161907.2875631-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: make sure TRB is fully written before giving it to the controller</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2021-01-15T16:19:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23ce98a5af66a7f9631bd0b66f245a8fbb39f218'/>
<id>urn:sha1:23ce98a5af66a7f9631bd0b66f245a8fbb39f218</id>
<content type='text'>
commit 576667bad341516edc4e18eb85acb0a2b4c9c9d9 upstream.

Once the command ring doorbell is rung the xHC controller will parse all
command TRBs on the command ring that have the cycle bit set properly.

If the driver just started writing the next command TRB to the ring when
hardware finished the previous TRB, then HW might fetch an incomplete TRB
as long as its cycle bit set correctly.

A command TRB is 16 bytes (128 bits) long.
Driver writes the command TRB in four 32 bit chunks, with the chunk
containing the cycle bit last. This does however not guarantee that
chunks actually get written in that order.

This was detected in stress testing when canceling URBs with several
connected USB devices.
Two consecutive "Set TR Dequeue pointer" commands got queued right
after each other, and the second one was only partially written when
the controller parsed it, causing the dequeue pointer to be set
to bogus values. This was seen as error messages:

"Mismatch between completed Set TR Deq Ptr command &amp; xHCI internal state"

Solution is to add a write memory barrier before writing the cycle bit.

Cc: &lt;stable@vger.kernel.org&gt;
Tested-by: Ross Zwisler &lt;zwisler@google.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20210115161907.2875631-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: bdc: Make bdc pci driver depend on BROKEN</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>Patrik Jakobsson</name>
<email>patrik.r.jakobsson@gmail.com</email>
</author>
<published>2021-01-18T20:36:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54e278d8cd5c47999acc0833bd3429dc6f6c7972'/>
<id>urn:sha1:54e278d8cd5c47999acc0833bd3429dc6f6c7972</id>
<content type='text'>
commit ef02684c4e67d8c35ac83083564135bc7b1d3445 upstream.

The bdc pci driver is going to be removed due to it not existing in the
wild. This patch turns off compilation of the driver so that stable
kernels can also pick up the change. This helps the out-of-tree
facetimehd webcam driver as the pci id conflicts with bdc.

Cc: Al Cooper &lt;alcooperx@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Felipe Balbi &lt;balbi@kernel.org&gt;
Signed-off-by: Patrik Jakobsson &lt;patrik.r.jakobsson@gmail.com&gt;
Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: udc: core: Use lock when write to soft_connect</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>Thinh Nguyen</name>
<email>Thinh.Nguyen@synopsys.com</email>
</author>
<published>2021-01-14T08:09:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2434d1a38d37f016c8f77dbb01cad0c8d6c305a6'/>
<id>urn:sha1:2434d1a38d37f016c8f77dbb01cad0c8d6c305a6</id>
<content type='text'>
commit c28095bc99073ddda65e4f31f6ae0d908d4d5cd8 upstream.

Use lock to guard against concurrent access for soft-connect/disconnect
operations when writing to soft_connect sysfs.

Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class")
Cc: stable@vger.kernel.org
Acked-by: Felipe Balbi &lt;balbi@kernel.org&gt;
Signed-off-by: Thinh Nguyen &lt;Thinh.Nguyen@synopsys.com&gt;
Link: https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: ehci: fix an interrupt calltrace error</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>Longfang Liu</name>
<email>liulongfang@huawei.com</email>
</author>
<published>2021-01-12T01:57:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cfbce79c6dce21f0d21ab6c4112849199bb54e46'/>
<id>urn:sha1:cfbce79c6dce21f0d21ab6c4112849199bb54e46</id>
<content type='text'>
commit 643a4df7fe3f6831d14536fd692be85f92670a52 upstream.

The system that use Synopsys USB host controllers goes to suspend
when using USB audio player. This causes the USB host controller
continuous send interrupt signal to system, When the number of
interrupts exceeds 100000, the system will forcibly close the
interrupts and output a calltrace error.

When the system goes to suspend, the last interrupt is reported to
the driver. At this time, the system has set the state to suspend.
This causes the last interrupt to not be processed by the system and
not clear the interrupt flag. This uncleared interrupt flag constantly
triggers new interrupt event. This causing the driver to receive more
than 100,000 interrupts, which causes the system to forcibly close the
interrupt report and report the calltrace error.

so, when the driver goes to sleep and changes the system state to
suspend, the interrupt flag needs to be cleared.

Signed-off-by: Longfang Liu &lt;liulongfang@huawei.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongfang@huawei.com
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ehci: fix EHCI host controller initialization sequence</title>
<updated>2021-01-30T12:27:15+00:00</updated>
<author>
<name>Eugene Korenevsky</name>
<email>ekorenevsky@astralinux.ru</email>
</author>
<published>2021-01-10T17:36:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e418332942a2a4fa25f11578d92a19db103f7b33'/>
<id>urn:sha1:e418332942a2a4fa25f11578d92a19db103f7b33</id>
<content type='text'>
commit 280a9045bb18833db921b316a5527d2b565e9f2e upstream.

According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever
USBCMD.RS=1.

However, it is a good practice to wait some time after setting USBCMD.RS
(approximately 100ms) until USBSTS.HCHalted become zero.

Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs
(see BugLink).

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Eugene Korenevsky &lt;ekorenevsky@astralinux.ru&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20210110173609.GA17313@himera.home
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>stm class: Fix module init return on allocation failure</title>
<updated>2021-01-30T12:27:14+00:00</updated>
<author>
<name>Wang Hui</name>
<email>john.wanghui@huawei.com</email>
</author>
<published>2021-01-15T19:59:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=186a03e3bdd7bb0269afc37a6298ebfa8782a639'/>
<id>urn:sha1:186a03e3bdd7bb0269afc37a6298ebfa8782a639</id>
<content type='text'>
commit 927633a6d20af319d986f3e42c3ef9f6d7835008 upstream.

In stm_heartbeat_init(): return value gets reset after the first
iteration by stm_source_register_device(), so allocation failures
after that will, after a clean up, return success. Fix that.

Fixes: 119291853038 ("stm class: Add heartbeat stm source device")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wang Hui &lt;john.wanghui@huawei.com&gt;
Signed-off-by: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20210115195917.3184-2-alexander.shishkin@linux.intel.com
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: ad5504: Fix setting power-down state</title>
<updated>2021-01-30T12:27:14+00:00</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2020-12-09T10:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=97f337118d0e2d4621abe4114c549fdd3c28fe7b'/>
<id>urn:sha1:97f337118d0e2d4621abe4114c549fdd3c28fe7b</id>
<content type='text'>
commit efd597b2839a9895e8a98fcb0b76d2f545802cd4 upstream.

The power-down mask of the ad5504 is actually a power-up mask. Meaning if
a bit is set the corresponding channel is powered up and if it is not set
the channel is powered down.

The driver currently has this the wrong way around, resulting in the
channel being powered up when requested to be powered down and vice versa.

Fixes: 3bbbf150ffde ("staging:iio:dac:ad5504: Use strtobool for boolean values")
Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Acked-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Link: https://lore.kernel.org/r/20201209104649.5794-1-lars@metafoo.de
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
