lkml.org 
[lkml]   [2017]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 15/17] dt-bindings: qca7000: append UART interface to binding
Hi,

Zitat von Jakub Kicinski <kubakici@wp.pl>:

> On Thu, 11 May 2017 21:12:22 +0200, Michael Heimpold wrote:
>> Am Mittwoch, 10. Mai 2017, 10:53:26 CEST schrieb Stefan Wahren:
>> > This merges the serdev binding for the QCA7000 UART driver (Ethernet over
>> > UART) into the existing document.
>> >
>> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> > ---
>> > .../devicetree/bindings/net/qca-qca7000.txt | 32
>> > ++++++++++++++++++++++ 1 file changed, 32 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/net/qca-qca7000.txt
>> > b/Documentation/devicetree/bindings/net/qca-qca7000.txt index
>> > a37f656..08364c3 100644
>> > --- a/Documentation/devicetree/bindings/net/qca-qca7000.txt
>> > +++ b/Documentation/devicetree/bindings/net/qca-qca7000.txt
>> > @@ -54,3 +54,35 @@ ssp2: spi@80014000 {
>> > local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
>> > };
>> > };
>> > +
>> > +(b) Ethernet over UART
>> > +
>> > +In order to use the QCA7000 as UART slave it must be defined as
>> a child of
>> > a +UART master in the device tree. It is possible to preconfigure the UART
>> > +settings of the QCA7000 firmware, but it's not possible to change them
>> > during +runtime.
>> > +
>> > +Required properties:
>> > +- compatible : Should be "qca,qca7000-uart"
>>
>> I already discussed this with Stefan off-list a little bit, but I would like
>> to bring this to a broader audience: I'm not sure whether the compatible
>> should contain the "-uart" suffix, because the hardware chip is the
>> very same
>> QCA7000 chip which can also be used with SPI protocol.
>> The only difference is the loaded firmware within the chip which can either
>> speak SPI or UART protocol (but not both at the same time - due to shared
>> pins). So the hardware design decides which interface type is used.
>>
>> At the moment, this patch series adds a dedicated driver for the UART
>> protocol, in parallel to the existing SPI driver. So a different compatible
>> string is needed here to match against the new driver.
>>
>> An alternative approach would be to re-use the existing compatible string
>> "qca,qca7000" for both, the SPI and UART protocol, because a "smarter"
>> (combined) driver would detect which protocol to use. For example the driver
>> could check for spi-cpha and/or spi-cpol which are required for SPI
>> protocol:
>> if these exists the driver could assume that SPI must be used, if both are
>> missing then UART protocol should be used.
>> (This way it would not be necessary to check whether the node is a child of
>> a SPI or UART master node - but maybe this is even easier - I don't know)
>>
>> Or in shorter words: my concern is that while "qca7000-uart" describes the
>> hardware, it's too closely coupled to the driver implementation. Having
>> some feedback of the experts would be nice :-)
>
> I'm no expert, but devices which can do both I2C and SPI are quite
> common, and they usually have the same compatible string for both
> buses.

do you have an example driver at hand? I only found GPIO mcp23s08 driver,
which can handle both I2C and SPI chips, but there are different compatible
strings used to distinguish several chip models.

Regards,
Michael


\
 
 \ /
  Last update: 2017-05-12 08:16    [W:0.105 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site