On 31/03/26 10:02 am, Jakub Kicinski wrote:

quoted

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index

32a4e8d423115..8747c55e0a484 100644

--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c

[ ... ]

quoted

+static void sram_write_w0w1(struct r8152 *tp, u16 addr, u16 clear,
+u16 set) {
+     u16 data;
+
+     data = sram_read(tp, addr);
+     data = (data & ~clear) | set;
+     ocp_reg_write(tp, OCP_SRAM_DATA, data);

AI flags:

  Does writing directly to OCP_SRAM_DATA here actually write to the
intended
  address?

Yes, this actually writes to the intended address.

  Because hardware indirect SRAM access ports typically auto-increment their
  internal address pointer upon access, the sram_read() call will advance the
  pointer. By writing directly to OCP_SRAM_DATA instead of using
  sram_write(tp, addr, data) to re-establish the address, the updated value
  would be written to the next address (addr + 1) rather than the original addr.

  Could this corrupt the PHY configuration memory across the initialization
paths
  that now use sram_clr_bits() and sram_set_bits()?

Can you confirm if this is legit? Not sure whether this device / register
auto-increments or where AI got it from.

The address pointer, OCP_SRAM_ADDR, is not auto-incremented after sram_read(tp, addr).
However, the address pointer is incremented automatically after ocp_reg_write(tp, OCP_SRAM_DATA, data).

Best Regards,
Chih-Kai