linux-kernel - Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM driver

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:	Sat, 21 May 2011 11:31:32 -0400
From:	Chris Metcalf <cmetcalf@...era.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Greg KH <gregkh@...e.de>,
	Eric Biederman <ebiederm@...stanetworks.com>,
	<linux-kernel@...r.kernel.org>, Chris Wright <chrisw@...s-sol.org>,
	Benjamin Thery <benjamin.thery@...l.net>,
	Phil Carmody <ext-phil.2.carmody@...ia.com>
Subject: Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM
 driver

On 5/21/2011 11:02 AM, Arnd Bergmann wrote:
> On Saturday 21 May 2011 15:52:39 Chris Metcalf wrote:
>> Sounds like the consensus is that a character driver is in fact the best
>> option here.
> At least the one that meets the least resistance ;-)

Well, perhaps that's what I meant :-)  I do take Greg K-H's point that we
don't really want to mess with the cleanliness of the bin_attribute API,
though.

> The general tendency is to always group drivers by their purpose these
> days, instead of by the bus or other interface that they are attached
> to. I would definitely prefer grouping it with drivers of the same
> purpose.
>
> The main reason is to make sure that a driver writer can easily find
> existing drivers with the same purpose take them as example code, so
> that new code uses the same API as existing code.
>
> If you want to keep the srom.c driver with a chardev interface for
> the SPI chip only, I would recommend sticking it into drivers/char/
> for now, or possibly a new drivers/char/flash/.

I will plan to push it to drivers/char/tile-srom.c for now, then.

> I have agreed to take over future maintainership of drivers/char and
> driver/misc during UDS in Budapest, basically to keep random
> stuff from getting added there, so I will try to find a better place
> for flash drivers like this.

I'll add my thanks for helping keep the kernel a better place.  It's great
that there are folks like yourself who are willing to devote time to code
and structural cleanliness rather than just shoving in whatever they can
get away with :-)

> Can you explain why there are both i2c and spi drivers? If they
> have the same purpose (e.g. providing a place to store the kernel
> binary) and same data layout, I would recommend using the
> same user interface for both.

The I2C eeprom driver can't be used to store the boot stream, just the SPI
driver; the I2C eeprom driver is mostly for customer use.  In fact the
drivers are similar enough that I rewrote the SPI driver for sysfs first,
since it was harder, but then found that grafting in support for the I2C
driver was pretty easy, since all I had to do was add some
conditionalization (different "chunk" size for writes, no need for write
retries during sector erase, no support for page_size and sector_size
attributes).  The absence of "size" attributes for the I2C driver is the
only visible user interface difference, but it's fundamental to the devices.

It's tempting to combine the drivers into one, but it feels like we might
as well publish the I2C driver with the other eeprom sysfs drivers, and the
SPI driver as a character device, as discussed.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

--
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/