* Re: [PATCH 3/3] Freescale enhanced Local Bus Controller FCM NAND support.
From: Stephen Rothwell @ 2008-01-14 6:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20080111204320.GC11215@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:43:20 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +static int __devinit fsl_elbc_ctrl_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + child = NULL;
> + while ((child = of_get_next_child(ofdev->node, child)))
for_each_child_of_node(of_dev->node, child)
> + if (of_device_is_compatible(child, "fsl,elbc-fcm-nand"))
> + fsl_elbc_chip_probe(ctrl, child);
> +static struct of_device_id fsl_elbc_match[] = {
const, please.
> +static struct of_platform_driver fsl_elbc_ctrl_driver = {
.driver = {
> + .name = "fsl-elbc",
},
> + .match_table = fsl_elbc_match,
> + .probe = fsl_elbc_ctrl_probe,
> + .remove = __devexit_p(fsl_elbc_ctrl_remove),
> +};
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-14 6:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <20080111204316.GB11215@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:43:16 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/drivers/mtd/ofpart.c
> +int __devinit of_mtd_parse_partitions(struct device *dev,
> + nr_parts = 0;
> + for (pp = node->child; pp; pp = pp->sibling)
for_each_child_of_node(node, pp)
> + nr_parts++;
> + for (pp = of_get_next_child(node, NULL), i = 0; pp;
> + pp = of_get_next_child(node, pp), i++) {
i = 0;
for_each_child_of_node(node, pp) {
> + const u32 *reg;
> + int len;
> +
> + reg = of_get_property(pp, "reg", &len);
> + if (!reg || (len != 2*sizeof(u32))) {
Spaces around '*'.
> + of_node_put(pp);
> + dev_err(dev, "Invalid 'reg' on %s\n", node->full_name);
> + kfree(*pparts);
> + *pparts = NULL;
> + return -EINVAL;
> + }
> + (*pparts)[i].offset = reg[0];
> + (*pparts)[i].size = reg[1];
> +
> + partname = of_get_property(pp, "label", &len);
> + if (!partname)
> + partname = of_get_property(pp, "name", &len);
> + (*pparts)[i].name = (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + (*pparts)[i].mask_flags = MTD_WRITEABLE;
i++;
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Stephen Rothwell @ 2008-01-14 5:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200742.GB696@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
Hi Scott,
On Fri, 11 Jan 2008 14:07:42 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/82xx/ep8248e.c
> +static struct mdiobb_ops ep8248e_mdio_ops = {
const, please.
> +static struct of_platform_driver ep8248e_mdio_driver = {
.driver = {
> + .name = "ep8248e-mdio-bitbang",
},
> +static const struct cpm_pin ep8248_pins[] = {
Could be __initdata
> +static void __init ep8248_setup_arch(void)
> +{
> + ep8248e_bcsr_node =
> + of_find_compatible_node(NULL, NULL, "fsl,ep8248e-bcsr");
> + if (!ep8248e_bcsr_node) {
> + printk(KERN_ERR "No bcsr in device tree\n");
> + return;
> + }
> +
> + ep8248e_bcsr = of_iomap(ep8248e_bcsr_node, 0);
> + if (!ep8248e_bcsr) {
> + printk(KERN_ERR "Cannot map BCSR registers\n");
of_node_put(ep8248e_bcsr_node);
ep8248e_bcsr_node = NULL;
> + return;
> +static int __init declare_of_platform_devices(void)
> +{
> + if (!machine_is(ep8248))
> + return 0;
> +
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> + of_register_platform_driver(&ep8248e_mdio_driver);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
machine_device_initcall(ep8248, declare_of_platform_devices);
Then remove the machine_is test above.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Olof Johansson @ 2008-01-14 5:24 UTC (permalink / raw)
To: Linas Vepstas; +Cc: lkessler, linuxppc-dev, Nathan Lynch, mahuja, strosake
In-Reply-To: <3ae3aa420801110857l5e43fd56s5bd1c24ffac939f3@mail.gmail.com>
On Fri, Jan 11, 2008 at 10:57:51AM -0600, Linas Vepstas wrote:
> On 10/01/2008, Nathan Lynch <ntl@pobox.com> wrote:
> > Mike Strosaker wrote:
> > >
> > > At the risk of repeating what others have already said, the PHYP-assistance
> > > method provides some advantages that the kexec method cannot:
> > > - Availability of the system for production use before the dump data is
> > > collected. As was mentioned before, some production systems may choose not
> > > to operate with the limited memory initially available after the reboot,
> > > but it sure is nice to provide the option.
> >
> > I'm more concerned that this design encourages the user to resume a
> > workload *which is almost certainly known to result in a system crash*
> > before collection of crash data is complete. Maybe the gamble will
> > pay off most of the time, but I wouldn't want to be working support
> > when it doesn't.
>
> Workloads that cause crashes within hours of startup tend to be
> weeded-out/discovered during pre-production test of the system
> to be deployed. Since its pre-production test, dumps can be
> taken in a leisurely manner. Heck, even a session at the
> xmon prompt can be contemplated.
>
> The problem is when the crash only reproduces after days or
> weeks of uptime, on a production machine. Since the machine
> is in production, its got to be brought back up ASAP. Since
> its crashing only after days/weeks, the dump should have
> plenty of time to complete. (And if it crashes quickly after
> that reboot ... well, support people always welcome ways
> in which a bug can be reproduced more quickly/easily).
How do you expect to have it in full production if you don't have all
resources available for it? It's not until the dump has finished that you
can return all memory to the production environment and use it.
This can very easily be argued in both direction, with no clear winner:
If the crash is stress-induced (say a slashdotted website), for those
cases it seems more rational to take the time, collect _good data_ even
if it takes a little longer, and then go back into production. Especially
if the alternative is to go back into production immediately, collect
about half of the data, and then crash again. Rinse and repeat.
Anyway -- I can agree that some of the arguments w.r.t robustness and
reliability of collecting dumps can be higher using this approach. It
really surprises me that there's no way to reset a device through PHYP
though. Seems like such a fundamental feature.
I think people are overly optimistic if they think it'll be possible
to do all of this reliably (as in with consistent performance) without
a second reboot though. At least without similar amounts of work being
done as it would have taken to fix kdump's reliability in the first place.
Speaking of reboots. PHYP isn't known for being quick at rebooting a
partition, it used to take in the order of minutes even on a small
machine. Has that been fixed? If not, the avoiding an extra reboot
argument hardly seems like a benefit versus kdump+kexec, which reboots
nearly instantly and without involvement from PHYP.
-Olof
^ permalink raw reply
* Problem booting Linux 2.6 on Virtex-4
From: David Baird @ 2008-01-14 5:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having trouble with getting Linux to boot farther than early_init.
Things start to go obviously wrong after early_init calls memset to
clear the .bss section. The first symptom I noticed was that the
stack (which currently contains the link register) was getting zeroed
by memset. This doesn't make any sense because the stack does not
intersect the .bss section; I confirmed that the do not intersect by
using JTAG+xmd to read the registers and also by inserting print
statements.
So, I experimented further and discovered that different memory
regions seem to be aliased on to each other every 2*32*256 bytes.
e.g.:
char * ptr = 0;
unsigned long addr = 0xc0001234; // pick some address
int n = 1; // pick some integer
// Now write values to two different addresses:
ptr[addr] = 42;
ptr[addr + n*2*32*256] = 24;
volatile asm ("nop");
// Now mysteriously, ptr[addr] == 24
The reason I have written 32*256 is because that corresponds to the
number of bytes per cache line times the number of cache lines ...
because I was suspicious this might be related to caching. However,
with experimentation, I found that the aliasing does not occur every
32*256 bytes, but rather every 32*512 bytes (hence 2*32*256).
Anyways, I looked in embed_config (and confirmed by dumping zImage.elf
with objdump) that the cache is being invalidated with "dccci".
"dccci" is being called, as expected, and therefore everything looks
good in the code.
I am completely perplexed. The cache appears to be initialized
properly. I don't have any trouble in real mode. But as soon the
kernel switches into virtual mode (in head_4xx.S), then this memory
aliasing problem happens. I wrote a completely standalone assembler
script that initializes the cache, TLBs, and virtual mode in the same
way as embed_config and head_4xx.S and so I am able to reproduce the
problem outside of the kernel. I can attach that code if someone
thinks it will be useful - just let me know.
Does anyone have an idea about what might be going wrong? I can send
more information or test anything that you want me to.
-David
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-14 4:55 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051041.18173.sr@denx.de>
Stefan Roese wrote:
>
>> +#ifdef CONFIG_TACO
>> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
>> + * the taco!
>> + */
>>
>
> We definitely don't want to see such board specific stuff in the common
> NDFC driver. And I really doubt that you need this change for your board.
> We are using this ndfc driver on multiple boards, and all have no
> problems accessing the controller with 32bit read/writes. So you most
> likely have a problem with your board port. Perhaps something with
> with the EBC setup. Please re-check and compare with boards that are know
> to work, like Sequoia.
>
How about adding a config option that lets you specify 8 bit access?
Something like CONFIG_NDFC_8BIT_ACCESS. We could default it to no and
put a little blurb that says something like:
On some platforms the 32bit read/writes cause a machine access
exception. If you get a machine access exception while reading the NAND
bad block table, try turning on 8 bit access.
Cheers,
Sean
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Olof Johansson @ 2008-01-14 4:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, ppc-dev
In-Reply-To: <fa686aa40801131635o499c8c08i6a2667cd7df1a72e@mail.gmail.com>
On Sun, Jan 13, 2008 at 05:35:09PM -0700, Grant Likely wrote:
> On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
> >
> > Hi guys,
> >
> > I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> > for it) and have not found any CAN bus documentation for device trees.
> >
> > I want to update the firmware tree to add these but, am basically looking
> > for those docs, or someone to go over a few points.. is there some kind of
> > tree standard I should be looking at, or some patch I missed which has
> > a driver which implements something that looks at a compatible tree?
>
> I think some consensus has been achieved for describing i2c busses and
> their attached devices, but I don't think booting-without-of.txt has
> been updated with the details yet. I need to look into that more.
I think simple devices might have been agreed upon (but it's been a
while since it was covered). Muxed busses probably hasn't. Either that
or I completely missed the emails.
-Olof
^ permalink raw reply
* Re: Enable RTC for Ebony and Walnut (v2)
From: David Gibson @ 2008-01-14 4:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080111172957.c0431145.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
On Fri, Jan 11, 2008 at 05:29:57PM +1100, Stephen Rothwell wrote:
> On Fri, 11 Jan 2008 14:25:34 +1100 David Gibson <dwg@au1.ibm.com> wrote:
> >
> > +++ working-2.6/arch/powerpc/sysdev/of_rtc.c 2008-01-11 14:17:03.000000000 +1100
>
> > +static __initdata struct {
> > + const char *compatible;
>
> If you make this an array, then the string will become __initdata as well.
Well, yes, but then I'd have to pick a specific size for the string.
Since this is supposed to be a stopgap until I can build a more
general constructor mechanism..
> > + char *plat_name;
> > +} of_rtc_table[] = {
> > + { "ds1743-nvram", "rtc-ds1742" },
> > +};
>
> > + platform_device_register_simple(plat_name, -1, res, 1);
>
> Do we care if this fails?
Well.. sort of, but there's not really any sane way of reporting it.
This will be called from early platform init code, failures shouldn't
cause us not to boot, and failure to register one rtc shouldn't cause
us not to attempt to register others if they're present.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: I2C and CAN bus on MPC5200B device tree
From: Grant Likely @ 2008-01-14 0:35 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <478A967E.7080201@genesi-usa.com>
On 1/13/08, Matt Sealey <matt@genesi-usa.com> wrote:
>
> Hi guys,
>
> I know the I2C stuff is up in the air (I cannot pinpoint the documentation
> for it) and have not found any CAN bus documentation for device trees.
>
> I want to update the firmware tree to add these but, am basically looking
> for those docs, or someone to go over a few points.. is there some kind of
> tree standard I should be looking at, or some patch I missed which has
> a driver which implements something that looks at a compatible tree?
I think some consensus has been achieved for describing i2c busses and
their attached devices, but I don't think booting-without-of.txt has
been updated with the details yet. I need to look into that more.
I don't think anyone has tackled CAN. Best bet is to draft a tree in
the way you think it should be described and post it to the list.
That will give a starting point for us to discuss it and come to
consensus.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: David Gibson @ 2008-01-14 0:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200705.GA696@loki.buserror.net>
On Fri, Jan 11, 2008 at 02:07:05PM -0600, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> + aliases {
> + console = &console;
> + enet0 = ð0;
> + enet1 = ð1;
I think most other boards are settling on aliases "ethernet0"
etc. instead of "enet0" (though there's no reason you couldn't have
both.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* I2C and CAN bus on MPC5200B device tree
From: Matt Sealey @ 2008-01-13 22:53 UTC (permalink / raw)
To: ppc-dev, linuxppc-embedded
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically looking
for those docs, or someone to go over a few points.. is there some kind of
tree standard I should be looking at, or some patch I missed which has
a driver which implements something that looks at a compatible tree?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jean Delvare @ 2008-01-13 19:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910801131050h5349f3c7g459f5dfb07724b19@mail.gmail.com>
On Sun, 13 Jan 2008 13:50:46 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > The eeprom case might be a bit confusing because that i2c driver
> > supports a single device type, so the driver name is the same as the
> > device name. Take a look at the hwmon/lm90 driver for a better example:
> > this device supports 7 different devices. The devices are mostly
> > compatible so it made sense to have a single driver for them, but they
> > all differ in some way. For example, the LM90 doesn't support PEC,
> > while the ADM1032 does. User-space needs to be able to distinguish
> > between the various types. That's the reason why we export the device
> > name through sysfs.
> >
> > Most i2c sensor drivers support several chip types, and libsensors has
> > been relying heavily on the name attribute. Less so with the lm-sensors
> > 3.0.0 rewrite, where most things are automatically detected, but if
> > nothing else, giving humans a way to distinguish between the different
> > sensor chip types is very useful. Also, not everyone will upgrade to
> > lm-sensors 3.0.0 so we need to keep supporting the previous versions.
>
> Another way to handle this is to have the drivers register multiple
> times using different names. So LM90 would register as both LM90 and
> ADM1032. All the code is shared, you just register it multiple times
> under different names.
This won't let us get rid of the name attribute. As I repeatedly
explained, removing that file now would instantly break at least all
versions of lm-sensors before 3.0.0. This alone is enough to make it
unacceptable for the years to come.
Not to mention that this seems like a waste of kernel memory. The name
attribute certainly takes one order of magnitude less memory than
registering the same driver multiple times.
I'm not sure why you want these i2c chip names to go way, given that
the module aliases you'd like to add are almost the same, just in a
different form and using OF names instead of arbitrary names.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2008-01-13 18:50 UTC (permalink / raw)
To: Jean Delvare; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <20080113194523.51683e97@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Jon,
>
> On Sun, 13 Jan 2008 13:01:06 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare wrote:
> > > On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > > > The kernel automatically exposes modalias as a sysfs attribute so the
> > > > string must be recorded further down in the driver support layers. No
> > > > need to keep a copy in the i2c structure.
> > >
> > > Really? I didn't know that. So that's another thing that the i2c
> > > subsystem is not doing like the rest of the kernel? Can you please
> > > point me to the code that does this?
> >
> > I never noticed it before either. Just do find | grep modalias in /sys
> > and see that every driver has a modalias attribute. It is probably
> > implement in drivers/base.
>
> This doesn't mean that the kernel does this automatically! It could
> also be that each subsystem does it on its own. Given that the format of
> the modalias depends on the bus type, it wouldn't be all that
> surprising. Anyway, I'll go look at how the other subsystems handle it
> before going on.
>
> > > > Standard devices don't export a 'name' attribute. To see the driver
> > > > name for a device in sysfs look at the 'driver' link.
> > >
> > > The driver name and the device name are different things! The "name"
> > > attribute that i2c devices have tells user-space the device name, not
> > > the driver name.
> >
> > For this system my i2c device names are:
> > 0-0050 0-0051 0-0052 0-0053
>
> These are not device names, these are device bus IDs. They tell you how
> to access the devices, but they do not tell you what these devices are.
>
> > How does the name=eeprom attribute interact with this? All four of my
> > devices have name=eeprom. What is the name field used for in user
> > space?
>
> The eeprom case might be a bit confusing because that i2c driver
> supports a single device type, so the driver name is the same as the
> device name. Take a look at the hwmon/lm90 driver for a better example:
> this device supports 7 different devices. The devices are mostly
> compatible so it made sense to have a single driver for them, but they
> all differ in some way. For example, the LM90 doesn't support PEC,
> while the ADM1032 does. User-space needs to be able to distinguish
> between the various types. That's the reason why we export the device
> name through sysfs.
>
> Most i2c sensor drivers support several chip types, and libsensors has
> been relying heavily on the name attribute. Less so with the lm-sensors
> 3.0.0 rewrite, where most things are automatically detected, but if
> nothing else, giving humans a way to distinguish between the different
> sensor chip types is very useful. Also, not everyone will upgrade to
> lm-sensors 3.0.0 so we need to keep supporting the previous versions.
Another way to handle this is to have the drivers register multiple
times using different names. So LM90 would register as both LM90 and
ADM1032. All the code is shared, you just register it multiple times
under different names.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jean Delvare @ 2008-01-13 18:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910801131001o604c1474vc2fd021d32b8c2a3@mail.gmail.com>
Hi Jon,
On Sun, 13 Jan 2008 13:01:06 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare wrote:
> > On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > > The kernel automatically exposes modalias as a sysfs attribute so the
> > > string must be recorded further down in the driver support layers. No
> > > need to keep a copy in the i2c structure.
> >
> > Really? I didn't know that. So that's another thing that the i2c
> > subsystem is not doing like the rest of the kernel? Can you please
> > point me to the code that does this?
>
> I never noticed it before either. Just do find | grep modalias in /sys
> and see that every driver has a modalias attribute. It is probably
> implement in drivers/base.
This doesn't mean that the kernel does this automatically! It could
also be that each subsystem does it on its own. Given that the format of
the modalias depends on the bus type, it wouldn't be all that
surprising. Anyway, I'll go look at how the other subsystems handle it
before going on.
> > > Standard devices don't export a 'name' attribute. To see the driver
> > > name for a device in sysfs look at the 'driver' link.
> >
> > The driver name and the device name are different things! The "name"
> > attribute that i2c devices have tells user-space the device name, not
> > the driver name.
>
> For this system my i2c device names are:
> 0-0050 0-0051 0-0052 0-0053
These are not device names, these are device bus IDs. They tell you how
to access the devices, but they do not tell you what these devices are.
> How does the name=eeprom attribute interact with this? All four of my
> devices have name=eeprom. What is the name field used for in user
> space?
The eeprom case might be a bit confusing because that i2c driver
supports a single device type, so the driver name is the same as the
device name. Take a look at the hwmon/lm90 driver for a better example:
this device supports 7 different devices. The devices are mostly
compatible so it made sense to have a single driver for them, but they
all differ in some way. For example, the LM90 doesn't support PEC,
while the ADM1032 does. User-space needs to be able to distinguish
between the various types. That's the reason why we export the device
name through sysfs.
Most i2c sensor drivers support several chip types, and libsensors has
been relying heavily on the name attribute. Less so with the lm-sensors
3.0.0 rewrite, where most things are automatically detected, but if
nothing else, giving humans a way to distinguish between the different
sensor chip types is very useful. Also, not everyone will upgrade to
lm-sensors 3.0.0 so we need to keep supporting the previous versions.
--
Jean Delvare
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-13 18:04 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080113184337.5d4cd546@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > > Teach module-init-tools about the i2c subsystem.
> > > > >
> > > > > Can you please explain what this patch does and why it is needed?
> > > >
> > > > It generates the entries needed for the user space module tools to
> > > > work with the aliases. For example modprobe/depmod. It is a standard
> > > > part of the kernel module system.
> > >
> > > What entries, where? What can you do after applying your patch that you
> > > couldn't do before?
> >
> > The drivers you are testing with don't depend on other drivers.
>
> They do. I'm testing with the lm90 driver, which depends on the hwmon
> driver. Both load automatically when the underlying i2c-parport driver
> instantiate an "adm1032" i2c device.
I don't know exactly what those modules tables are used for. I just
copied what the other subsystems do. Maybe they are used when you make
an initrd to know which drivers to copy into the image.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2008-01-13 18:01 UTC (permalink / raw)
To: Jean Delvare; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <20080113184017.7e3b409f@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare wrote:
> > > On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote:
> > > > IMHO, driver_name/type should be removed in new style drivers and
> > > > replaced with aliases on all platforms since aliases are the standard
> > > > kernel mechanism.
> > >
> > > I agree. But we can take your aliasing code now (once you have
> > > addressed the issues I raised) and convert the users of driver_name
> > > later; it doesn't have to be done all at once.
> >
> > GregKH, adding a new dynamically loadable subsystem is not something
> > that happens every day, can you check to make sure all of the standard
> > kernels mechanisms are being used? I'm not totally sure how the
> > modalias naming code is supposed to be done. The subsystem core code
> > in these patches needs review.
> >
> > Jean, could you take over the i2c core portion of the patch? That will
> > let you decide exactly how you want the driver_name/name fields to be
> > dealt with. After you get standard naming support into i2c core I'll
> > rework the rest of the patch to use your new code.
>
> Yes, that could be done, and I agree that it will probably be faster
> than iterative review/rework cycles between you and me. I'll free some
> cycles next week for that.
>
> > I don't think driver_name/name fields should be stored in an i2c
> > structure at all. They are redundant with the standard mechanism.
> >
> > The kernel automatically exposes modalias as a sysfs attribute so the
> > string must be recorded further down in the driver support layers. No
> > need to keep a copy in the i2c structure.
>
> Really? I didn't know that. So that's another thing that the i2c
> subsystem is not doing like the rest of the kernel? Can you please
> point me to the code that does this?
I never noticed it before either. Just do find | grep modalias in /sys
and see that every driver has a modalias attribute. It is probably
implement in drivers/base.
>
> > Standard devices don't export a 'name' attribute. To see the driver
> > name for a device in sysfs look at the 'driver' link.
>
> The driver name and the device name are different things! The "name"
> attribute that i2c devices have tells user-space the device name, not
> the driver name.
For this system my i2c device names are:
0-0050 0-0051 0-0052 0-0053
How does the name=eeprom attribute interact with this? All four of my
devices have name=eeprom. What is the name field used for in user
space?
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ ls
driver eeprom modalias name power subsystem uevent
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ cat name
eeprom
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$ ls driver -l
lrwxrwxrwx 1 root root 0 2008-01-13 12:46 driver ->
../../../../../../bus/i2c/drivers/eeprom
jonsmirl@terra:/sys/bus/i2c/devices/0-0052$
jonsmirl@terra:/sys/bus/i2c/drivers$ ls
eeprom
jonsmirl@terra:/sys/bus/i2c/drivers$ ls eeprom
0-0050 0-0051 0-0052 0-0053 bind module uevent unbind
>
> You may not like what the i2c subsystem does but you can't ignore its
> history. The name attribute of i2c devices has been there pretty much
> forever and user-space relies on it, thus we can't remove it.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jean Delvare @ 2008-01-13 17:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801130826l799e4897pe7380ccb973b5fd0@mail.gmail.com>
On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > > Follow on to: "Series to add device tree naming to i2c"
> > > > > Teach module-init-tools about the i2c subsystem.
> > > >
> > > > Can you please explain what this patch does and why it is needed?
> > >
> > > It generates the entries needed for the user space module tools to
> > > work with the aliases. For example modprobe/depmod. It is a standard
> > > part of the kernel module system.
> >
> > What entries, where? What can you do after applying your patch that you
> > couldn't do before?
>
> The drivers you are testing with don't depend on other drivers.
They do. I'm testing with the lm90 driver, which depends on the hwmon
driver. Both load automatically when the underlying i2c-parport driver
instantiate an "adm1032" i2c device.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jean Delvare @ 2008-01-13 17:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Greg KH, i2c, linux-kernel, linuxppc-dev
In-Reply-To: <9e4733910801130824i547b65a9n64e415f9626d6ab5@mail.gmail.com>
On Sun, 13 Jan 2008 11:24:29 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare wrote:
> > On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote:
> > > IMHO, driver_name/type should be removed in new style drivers and
> > > replaced with aliases on all platforms since aliases are the standard
> > > kernel mechanism.
> >
> > I agree. But we can take your aliasing code now (once you have
> > addressed the issues I raised) and convert the users of driver_name
> > later; it doesn't have to be done all at once.
>
> GregKH, adding a new dynamically loadable subsystem is not something
> that happens every day, can you check to make sure all of the standard
> kernels mechanisms are being used? I'm not totally sure how the
> modalias naming code is supposed to be done. The subsystem core code
> in these patches needs review.
>
> Jean, could you take over the i2c core portion of the patch? That will
> let you decide exactly how you want the driver_name/name fields to be
> dealt with. After you get standard naming support into i2c core I'll
> rework the rest of the patch to use your new code.
Yes, that could be done, and I agree that it will probably be faster
than iterative review/rework cycles between you and me. I'll free some
cycles next week for that.
> I don't think driver_name/name fields should be stored in an i2c
> structure at all. They are redundant with the standard mechanism.
>
> The kernel automatically exposes modalias as a sysfs attribute so the
> string must be recorded further down in the driver support layers. No
> need to keep a copy in the i2c structure.
Really? I didn't know that. So that's another thing that the i2c
subsystem is not doing like the rest of the kernel? Can you please
point me to the code that does this?
> Standard devices don't export a 'name' attribute. To see the driver
> name for a device in sysfs look at the 'driver' link.
The driver name and the device name are different things! The "name"
attribute that i2c devices have tells user-space the device name, not
the driver name.
You may not like what the i2c subsystem does but you can't ignore its
history. The name attribute of i2c devices has been there pretty much
forever and user-space relies on it, thus we can't remove it.
--
Jean Delvare
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-13 16:26 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080113163543.16e3d26b@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> > On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > > Follow on to: "Series to add device tree naming to i2c"
> > > > Teach module-init-tools about the i2c subsystem.
> > >
> > > Can you please explain what this patch does and why it is needed?
> >
> > It generates the entries needed for the user space module tools to
> > work with the aliases. For example modprobe/depmod. It is a standard
> > part of the kernel module system.
>
> What entries, where? What can you do after applying your patch that you
> couldn't do before?
The drivers you are testing with don't depend on other drivers.
> I'm asking because automatic i2c driver loading works just fine for me
> without patching user-space. So I don't get why your want to change
> anything.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2008-01-13 16:24 UTC (permalink / raw)
To: Jean Delvare, Greg KH; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080113154114.4a1c5166@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Jon,
>
> On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote:
> > The common scheme used elsewhere in the kernel for handling more than
> > one device in a single driver is aliases. The i2c code's existing
> > driver_name/type combination is a different way of implementing the
> > same feature. But there is no real need for driver_name/type on any
> > platform if aliases are used. Back in version 10 or 11 I had code in
> > there which replaced the two fields with aliases on all platforms but
> > too many people objected so I removed it..
>
> While I agree that aliases make i2c_client.driver_name obsolete,
> i2c_client.type is still needed. Not for device/driver matching in the
> kernel, granted, but for device identification from userspace. This is
> a first problem your patch has: when using your aliasing mechanism, the
> type string is left empty. i2c-core exports this value to user-space
> via the "name" sysfs attribute, and some libraries and applications
> make use of it. I know of libsensors at least, but I guess there are
> more. I can't apply your patch until this problem is solved, otherwise
> we would break some user-space applications.
>
> > IMHO, driver_name/type should be removed in new style drivers and
> > replaced with aliases on all platforms since aliases are the standard
> > kernel mechanism.
>
> I agree. But we can take your aliasing code now (once you have
> addressed the issues I raised) and convert the users of driver_name
> later; it doesn't have to be done all at once.
GregKH, adding a new dynamically loadable subsystem is not something
that happens every day, can you check to make sure all of the standard
kernels mechanisms are being used? I'm not totally sure how the
modalias naming code is supposed to be done. The subsystem core code
in these patches needs review.
Jean, could you take over the i2c core portion of the patch? That will
let you decide exactly how you want the driver_name/name fields to be
dealt with. After you get standard naming support into i2c core I'll
rework the rest of the patch to use your new code.
I don't think driver_name/name fields should be stored in an i2c
structure at all. They are redundant with the standard mechanism.
The kernel automatically exposes modalias as a sysfs attribute so the
string must be recorded further down in the driver support layers. No
need to keep a copy in the i2c structure.
Standard devices don't export a 'name' attribute. To see the driver
name for a device in sysfs look at the 'driver' link.
> The second problem I have with your patch is that you make use of the
> driver_name field, while I ultimately want to get rid of it. I'd rather
> see you use a different field for aliases, so that the later removal of
> the driver_name field and the associated mechanism is easier.
>
> A third, related problem, is the contents of the modalias file when
> using your patch. When I tested on my ADM1032 evaluation board, the
> modalias contained "adm1032". This isn't a valid module alias string:
> "modprobe adm1032" doesn't work. What works is "modprobe i2c:Nadm1032"
> so the modalias file should contain "i2c:Nadm1032". Just take a look at
> all modalias files in /sys, they all include the subsystem prefix and a
> simple modprobe `cat modalias` loads the required driver. I fail to see
> why the i2c subsystem would be different.
>
> I said this is related to the second problem because right now,
> i2c-core can't easily differentiate between driver names and aliases,
> as both are stored in i2c_client.driver_name. Having separate fields
> would make it possible (and relatively easy) to add the required prefix
> before aliases but not before driver names. The only drawback is that
> it will increase the size of the i2c_client structure, but I do not
> care that much given that it is only temporary.
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jean Delvare @ 2008-01-13 15:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801130714m1be16826jf240171972324d16@mail.gmail.com>
On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
> On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> > On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > > Follow on to: "Series to add device tree naming to i2c"
> > > Teach module-init-tools about the i2c subsystem.
> >
> > Can you please explain what this patch does and why it is needed?
>
> It generates the entries needed for the user space module tools to
> work with the aliases. For example modprobe/depmod. It is a standard
> part of the kernel module system.
What entries, where? What can you do after applying your patch that you
couldn't do before?
I'm asking because automatic i2c driver loading works just fine for me
without patching user-space. So I don't get why your want to change
anything.
--
Jean Delvare
^ permalink raw reply
* Re: [i2c] [PATCH] update module-init-tools to support the i2c subsystem
From: Jon Smirl @ 2008-01-13 15:14 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20080113152735.5dca46a1@hyperion.delvare>
On 1/13/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Mon, 17 Dec 2007 21:39:37 -0500, Jon Smirl wrote:
> > Follow on to: "Series to add device tree naming to i2c"
> > Teach module-init-tools about the i2c subsystem.
>
> Can you please explain what this patch does and why it is needed?
It generates the entries needed for the user space module tools to
work with the aliases. For example modprobe/depmod. It is a standard
part of the kernel module system.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jean Delvare @ 2008-01-13 15:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801120800g5b13c84u8720442fc8551339@mail.gmail.com>
Hi Jon,
On Sat, 12 Jan 2008 11:00:31 -0500, Jon Smirl wrote:
> On 1/12/08, Jean Delvare wrote:
> > What I meant is that the translation from Open Firmware device name to
> > Linux device name could happen in different ways. Making module aliases
> > out of the is one possibility but this is not the only one.
> >
> > I am curious why the translation could not happen "offline". As I
> > understand it, you're getting the device names from these .dts files.
> > However you're not parsing them in the kernel directly, are you? I
> > presume that you have some tool that converts these files into C code
> > that the kernel can use? This conversion tool could translate the names.
>
> Those dts files are for embedded devices that were specifically
> developed for Linux. All of the PowerPC Macs in the world have a
> device tree in ROM that was developed by Apple following the Open
> Firmware standard. Same thing for Sun boxes, but I'm not working on
> those.
OK. So basically we have to handle two different cases here, trees that
come from the .dts files and trees that are read from ROMs, right?
Does this mean that .dts files are compiled to some binary format to
look like what is in the ROMs? Is there kernel code that parses this?
Please explain how both types are handled by the kernel. I need to
understand how this works before I can decide where the OF names ->
Linux names translation can happen.
> The kernel has an existing mechanism for handling translations like
> these, the alias scheme.
That we agree on. My concern here is that you want to replace the Linux
names of i2c devices by OF names, without realizing that the Linux
names have a use outside of the kernel. We can't just replace them like
that, it would break some user-space applications. That's the reason
why I believe that it would make more sense to translate from OF names
to Linux names early in the process, so that the kernel, and thus
user-space applications, always handle and see the Linux names,
independently of the platform. I'm asking questions in order to figure
out whether and how this could be achieved.
> Currently developers add entries to the table in their private builds
> for the i2c devices they are using. Another way to avoid adding a
> table entry is to create a platform device in the platform code. But
> this support is being extended to audio codecs too. There are hundreds
> of audio codecs.
>
> The whole purpose of this code is to dynamically load the correct i2c
> and audio drivers by reading the device tree instead of having static
> i2s/codec devices for every possible platform combination.
I2C driver autoloading is already implemented, and works. Just not the
way you expected, but it works.
Replacing this mechanism with standard aliases is IMHO a good idea, it
makes the code cleaner and also more similar to what the rest of the
kernel does, which is always nice.
However, having a module aliasing mechanism for i2c drivers does NOT
require that OF names are used. We could implement aliasing using Linux
device names. Note that I have no problem with using OF names for
aliasing, however it should not break applications that currently know
the I2C devices by their Linux name.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Bryan O'Donoghue @ 2008-01-13 14:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080111200705.GA696@loki.buserror.net>
Greetings Scott.
Using u-boot Adder_config
U-Boot 1.3.1-g5c740711-dirty (Jan 13 2008 - 13:43:30) - using an ELDK
4.1 uclibc toolchain
I can't boot your board - port.
I've applied your code against Linus' git v2.6.26-rc7 as at today.
I have to apply
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 31147a0..8c060ca 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -163,7 +163,7 @@ ps3)
ksection=.kernel:vmlinux.bin
isection=.kernel:initrd
;;
-ep88xc)
+ep88xc|ep405|redboot*)
platformo="$object/fixed-head.o $object/$platform.o"
binary=y
;;
and
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..e426052 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -56,7 +56,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c
cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c
+ fixed-head.S ep88xc.c cuboot-hpc2.c redboot-8xx.c
src-boot := $(src-wlib) $(src-plat) empty.c
manually since those two fail to apply to Linus' tree - presumably
because they depend on other patches - should I be using -mm or some
other tree here instead ?
I then run
source /opt/eldk/eldk_init ppc_8xx
export ARCH=powerpc
make adder87x-uboot_defconfig
make uImage
cp arch/powerpc/boot/uImage /tftpboot - which is my tftpd root
directory.
In U-Boot then.
=> tftpboot 0x400000 uImage
=> bootm 0x400000
Which doesn't boot.
Attaching a BDI2000 to the target board I see that the kernel is
panicing somewhere around line 104 of arch/powerpc/kernel/prom.c in
of_scan_flat_dt - presumably because the kernel cannot find an
OpenFirmware tree..
I admit not understanding everything I should about where the output
of .dts & dtc "go" with respect to booting Linux.... but, didn't want to
ask on the list - lest I display a "lack of knowledge" ...
Seriously though, could you offer a pointer as to how I run this code on
the Adder875 here ?
My kernel command line is
root=/dev/nfs nfsroot=192.168.1.101:/tftpboot/root_fs rw
ip=192.168.1.202:::::eth0:off console=ttyCPM,115200
I've also tried - in ignorance of how OF works I admit to add the
following options to u-boot to no avail.
/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#undef CONFIG_OF_FLAT_TREE
#define CONFIG_OF_BOARD_SETUP 1
#define CONFIG_OF_HAS_BD_T 1
#define CONFIG_OF_HAS_UBOOT_ENV 1
#define OF_CPU "PowerPC,875@0"
#define OF_SOC "soc875@ff000000"
#define OF_TBCLK (bd->bi_busfreq / 4)
Have I missed a step with the .dts & dtc - and is this why
of_scan_flat_dt is failing - or - should the board port simply "just
work" with a
make dder87x-uboot_defconfig && make uImage ?
I'm sure I've done something obscenely obvious with respect to not
getting the whole OF thing right.... but if you could point to what that
is... I'd be highly appreciative.
Regards,
Bryan
^ permalink raw reply related
* Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
From: Jean Delvare @ 2008-01-13 14:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910801120826haa8905dk863ed1c8e9f420c9@mail.gmail.com>
Hi Jon,
On Sat, 12 Jan 2008 11:26:34 -0500, Jon Smirl wrote:
> The common scheme used elsewhere in the kernel for handling more than
> one device in a single driver is aliases. The i2c code's existing
> driver_name/type combination is a different way of implementing the
> same feature. But there is no real need for driver_name/type on any
> platform if aliases are used. Back in version 10 or 11 I had code in
> there which replaced the two fields with aliases on all platforms but
> too many people objected so I removed it..
While I agree that aliases make i2c_client.driver_name obsolete,
i2c_client.type is still needed. Not for device/driver matching in the
kernel, granted, but for device identification from userspace. This is
a first problem your patch has: when using your aliasing mechanism, the
type string is left empty. i2c-core exports this value to user-space
via the "name" sysfs attribute, and some libraries and applications
make use of it. I know of libsensors at least, but I guess there are
more. I can't apply your patch until this problem is solved, otherwise
we would break some user-space applications.
> IMHO, driver_name/type should be removed in new style drivers and
> replaced with aliases on all platforms since aliases are the standard
> kernel mechanism.
I agree. But we can take your aliasing code now (once you have
addressed the issues I raised) and convert the users of driver_name
later; it doesn't have to be done all at once.
The second problem I have with your patch is that you make use of the
driver_name field, while I ultimately want to get rid of it. I'd rather
see you use a different field for aliases, so that the later removal of
the driver_name field and the associated mechanism is easier.
A third, related problem, is the contents of the modalias file when
using your patch. When I tested on my ADM1032 evaluation board, the
modalias contained "adm1032". This isn't a valid module alias string:
"modprobe adm1032" doesn't work. What works is "modprobe i2c:Nadm1032"
so the modalias file should contain "i2c:Nadm1032". Just take a look at
all modalias files in /sys, they all include the subsystem prefix and a
simple modprobe `cat modalias` loads the required driver. I fail to see
why the i2c subsystem would be different.
I said this is related to the second problem because right now,
i2c-core can't easily differentiate between driver names and aliases,
as both are stored in i2c_client.driver_name. Having separate fields
would make it possible (and relatively easy) to add the required prefix
before aliases but not before driver names. The only drawback is that
it will increase the size of the i2c_client structure, but I do not
care that much given that it is only temporary.
--
Jean Delvare
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox