[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071106175114.62284a6c@hyperion.delvare>
Date: Tue, 6 Nov 2007 17:51:14 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: "Jon Smirl" <jonsmirl@...il.com>
Cc: lkml <linux-kernel@...r.kernel.org>, i2c@...sensors.org
Subject: Re: [i2c] [PATCH] Fix i2c module parameter permissions for
read/write
Hi Jon,
On Sun, 4 Nov 2007 08:39:49 -0500, Jon Smirl wrote:
> I figured out later by inserting printks into the driver that they
> were being set from the command line, but without changing the
> permissions there was no way to read them to verify. The permissions
> should at least be set to 0444 to allow them to be read.
There's nothing to "verify" - the code works as intended, that's about
it.
> IMHO the I2C_CLIENT_INSMOD macros could use some rework since they use
> side effects to set variables without being explicit about it.
I don't understand what you mean here. Can you please be more specific?
> The real problem was unrelated to this, it was an off by one error in
> the i2c bus numbering code of my embedded processor. That made the
> parameters not work since I was setting them on a different bus.
>
> Changed to 0444.
I'd rather not do that. The i2c core uses I2C_CLIENT_MODULE_PARM()
extensively and I don't really want to create dozens of additional
sysfs files for no good reason. If you want your own parameter to be
readable (or even writable if it makes sense - you didn't show the
code) I'd rather suggest adding a parameter to I2C_CLIENT_MODULE_PARM()
to let the caller decide what mode the attribute should have, setting
the mode to 0 for all the core parameters.
That being said, this whole set of macros in i2c.h is a complete mess
and with David Brownell's work on the i2c-core, using them should
become less necessary over time. Ultimately I'd be happy to get rid of
them completely.
Thanks,
--
Jean Delvare
-
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