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

From: Selvamani Rajagopal
Date: Wed Jun 05 2024 - 20:36:08 EST




> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Wednesday, June 5, 2024 4:43 PM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@xxxxxxxxxx>
> Cc: Parthiban.Veerasooran@xxxxxxxxxxxxx; Piergiorgio Beruto
> <Pier.Beruto@xxxxxxxxxx>; davem@xxxxxxxxxxxxx;
> edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx; pabeni@xxxxxxxxxx;
> horms@xxxxxxxxxx; saeedm@xxxxxxxxxx; anthony.l.nguyen@xxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; corbet@xxxxxxx;
> linux-doc@xxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
> krzysztof.kozlowski+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; Horatiu.Vultur@xxxxxxxxxxxxx;
> ruanjinjie@xxxxxxxxxx; Steen.Hegelund@xxxxxxxxxxxxx;
> vladimir.oltean@xxxxxxx; UNGLinuxDriver@xxxxxxxxxxxxx;
> Thorsten.Kummermehr@xxxxxxxxxxxxx;
> Nicolas.Ferre@xxxxxxxxxxxxx;
> benjamin.bigler@xxxxxxxxxxxxxxxxxxxxx; Viliam Vozar
> <Viliam.Vozar@xxxxxxxxxx>; Arndt Schuebel
> <Arndt.Schuebel@xxxxxxxxxx>
> 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