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]
Date:	Wed, 22 Oct 2008 22:19:03 -0700
From:	David Brownell <david-b@...bell.net>
To:	avorontsov@...mvista.com
Cc:	benh@...nel.crashing.org, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org, i2c@...sensors.org,
	Jean Delvare <khali@...ux-fr.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls

On Wednesday 22 October 2008, Anton Vorontsov wrote:
> > 
> > So have it live in the __init text section...
> 
> Won't work, unfortunately. I2C devices are created by the
> i2c controllers, via drivers/of_i2c.c  of_register_i2c_devices().

And I'm pointing out a way to have the normal I2C core code
flow do that creation.  OF shouldn't need to be so much of a
special case.


> There is a good reason to do so, the code needs to know
> controller's OF node to walk down and register the child nodes
> (devices). See drivers/i2c/busses/i2c-mpc.c -- it calls
> of_register_i2c_devices() at the end of the probe().

I don't get it.  (But then, so much of the OF support seems
needlessly convoluted to me ... on top of seeming to be
insufficient for configuring board-specific details.)

There's an OF device tree, distinct from the Linux driver
model tree.  Why should there be any obstacle to accessing
records from that tree before the relevant driver model nodes
have been created?  Remember that the various board_info
structs get registered before the driver model nodes for
which they are templates.  Just translate the OF tree data
to those templates(*), then register them.

I understand that it's currently structured differetnly
than that ... consulting the OF tree "late" not early.
But that's still newish, and from what I've heard so far
it doesn't seem like the best structure either... nothing
seems to plug in smoothly.

- Dave

(*) The role of the board_info structs is very similar
    to the role of OF device attributes.  As is the role
    of the platform_data ... except that's more specific
    to the chip involved (and its driver), and expects
    any callbacks to be in C code not FORTH.
--
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