<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers, branch v5.1.1</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.1.1</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.1.1'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-05-11T05:49:56Z</updated>
<entry>
<title>i3c: Fix a shift wrap bug in i3c_bus_set_addr_slot_status()</title>
<updated>2019-05-11T05:49:56Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2019-04-23T10:40:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3ae39e99e5395bee9dfa6796c2e2f125d96d0096'/>
<id>urn:sha1:3ae39e99e5395bee9dfa6796c2e2f125d96d0096</id>
<content type='text'>
commit 476c7e1d34f2a03b1aa5a924c50703053fe5f77c upstream.

The problem here is that addr can be I3C_BROADCAST_ADDR (126).  That
means we're shifting by (126 * 2) % 64 which is 60.  The
I3C_ADDR_SLOT_STATUS_MASK is an enum which is an unsigned int in GCC
so shifts greater than 31 are undefined.

Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@collabora.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>UAS: fix alignment of scatter/gather segments</title>
<updated>2019-05-11T05:49:56Z</updated>
<author>
<name>Oliver Neukum</name>
<email>oneukum@suse.com</email>
</author>
<published>2019-04-30T10:21:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7fc35c756bc845a740abda5b36f17357f251b279'/>
<id>urn:sha1:7fc35c756bc845a740abda5b36f17357f251b279</id>
<content type='text'>
commit 3ae62a42090f1ed48e2313ed256a1182a85fb575 upstream.

This is the UAS version of

747668dbc061b3e62bc1982767a3a1f9815fcf0e
usb-storage: Set virt_boundary_mask to avoid SG overflows

We are not as likely to be vulnerable as storage, as it is unlikelier
that UAS is run over a controller without native support for SG,
but the issue exists.
The issue has been existing since the inception of the driver.

Fixes: 115bb1ffa54c ("USB: Add UAS driver")
Signed-off-by: Oliver Neukum &lt;oneukum@suse.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Fix empty regulator supplies for Intel Macs</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wens@csie.org</email>
</author>
<published>2019-04-01T03:43:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d00686df16844a12910fae00dbc79b228e50cce7'/>
<id>urn:sha1:d00686df16844a12910fae00dbc79b228e50cce7</id>
<content type='text'>
commit 62611abc8f37d00e3b0cff0eb2d72fa92b05fd27 upstream.

The code path for Macs goes through bcm_apple_get_resources(), which
skips over the code that sets up the regulator supplies. As a result,
the call to regulator_bulk_enable() / regulator_bulk_disable() results
in a NULL pointer dereference.

This was reported on the kernel.org Bugzilla, bug 202963.

Unbreak Broadcom Bluetooth support on Intel Macs by checking if the
supplies were set up before enabling or disabling them.

The same does not need to be done for the clocks, as the common clock
framework API checks for NULL pointers.

Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies")
Cc: &lt;stable@vger.kernel.org&gt; # 5.0.x
Signed-off-by: Chen-Yu Tsai &lt;wens@csie.org&gt;
Tested-by: Imre Kaloz &lt;kaloz@openwrt.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix device staying in blocked state</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Quinn Tran</name>
<email>qtran@marvell.com</email>
</author>
<published>2019-04-23T21:52:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=435885bdb0d8ba3edd414a807343f7ae4167513b'/>
<id>urn:sha1:435885bdb0d8ba3edd414a807343f7ae4167513b</id>
<content type='text'>
commit 2137490f2147a8d0799b72b9a1023efb012d40c7 upstream.

This patch fixes issue reported by some of the customers, who discovered
that after cable pull scenario the devices disappear and path seems to
remain in blocked state. Once the device reappears, driver does not seem to
update path to online. This issue appears because of the defer flag
creating race condition where the same session reappears.  This patch fixes
this issue by indicating SCSI-ML of device lost when
qlt_free_session_done() is called from qlt_unreg_sess().

