On Thu, Jun 7, 2018 at 11:28 PM, Simon Glass <[email protected]> wrote: > Hi Ramon, > > On 3 June 2018 at 14:32, Ramon Fried <[email protected]> wrote: >> On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried <[email protected]> wrote: >>> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt <[email protected]> >>> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
