Hi All, First of all, I thank all of you for the comments and response. In my opinion, the framework what we have in this patch series will support all the necessary features to enable basic 10Base-T1S Ethernet communication and also we tested this with Microchip LAN8650/1. If it is not supporting for other vendor's devices, then please let me know we can add necessary changes to support them. The basic idea with this patch series is to baseline an initial version which basically supports 10Base-T1S Ethernet communication. I agree we may have some more further features to be implemented in the framework but they can be done later once we have a basic version mainlined. We can't have all things together in the 1st version of the patch series which will create unnecessary deviations from our focus. So I would request all of you to give your comments on the existing implementation in the patch series to improve better. Once this version is mainlined we will discuss further to implement further features supported. I feel the current discussion doesn't have any impact on the existing implementation which supports basic 10Base-T1S Ethernet communication. Thanks for your understanding. Please let me know if you have any opinion on this. Best regards, Parthiban V On 30/05/24 3:13 pm, Piergiorgio Beruto wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Hello Andrew, > > I was reading back into the MACPHY specifications in OPEN Alliance, and it seems like MMS 10 to MMS 15 are actually allowed as vendor specific registers. See page 50. > The specifications further say that vendor specific registers of the PHY that would normally be in MMD30-31 (ie, excluding the PLCA registers and the other OPEN standard registers) would go into MMS10 to MMS15. > > So I'm wondering, why is it bad to have vendor specific registers into MMD10 to MMD15? > I think the framework should allow non-standard stuff to be mapped into these, no? > > Thanks, > Piergiorgio > > -----Original Message----- > From: Andrew Lunn <andrew@xxxxxxx> > Sent: 24 May, 2024 23:55 > To: Piergiorgio Beruto <Pier.Beruto@xxxxxxxxxx> > Cc: Selvamani Rajagopal <Selvamani.Rajagopal@xxxxxxxxxx>; Parthiban.Veerasooran@xxxxxxxxxxxxx; 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 > 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. > >> In reality, it is not the PHY having register in MMS12, and not even >> the MAC. These are really "chip-specific" registers, unrelated to >> networking (e.g., GPIOs, HW diagnostics, etc.). > > Having a GPIO driver within the MAC driver is O.K. For hardware diagnostics you should be using devlink, which many MAC drivers have. So i don't see a need for the PHY driver to access MMS 12. > > Anyway, we can do a real review when you post your code. > >> Although, I think it is a good idea anyway to allow the MACPHY drivers >> to hook into / extend the MDIO access functions. If anything, because >> of the hacks you mentioned. But also to allow vendor-specific >> extensions. > > But we don't want vendor specific extensions. OS 101, the OS is there to make all hardware look the same. And in general, it is not often that vendors actually come up with anything unique. And if they do, and it is useful, other vendors will copy it. So rather than doing vendor specific extensions, you should be thinking about how to export it in a way which is common across multiple vendors. > > Andrew
