Message-ID: <20210507115319.22109-1-campion.kang@advantech.com.tw>
Date:   Fri, 7 May 2021 19:53:19 +0800
From:   Campion Kang <campion.kang@...antech.com.tw>
To:     <hdegoede@...hat.com>
CC:     <andy.shevchenko@...il.com>, <campion.kang@...antech.com.tw>,
        <chia-lin.kao@...onical.com>, <corbet@....net>,
        <devicetree@...r.kernel.org>, <jdelvare@...e.com>,
        <lee.jones@...aro.org>, <linux-doc@...r.kernel.org>,
        <linux-hwmon@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-watchdog@...r.kernel.org>, <linux@...ck-us.net>,
        <mgross@...ux.intel.com>, <platform-driver-x86@...r.kernel.org>,
        <robh+dt@...nel.org>, <wim@...ux-watchdog.org>
Subject: Re: [PATCH v7 1/7] MAINTAINERS: Add Advantech AHC1EC0 embedded controller entry

Hi, Very thanks your time for reviewing.

>-----Original Message-----
>From: Hans de Goede <hdegoede@...hat.com>
>Sent: Thursday, May 6, 2021 5:39 PM
>Subject: Re: [PATCH v7 1/7] MAINTAINERS: Add Advantech AHC1EC0 embedded
>controller entry
>
>Hi,
>
>On 5/6/21 11:23 AM, Andy Shevchenko wrote:
>> On Thu, May 6, 2021 at 11:48 AM Hans de Goede <hdegoede@...hat.com>
>wrote:
>>> I'm replying here since this series has no cover-letter, for
>>> the next version for a series touching so many different
>>> sub-systems it would be good to start with a cover-letter
>>> providing some background info on the series.
>>>

Sorry about that, i will study what is cover-letter and its content.
Would you kindly provide me a good reference?
Can I resend a [Patch v7 0/7] for these patch or provide it in next version?


>>> I see this is binding to an ACPI device, yet it is also using
>>> devicetree bindings and properties.
>>>
>>> So I take it this means that your ACPI tables are using the
>>> optional capability of embedded device-tree blobs inside the
>>> ACPI tables ?
>>>
>>> That is an unusual combination on a x86 device, note it is
>>> not wrong
>>
>> It's actually not okay. We have agreed at some point with DT people,
>> that ACPI should not use non-native variants of natively supported
>> things. For example, it shouldn't use "interrupt" property for IOxAPIC
>> (or xIC) provided interrupts, rather Interrupt() has to be used and so
>> on.

In our experience, most risc platforms are using devicetree, and x86/64 platforms
are using ACPI table or grub configure for their specific settings in different HW paltform.
In this case, EC chip is a LPC interface that can be integrated in whenever risc or x86/64.
So in my understand, I think it is not conflict.
(please correct me if i am misunderstanding, i will try to describe more)

If the EC chip is connected to the risc processor, we will bind its properties in the device-tree without modifing the source.
If the EC chip is connected to the X86/64 processor, we bind its the properties in the ACPI table and also without modifing the source.
Why do we need to bind the properties in ACPI or in the device-tree? Because it is an LPC interface, it cannot automatically load the driver like a USB or PCI device.
In the early days, we had to install the EC driver module in our HW platform and manually load it at every boot. Different Advantech HW platforms have different properties for HWMON and others sub-systems. This causes the EC source to be a bit dirty. It is necessary to obtain the hardware platform name from the BIOS DMI table and determine its attributes according to its platform name.
Now bind the attributes to ACPI table or device-tree, the EC source is more clear and universal for Advantech devices, and it is important that if the ACPI table matches, it can be automatically loaded.

>
>Right, but that is not the case here, they are using 2 device-tree
>properties (1), from patch 3/7:
>
>+properties:
>+  compatible:
>+    const: advantech,ahc1ec0
>+
>+  advantech,hwmon-profile:
>+    description:
>+      The number of sub-devices specified in the platform. Defines for the
>+      hwmon profiles can found in dt-bindings/mfd/ahc1ec0-dt.
>+    $ref: /schemas/types.yaml#/definitions/uint32
>+    maxItems: 1
>+
>+  advantech,has-watchdog:
>+    description:
>+      Some implementations of the EC include a watchdog used to monitor
>the
>+      system. This boolean flag is used to specify whether this watchdog is
>+      present or not. Default is true, otherwise set to false.
>+    type: boolean
>
>
>>> but AFAIK you are the first to do this on x86.
>>
>> No, not the first. Once Intel tried to invent the pin control
>> configuration and muxing properties in ACPI, it was luckily rejected
>> (ACPI 6.x OTOH provides a set of special resources for that).
>>
>> So, NAK from me, *if* it's really the case. ACPI tables must be revisited.
>

I am not sure it supports vendor self-defined attributes for ACPI table?

>AFAIK Advantech are not defining things for which an ACPI standard exists,
>although these 2 properties might just as well may be 2 simple ACPI integer
>methods, which would actually make things a bit simpler (.e.g it would
>allow dropping patch 2/7 and 3/7 from the set).
>
>Campion, any reason why you went this route; and can the ACPI tables
>still be changed?
>

If patches 2/7 and 3/7 are removed, it will be even simpler.
This means that there is no device-tree binding designed, in fact, the EC chip only be integrated in the x86/64 platform at present.
Sorry, ACPI table now is integrated in the BIOS for Advantech UNO device, 
it may be revert to previous rule, that is, there is no ACPI table binding and manually loaded the EC driver. If you have any suggestons I would be very grateful.

>Regards,
>
>Hans

Powered by blists - more mailing lists