From: Walter Lozano <walter.lozano@collabora.com>
To: u-boot@lists.denx.de
Subject: [RFC] dm: uclass: add functions to get device by platdata
Date: Thu, 5 Mar 2020 10:54:10 -0300 [thread overview]
Message-ID: <d5d11dc7-8724-d1d2-44c3-06e39e4e20c1@collabora.com> (raw)
In-Reply-To: <CAPnjgZ14JEZY8oLmhwM9SVz4CaJ=eGBpWL9ftH+=-zZhVzcdNg@mail.gmail.com>
Hi Simon,
Thanks for taking the time to check for my comments
On 4/3/20 20:11, Simon Glass wrote:
> Hi Walter,
>
> On Wed, 4 Mar 2020 at 12:40, Walter Lozano <walter.lozano@collabora.com> wrote:
>> When OF_PLATDATA is enabled DT information is parsed and platdata
>> structures are populated. In this context the links between DT nodes are
>> represented as pointers to platdata structures, and there is no clear way
>> to access to the device which owns the structure.
>>
>> This patch implements a set of functions:
>>
>> - device_find_by_platdata
>> - uclass_find_device_by_platdata
>>
>> to access to the device.
>>
>> Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
>> ---
>> drivers/core/device.c | 19 +++++++++++++++++++
>> drivers/core/uclass.c | 34 ++++++++++++++++++++++++++++++++++
>> include/dm/device.h | 2 ++
>> include/dm/uclass-internal.h | 3 +++
>> include/dm/uclass.h | 2 ++
>> 5 files changed, 60 insertions(+)
> This is interesting. Could you also add the motivation for this? It's
> not clear to me who would call this function.
I have been reviewing the OF_PLATDATA support as an R&D project, in this context, in order to have
a better understanding on the possibilities and limitations I decided to add its support to iMX6,
more particularly to the MMC drivers. The link issue arises when I tried to setup the GPIO for
Card Detection, which is trivial when DT is available. However, when OF_PLATDATA is enabled
this seems, at least for me, not straightforward.
In order to overcome this limitation I think that having a set of functions to find/get devices
based on platdata could be useful. Of course, there might be a better approach/idea, so that is
the motivation for this RFC.
An example of the usage could be
#if CONFIG_IS_ENABLED(DM_GPIO)
??????? struct udevice *gpiodev;
??????? ret = uclass_get_device_by_platdata(UCLASS_GPIO, (void *)dtplat->cd_gpios->node, &gpiodev);
??????? if (ret)
??????????????? return ret;
??????? ret = gpio_dev_request_index(gpiodev, gpiodev->name, "cd-gpios",
dtplat->cd_gpios->arg[0], GPIOD_IS_IN,
???????????????????????????????????? dtplat->cd_gpios->arg[1], &priv->cd_gpio);
??????? if (ret)
??????????????? return ret;
#endif
This is part of my current work, a series of patches to add OF_PLATDATA support as explained.
Does this make sense to you?
> Also it relates to another thing I've been thinking about for a while,
> which is to validate that all the structs pointed to are correct.
>
> E.g. if every struct had a magic number like:
>
> struct tpm_platdata {
> DM_STRUCT(UCLASS_TPM, DM_STRUCT_PLATDATA, ...)
> fields here
> };
>
> then we could check the structure pointers are correct.
>
> DM_STRUCT() would define to nothing if we were not building with
> CONFIG_DM_DEBUG or similar.
Interesting, I think it could be useful and save us from headaches while debugging.
Thanks for sharing this idea.
> Anyway, I wonder whether you could expand your definition a bit so you
> have an enum for the different types of struct you can request:
>
> enum dm_struct_t {
> DM_STRUCT_PLATDATA,
> ...
>
> DM_STRUCT_COUNT,
> };
>
> and modify the function so it can request it via the enum?
Let me check if I understand correctly, your suggestion is to do
something like diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 92c07f8426..bf09dadf3f 100644 --- a/include/dm/uclass.h +++
b/include/dm/uclass.h
@@ -167,8 +167,8 @@ int uclass_get_device(enum uclass_id id, int index,
struct udevice **devp);
?int uclass_get_device_by_name(enum uclass_id id, const char *name,
????????????????????????????? struct udevice **devp); -int
uclass_get_device_by_platdata(enum uclass_id id, void *platdata,
-???????????????????????????? struct udevice **devp);
+int uclass_get_device_by_struct(enum uclass_id id, enum dm_struct_t
struct_id, +???????????????????????????? void *struct_pointer, struct
udevice **devp); ?/** ? * uclass_get_device_by_seq() - Get a uclass
device based on an ID and sequence ? *
If that is the case, I would be happy to help.
Also, if my understanding is correct, could you elaborate which cases
are you trying to cover with this approach? Regards,
Walter
next prev parent reply other threads:[~2020-03-05 13:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 19:40 [RFC] dm: uclass: add functions to get device by platdata Walter Lozano
2020-03-04 23:11 ` Simon Glass
2020-03-05 13:54 ` Walter Lozano [this message]
2020-03-05 14:06 ` Walter Lozano
2020-03-06 13:17 ` Simon Glass
2020-03-06 16:10 ` Walter Lozano
2020-03-06 20:32 ` Simon Glass
2020-03-09 18:26 ` Walter Lozano
2020-04-06 3:43 ` Simon Glass
2020-04-07 20:05 ` Walter Lozano
2020-04-08 3:14 ` Simon Glass
2020-04-09 18:57 ` Walter Lozano
2020-04-09 19:36 ` Simon Glass
2020-04-09 20:00 ` Walter Lozano
2020-04-17 21:18 ` Walter Lozano
2020-04-21 17:36 ` Simon Glass
2020-04-23 3:38 ` Walter Lozano
2020-05-06 12:57 ` Walter Lozano
2020-05-08 1:36 ` Simon Glass
2020-05-08 10:08 ` Walter Lozano
2020-05-08 13:18 ` Simon Glass
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=d5d11dc7-8724-d1d2-44c3-06e39e4e20c1@collabora.com \
--to=walter.lozano@collabora.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox