On Wed, Nov 13, 2019 at 11:42:39AM +0200, Mark Kuckian Cowan wrote: > The out-of-tree DTS in question was developed quickly and lazily for > getting CAN working on a prototype, where the MCU's built-in CAN had > not been routed correctly (so I added an MCP251x via SPI for testing). > It was a one-off fix for a problem that no longer exists, for hardware > which no longer exists. Probably not the best approach to fix the > problem either. > > I shared the DTS to help others at the time who might be using the > same part with similar kernel versions (~4.9?) and out-of-tree mcp2515 > driver. > There is an driver available in-tree, with documentation of DTS > properties at linux://Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt > > I don't care about that out-of-tree MCP2515 DTS any more, the kernel > developers certainly shouldn't care about it, and neither should > anyone else. > > -- Mark Kuckian Cowan > > On Wed, 13 Nov 2019 at 11:19, andriy.shevchenko@xxxxxxxxx > <andriy.shevchenko@xxxxxxxxx> wrote: > > First of all, there are rules (which are getting stricter all the time) about > > property names and use in DT. Second, no one cares about out-of-tree > > customizations. In kernel we consider no regression made if we introduce > > properties that are not compatible with no-one-knows DTSes (it didn't work > > with older kernel, it continue not working with new — status quo). > > > > -- > > With Best Regards, > > Andy Shevchenko Thanks for your insights, Andy and Mark. Mark - sorry to drag you into this. Thank you for sharing that DTS as it helped me out a lot in figuring out what I needed to get it working on the PocketBeagle. I should have looked the official mcp251x bindings before I assumed those "mcp251x," properties were being used by the driver. thanks, drew
