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] [day] [month] [year] [list]
Message-ID: <20070426200732.529eddc7@vitb.ru.mvista.com>
Date:	Thu, 26 Apr 2007 20:07:32 +0400
From:	Vitaly Bordug <vitb@...nel.crashing.org>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	"linuxppc-dev@...abs.org" <linuxppc-dev@...abs.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] i2c: adds support for i2c bus on 8xx

On Thu, 26 Apr 2007 17:54:38 +0200
Jean Delvare <khali@...ux-fr.org> wrote:

> Hi Vitaly,
> 
> On Wed, 25 Apr 2007 21:06:10 +0400, Vitaly Bordug wrote:
> > Jean Delvare wrote:
> > >>>> +/* Structure for a device driver */
> > >>>> +static struct device_driver i2c_rpx_driver = {
> > >>>> +	.name = "fsl-i2c-cpm",
> > >>>> +	.bus = &platform_bus_type,
> > >>>> +	.probe = i2c_rpx_probe,
> > >>>> +	.remove = i2c_rpx_remove,
> > >>>> +};
> > >>>>         
> > >>> Why don't you declare it as a struct platform_driver, register it with
> > >>> platform_driver_register() and unregister it with
> > >>> platform_driver_unregister()?
> > >>>       
> > >> Well. This stuff belongs to CPM1, of the mpc8xx family, but the
> > >> target boards are different, and they may/should provide board
> > >> specific inits and filling of platform data. With
> > >> platform_driver_register we may end up with ifdef stuff here
> > >> (which is evil).
> > >>     
> > >
> > > I don't follow you here, sorry. Platform devices are declared by
> > > board-specific code which can include all the needed initialization.
> > > And device-specific data can be carried to the platform driver for
> > > further use. The platform device/driver infrastructure is meant to
> > > handle that kind of situation, so there really is no excuse that I can
> > > see not to use it. i2c-omap and i2c-mpc use it. As a matter of fact you
> > > _are_ declaring a platform driver (.bus = &platform_bus_type), just not
> > > using the standard way.
> > >
> > >   
> > Standard way here - platform devices got registered from elsewhere - 
> > from arch/ppc/ppc_sys.c if arch/ppc or from 
> > arch/powerpc/sysdev/fsl_soc.c if powerpc.
> > Every way (powerpc is more flexible since is pulling the information 
> > from the firmware-passed device tree) fills in the resources and 
> > platform data, and
> > is capable with device/drive bound you are talking about.
> 
> This doesn't explain why you can't use platform_driver_register(),
> which is the right way to register a platform driver.

Ahm, I clearly confused myself (with device/driver stuff), sorry.

Anyway I think we'll look at of_device for this, to reduce extract from OF->insert platform device overhead.


-- 
Sincerely, 
Vitaly
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