netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jiawen Wu" <jiawenwu@trustnetic.com>
To: "'Andrew Lunn'" <andrew@lunn.ch>
Cc: <andi.shyti@kernel.org>, <jarkko.nikula@linux.intel.com>,
	<andriy.shevchenko@linux.intel.com>,
	<mika.westerberg@linux.intel.com>, <jsd@semihalf.com>,
	<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <rmk+kernel@armlinux.org.uk>,
	<linux-i2c@vger.kernel.org>, <netdev@vger.kernel.org>,
	<mengyuanlou@net-swift.com>, <duanqiangwen@net-swift.com>
Subject: RE: [PATCH net 0/3] Add I2C bus lock for Wangxun
Date: Tue, 3 Sep 2024 14:31:40 +0800	[thread overview]
Message-ID: <03fc01dafdca$ef952100$cebf6300$@trustnetic.com> (raw)
In-Reply-To: <d91674af-1682-4efe-ad15-bd64f871c1de@lunn.ch>

On Thu, Aug 29, 2024 11:28 PM, Andrew Lunn wrote:
> > > O.K, that is bad. The SFP is totally unreliable...
> > >
> > > You however have still not answered my question. What is the firmware
> > > accessing? How does it handle pages?
> > >
> > > The hack you have put in place is per i2c transaction. But accessing
> > > pages is likely to be multiple transactions. One to change the page,
> > > followed by a few reads/writes in the new page, then maybe followed by
> > > a transactions to return to page 0.
> >
> > Do you mean the bus address A0 or A2? Firmware accesses I2C just like driver,
> > but it only change the page once per full transaction, during a possession of
> > the semaphore.  What you fear seems unlikely to happen.
> 
> What sort of SFP is this? QSFP byte 127 selects the page for addresses
> 128-255. Paged 0 and 3 are mandatory, pages 1 and 2 are optional.
>
> SFP+ also uses byte 127 in the same way:
> 
> 10.3 Optional Page Select Byte [Address A2h, Byte 127]
> 
> In order to provide memory space for DWDM and CDR control functions
> and for other potential extensions, multiple Pages can be defined for
> the upper half of the A2h address space. At startup the value of byte
> 127 defaults to 00h, which points to the User EEPROM. This ensures
> backward compatibility for transceivers that do not implement the
> optional Page structure. When a Page value is written to byte 127,
> subsequent reads and writes to bytes 128-255 are made to the relevant
> Page.
> 
> This specification defines functions in Pages 00h-02h. Pages 03-7Fh
> are reserved for future use. Writing the value of a non-supported Page
> shall not be accepted by the transceiver. The Page Select byte shall
> revert to 0 and read / write operations shall be to the unpaged A2h
> memory map.
> 
> ethtool allows you to access more than page 0.
> 
> ethtool -m|--dump-module-eeprom|--module-info devname [raw on|off]
>         [hex on|off] [offset N] [length N] [page N] [bank N] [i2c N]
> 
> > > I think your best solution is to simply take the mutex and never
> > > release it. Block your firmware from accessing the SFP.
> >
> > Firmware accesses the SFP in order to provide information to the BMC.
> > So it cannot simply be blocked.
> 
> Then you have a design problem. And i don't think locking the I2C bus
> per transaction is sufficient.

SFP+ is used on our device.

But I don't quite understand why this lock is not sufficient. The entire
transaction is locked, include setting the bus address and selecting pages,
and all subsequent reads and writes on this page. Also, firmware uses this
lock (hardware semaphore) in the same way. Neither driver nor firmware
switches pages whiling the other is reading / writing ?



  reply	other threads:[~2024-09-03  6:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-23  3:02 [PATCH net 0/3] Add I2C bus lock for Wangxun Jiawen Wu
2024-08-23  3:02 ` [PATCH net 1/3] net: txgbe: add IO address in I2C platform device data Jiawen Wu
2024-08-23 14:14   ` Andy Shevchenko
2024-08-23  3:02 ` [PATCH net 2/3] i2c: designware: add device private data passing to lock functions Jiawen Wu
2024-08-23 14:06   ` Andy Shevchenko
2024-08-27 13:24   ` Paolo Abeni
2024-08-29  5:16   ` kernel test robot
2024-08-23  3:02 ` [PATCH net 3/3] i2c: designware: support hardware lock for Wangxun 10Gb NIC Jiawen Wu
2024-08-23 14:13   ` Andy Shevchenko
2024-08-29  9:15     ` Jiawen Wu
2024-08-29 10:59       ` 'Andy Shevchenko'
2024-08-23 11:04 ` [PATCH net 0/3] Add I2C bus lock for Wangxun Jarkko Nikula
2024-08-27  2:26   ` Jiawen Wu
2024-08-26  1:32 ` Andrew Lunn
2024-08-26  2:04   ` Jiawen Wu
2024-08-26  2:33     ` Andrew Lunn
2024-08-27  2:21       ` Jiawen Wu
2024-08-27 12:18         ` Andrew Lunn
2024-08-29  6:40           ` Jiawen Wu
2024-08-29 15:27             ` Andrew Lunn
2024-09-03  6:31               ` Jiawen Wu [this message]
2024-09-03 12:45                 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='03fc01dafdca$ef952100$cebf6300$@trustnetic.com' \
    --to=jiawenwu@trustnetic.com \
    --cc=andi.shyti@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=duanqiangwen@net-swift.com \
    --cc=edumazet@google.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jsd@semihalf.com \
    --cc=kuba@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mengyuanlou@net-swift.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rmk+kernel@armlinux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).