Re: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
From: Jan-Bernd Themann
Date: Fri Feb 01 2008 - 09:38:20 EST
On Tuesday 29 January 2008 15:20, Christoph Raisch wrote:
> These pci functions corresponds to a
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port0
> and
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port1
>
> The busdriver currently does not find out, how many ports are in a
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1.
> This is up to the hardware specific driver responsible for ehea or ehca.
> Think of a PCI card where the PCI busdriver
> can not determine how many ports are implemented on the card.
>
> How should this be mapped to /sys ?
>
> Should we try to "flatten" the ports to something like
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1_port0
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1_port1
> ...which means physical hierarchy information would look a bit strange,
> but could be the simpler one.
>
> The way which corresponds to the hardware would be to
> improve the kernel in such a way that hierarchical ports also wortk for
> netdev_register.
> Then we could keep this structure
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port0
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port1
>
>
> So, which way should we try?
>
> Gruss / Regards
> Christoph Raisch
>
>
>
Hi,
so far we fould 2 options. The ibmebus manages (add / remove)
ONLY eHEA adapters (not ehea ethernet ports).
All ethernet ports have to be added / removed by the eHEA device driver when
an eHEA adapter has been added by the ibmebus as a new device.
This means the sysfs-links "driver" for our eHEA ethernet devices (ports)
are not automatically generated.
Option 1)
- We can create then ourselves. Therefore we would
need two functions exported and included in the proper header file:
- static int driver_sysfs_add(struct device *dev)
- static void driver_sysfs_remove(struct device *dev)
Option 2)
- we just leave it out which would be inconsistent with
other pci based ethernet adapters.
So far we prefer option 1.
Do you see any other ways we should investigate?
To resolve the build issue I've posted a first patch to remove the
old sysfs links.
Regards,
Jan-Bernd & Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/