RE: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver
Abhay_Salunke_at_Dell.com
Date: 06/07/05
- Previous message: Brice Goglin: "Re: 2.6.12?"
- Maybe in reply to: Abhay_Salunke_at_Dell.com: "RE: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver"
- Next in thread: Greg KH: "Re: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver"
- Reply: Greg KH: "Re: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 7 Jun 2005 09:47:47 -0500 To: <greg@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Monday, June 06, 2005 3:13 PM
> To: Salunke, Abhay
> Cc: marcel@holtmann.org; linux-kernel@vger.kernel.org; akpm@osdl.org;
> Domsch, Matt
> Subject: Re: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new
> DellBIOS update driver
>
> On Mon, Jun 06, 2005 at 03:01:04PM -0500, Abhay_Salunke@Dell.com
wrote:
> > > Ok, in re-reading the firmware code, you are correct, it will
still
> > > timeout in 10 seconds and call your callback.
> > >
> > > Which, in my opinion, is wrong. We should have some way to say
"wait
> > > forever". Care to change the firmware_class.c code to support
this?
> > Will give it a try. So far the request_firmware code calls
> > kobject_hotplug with action as KOBJ_ADD. It invokes a hotplug script
> > form user mode. I guess we need to have some reverse mechanism which
is
> > invoked when a user writes to the file.
>
> Why? Your completion function should be called when the file is
closed,
> right?
>
> > > I was assuming that this would wait forever, and is why I pointed
you
> > in
> > > this direction. Sorry about the confusion here.
> > >
> > I guess the earlier method of request_firmware would work out as is
with
> > the only disadvantage of the user having to depend on hotplug
mechanism
> > and echoing firmware name.
> > Let me know if that is acceptable till we find a solution to wait
for
> > ever without using hotplug stuff.
>
> Why not fix the firmware_class.c code now? :)
I am working on a solution for this; so yes, I will submit a patch to
enhance firmware_class.c code.
Mean while the driver sent earlier is tested and working on current
version of 2.6 kernel and we have tested it with various distros based
on 2.6 kernel. Changing the kernel and making the driver dependent on
the new code will make the driver not work on the current kernels which
the users have.
This will make driver non functional on current 2.6 kernels and will be
an issue if users don't want to upgrade their kernels but just want the
driver to update BIOS.
Thanks,
Abhay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Brice Goglin: "Re: 2.6.12?"
- Maybe in reply to: Abhay_Salunke_at_Dell.com: "RE: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver"
- Next in thread: Greg KH: "Re: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver"
- Reply: Greg KH: "Re: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
