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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux