linux-kernel - Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

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, 1 Apr 2009 15:43:43 +0200
From:	Juergen Beisert <jbe@...gutronix.de>
To:	linux-mtd@...ts.infradead.org
Cc:	Kay Sievers <kay.sievers@...y.org>,
	David Brownell <david-b@...bell.net>, dwmw2@...radead.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates

Hi David, Kay,

On Mittwoch, 1. April 2009, Kay Sievers wrote:
> On Tue, Mar 31, 2009 at 23:18, David Brownell <david-b@...bell.net> wrote:
> > On Thursday 26 March 2009, David Brownell wrote:
> >> From: David Brownell <dbrownell@...rs.sourceforge.net>
> >>
> >> Update driver model support in the MTD framework, so it fits
> >> better into the current udev-based hotplug framework:
> >
> > Hmm, no comments?  I had understood there was interest over on
> > the MTD side of things in exposing more information through
> > sysfs, to help avoid the need to add Even More Ioctls as part
> > of support for things like NAND chips with 4KB pages, or which
> > handle more than 4GBytes ...
>
> Please have a look at this. We got asked repeatedly to provide better
> hotplug/udev integration, and the patches, and having the parent
> device properly assigned, would solve some of the problems people run
> into currently.

Without patch:
--------------

$ udevadm info -a -p /sys/block/mtdblock0
[...]
  looking at device '/devices/virtual/block/mtdblock0':
    KERNEL=="mtdblock0"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="1"
    ATTR{removable}=="0"
    ATTR{size}=="256"
    ATTR{capability}=="10"
    ATTR{stat}=="       0        0        0        0        0        0        0        0        0        0        0"

And nearly the same data for the other flash device. No chance to detect if
this one is the NOR or the NAND type...

With the patch:
---------------

$ udevadm info -a -p /sys/block/mtdblock0
[...]
  looking at parent device '/devices/platform/physmap-flash.0':
    KERNELS=="physmap-flash.0"
    SUBSYSTEMS=="platform"
    DRIVERS=="physmap-flash"
    ATTRS{modalias}=="platform:physmap-flash"

The second flash device is of NAND type and 'udevadm' shows:

$ udevadm info -a -p /sys/block/mtdblock4
[...]
  looking at parent device '/devices/platform/mxc_nand.0':
    KERNELS=="mxc_nand.0"
    SUBSYSTEMS=="platform"
    DRIVERS=="mxc_nand"
    ATTRS{modalias}=="platform:mxc_nand"

\o/

I will try now to define some udev rules to match for my different flash
memories.

Thank you,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |
--
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/