Fixes: 41dc529a4602a ("qla2xxx: Improve RSCN handling in driver")
Signed-off-by: Quinn Tran &lt;qtran@marvell.com&gt;
Cc: stable@vger.kernel.org #4.19
Signed-off-by: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: qla2xxx: Set remote port devloss timeout to 0</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Giridhar Malavali</name>
<email>gmalavali@marvell.com</email>
</author>
<published>2019-04-02T21:24:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=63ec822488c994221510a8084038b9ef60b845c0'/>
<id>urn:sha1:63ec822488c994221510a8084038b9ef60b845c0</id>
<content type='text'>
commit ffc81fc07efc94a04695a8c1d458a06aecaf9f30 upstream.

This patch sets remote_port_devloss value to 0. This indicates to FC-NVMe
transport that driver is unloading and transport should not retry.

Fixes: e476fe8af5ff ("scsi: qla2xxx: Fix unload when NVMe devices are configured")
Cc: stable@vger.kernel.org
Signed-off-by: Giridhar Malavali &lt;gmalavali@marvell.com&gt;
Signed-off-by: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix incorrect region-size setting in optrom SYSFS routines</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Andrew Vasquez</name>
<email>andrewv@marvell.com</email>
</author>
<published>2019-04-02T21:24:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7065a70d695b031d70e629adbb07237de94eca31'/>
<id>urn:sha1:7065a70d695b031d70e629adbb07237de94eca31</id>
<content type='text'>
commit 5cbdae10bf11f96e30b4d14de7b08c8b490e903c upstream.

Commit e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs
code") incorrectly set 'optrom_region_size' to 'start+size', which can
overflow option-rom boundaries when 'start' is non-zero.  Continue setting
optrom_region_size to the proper adjusted value of 'size'.

Fixes: e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code")
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Vasquez &lt;andrewv@marvell.com&gt;
Signed-off-by: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: lpfc: change snprintf to scnprintf for possible overflow</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Silvio Cesare</name>
<email>silvio.cesare@gmail.com</email>
</author>
<published>2019-03-21T16:44:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1119e98d0eb093f2ac8c230ef31afeb3be522520'/>
<id>urn:sha1:1119e98d0eb093f2ac8c230ef31afeb3be522520</id>
<content type='text'>
commit e7f7b6f38a44697428f5a2e7c606de028df2b0e3 upstream.

Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.

1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up larger than SIZE. In later
uses of snprintf, SIZE - size will result in a negative number, leading
to problems. Note that size might already be too large by using
size = snprintf before the code reaches a case of size += snprintf.

2) If size is ultimately used as a length parameter for a copy back to user
space, then it will potentially allow for a buffer overflow and information
disclosure when size is greater than SIZE. When the size is used to index
the buffer directly, we can have memory corruption. This also means when
size = snprintf... is used, it may also cause problems since size may become
large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
configuration.

The solution to these issues is to use scnprintf which returns the number of
characters actually written to the buffer, so the size variable will never
exceed SIZE.

Signed-off-by: Silvio Cesare &lt;silvio.cesare@gmail.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: James Smart &lt;james.smart@broadcom.com&gt;
Cc: Dick Kennedy &lt;dick.kennedy@broadcom.com&gt;
Cc: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Greg KH &lt;greg@kroah.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>soc: sunxi: Fix missing dependency on REGMAP_MMIO</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Samuel Holland</name>
<email>samuel@sholland.org</email>
</author>
<published>2019-04-30T14:59:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4fb84183e04792c3abc3205336a56b374d6a515d'/>
<id>urn:sha1:4fb84183e04792c3abc3205336a56b374d6a515d</id>
<content type='text'>
commit a84014e1db35d8e7af09878d0b4bf30804fb17d5 upstream.

When enabling ARCH_SUNXI from allnoconfig, SUNXI_SRAM is enabled, but
not REGMAP_MMIO, so the kernel fails to link with an undefined reference
to __devm_regmap_init_mmio_clk. Select REGMAP_MMIO, as suggested in
drivers/base/regmap/Kconfig.

