On 10/20/17 21:08, Christian Lamparter wrote: > Wait. > > I had the same comment about this earlier and a few more suggestions > to move the driver to gpio-mmio's dt. Didn't you read the mail? > > <https://marc.info/?l=linux-gpio&m=150678737724132&w=2> > > It made it to the list archive, so I'm pretty sure this got delivered > to you as well. > Hi, looks like I overlooked your message, sorry. > Hm, Is it possible to differenciate it from a "syscon" device? This is not a register region containing a set of miscellaneous registers, which are not cohesive enough to represent as any specific type of device. At least not how I understand the term. That would mean unrelated but hardwired functions that share the same register. The various functions would be fixed and documented in the manual. The difference is that there is no fixed function at all, like in the case of a I/O pin where the signal is routed on the PCB to some external device. Instead the signals are routed through the internal interconnect to logic functions on the FPGA. > The driver seemd fairly simple. So, You could actually get > away with just adding the "altr,fpgamgr-gpio" compatible string > to gpio-mmio.c's bgpio_of_match struct at [0] and change the dt > to something like this: This structure does not reflect the internal register structure of the FPGA Manager's I/O register block any more. I think this could of course be a completely generic driver, in that case I see no need to use a string like "altr,fpgamgr-gpio" at all, maybe just "generic-gpio". I would still see a value in having a specific driver for this specific hardware. But is this driver is too simple, to be acceptable? Bernd. ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
