Hi Denis, On Thu, 20 Aug 2020 at 03:19, Denis CIOCCA <denis.ciocca@xxxxxx> wrote: > I strongly disagree that these parts will be supported by STMicroelectronics driver. The alternative seems to be write a totally new driver that does exactly the same thing, use a lot of people's time to get it ready to go into the kernel etc when we could come up with a way to allow the driver to accept a different WAI register value in a non-intrusive way that can go in the bin at a later date if it turns out supporting these chips is too much hassle. > We DO NOT want to find out one day that we need to modify our structure in order to support competition. I think Jonathan suggested adding me as a reviewer for these parts thus making me responsible for them. I'm fine with that. If it comes to the point where the driver changes so much that it's not possible to keep them working then you'd have my blessing to just remove support for them. That said I'm not going to force this on anyone. This patch was a spin-off of a personal project to try to make cheap Linux capable SoCs available to makers[0]. One of the devices I used to reverse engineer that hardware had one of these Silan parts, I noticed the registers looked exactly the same as ST parts supported in the kernel already and upon testing they worked so I thought it was worth throwing this out there. If you guys don't want to deal with it I'll just leave it in my tree. >If they need to support this chip, please provide a new driver for that part leaving STMicroelectronics driver managing our parts. To be clear I'm not working for Silan and I doubt they have any interest in supporting these parts. There are hacky drivers for them in 3.x kernels that some vendors are still using and that's probably as much as they care. Thanks, Daniel [0] - https://github.com/breadbee/breadbee
