<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux, branch v4.9.270</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.270</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.270'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-05-26T09:29:08+00:00</updated>
<entry>
<title>vt: Fix character height handling with VT_RESIZEX</title>
<updated>2021-05-26T09:29:08+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@orcam.me.uk</email>
</author>
<published>2021-05-13T09:51:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3bd3a8ca5a7b1530f463b6e1cc811c085e6ffa01'/>
<id>urn:sha1:3bd3a8ca5a7b1530f463b6e1cc811c085e6ffa01</id>
<content type='text'>
commit 860dafa902595fb5f1d23bbcce1215188c3341e6 upstream.

Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter
which is the number of pixel rows per character (cell) rather than the
height of the font used.

For framebuffer devices the two values are always the same, because the
former is inferred from the latter one.  For VGA used as a true text
mode device these two parameters are independent from each other: the
number of pixel rows per character is set in the CRT controller, while
font height is in fact hardwired to 32 pixel rows and fonts of heights
below that value are handled by padding their data with blanks when
loaded to hardware for use by the character generator.  One can change
the setting in the CRT controller and it will update the screen contents
accordingly regardless of the font loaded.

The `v_clin' parameter is used by the `vgacon' driver to set the height
of the character cell and then the cursor position within.  Make the
parameter explicit then, by defining a new `vc_cell_height' struct
member of `vc_data', set it instead of `vc_font.height' from `v_clin' in
the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver
except where actual font data is accessed which as noted above is
independent from the CRTC setting.

This way the framebuffer console driver is free to ignore the `v_clin'
parameter as irrelevant, as it always should have, avoiding any issues
attempts to give the parameter a meaning there could have caused, such
as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX
behave like VT_RESIZE"):

 "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2],
  for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height
  larger than actual font height calculated by con_font_set() from
  ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates
  minimal amount of memory based on actual font height calculated by
  con_font_set(), use of vt_resizex() can cause UAF/OOB read for font
  data."

The problem first appeared around Linux 2.5.66 which predates our repo
history, but the origin could be identified with the old MIPS/Linux repo
also at: &lt;git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git&gt;
as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX
code in `vt_ioctl' was updated as follows:

 		if (clin)
-			video_font_height = clin;
+			vc-&gt;vc_font.height = clin;

making the parameter apply to framebuffer devices as well, perhaps due
to the use of "font" in the name of the original `video_font_height'
variable.  Use "cell" in the new struct member then to avoid ambiguity.

References:

