<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v5.8.14</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.8.14</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.8.14'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-10-07T06:02:54+00:00</updated>
<entry>
<title>scsi: sd: sd_zbc: Fix ZBC disk initialization</title>
<updated>2020-10-07T06:02:54+00:00</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@wdc.com</email>
</author>
<published>2020-09-15T07:33:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5e6bc9b1f1aef66fc4bae1a40afad33a8458e368'/>
<id>urn:sha1:5e6bc9b1f1aef66fc4bae1a40afad33a8458e368</id>
<content type='text'>
commit 6c5dee18756b4721ac8518c69b22ee8ac0c9c442 upstream.

Make sure to call sd_zbc_init_disk() when the sdkp-&gt;zoned field is known,
that is, once sd_read_block_characteristics() is executed in
sd_revalidate_disk(), so that host-aware disks also get initialized.  To do
so, move sd_zbc_init_disk() call in sd_zbc_revalidate_zones() and make sure
to execute it for all zoned disks, including for host-aware disks used as
regular disks as these disk zoned model may be changed back to BLK_ZONED_HA
when partitions are deleted.

Link: https://lore.kernel.org/r/20200915073347.832424-3-damien.lemoal@wdc.com
Fixes: 5795eb443060 ("scsi: sd_zbc: emulate ZONE_APPEND commands")
Cc: &lt;stable@vger.kernel.org&gt; # v5.8+
Reported-by: Borislav Petkov &lt;bp@alien8.de&gt;
Tested-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Johannes Thumshirn &lt;johannes.thumshirn@wdc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@wdc.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: sd: sd_zbc: Fix handling of host-aware ZBC disks</title>
<updated>2020-10-07T06:02:54+00:00</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@wdc.com</email>
</author>
<published>2020-09-15T07:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a12f67b5477199ddd483052761f1cb2998aa5eea'/>
<id>urn:sha1:a12f67b5477199ddd483052761f1cb2998aa5eea</id>
<content type='text'>
commit 27ba3e8ff3ab86449e63d38a8d623053591e65fa upstream.

When CONFIG_BLK_DEV_ZONED is disabled, allow using host-aware ZBC disks as
regular disks. In this case, ensure that command completion is correctly
executed by changing sd_zbc_complete() to return good_bytes instead of 0
and causing a hang during device probe (endless retries).

When CONFIG_BLK_DEV_ZONED is enabled and a host-aware disk is detected to
have partitions, it will be used as a regular disk. In this case, make sure
to not do anything in sd_zbc_revalidate_zones() as that triggers warnings.

Since all these different cases result in subtle settings of the disk queue
zoned model, introduce the block layer helper function
blk_queue_set_zoned() to generically implement setting up the effective
zoned model according to the disk type, the presence of partitions on the
disk and CONFIG_BLK_DEV_ZONED configuration.

Link: https://lore.kernel.org/r/20200915073347.832424-2-damien.lemoal@wdc.com
Fixes: b72053072c0b ("block: allow partitions on host aware zone devices")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Borislav Petkov &lt;bp@alien8.de&gt;
Suggested-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Johannes Thumshirn &lt;johannes.thumshirn@wdc.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@wdc.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>drm/i915/gvt: Fix port number for BDW on EDID region setup</title>
<updated>2020-10-07T06:02:54+00:00</updated>
<author>
<name>Zhenyu Wang</name>
<email>zhenyuw@linux.intel.com</email>
</author>
<published>2020-09-14T03:03:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ecd72c95c2786d4eb73786922964ec0b707f1c3e'/>
<id>urn:sha1:ecd72c95c2786d4eb73786922964ec0b707f1c3e</id>
<content type='text'>
commit 28284943ac94014767ecc2f7b3c5747c4a5617a0 upstream.

Current BDW virtual display port is initialized as PORT_B, so need
to use same port for VFIO EDID region, otherwise invalid EDID blob
pointer is assigned which caused kernel null pointer reference. We
might evaluate actual display hotplug for BDW to make this function
work as expected, anyway this is always required to be fixed first.

