[U-Boot] Generic uclass ID

[Ramon Fried]

On Thu, Jun 7, 2018 at 11:28 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Ramon,
>
> On 3 June 2018 at 14:32, Ramon Fried <ramon.fried at gmail.com> wrote:
>> On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried <ramon.fried at gmail.com> wrote:
>>> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>> On 06/02/2018 06:25 PM, Ramon Fried wrote:
>>>>> Hi Simon, all.
>>>>>
>>>>> I want to port a specific driver from Linux Kernel (Qualcomm smem)
>>>>> which is declared in Linux as platform device.
>>>>> The implementation is very specific and It doesn't fall into any
>>>>> defined uclass id.
>>>>> I still want to use the dm framework, what's the approach taken on
>>>>> these kind of things ?
>>>>> Is it possible to create a generic uclass id ?
>>>>
>>>> Hello Ramon,
>>>>
>>>> a major benefit of the driver model is that drivers are selected via the
>>>> device tree.
>>>>
>>>> In Linux the driver is in drivers/soc. Wouldn't it make sense to create
>>>> a minimal uclass for platform devices in drivers/soc on U-Boot?
>>>>
>>>> drivers/ram/ram-uclass.c shows what a minimal uclass looks like.
>>>> The identifier has to be added in include/dm/uclass-id.h.
>>>>
>>>> Best regards
>>>>
>>>> Heinrich
>>> Thanks for the comment Heinrich.
>>> My initial intention was to place the driver under drivers/soc and I
>>> do thing that
>>> creating a UCLASS_PLATFORM make sense, acutally, it's exaclt what I'm suggesting
>>> in a different name.
>>> The thing is that there's no apperent ops that I think will suit all
>>> the platform drivers as they're different in nature.
>>> So, I don't see any requirement to create a platform_uclass.c file.
>>>
>>> Thanks,
>>> Ramon.
>>
>> Added some initial contributors to uclass for comments.
>
> It's OK to create a uclass if you need to. What does your driver do?
Hi Simon, thanks for replying.
The driver purpose is to provide a way to access Qualcomm's shared
memory region and
to read and write properties to it accessed by other cores (Trustzone
for instance).
The Linux kernel driver I use as a reference
(https://elixir.bootlin.com/linux/latest/source/drivers/soc/qcom/smem.c)
relies heavily on device-tree bindings, and I wanted to keep as much
of the driver intact.

As this is very specific to Qualcomm, I don't think that it fits any
other UCLASS_ definition and thus I
suggested adding UCLASS_PLATFORM which is intended for platform
specific drivers/devices.

In such a case, the .ops will be empty as there isn't any shared
functionailty that can be generalized.

Does this make sense ? should I ditch the driver-module idea and just
implement it as piece of code under arch/arm/mach-snapdragon ?

Thanks,
Ramon.

>
> Regards,
> Simon