From: Bhanu Prakash Maiya <[email protected]>
Add DT compatible string in
Documentation/devicetree/bindings/mfd/cros_ec.txt
Signed-off-by: Bhanu Prakash Maiya <[email protected]>
---
Changes in v3:
- Rebased changes on google,cros-ec.yaml
Changes in v2:
- No change
Documentation/devicetree/bindings/mfd/google,cros-ec.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
index 6a7279a85ec1c..552d1c9bf3de4 100644
--- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
+++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
@@ -10,11 +10,12 @@ maintainers:
- Benson Leung <[email protected]>
- Enric Balletbo i Serra <[email protected]>
- Guenter Roeck <[email protected]>
+ - Bhanu Prakash Maiya <[email protected]>
description:
Google's ChromeOS EC is a microcontroller which talks to the AP and
implements various functions such as keyboard and battery charging.
- The EC can be connected through various interfaces (I2C, SPI, and others)
+ The EC can be connected through various interfaces (I2C, SPI, UART and others)
and the compatible string specifies which interface is being used.
properties:
@@ -29,6 +30,9 @@ properties:
- description:
For implementations of the EC is connected through RPMSG.
const: google,cros-ec-rpmsg
+ - description:
+ For implementations of the EC is connected through UART.
+ const: google,cros-ec-uart
google,cros-ec-spi-pre-delay:
description:
--
2.26.2
On Wed, Jul 15, 2020 at 10:16:04PM -0700, Bhanu Prakash Maiya wrote:
> From: Bhanu Prakash Maiya <[email protected]>
>
> Add DT compatible string in
> Documentation/devicetree/bindings/mfd/cros_ec.txt
Need to update this.
With that,
Reviewed-by: Rob Herring <[email protected]>
> Signed-off-by: Bhanu Prakash Maiya <[email protected]>
> ---
>
> Changes in v3:
> - Rebased changes on google,cros-ec.yaml
>
> Changes in v2:
> - No change
>
> Documentation/devicetree/bindings/mfd/google,cros-ec.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Hi Rob,
On 16/7/20 21:13, Rob Herring wrote:
> On Wed, Jul 15, 2020 at 10:16:04PM -0700, Bhanu Prakash Maiya wrote:
>> From: Bhanu Prakash Maiya <[email protected]>
>>
>> Add DT compatible string in
>> Documentation/devicetree/bindings/mfd/cros_ec.txt
>
> Need to update this.
>
> With that,
>
> Reviewed-by: Rob Herring <[email protected]>
>
So this is an ACPI-only driver that is instantiated by using the Device Tree
namespace link in ACPI. I am not sure how to deal with this, but I suspect we
need a proper OF binding definition before accept it.
The driver gets at least the baudrate and the flowcontrol from ACPI resources,
so I'm wondering if we should also add the properties in the device-tree
description (although we're not able to really test because there is not OF
hardware that supports it yet). Or is fine to just accept the compatible for now
and we can do this later when we have the possibility to test with OF-based
hardware.
Rob, any thoughts on this?
Thanks,
Enric
>> Signed-off-by: Bhanu Prakash Maiya <[email protected]>
>> ---
>>
>> Changes in v3:
>> - Rebased changes on google,cros-ec.yaml
>>
>> Changes in v2:
>> - No change
>>
>> Documentation/devicetree/bindings/mfd/google,cros-ec.yaml | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
On Fri, Jul 17, 2020 at 3:53 AM Enric Balletbo i Serra
<[email protected]> wrote:
>
> Hi Rob,
>
> On 16/7/20 21:13, Rob Herring wrote:
> > On Wed, Jul 15, 2020 at 10:16:04PM -0700, Bhanu Prakash Maiya wrote:
> >> From: Bhanu Prakash Maiya <[email protected]>
> >>
> >> Add DT compatible string in
> >> Documentation/devicetree/bindings/mfd/cros_ec.txt
> >
> > Need to update this.
> >
> > With that,
> >
> > Reviewed-by: Rob Herring <[email protected]>
> >
>
> So this is an ACPI-only driver that is instantiated by using the Device Tree
> namespace link in ACPI. I am not sure how to deal with this, but I suspect we
> need a proper OF binding definition before accept it.
In that case, NAK because I have no bandwidth or desire for ACPI
stuff. The DT bindings in ACPI concept is flawed.
> The driver gets at least the baudrate and the flowcontrol from ACPI resources,
> so I'm wondering if we should also add the properties in the device-tree
> description (although we're not able to really test because there is not OF
> hardware that supports it yet). Or is fine to just accept the compatible for now
> and we can do this later when we have the possibility to test with OF-based
> hardware.
That's all defined by the serial device binding already, so it doesn't
really matter here.
You can keep my R-by, but don't send me more ACPI crap.
Rob