Reported-by: Alejandro Sior &lt;aho@sior.be&gt;
Cc: Alejandro Sior &lt;aho@sior.be&gt;
Fixes: 0178f4ce3c3b ("drm/i915/gvt: Enable vfio edid for all GVT supported platform")
Reviewed-by: Hang Yuan &lt;hang.yuan@intel.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200914030302.2775505-1-zhenyuw@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>gpiolib: Fix line event handling in syscall compatible mode</title>
<updated>2020-10-07T06:02:54+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2020-09-15T12:58:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=115b0aed8b749e9435210d5b1d23ac16fa6658ef'/>
<id>urn:sha1:115b0aed8b749e9435210d5b1d23ac16fa6658ef</id>
<content type='text'>
[ Upstream commit 5ad284ab3a01e2d6a89be2a8663ae76f4e617549 ]

The introduced line event handling ABI in the commit

  61f922db7221 ("gpio: userspace ABI for reading GPIO line events")

missed the fact that 64-bit kernel may serve for 32-bit applications.
In such case the very first check in the lineevent_read() will fail
due to alignment differences.

To workaround this introduce lineevent_get_size() helper which returns actual
size of the structure in user space.

Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Suggested-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Tested-by: Kent Gibson &lt;warthog618@gmail.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Fix the overwritten field in IVMD header</title>
<updated>2020-10-07T06:02:54+00:00</updated>
<author>
<name>Adrian Huang</name>
<email>ahuang12@lenovo.com</email>
</author>
<published>2020-09-26T10:26:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f6e5c604d67b37a88ea5393c397b061151187afe'/>
<id>urn:sha1:f6e5c604d67b37a88ea5393c397b061151187afe</id>
<content type='text'>
[ Upstream commit 0bbe4ced53e36786eafc2ecbf9a1761f55b4a82e ]

Commit 387caf0b759a ("iommu/amd: Treat per-device exclusion
ranges as r/w unity-mapped regions") accidentally overwrites
the 'flags' field in IVMD (struct ivmd_header) when the I/O
virtualization memory definition is associated with the
exclusion range entry. This leads to the corrupted IVMD table
(incorrect checksum). The kdump kernel reports the invalid checksum:

ACPI BIOS Warning (bug): Incorrect checksum in table [IVRS] - 0x5C, should be 0x60 (20200717/tbprint-177)
AMD-Vi: [Firmware Bug]: IVRS invalid checksum

Fix the above-mentioned issue by modifying the 'struct unity_map_entry'
member instead of the IVMD header.

Cleanup: The *exclusion_range* functions are not used anymore, so
get rid of them.

Fixes: 387caf0b759a ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions")
Reported-and-tested-by: Baoquan He &lt;bhe@redhat.com&gt;
Signed-off-by: Adrian Huang &lt;ahuang12@lenovo.com&gt;
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Link: https://lore.kernel.org/r/20200926102602.19177-1-adrianhuang0701@gmail.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: pca953x: Correctly initialize registers 6 and 7 for PCA957x</title>
<updated>2020-10-07T06:02:53+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2020-09-30T14:20:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7af706248ce2319292a634a94a18a0e380fc4975'/>
<id>urn:sha1:7af706248ce2319292a634a94a18a0e380fc4975</id>
<content type='text'>
[ Upstream commit 8c1f1c34777bddb633d4a068a9c812d29974c6bd ]

When driver has been converted to the bitmap API the non-bitmap functions
started behaving differently on 32-bit BE architectures since the bytes in
two consequent unsigned longs are in different order in comparison to byte
array. Hence if the chip had had more than 32 lines the memset() call over
it would have not set up upper lines correctly.
Although it's currently a theoretical case (no supported chips of this type
has 32+ lines), it's better to provide a clean code to avoid people thinking
this is okay and potentially producing not fully working things.

