<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/ethernet/asix, branch linux-6.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-12-12T21:20:37Z</updated>
<entry>
<title>net: asix: fix fortify warning</title>
<updated>2023-12-12T21:20:37Z</updated>
<author>
<name>Dmitry Antipov</name>
<email>dmantipov@yandex.ru</email>
</author>
<published>2023-12-11T09:05:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2a62644800208fcba79a55b297ec0d9aad115221'/>
<id>urn:sha1:2a62644800208fcba79a55b297ec0d9aad115221</id>
<content type='text'>
When compiling with gcc version 14.0.0 20231129 (experimental) and
CONFIG_FORTIFY_SOURCE=y, I've noticed the following warning:

...
In function 'fortify_memcpy_chk',
    inlined from 'ax88796c_tx_fixup' at drivers/net/ethernet/asix/ax88796c_main.c:287:2:
./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
declared with attribute warning: detected read beyond size of field (2nd parameter);
maybe use struct_group()? [-Wattribute-warning]
  588 |                         __read_overflow2_field(q_size_field, size);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

This call to 'memcpy()' is interpreted as an attempt to copy TX_OVERHEAD
(which is 8) bytes from 4-byte 'sop' field of 'struct tx_pkt_info' and
thus overread warning is issued. Since we actually want to copy both
'sop' and 'seg' fields at once, use the convenient 'struct_group()' here.

Signed-off-by: Dmitry Antipov &lt;dmantipov@yandex.ru&gt;
Acked-by: Łukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Link: https://lore.kernel.org/r/20231211090535.9730-1-dmantipov@yandex.ru
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ax88796c: replace deprecated strncpy with strscpy</title>
<updated>2023-10-06T22:55:29Z</updated>
<author>
<name>Justin Stitt</name>
<email>justinstitt@google.com</email>
</author>
<published>2023-10-05T01:06:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9c9e3ab20f35b2903a4fd3619229e6df7c7986b3'/>
<id>urn:sha1:9c9e3ab20f35b2903a4fd3619229e6df7c7986b3</id>
<content type='text'>
`strncpy` is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.

A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on the destination buffer without
unnecessarily NUL-padding.

It should be noted that there doesn't currently exist a bug here as
DRV_NAME is a small string literal which means no overread bugs are
present.

Also to note, other ethernet drivers are using strscpy in a similar
pattern:
|       dec/tulip/tulip_core.c
|       861:    strscpy(info-&gt;driver, DRV_NAME, sizeof(info-&gt;driver));
|
|       8390/ax88796.c
|       582:    strscpy(info-&gt;driver, DRV_NAME, sizeof(info-&gt;driver));
|
|       dec/tulip/dmfe.c
|       1077:   strscpy(info-&gt;driver, DRV_NAME, sizeof(info-&gt;driver));
|
|       8390/etherh.c
|       558:    strscpy(info-&gt;driver, DRV_NAME, sizeof(info-&gt;driver));

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt &lt;justinstitt@google.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Lukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-asix-ax88796c_ioctl-c-v1-1-6fafdc38b170@google.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: Replace all spi-&gt;chip_select and spi-&gt;cs_gpiod references with function call</title>
<updated>2023-03-11T12:34:02Z</updated>
<author>
<name>Amit Kumar Mahapatra</name>
<email>amit.kumar-mahapatra@amd.com</email>
</author>
<published>2023-03-10T17:32:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=25fd0550d9b9c92288a17fb7d605cdcdb4a65a64'/>
<id>urn:sha1:25fd0550d9b9c92288a17fb7d605cdcdb4a65a64</id>
<content type='text'>
Supporting multi-cs in spi drivers would require the chip_select &amp; cs_gpiod
members of struct spi_device to be an array. But changing the type of these
members to array would break the spi driver functionality. To make the
transition smoother introduced four new APIs to get/set the
spi-&gt;chip_select &amp; spi-&gt;cs_gpiod and replaced all spi-&gt;chip_select and
spi-&gt;cs_gpiod references with get or set API calls.
While adding multi-cs support in further patches the chip_select &amp; cs_gpiod
members of the spi_device structure would be converted to arrays &amp; the
"idx" parameter of the APIs would be used as array index i.e.,
spi-&gt;chip_select[idx] &amp; spi-&gt;cs_gpiod[idx] respectively.

Signed-off-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@amd.com&gt;
Reviewed-by: Michal Simek &lt;michal.simek@amd.com&gt;
Link: https://lore.kernel.org/r/20230310173217.3429788-3-amit.kumar-mahapatra@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: Remove the obsolte u64_stats_fetch_*_irq() users (drivers).</title>
<updated>2022-10-29T03:13:54Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2022-10-26T13:22:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=068c38ad88ccb09e5e966d4db5cedab0e02b3b95'/>
<id>urn:sha1:068c38ad88ccb09e5e966d4db5cedab0e02b3b95</id>
<content type='text'>
Now that the 32bit UP oddity is gone and 32bit uses always a sequence
count, there is no need for the fetch_irq() variants anymore.

