All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Tony <tony.makkiel@daqri.com>,
	linux-leds@vger.kernel.org, rpurdie@rpsys.net,
	Len Brown <lenb@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v7 1/1] leds: LED driver for TI LP3952 6-Channel Color LED
Date: Tue, 05 Jul 2016 14:33:53 +0200	[thread overview]
Message-ID: <577BA931.5070403@samsung.com> (raw)
In-Reply-To: <CAJZ5v0iDD4WbnrENEdO+4qjOe2_db1-8W0yJePUmeVB57bCkzg@mail.gmail.com>

On 07/05/2016 02:12 PM, Rafael J. Wysocki wrote:
> On Tue, Jul 5, 2016 at 12:47 PM, Jacek Anaszewski
> <j.anaszewski@samsung.com> wrote:
>> PING
>>
>>
>> On 06/29/2016 12:54 PM, Jacek Anaszewski wrote:
>>>
>>> On 06/29/2016 12:07 PM, Tony wrote:
>>>>
>>>>
>>>> On 29/06/16 07:52, Jacek Anaszewski wrote:
>>>>>
>>>>> Hi Rafael,
>>>>
>>>>
>>>>>>> +#ifdef CONFIG_ACPI
>>>>>>> +static const struct acpi_device_id lp3952_acpi_match[] = {
>>>>>>> +    {LP3952_ACPI_NAME, 0},
>>>>>>
>>>>>>
>>>>>> No, you can't use "PRP0001" in this list.
>>>>>>
>>>>>>> +    {}
>>>>>>> +};
>>>>>>> +
>>>>>>> +MODULE_DEVICE_TABLE(acpi, lp3952_acpi_match);
>>>>>>
>>>>>>
>>>>>> And you don't need this for the "PRP0001" thing to work.  The core will
>>>>>> take care of it for you then.
>>>>>>
>>>>>>> +#endif
>>>>>>
>>>>>>
>>>>>> So the entire ACPI block can be dropped for now.
>>>>>>
>>>>>> And the driver doesn't have to depend on CONFIG_ACPI any more, does it?
>>>>>
>>>>>
>>>>> The driver currently supports probing only with ACPI.
>>>>> I have one question BTW: isn't there anything similar to the device tree
>>>>> bindings documentation required for ACPI overlays?
>>>>> Pointer to the discussion which led us to this solution:
>>>>>
>>>>> http://www.spinics.net/lists/linux-leds/msg06230.html
>>>>>
>>>> _DSD is working now. I managed to get "PRP0001" working as suggested by
>>>> Rafael in
>>>> http://marc.info/?l=linux-acpi&m=146711623115228&w=2
>>>> with _DSD
>>>
>>>
>>> Thanks for the link.
>>>
>>> Rafael, "Package" entries seem to mimic Device Tree properties defined
>>> in the common leds bindings. Would it be possible to make it even
>>> more compatible and define every LED connected to the LED controller
>>> in the form of a child node, similarly as in case of LED DT bindings?
>>>
>>> See Documentation/devicetree/bindings/leds/common.txt and other
>>> bindings in Documentation/devicetree/bindings/leds.
>
> I'm not sure what you mean.
>
> If somebody decides to arrange the data in their ACPI tables to follow
> that scheme, it will just work IMO.
>
> Is there anything more that needs to be done in the kernel here?

In case of Device Tree based platforms it is customary to define each
LED as a child node of the LED controller node. LED names can then
be obtained from the 'label' property or DT node name.
Tony has encountered some issues [1] while trying to follow this
pattern. Tony, could you please double check that?

[1] http://www.spinics.net/lists/linux-leds/msg06230.html

-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-07-05 12:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28 16:05 [PATCH v7 1/1] leds: LED driver for TI LP3952 6-Channel Color LED Tony Makkiel
2016-06-29  0:45 ` Rafael J. Wysocki
2016-06-29  6:52   ` Jacek Anaszewski
2016-06-29 10:07     ` Tony
2016-06-29 10:54       ` Jacek Anaszewski
2016-07-05 10:47         ` Jacek Anaszewski
2016-07-05 12:12           ` Rafael J. Wysocki
2016-07-05 12:33             ` Jacek Anaszewski [this message]
2016-07-05 13:14               ` Tony
2016-07-06 13:32               ` Jacek Anaszewski
2016-07-06 21:15                 ` Rafael J. Wysocki
2016-07-07  7:13                   ` Jacek Anaszewski
2016-07-07 10:35                     ` Tony
2016-07-07 11:09                       ` Jacek Anaszewski
2016-06-29 10:02   ` Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=577BA931.5070403@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rpurdie@rpsys.net \
    --cc=tony.makkiel@daqri.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.