Fixes: 35d13d94893f ("gpio: pca953x: convert to use bitmap API")
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Link: https://lore.kernel.org/r/20200930142013.59247-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: mediatek: check mtk_is_virt_gpio input parameter</title>
<updated>2020-10-07T06:02:53+00:00</updated>
<author>
<name>Hanks Chen</name>
<email>hanks.chen@mediatek.com</email>
</author>
<published>2020-08-20T11:22:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7d42304148585a388d6516c87e1462282e7ebf6'/>
<id>urn:sha1:b7d42304148585a388d6516c87e1462282e7ebf6</id>
<content type='text'>
[ Upstream commit 39c4dbe4cc363accd676162c24b264f44c581490 ]

check mtk_is_virt_gpio input parameter,
virtual gpio need to support eint mode.

add error handler for the ko case
to fix this boot fail:
pc : mtk_is_virt_gpio+0x20/0x38 [pinctrl_mtk_common_v2]
lr : mtk_gpio_get_direction+0x44/0xb0 [pinctrl_paris]

Fixes: edd546465002 ("pinctrl: mediatek: avoid virtual gpio trying to set reg")
Signed-off-by: Hanks Chen &lt;hanks.chen@mediatek.com&gt;
Acked-by: Sean Wang &lt;sean.wang@kernel.org&gt;
Singed-off-by: Jie Yang &lt;sin_jieyang@mediatek.com&gt;
Link: https://lore.kernel.org/r/1597922546-29633-1-git-send-email-hanks.chen@mediatek.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: qcom: sm8250: correct sdc2_clk</title>
<updated>2020-10-07T06:02:53+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2020-09-14T09:18:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b62e4935b0cce18cafba105dac4c6eb93ae2e02'/>
<id>urn:sha1:1b62e4935b0cce18cafba105dac4c6eb93ae2e02</id>
<content type='text'>
[ Upstream commit 5d8ff95a52c36740bf4e61202d08549e7a9caf20 ]

Correct sdc2_clk pin definition (register offset is wrong, verified by
the msm-4.19 driver).

Fixes: 4e3ec9e407ad ("pinctrl: qcom: Add sm8250 pinctrl driver.")
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Acked-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Link: https://lore.kernel.org/r/20200914091846.55204-1-dmitry.baryshkov@linaro.org
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Input: trackpoint - enable Synaptics trackpoints</title>
<updated>2020-10-07T06:02:53+00:00</updated>
<author>
<name>Vincent Huang</name>
<email>vincent.huang@tw.synaptics.com</email>
</author>
<published>2020-09-28T23:19:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6141f191d830f5437eff08816187ae077e377d7'/>
<id>urn:sha1:a6141f191d830f5437eff08816187ae077e377d7</id>
<content type='text'>
[ Upstream commit 996d585b079ad494a30cac10e08585bcd5345125 ]

Add Synaptics IDs in trackpoint_start_protocol() to mark them as valid.

Signed-off-by: Vincent Huang &lt;vincent.huang@tw.synaptics.com&gt;
Fixes: 6c77545af100 ("Input: trackpoint - add new trackpoint variant IDs")
Reviewed-by: Harry Cutts &lt;hcutts@chromium.org&gt;
Tested-by: Harry Cutts &lt;hcutts@chromium.org&gt;
Link: https://lore.kernel.org/r/20200924053013.1056953-1-vincent.huang@tw.synaptics.com
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: npcm7xx: Clear LAST bit after a failed transaction.</title>
<updated>2020-10-07T06:02:53+00:00</updated>
<author>
<name>Tali Perry</name>
<email>tali.perry1@gmail.com</email>
</author>
<published>2020-09-20T20:48:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=83884333497fb58f1d96dada1e9995d868e4d38c'/>
<id>urn:sha1:83884333497fb58f1d96dada1e9995d868e4d38c</id>
<content type='text'>
[ Upstream commit 8947efc077168c53b84d039881a7c967086a248a ]

Due to a HW issue, in some scenarios the LAST bit might remain set.
This will cause an unexpected NACK after reading 16 bytes on the next
read.

Example: if user tries to read from a missing device, get a NACK,
then if the next command is a long read ( &gt; 16 bytes),
the master will stop reading after 16 bytes.
To solve this, if a command fails, check if LAST bit is still
set. If it does, reset the module.

Fixes: 56a1485b102e (i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver)
Signed-off-by: Tali Perry &lt;tali.perry1@gmail.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
