RE: [PATCH net-next v4 00/12] Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface

Selvamani Rajagopal
2024-06-06T00:35:49Z

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Wednesday, June 5, 2024 4:43 PM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> Cc: Parthiban.Veerasooran@microchip.com; Piergiorgio Beruto
> <Pier.Beruto@onsemi.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
> horms@kernel.org; saeedm@nvidia.com; anthony.l.nguyen@intel.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; corbet@lwn.net;
> linux-doc@vger.kernel.org; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> devicetree@vger.kernel.org; Horatiu.Vultur@microchip.com;
> ruanjinjie@huawei.com; Steen.Hegelund@microchip.com;
> vladimir.oltean@nxp.com; UNGLinuxDriver@microchip.com;
> Thorsten.Kummermehr@microchip.com;
> Nicolas.Ferre@microchip.com;
> benjamin.bigler@bernformulastudent.ch; Viliam Vozar
> <Viliam.Vozar@onsemi.com>; Arndt Schuebel
> <Arndt.Schuebel@onsemi.com>
> Subject: Re: [PATCH net-next v4 00/12] Add support for OPEN Alliance
> 10BASE-T1x MACPHY Serial Interface
>
> [External Email]: This email arrived from an external source - Please
> exercise caution when opening any attachments or clicking on links.
>
>
> On Wed, Jun 05, 2024 at 09:40:12PM +0000, Selvamani Rajagopal
> wrote:
> > Parthiban/Andrew,
> >
> > Couple of requests / suggestions after completing the integration of
> our drivers to the current framework.
>
> Please configure your email client to wrap lines at about 78
> characters.
>

I believe my client is configured to wrap at 70th characters.
Not sure why it is not doing it.

>
> >
> > 1) Can we move memory map selector definitions
> (OA_TC6_PHY_C45_PCS_MMS2 and other 4 definitions) to the header
> file
> > include/linux/oa_tc6.h?
> > Also, if possible, could we add the MMS0, MMS1?. Our driver is
> using them. Of course, we could add it when we submit our driver.
>
> Interesting. So you have vendor registers outside of MMS 10-15?

This is not about vendor registers. The current oa_tc6 defines
MMS selector values for 2, 3, 4, 5, 6. I am asking, if 0, 1 can be added,
which are meant for "Standard Control and Status" and MAC respectively,
according to MMS assignment table 6 on OA standard.

>
> Or do you need to access standard registers? I would prefer to see
> your use cases before deciding this. If you want to access standard
> registers, you are probably doing stuff other vendors also want to do,
> so we should add a helper in the framework.
>
> 2) If it not too late to ask, Is it possible to move interrupt
> > handler to vendor's code?
>
> I would say no, not at the moment.
>
> What we can do in the future is allow a driver to register a function
> to handle the vendor interrupts, leaving the framework to handle the
> standard interrupts, and chain into the specific driver vendor
> interrupt handler when a vendor interrupt it indicated.
>
> > This way, it will provide vendors' code an ability to deal with some
> > of the interrupts. For example, our code deals with PHYINT bit.
>
> Please explain what you are doing here? What are you doing which the
> framework does not cover.

One example I can think of is, to handle PHYINT status bit
that may be set in STATUS0 register. Another example could be,
to give a vendor flexibility to not to use interrupt mode.
FYI: Our driver uses interrupts. So, this is not the main reason.

>
> Andrew