> > > Hi Andrew, > > > > So the switch will be left in dumb switch everything to every port > > mode? Or it will be totally autonomous using the in build firmware? > > > > What you cannot expect is we allow you to manage the switch from Linux > > using something other than an in kernel driver, probably DSA or pure > > switchdev. > > This looks reasonable as an advice about to ideally fit within the existing > Linux subsystems, however that is purely informational and it should not > impair the review and acceptance of the stmmac drivers. > > Doing otherwise, and rejecting the stmmac changes because now you and other > reviewers/maintainers know how it gets used in the bigger picture means this > is starting to be overreaching. Yes silicon vendor companies like to do all > sorts of proprietary things for random reasons, I think we have worked > together long enough on DSA that you know my beliefs on that aspect. > > I think the stmmac changes along have their own merit, and I would seriously > like to see a proper DSA or switchdev driver for the switching silicon that > is being used, but I don't think we need to treat the latter as a > prerequisite for merging the former. I fully agree this patchset should be merged without needing a DSA driver. We have seen a number of automotive systems recently doing very similar things, Linux is just a host connected to a switch. Linux is too unreliable to manage the switch, or Linux takes too long to boot and configure the switch etc. So something else is in control of the switch. Linux only view onto the switch is as a typical external device, it can walk the SNMP MIBs etc. If you decided Linux can manage this switch, then great, please sometime in the future submit a DSA or switchdev driver. Otherwise Linux is just a host with no real knowledge of the switch, and the SPI interface is not used. Andrew