Convert to the regular interface.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Acked-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ax88796c: Use skb_put_data() instead of skb_put/memcpy pair</title>
<updated>2022-09-29T07:37:29Z</updated>
<author>
<name>Shang XiaoJing</name>
<email>shangxiaojing@huawei.com</email>
</author>
<published>2022-09-27T02:30:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=85e69a7dd693667b3e3114713d61edef7552ca88'/>
<id>urn:sha1:85e69a7dd693667b3e3114713d61edef7552ca88</id>
<content type='text'>
Use skb_put_data() instead of skb_put() and memcpy(), which is clear.

Signed-off-by: Shang XiaoJing &lt;shangxiaojing@huawei.com&gt;
Link: https://lore.kernel.org/r/20220927023043.17769-1-shangxiaojing@huawei.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: ax88796c: Fix return type of ax88796c_start_xmit</title>
<updated>2022-09-20T01:23:04Z</updated>
<author>
<name>Nathan Huckleberry</name>
<email>nhuck@google.com</email>
</author>
<published>2022-09-12T19:40:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fcb7c210a24209ea8f6f32593580b57f52382ec2'/>
<id>urn:sha1:fcb7c210a24209ea8f6f32593580b57f52382ec2</id>
<content type='text'>
The ndo_start_xmit field in net_device_ops is expected to be of type
netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev).

The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.

The return type of ax88796c_start_xmit should be changed from int to
netdev_tx_t.

Reported-by: Dan Carpenter &lt;error27@gmail.com&gt;
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: llvm@lists.linux.dev
Signed-off-by: Nathan Huckleberry &lt;nhuck@google.com&gt;
Acked-by: Lukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Link: https://lore.kernel.org/r/20220912194031.808425-1-nhuck@google.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ethernet: Use netif_rx().</title>
<updated>2022-03-04T12:02:19Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2022-03-03T17:15:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=90f77c1c512ffe2e91473658b5eb259b5da04b04'/>
<id>urn:sha1:90f77c1c512ffe2e91473658b5eb259b5da04b04</id>
<content type='text'>
Since commit
   baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.")

the function netif_rx() can be used in preemptible/thread context as
well as in interrupt context.

Use netif_rx().

Cc: Łukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Cc: Horatiu Vultur &lt;horatiu.vultur@microchip.com&gt;
Cc: UNGLinuxDriver@microchip.com
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>spi: make remove callback a void function</title>
<updated>2022-02-09T13:00:45Z</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2022-01-23T17:52:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a0386bba70934d42f586eaf68b21d5eeaffa7bd0'/>
<id>urn:sha1:a0386bba70934d42f586eaf68b21d5eeaffa7bd0</id>
<content type='text'>
The value returned by an spi driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)

So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Acked-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Acked-by: Jérôme Pouiller &lt;jerome.pouiller@silabs.com&gt;
Acked-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Claudius Heine &lt;ch@denx.de&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt; # For MMC
Acked-by: Marcus Folkesson &lt;marcus.folkesson@gmail.com&gt;
Acked-by: Łukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Acked-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2021-11-26T21:45:19Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2021-11-26T21:26:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=93d5404e8988882bd33f6acc0d343c4db51eb8b4'/>
<id>urn:sha1:93d5404e8988882bd33f6acc0d343c4db51eb8b4</id>
<content type='text'>
drivers/net/ipa/ipa_main.c
  8afc7e471ad3 ("net: ipa: separate disabling setup from modem stop")
  76b5fbcd6b47 ("net: ipa: kill ipa_modem_init()")

Duplicated include, drop one.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ax88796c: do not receive data in pointer</title>
<updated>2021-11-22T14:32:05Z</updated>
<author>
<name>Nicolas Iooss</name>
<email>nicolas.iooss_linux@m4x.org</email>
</author>
<published>2021-11-21T20:06:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f93fd0ca5e7de743ce687951266950fb37877e34'/>
<id>urn:sha1:f93fd0ca5e7de743ce687951266950fb37877e34</id>
<content type='text'>
Function axspi_read_status calls:

    ret = spi_write_then_read(ax_spi-&gt;spi, ax_spi-&gt;cmd_buf, 1,
                              (u8 *)&amp;status, 3);

status is a pointer to a struct spi_status, which is 3-byte wide:

    struct spi_status {
        u16 isr;
        u8 status;
    };

But &amp;status is the pointer to this pointer, and spi_write_then_read does
not dereference this parameter:

    int spi_write_then_read(struct spi_device *spi,
                            const void *txbuf, unsigned n_tx,
                            void *rxbuf, unsigned n_rx)

Therefore axspi_read_status currently receive a SPI response in the
pointer status, which overwrites 24 bits of the pointer.

Thankfully, on Little-Endian systems, the pointer is only used in

    le16_to_cpus(&amp;status-&gt;isr);

... which is a no-operation. So there, the overwritten pointer is not
dereferenced. Nevertheless on Big-Endian systems, this can lead to
dereferencing pointers after their 24 most significant bits were
overwritten. And in all systems this leads to possible use of
uninitialized value in functions calling spi_write_then_read which
expect status to be initialized when the function returns.

Moreover function axspi_read_status (and macro AX_READ_STATUS) do not
seem to be used anywhere. So currently this seems to be dead code. Fix
the issue anyway so that future code works properly when using function
axspi_read_status.

Fixes: a97c69ba4f30 ("net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver")

Signed-off-by: Nicolas Iooss &lt;nicolas.iooss_linux@m4x.org&gt;
Acked-by: Łukasz Stelmach &lt;l.stelmach@samsung.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
