[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080128195436.GA8574@kroah.com>
Date: Mon, 28 Jan 2008 11:54:36 -0800
From: Greg KH <greg@...ah.com>
To: Nathan Lynch <ntl@...ox.com>
Cc: Jan-Bernd Themann <ossthema@...ibm.com>,
Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
sam@...nborg.org, Christoph Raisch <raisch@...ibm.com>
Subject: Re: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Mon, Jan 28, 2008 at 01:22:04PM -0600, Nathan Lynch wrote:
> Greg KH wrote:
> > On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote:
> > > Jan-Bernd Themann wrote:
> > > >
> > > > On Thursday 10 January 2008 18:34, Greg KH wrote:
> > > > > > The structure device_driver(in device.h) has a member struct driver_private which
> > > > > > contains the member kobj (according to drivers/base/base.h).
> > > > > > But in device.h struct driver_private has been declared localy and
> > > > > > neither defined nor included from base.h.
> > > > > > So my effort to use driver->driver_private->obj also does not work.
> > > > > > (I am surprised from where do you access the struct device_driver)
> > > > >
> > > > > That is because a driver should not be accessing such a field.
> > > > >
> > > > > And especially not in this manner, why would this driver be creating a
> > > > > symlink that has already been created by the driver core? This whole
> > > > > thing can just be removed with no problems. Can you try just removing
> > > > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to
> > > > > verify this as I don't have the hardware present to test it out.
> > > >
> > > > The eHEA driver tries to orginize its sys-entries as close as possible to
> > > > other ethernet drivers. Each eHEA NIC has multiple ports which is not that
> > > > common in PCI. This means that each port is represented by a subdirectory
> > > > which has not the "driver" sys-link, only the root directory has.
> > > > Some tools expect to have this driver link in each port directory.
> > > > That is the reason why this link is created manually.
> > > >
> > > > Are there any other ways to create this link?
> > >
> > >
> > > This is now broken in mainline...
> > >
> > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
> > > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has
> > > no member named 'kobj'
> > > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has
> > > no member named 'kobj'
> > > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has
> > > no member named 'kobj'
> > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
> > > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has
> > > no member named 'kobj'
> >
> > Does the patch below fix this? That driver should not have been trying
> > to create symlinks that the driver core has already created for it.
>
> Yes, it fixes the build error, by just removing the code that got
> broken. Jan-Bernd gave a rationale for creating the symlink that
> didn't really seem to be answered.
See my other post to him. I do not see why this is not just duplicating
the same exact code in the driver core. If you are trying to "fake out"
userspace by saying a device is bound to a driver, well, that's just
wrong.
thanks,
greg k-h
--
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