linux-kernel - Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C5AF854.4020502@codeaurora.org>
Date:	Thu, 05 Aug 2010 10:43:48 -0700
From:	Patrick Pannuto <ppannuto@...eaurora.org>
To:	Magnus Damm <magnus.damm@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"damm@...nsource.se" <damm@...nsource.se>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"rjw@...k.pl" <rjw@...k.pl>,
	"eric.y.miao@...il.com" <eric.y.miao@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>, alan@...rguk.ukuu.org.uk,
	zt.tmzt@...il.com
Subject: Re: [PATCH] platform: Facilitate the creation of pseduo-platform
 	busses

On 08/04/2010 07:32 PM, Magnus Damm wrote:
> On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto <ppannuto@...eaurora.org> wrote:
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>
>> RFC: http://lkml.org/lkml/2010/8/3/496
>> Patch is unchanged from the RFC. Reviews seemed generally positive
>> and it seemed this was desired functionality.
> 
> Thanks for your patch, it's really nice to see work done in this area!
> I'd like to see something like this merged in the not so distant
> future. At this point I'm not so concerned about the details, so I'll
> restrict myself to this:
> 
>> /drivers/my_driver.c
>>        static struct platform_driver my_driver = {
>>                .driver = {
>>                        .name   = "my-driver",
>>                        .owner  = THIS_MODULE,
>>                        .bus    = &my_bus_type,
>>                },
>>        };
> 
> I would really prefer not to have the bus type in the here. I
> understand it's needed at this point, but I wonder if it's possible to
> adjust the device<->driver matching for platform devices to allow any
> type of pseudo-platform bus_type.
> 
> The reason why I'd like to avoid having the bus type in the driver is
> that I'd like to reuse the platform driver across multiple
> architectures and buses. For instance, on the SH architecture and

So would I :). That's where this was all heading eventually, I was just
originally doing it in two passes. I have some ideas for how to do this
and will try to send out a patchset either today or tomorrow.

> SH-Mobile ARM we have SoCs with SCIF hardware blocks driven by the
> sh-sci.c serial driver. The sh-sci.c platform driver supports a wide
> range of different SCI(F)(A)(B) hardware blocks, and on any given SoC
> there is a mix of SCIF blocks spread out on different buses.
> 
> At this point our SH platform drivers are unaware where their driver
> instanced are located on the SoC. The I/O address and IRQs are
> assigned via struct resource and clocks are managed through clkdev. I
> believe that adding the bus type in the driver will violate this
> abstraction and make it more difficult to just instantiate a driver
> somewhere on the SoC.
> 
>> /somewhere/my_device.c
>>        static struct platform_device my_device = {
>>                .name           = "my-device",
>>                .id             = -1,
>>                .dev.bus        = &my_bus_type,
>>                .dev.parent     = &sub_bus_1.dev,
>>        };
> 
> This I don't mind at all. Actually, this is the place where the
> topology should be defined IMO.
> 

Agreed.

> Cheers,
> 
> / magnus


-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/