This creates the following dependency loop:

  drivers/of/Kconfig:68:                symbol OF_IRQ depends on IRQ_DOMAIN
  kernel/irq/Kconfig:63:                symbol IRQ_DOMAIN is selected by REGMAP
  drivers/base/regmap/Kconfig:7:        symbol REGMAP default is visible depending on REGMAP_MMIO
  drivers/base/regmap/Kconfig:39:       symbol REGMAP_MMIO is selected by SUNXI_SRAM
  drivers/soc/sunxi/Kconfig:4:          symbol SUNXI_SRAM is selected by USB_MUSB_SUNXI
  drivers/usb/musb/Kconfig:63:          symbol USB_MUSB_SUNXI depends on GENERIC_PHY
  drivers/phy/Kconfig:7:                symbol GENERIC_PHY is selected by PHY_BCM_NS_USB3
  drivers/phy/broadcom/Kconfig:29:      symbol PHY_BCM_NS_USB3 depends on MDIO_BUS
  drivers/net/phy/Kconfig:12:           symbol MDIO_BUS default is visible depending on PHYLIB
  drivers/net/phy/Kconfig:181:          symbol PHYLIB is selected by ARC_EMAC_CORE
  drivers/net/ethernet/arc/Kconfig:18:  symbol ARC_EMAC_CORE is selected by ARC_EMAC
  drivers/net/ethernet/arc/Kconfig:24:  symbol ARC_EMAC depends on OF_IRQ

To fix the circular dependency, make USB_MUSB_SUNXI select GENERIC_PHY
instead of depending on it. This matches the use of GENERIC_PHY by all
but two other drivers.

Cc: &lt;stable@vger.kernel.org&gt; # 4.19
Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64")
Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Acked-by: Maxime Ripard &lt;maxime.ripard@bootlin.com&gt;
Signed-off-by: Bin Liu &lt;b-liu@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPI / LPSS: Use acpi_lpss_* instead of acpi_subsys_* functions for hibernate</title>
<updated>2019-05-11T05:49:55Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2019-04-18T11:39:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cebdbdda4850e4ce844c2c2d03d838a43abbd63a'/>
<id>urn:sha1:cebdbdda4850e4ce844c2c2d03d838a43abbd63a</id>
<content type='text'>
commit c8afd03486c26accdda4846e5561aa3f8e862a9d upstream.

Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set.

This means that on resume from hibernate dw_i2c_plat_resume() doesn't get
called by the restore_early callback, acpi_lpss_resume_early(). Instead it
should be called by the restore_noirq callback matching how things are done
when resume_from_noirq is set and we are doing a regular resume.

Change the restore_noirq callback to acpi_lpss_resume_noirq so that
dw_i2c_plat_resume() gets properly called when resume_from_noirq is set
and we are resuming from hibernate.

Likewise also change the poweroff_noirq callback so that
dw_i2c_plat_suspend gets called properly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139
Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq")
Reported-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Cc: 4.20+ &lt;stable@vger.kernel.org&gt; # 4.20+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cpufreq: armada-37xx: fix frequency calculation for opp</title>
<updated>2019-05-11T05:49:54Z</updated>
<author>
<name>Gregory CLEMENT</name>
<email>gregory.clement@bootlin.com</email>
</author>
<published>2019-03-08T16:47:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f6ad5c7d15ea2203e2f69a0a3e264428c2a23825'/>
<id>urn:sha1:f6ad5c7d15ea2203e2f69a0a3e264428c2a23825</id>
<content type='text'>
commit 8db82563451f976597ab7b282ec655e4390a4088 upstream.

The frequency calculation was based on the current(max) frequency of the
CPU. However for low frequency, the value used was already the parent
frequency divided by a factor of 2.

Instead of using this frequency, this fix directly get the frequency from
the parent clock.

Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Christian Neubert &lt;christian.neubert.86@gmail.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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