[1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837
[2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3

Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org # v2.6.12+
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>extcon: adc-jack: Fix incompatible pointer type warning</title>
<updated>2021-05-22T08:40:33+00:00</updated>
<author>
<name>Peter Foley</name>
<email>pefoley2@pefoley.com</email>
</author>
<published>2016-11-28T02:37:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb7d2be7f239e8c42bc850dd39c736118bb2ce00'/>
<id>urn:sha1:cb7d2be7f239e8c42bc850dd39c736118bb2ce00</id>
<content type='text'>
commit 8a522bf2d4f788306443d36b26b54f0aedcdfdbe upstream.

This patch fixes the incompatible warning of extcon-adc-jack.c driver
when calling devm_extcon_dev_allocate().

Signed-off-by: Peter Foley &lt;pefoley2@pefoley.com&gt;
[cw00.choi: Modify the patch title and descritpion]
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: plantronics: Workaround for double volume key presses</title>
<updated>2021-05-22T08:40:26+00:00</updated>
<author>
<name>Maxim Mikityanskiy</name>
<email>maxtram95@gmail.com</email>
</author>
<published>2021-02-07T14:47:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a9104f65c7ac184bcfb3fdf3f029b7687299d691'/>
<id>urn:sha1:a9104f65c7ac184bcfb3fdf3f029b7687299d691</id>
<content type='text'>
[ Upstream commit f567d6ef8606fb427636e824c867229ecb5aefab ]

Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice
for each volume key press. This patch adds a quirk to hid-plantronics
for this product ID, which will ignore the second volume key press if
it happens within 5 ms from the last one that was handled.

The patch was tested on the mentioned model only, it shouldn't affect
other models, however, this quirk might be needed for them too.
Auto-repeat (when a key is held pressed) is not affected, because the
rate is about 3 times per second, which is far less frequent than once
in 5 ms.

Fixes: 81bb773faed7 ("HID: plantronics: Update to map volume up/down controls")
Signed-off-by: Maxim Mikityanskiy &lt;maxtram95@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tty: fix return value for unsupported ioctls</title>
<updated>2021-05-22T08:40:24+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2021-04-07T09:52:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2707118baec5958a3eece6420eeb54a505857e8e'/>
<id>urn:sha1:2707118baec5958a3eece6420eeb54a505857e8e</id>
<content type='text'>
[ Upstream commit 1b8b20868a6d64cfe8174a21b25b74367bdf0560 ]

Drivers should return -ENOTTY ("Inappropriate I/O control operation")
when an ioctl isn't supported, while -EINVAL is used for invalid
arguments.

Fix up the TIOCMGET, TIOCMSET and TIOCGICOUNT helpers which returned
-EINVAL when a tty driver did not implement the corresponding
operations.

Note that the TIOCMGET and TIOCMSET helpers predate git and do not get a
corresponding Fixes tag below.

Fixes: d281da7ff6f7 ("tty: Make tiocgicount a handler")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Link: https://lore.kernel.org/r/20210407095208.31838-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>idr: add ida_is_empty</title>
<updated>2021-03-30T12:41:41+00:00</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@linux.intel.com</email>
</author>
<published>2016-12-14T23:09:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b71c271c6234161c0b8c43253a9d14c33adcf891'/>
<id>urn:sha1:b71c271c6234161c0b8c43253a9d14c33adcf891</id>
<content type='text'>
[ Upstream commit 99c494077e2d4282a17120a772eecc00ec3004cc ]

Two of the USB Gadgets were poking around in the internals of struct ida
in order to determine if it is empty.  Add the appropriate abstraction.

Link: http://lkml.kernel.org/r/1480369871-5271-63-git-send-email-mawilcox@linuxonhyperv.com
Signed-off-by: Matthew Wilcox &lt;willy@linux.intel.com&gt;
Acked-by: Konstantin Khlebnikov &lt;koct9i@gmail.com&gt;
Tested-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Ross Zwisler &lt;ross.zwisler@linux.intel.com&gt;
Cc: Felipe Balbi &lt;balbi@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Cc: Matthew Wilcox &lt;mawilcox@microsoft.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>macvlan: macvlan_count_rx() needs to be aware of preemption</title>
<updated>2021-03-30T12:41:40+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2021-03-10T09:56:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9bd8da264b7ec155cd8a4effe9a830e4d5103a26'/>
<id>urn:sha1:9bd8da264b7ec155cd8a4effe9a830e4d5103a26</id>
<content type='text'>
[ Upstream commit dd4fa1dae9f4847cc1fd78ca468ad69e16e5db3e ]

macvlan_count_rx() can be called from process context, it is thus
necessary to disable preemption before calling u64_stats_update_begin()

syzbot was able to spot this on 32bit arch:

WARNING: CPU: 1 PID: 4632 at include/linux/seqlock.h:271 __seqprop_assert include/linux/seqlock.h:271 [inline]
WARNING: CPU: 1 PID: 4632 at include/linux/seqlock.h:271 __seqprop_assert.constprop.0+0xf0/0x11c include/linux/seqlock.h:269
Modules linked in:
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 4632 Comm: kworker/1:3 Not tainted 5.12.0-rc2-syzkaller #0
Hardware name: ARM-Versatile Express
Workqueue: events macvlan_process_broadcast
Backtrace:
[&lt;82740468&gt;] (dump_backtrace) from [&lt;827406dc&gt;] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:252)
 r7:00000080 r6:60000093 r5:00000000 r4:8422a3c4
[&lt;827406c4&gt;] (show_stack) from [&lt;82751b58&gt;] (__dump_stack lib/dump_stack.c:79 [inline])
[&lt;827406c4&gt;] (show_stack) from [&lt;82751b58&gt;] (dump_stack+0xb8/0xe8 lib/dump_stack.c:120)
[&lt;82751aa0&gt;] (dump_stack) from [&lt;82741270&gt;] (panic+0x130/0x378 kernel/panic.c:231)
 r7:830209b4 r6:84069ea4 r5:00000000 r4:844350d0
[&lt;82741140&gt;] (panic) from [&lt;80244924&gt;] (__warn+0xb0/0x164 kernel/panic.c:605)
 r3:8404ec8c r2:00000000 r1:00000000 r0:830209b4
 r7:0000010f
[&lt;80244874&gt;] (__warn) from [&lt;82741520&gt;] (warn_slowpath_fmt+0x68/0xd4 kernel/panic.c:628)
 r7:81363f70 r6:0000010f r5:83018e50 r4:00000000
[&lt;827414bc&gt;] (warn_slowpath_fmt) from [&lt;81363f70&gt;] (__seqprop_assert include/linux/seqlock.h:271 [inline])
[&lt;827414bc&gt;] (warn_slowpath_fmt) from [&lt;81363f70&gt;] (__seqprop_assert.constprop.0+0xf0/0x11c include/linux/seqlock.h:269)
 r8:5a109000 r7:0000000f r6:a568dac0 r5:89802300 r4:00000001
[&lt;81363e80&gt;] (__seqprop_assert.constprop.0) from [&lt;81364af0&gt;] (u64_stats_update_begin include/linux/u64_stats_sync.h:128 [inline])
[&lt;81363e80&gt;] (__seqprop_assert.constprop.0) from [&lt;81364af0&gt;] (macvlan_count_rx include/linux/if_macvlan.h:47 [inline])
[&lt;81363e80&gt;] (__seqprop_assert.constprop.0) from [&lt;81364af0&gt;] (macvlan_broadcast+0x154/0x26c drivers/net/macvlan.c:291)
 r5:89802300 r4:8a927740
[&lt;8136499c&gt;] (macvlan_broadcast) from [&lt;81365020&gt;] (macvlan_process_broadcast+0x258/0x2d0 drivers/net/macvlan.c:317)
 r10:81364f78 r9:8a86d000 r8:8a9c7e7c r7:8413aa5c r6:00000000 r5:00000000
 r4:89802840
[&lt;81364dc8&gt;] (macvlan_process_broadcast) from [&lt;802696a4&gt;] (process_one_work+0x2d4/0x998 kernel/workqueue.c:2275)
 r10:00000008 r9:8404ec98 r8:84367a02 r7:ddfe6400 r6:ddfe2d40 r5:898dac80
 r4:8a86d43c
[&lt;802693d0&gt;] (process_one_work) from [&lt;80269dcc&gt;] (worker_thread+0x64/0x54c kernel/workqueue.c:2421)
 r10:00000008 r9:8a9c6000 r8:84006d00 r7:ddfe2d78 r6:898dac94 r5:ddfe2d40
 r4:898dac80
[&lt;80269d68&gt;] (worker_thread) from [&lt;80271f40&gt;] (kthread+0x184/0x1a4 kernel/kthread.c:292)
 r10:85247e64 r9:898dac80 r8:80269d68 r7:00000000 r6:8a9c6000 r5:89a2ee40
 r4:8a97bd00
[&lt;80271dbc&gt;] (kthread) from [&lt;80200114&gt;] (ret_from_fork+0x14/0x20 arch/arm/kernel/entry-common.S:158)
Exception stack(0x8a9c7fb0 to 0x8a9c7ff8)

Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>u64_stats,lockdep: Fix u64_stats_init() vs lockdep</title>
<updated>2021-03-30T12:41:39+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2021-03-08T08:38:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d54d0aaa05379d5cfcd6db328bf595c51e4fbc98'/>
<id>urn:sha1:d54d0aaa05379d5cfcd6db328bf595c51e4fbc98</id>
<content type='text'>
[ Upstream commit d5b0e0677bfd5efd17c5bbb00156931f0d41cb85 ]

Jakub reported that:

    static struct net_device *rtl8139_init_board(struct pci_dev *pdev)
    {
	    ...
	    u64_stats_init(&amp;tp-&gt;rx_stats.syncp);
	    u64_stats_init(&amp;tp-&gt;tx_stats.syncp);
	    ...
    }

results in lockdep getting confused between the RX and TX stats lock.
This is because u64_stats_init() is an inline calling seqcount_init(),
which is a macro using a static variable to generate a lockdep class.

By wrapping that in an inline, we negate the effect of the macro and
fold the static key variable, hence the confusion.

Fix by also making u64_stats_init() a macro for the case where it
matters, leaving the other case an inline for argument validation
etc.

Reported-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Debugged-by: "Ahmed S. Darwish" &lt;a.darwish@linutronix.de&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Tested-by: "Erhard F." &lt;erhard_f@mailbox.org&gt;
Link: https://lkml.kernel.org/r/YEXicy6+9MksdLZh@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>kernel, fs: Introduce and use set_restart_fn() and arch_set_restart_data()</title>
<updated>2021-03-24T09:59:25+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2021-02-01T17:46:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=376a76aa925722ecb0ab2e2b0fa765bf0cf06844'/>
<id>urn:sha1:376a76aa925722ecb0ab2e2b0fa765bf0cf06844</id>
<content type='text'>
commit 5abbe51a526253b9f003e9a0a195638dc882d660 upstream.

Preparation for fixing get_nr_restart_syscall() on X86 for COMPAT.

Add a new helper which sets restart_block-&gt;fn and calls a dummy
arch_set_restart_data() helper.

Fixes: 609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210201174641.GA17871@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: skb: can_skb_set_owner(): fix ref counting if socket was closed before setting skb ownership</title>
<updated>2021-03-17T15:10:13+00:00</updated>
<author>
<name>Oleksij Rempel</name>
<email>o.rempel@pengutronix.de</email>
</author>
<published>2021-02-26T09:24:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa2cdf772770bee1f47ed5b20b5f7ba418f57872'/>
<id>urn:sha1:fa2cdf772770bee1f47ed5b20b5f7ba418f57872</id>
<content type='text'>
commit e940e0895a82c6fbaa259f2615eb52b57ee91a7e upstream.

There are two ref count variables controlling the free()ing of a socket:
- struct sock::sk_refcnt - which is changed by sock_hold()/sock_put()
- struct sock::sk_wmem_alloc - which accounts the memory allocated by
  the skbs in the send path.

In case there are still TX skbs on the fly and the socket() is closed,
the struct sock::sk_refcnt reaches 0. In the TX-path the CAN stack
clones an "echo" skb, calls sock_hold() on the original socket and
references it. This produces the following back trace:

| WARNING: CPU: 0 PID: 280 at lib/refcount.c:25 refcount_warn_saturate+0x114/0x134
| refcount_t: addition on 0; use-after-free.
| Modules linked in: coda_vpu(E) v4l2_jpeg(E) videobuf2_vmalloc(E) imx_vdoa(E)
| CPU: 0 PID: 280 Comm: test_can.sh Tainted: G            E     5.11.0-04577-gf8ff6603c617 #203
| Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
| Backtrace:
| [&lt;80bafea4&gt;] (dump_backtrace) from [&lt;80bb0280&gt;] (show_stack+0x20/0x24) r7:00000000 r6:600f0113 r5:00000000 r4:81441220
| [&lt;80bb0260&gt;] (show_stack) from [&lt;80bb593c&gt;] (dump_stack+0xa0/0xc8)
| [&lt;80bb589c&gt;] (dump_stack) from [&lt;8012b268&gt;] (__warn+0xd4/0x114) r9:00000019 r8:80f4a8c2 r7:83e4150c r6:00000000 r5:00000009 r4:80528f90
| [&lt;8012b194&gt;] (__warn) from [&lt;80bb09c4&gt;] (warn_slowpath_fmt+0x88/0xc8) r9:83f26400 r8:80f4a8d1 r7:00000009 r6:80528f90 r5:00000019 r4:80f4a8c2
| [&lt;80bb0940&gt;] (warn_slowpath_fmt) from [&lt;80528f90&gt;] (refcount_warn_saturate+0x114/0x134) r8:00000000 r7:00000000 r6:82b44000 r5:834e5600 r4:83f4d540
| [&lt;80528e7c&gt;] (refcount_warn_saturate) from [&lt;8079a4c8&gt;] (__refcount_add.constprop.0+0x4c/0x50)
| [&lt;8079a47c&gt;] (__refcount_add.constprop.0) from [&lt;8079a57c&gt;] (can_put_echo_skb+0xb0/0x13c)
| [&lt;8079a4cc&gt;] (can_put_echo_skb) from [&lt;8079ba98&gt;] (flexcan_start_xmit+0x1c4/0x230) r9:00000010 r8:83f48610 r7:0fdc0000 r6:0c080000 r5:82b44000 r4:834e5600
| [&lt;8079b8d4&gt;] (flexcan_start_xmit) from [&lt;80969078&gt;] (netdev_start_xmit+0x44/0x70) r9:814c0ba0 r8:80c8790c r7:00000000 r6:834e5600 r5:82b44000 r4:82ab1f00
| [&lt;80969034&gt;] (netdev_start_xmit) from [&lt;809725a4&gt;] (dev_hard_start_xmit+0x19c/0x318) r9:814c0ba0 r8:00000000 r7:82ab1f00 r6:82b44000 r5:00000000 r4:834e5600
| [&lt;80972408&gt;] (dev_hard_start_xmit) from [&lt;809c6584&gt;] (sch_direct_xmit+0xcc/0x264) r10:834e5600 r9:00000000 r8:00000000 r7:82b44000 r6:82ab1f00 r5:834e5600 r4:83f27400
| [&lt;809c64b8&gt;] (sch_direct_xmit) from [&lt;809c6c0c&gt;] (__qdisc_run+0x4f0/0x534)

To fix this problem, only set skb ownership to sockets which have still
a ref count &gt; 0.

Fixes: 0ae89beb283a ("can: add destructor for self generated skbs")
Cc: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: Andre Naujoks &lt;nautsch2@gmail.com&gt;
Link: https://lore.kernel.org/r/20210226092456.27126-1-o.rempel@pengutronix.de
Suggested-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom</title>
<updated>2021-03-11T12:48:03+00:00</updated>
<author>
<name>Aswath Govindraju</name>
<email>a-govindraju@ti.com</email>
</author>
<published>2021-01-05T10:58:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c52e592d413098e366a18d8e398edaa42971f33b'/>
<id>urn:sha1:c52e592d413098e366a18d8e398edaa42971f33b</id>
<content type='text'>
[ Upstream commit f6f1f8e6e3eea25f539105d48166e91f0ab46dd1 ]

A dummy zero bit is sent preceding the data during a read transfer by the
Microchip 93LC46B eeprom (section 2.7 of[1]). This results in right shift
of data during a read. In order to ignore this bit a quirk can be added to
send an extra zero bit after the read address.

Add a quirk to ignore the zero bit sent before data by adding a zero bit
after the read address.

[1] - https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf

Signed-off-by: Aswath Govindraju &lt;a-govindraju@ti.com&gt;
Link: https://lore.kernel.org/r/20210105105817.17644-3-a-govindraju@ti.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
