Hello.
Stephen Neuendorffer wrote:
>>>Instead of attempting to come up with a generic description
>>>of this, I recommend just naming it after the actual device instance;
>>>something like compatible="xlnx,opb-uart16550";
>> Well, that means that we'll need a to add a code which "glues" the chip to
>>8250.c driver... well, of_serial.c could be that glue layer if we add to it
>>the ability to recognize Xilinx UART... well, legacy_serial.c could be taught
>>that trick too...
>> Well, we could also add the new compatible, but still claim "ns16550"
>>compatibility...
> This actually makes more sense to me... I'd rather have the code set
> the reg-shift than have it explicitly set in the device tree anyway.
> The compatibility set should include (at the least):
> opb_uart16550_v1_00_c
> opb_uart16550_v1_00_d
> opb_uart16550_v1_00_e
> plb_uart16550_v1_00_c
> xps_uart16550_v1_00_a
Sounds like too much? Couldn't this be handled via the "model" prop?
> I think this is somewhat independent of Sergei's arguments that generic
> ns16550 devices should allow having a reg-shift set....
> Steve
WBR, Sergei
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
