Re: CONFIG_IBM_BAY
On Tue 20. Mar - 09:19:32, Kristen Carlson Accardi wrote:
> On Tue, 20 Mar 2007 16:53:21 +0100
> Holger Macht <[EMAIL PROTECTED]> wrote:
>
> > On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote:
> > > On Sun, 18 Mar 2007 19:55:30 +0100
> > > Holger Macht <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > > > > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > > > > those ThinkPads where it is needed. Afterwards it does the
> > > > > > corresponding
> > > > > > dock/undock request on ibm_acpi. And this works reliably good what
> > > > > > I can
> > > > > > see from the feedback I already got. But for this to work,
> > > > > > userspace would
> > > > >
> > > > > It should work with the generic bay device too, but I have no ideas
> > > > > about
> > > > > dock. But you'll need to deal with udev with the new bay device,
> > > > > something
> > > > > I am not too happy about. These things are ACPI events, they should
> > > > > remain
> > > > > so unless all other ACPI events are going to become uevents.
> > > >
> > > > It doesn't work, I've already tried. The bay driver only emits an event
> > > > if
> > > > you really try to remove the bay, but not on docking/undocking.
> > > >
> > > > Regards,
> > > > Holger
> > > >
> > >
> > > this *should* work. The Bay driver registers with the dock driver to get
> > > dock events:
> > >
> > > /* if we are on a dock station, we should register for dock
> > > * notifications.
> > > */
> > > if (bay_is_dock_device(handle)) {
> > > bay_dprintk(handle, "Is dependent on dock\n");
> > > register_hotplug_dock_device(handle, bay_notify, new_bay);
> > > }
> > >
> >
> > But is_dock_device(...) for both the bay and for the parent handle return
> > false. I'm using an X60 here, so bay_notify is never registered. I
> > couldn't find the reason in the short time I was looking at it, though.
> >
> > Regards,
> > Holger
> >
>
> Works for me on my X60 - have you tested on the latest rc kernel? Also,
> let me know what your BIOS sets your SATA controller to. I can try to
> duplicate your issue and get it to work.
Tried with Linus' git tree from today. SATA is set to AHCI if that's the
information you're asking for.
Thanks,
Holger
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Tue, 20 Mar 2007 16:53:21 +0100
Holger Macht <[EMAIL PROTECTED]> wrote:
> On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote:
> > On Sun, 18 Mar 2007 19:55:30 +0100
> > Holger Macht <[EMAIL PROTECTED]> wrote:
> >
> > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > > > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > > > those ThinkPads where it is needed. Afterwards it does the
> > > > > corresponding
> > > > > dock/undock request on ibm_acpi. And this works reliably good what I
> > > > > can
> > > > > see from the feedback I already got. But for this to work, userspace
> > > > > would
> > > >
> > > > It should work with the generic bay device too, but I have no ideas
> > > > about
> > > > dock. But you'll need to deal with udev with the new bay device,
> > > > something
> > > > I am not too happy about. These things are ACPI events, they should
> > > > remain
> > > > so unless all other ACPI events are going to become uevents.
> > >
> > > It doesn't work, I've already tried. The bay driver only emits an event if
> > > you really try to remove the bay, but not on docking/undocking.
> > >
> > > Regards,
> > > Holger
> > >
> >
> > this *should* work. The Bay driver registers with the dock driver to get
> > dock events:
> >
> > /* if we are on a dock station, we should register for dock
> > * notifications.
> > */
> > if (bay_is_dock_device(handle)) {
> > bay_dprintk(handle, "Is dependent on dock\n");
> > register_hotplug_dock_device(handle, bay_notify, new_bay);
> > }
> >
>
> But is_dock_device(...) for both the bay and for the parent handle return
> false. I'm using an X60 here, so bay_notify is never registered. I
> couldn't find the reason in the short time I was looking at it, though.
>
> Regards,
> Holger
>
Works for me on my X60 - have you tested on the latest rc kernel? Also,
let me know what your BIOS sets your SATA controller to. I can try to
duplicate your issue and get it to work.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Tue 20. Mar - 17:07:07, Holger Macht wrote: > On Mon 19. Mar - 11:11:09, Kristen Carlson Accardi wrote: > > On Mon, 19 Mar 2007 15:37:46 +0100 > > Holger Macht <[EMAIL PROTECTED]> wrote: > > > > > Sure. What actually bothers me is that in its current state, the dock > > > station driver signals 'green' on the dock station as soon as the user > > > presses the hardware undock button, but regardlessly of anything else. I > > > think it would be ok to let the ACPI undock event up to userspace because > > > in many situations it knows best when it is save to undock. > > > > I disagree - as I mentioned, not all laptops actually let you (userspace) > > control the undock process because they don't lock. The dock driver > > does notify user space of an undock, before it actually undocks: > > Yes, I know that, but userspace won't have enough time to interact with > the user in this case. I just imagine having an external disk connected to > the usb port of the docking station. In the moment the user undocks, his > unsynced or unwritten data is lost because the usb port gets > disconnected. The user needs the knowledge to actually "save remove" the > external disk before he undocks. You are right, this won't help in case > the dock station has no indication when it is "safe" to undock. This mail was accidentially sent a little bit too early ;-) What I wanted to add is just that with letting it up to userspace, it would also work in all cases, with or without lock, it would just give userspace more possibilities and might be more convenient for those systems where the dock station locks the machine. But I clearly see the advantage of not needing a userspace helper and for getting this docking thing to work in 99% of all cases ;-) Regards, Holger - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon 19. Mar - 11:11:09, Kristen Carlson Accardi wrote: > On Mon, 19 Mar 2007 15:37:46 +0100 > Holger Macht <[EMAIL PROTECTED]> wrote: > > > Sure. What actually bothers me is that in its current state, the dock > > station driver signals 'green' on the dock station as soon as the user > > presses the hardware undock button, but regardlessly of anything else. I > > think it would be ok to let the ACPI undock event up to userspace because > > in many situations it knows best when it is save to undock. > > I disagree - as I mentioned, not all laptops actually let you (userspace) > control the undock process because they don't lock. The dock driver > does notify user space of an undock, before it actually undocks: Yes, I know that, but userspace won't have enough time to interact with the user in this case. I just imagine having an external disk connected to the usb port of the docking station. In the moment the user undocks, his unsynced or unwritten data is lost because the usb port gets disconnected. The user needs the knowledge to actually "save remove" the external disk before he undocks. You are right, this won't help in case the dock station has no indication when it is "safe" to undock. > > /* > * here we need to generate the undock > * event prior to actually doing the undock > * so that the device struct still exists. > */ > dock_event(ds, event, UNDOCK_EVENT); > hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST); > undock(ds); > eject_dock(ds); > > > We even notify other subsystems of our intent to undock prior to actually > doing it. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote:
> On Sun, 18 Mar 2007 19:55:30 +0100
> Holger Macht <[EMAIL PROTECTED]> wrote:
>
> > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > > those ThinkPads where it is needed. Afterwards it does the corresponding
> > > > dock/undock request on ibm_acpi. And this works reliably good what I can
> > > > see from the feedback I already got. But for this to work, userspace
> > > > would
> > >
> > > It should work with the generic bay device too, but I have no ideas about
> > > dock. But you'll need to deal with udev with the new bay device,
> > > something
> > > I am not too happy about. These things are ACPI events, they should
> > > remain
> > > so unless all other ACPI events are going to become uevents.
> >
> > It doesn't work, I've already tried. The bay driver only emits an event if
> > you really try to remove the bay, but not on docking/undocking.
> >
> > Regards,
> > Holger
> >
>
> this *should* work. The Bay driver registers with the dock driver to get
> dock events:
>
> /* if we are on a dock station, we should register for dock
> * notifications.
> */
> if (bay_is_dock_device(handle)) {
> bay_dprintk(handle, "Is dependent on dock\n");
> register_hotplug_dock_device(handle, bay_notify, new_bay);
> }
>
But is_dock_device(...) for both the bay and for the parent handle return
false. I'm using an X60 here, so bay_notify is never registered. I
couldn't find the reason in the short time I was looking at it, though.
Regards,
Holger
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On Tue, 20 Mar 2007, Shem Multinymous wrote: > >More like it is a "make sure we can actually eject, as we have been told > >to". We might return an error instead, but if we do, we need a way to > >force-eject (e.g. echo 2 >eject). > > Which stage are you referring to? Stage 2, of course. It is useful to have a force_eject functionality that **will** eject and not error out because of anything other than the eject command itself failing. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On 3/19/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: On Mon, 19 Mar 2007, Shem Multinymous wrote: > Userspace wants to (non-force-)-unmount by itself after (1), so it can > stop the eject process if the filesystems cannot be cleanly > unmounted. So the force-unmount at (3) ends up being a redundant > safety measure at best. More like it is a "make sure we can actually eject, as we have been told to". We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 >eject). Which stage are you referring to? Note that the only way to check if you can unmount is to actually do so. Otherwise, you're very likely to run into race conditions with someone accessing the filesystem between the check and the actual unmount. Shem - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On Mon, 19 Mar 2007, Shem Multinymous wrote: > Userspace wants to (non-force-)-unmount by itself after (1), so it can > stop the eject process if the filesystems cannot be cleanly > unmounted. So the force-unmount at (3) ends up being a redundant > safety measure at best. More like it is a "make sure we can actually eject, as we have been told to". We might return an error instead, but if we do, we need a way to force-eject (e.g. echo 2 >eject). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007 15:36:52 -0300 Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Sun, 18 Mar 2007, Holger Macht wrote: > > those ThinkPads where it is needed. Afterwards it does the corresponding > > dock/undock request on ibm_acpi. And this works reliably good what I can > > see from the feedback I already got. But for this to work, userspace would > > It should work with the generic bay device too, but I have no ideas about > dock. But you'll need to deal with udev with the new bay device, something > I am not too happy about. These things are ACPI events, they should remain > so unless all other ACPI events are going to become uevents. So ACPI is just a mechanism - an implementation detail in the kernel. I don't think we should have special ACPI events to deal with bay/dock activity. If for whatever reason we ever dock something without using ACPI, we can make this transparent to userspace. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon, 19 Mar 2007 15:37:46 +0100 Holger Macht <[EMAIL PROTECTED]> wrote: > Sure. What actually bothers me is that in its current state, the dock > station driver signals 'green' on the dock station as soon as the user > presses the hardware undock button, but regardlessly of anything else. I > think it would be ok to let the ACPI undock event up to userspace because > in many situations it knows best when it is save to undock. I disagree - as I mentioned, not all laptops actually let you (userspace) control the undock process because they don't lock. The dock driver does notify user space of an undock, before it actually undocks: /* * here we need to generate the undock * event prior to actually doing the undock * so that the device struct still exists. */ dock_event(ds, event, UNDOCK_EVENT); hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST); undock(ds); eject_dock(ds); We even notify other subsystems of our intent to undock prior to actually doing it. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007 19:55:30 +0100
Holger Macht <[EMAIL PROTECTED]> wrote:
> On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > those ThinkPads where it is needed. Afterwards it does the corresponding
> > > dock/undock request on ibm_acpi. And this works reliably good what I can
> > > see from the feedback I already got. But for this to work, userspace would
> >
> > It should work with the generic bay device too, but I have no ideas about
> > dock. But you'll need to deal with udev with the new bay device, something
> > I am not too happy about. These things are ACPI events, they should remain
> > so unless all other ACPI events are going to become uevents.
>
> It doesn't work, I've already tried. The bay driver only emits an event if
> you really try to remove the bay, but not on docking/undocking.
>
> Regards,
> Holger
>
this *should* work. The Bay driver registers with the dock driver to get
dock events:
/* if we are on a dock station, we should register for dock
* notifications.
*/
if (bay_is_dock_device(handle)) {
bay_dprintk(handle, "Is dependent on dock\n");
register_hotplug_dock_device(handle, bay_notify, new_bay);
}
then, on undock the dock driver calls the bay_notify function and passes
it the EJECT request event. This causes the bay driver to emit an event to
userspace.
case ACPI_NOTIFY_EJECT_REQUEST:
kobject_uevent(&dev->kobj, KOBJ_CHANGE);
break;
default:
an event to userspace.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon, 19 Mar 2007 13:22:43 + Matthew Garrett <[EMAIL PROTECTED]> wrote: > On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote: > > > I don't prefer any solution, whether doing it inside the kernel, or doing > > it in userspace. What would be good would be to know what's the 'right' > > way to go, or at least what both kernel people and userspace people can > > agree on so that we can find a solution across distributions, whatever. > > I'm currently just looking how to integrate the generic dock and bay > > driver into the openSUSE distribution, and this seems to be quite hard, > > especially because of the above mentioned already working solution ;-) > > If the kernel knows that a bay device has just been added or removed, it > makes sense for the device removal to take place in the kernel rather > than bouncing it out to userspace and then back into the kernel. Pulling > out a cardbus card doesn't require us to run a userspace helper to > detach the hardware. > > -- > Matthew Garrett | [EMAIL PROTECTED] > Not to mention, with dock stations some laptops don't actually lock the laptop into the dock station, so when the user decides to press the button and undock, it just does it instantly. And same with some bay devices - they don't actually give you an event until the bay is physically removed. Because of this, I think we should handle things in kernel space. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ibm-acpi-devel] CONFIG_IBM_BAY
On 3/19/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: True. The best available procedure to do this for ACPI bay/dock currently is, AFAIK: 1. Send event when bay/dock "please release" button/lever is pressed. Do *nothing* else. I know bay does this right, maybe dock doesn't. 2. Wait for something to echo 1 >eject or to call the appropriate routine directly, or (if this exists) for an notification from firmware that the user IS disconnecting the device for real. 3. delete the device. This means force-umount, force-close, etc. 4. Tell the hardware to eject. Note that currently (2) and (3) are swapped, as (3) is being done by userspace request, instead of by the kernel. This is something I *don't* like. Userspace wants to (non-force-)-unmount by itself after (1), so it can stop the eject process if the filesystems cannot be cleanly unmounted. So the force-unmount at (3) ends up being a redundant safety measure at best. Shem - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon 19. Mar - 12:36:59, Henrique de Moraes Holschuh wrote: > On Mon, 19 Mar 2007, Matthew Garrett wrote: > > > But you still have to deal with mounted filesystems, no matter if it a > > > cardbus or a cdrom. Wouldn't we need something like 'save removal' > > > triggered from userspace like you maybe know from 'the other' operating > > > system? > > > > Yes, there's a need for a mechanism to deal with all of this safely, but > > the same is true of any storage device that can be hotplugged (USB, > > firewire, anything in a hotplug bay...) > > True. The best available procedure to do this for ACPI bay/dock currently > is, AFAIK: > > 1. Send event when bay/dock "please release" button/lever is pressed. Do > *nothing* else. I know bay does this right, maybe dock doesn't. Yes, the dock driver just does the undock, without any event. As you know, the "please release" mechanism is how it works with ibm_acpi. ACPI event comes through proc and userspace does echo undock > That would also be my favourite because it already works quite well. Just without generic docking. > 2. Wait for something to echo 1 >eject or to call the appropriate routine > directly, or (if this exists) for an notification from firmware that the > user IS disconnecting the device for real. > > 3. delete the device. This means force-umount, force-close, etc. > > 4. Tell the hardware to eject. > > > Note that currently (2) and (3) are swapped, as (3) is being done by > userspace request, instead of by the kernel. This is something I *don't* > like. IMO should do as PCMCIA and hotplug PCI does, and do that in kernel > space. Right. > The time window where one can ask the user something or notify it is not a > good idea to eject is between (1) and (2). If the eject command is issued, > delete devices (includes sync, of course) and eject. Yes, at this point in time, userspace is required to have finished the tasks it is responsible for. Regards, Holger - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon, 19 Mar 2007, Matthew Garrett wrote: > > But you still have to deal with mounted filesystems, no matter if it a > > cardbus or a cdrom. Wouldn't we need something like 'save removal' > > triggered from userspace like you maybe know from 'the other' operating > > system? > > Yes, there's a need for a mechanism to deal with all of this safely, but > the same is true of any storage device that can be hotplugged (USB, > firewire, anything in a hotplug bay...) True. The best available procedure to do this for ACPI bay/dock currently is, AFAIK: 1. Send event when bay/dock "please release" button/lever is pressed. Do *nothing* else. I know bay does this right, maybe dock doesn't. 2. Wait for something to echo 1 >eject or to call the appropriate routine directly, or (if this exists) for an notification from firmware that the user IS disconnecting the device for real. 3. delete the device. This means force-umount, force-close, etc. 4. Tell the hardware to eject. Note that currently (2) and (3) are swapped, as (3) is being done by userspace request, instead of by the kernel. This is something I *don't* like. IMO should do as PCMCIA and hotplug PCI does, and do that in kernel space. The time window where one can ask the user something or notify it is not a good idea to eject is between (1) and (2). If the eject command is issued, delete devices (includes sync, of course) and eject. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon 19. Mar - 14:04:03, Matthew Garrett wrote: > On Mon, Mar 19, 2007 at 02:48:22PM +0100, Holger Macht wrote: > > > 1. libata integration into the bay driver > > It actually makes sense to tie all PATA/SATA devices to their ACPI > handles where appropriate - there's already code to do that in > libata-acpi.c, but it would be nicer if it was integrated in the same > way that PCI devices are. > > > 2. The dock station driver has to inform the bay driver that an undock > > event took place, right? > > Yeah. > > > But you still have to deal with mounted filesystems, no matter if it a > > cardbus or a cdrom. Wouldn't we need something like 'save removal' > > triggered from userspace like you maybe know from 'the other' operating > > system? > > Yes, there's a need for a mechanism to deal with all of this safely, but > the same is true of any storage device that can be hotplugged (USB, > firewire, anything in a hotplug bay...) Sure. What actually bothers me is that in its current state, the dock station driver signals 'green' on the dock station as soon as the user presses the hardware undock button, but regardlessly of anything else. I think it would be ok to let the ACPI undock event up to userspace because in many situations it knows best when it is save to undock. Regards, Holger - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon, Mar 19, 2007 at 02:48:22PM +0100, Holger Macht wrote: > 1. libata integration into the bay driver It actually makes sense to tie all PATA/SATA devices to their ACPI handles where appropriate - there's already code to do that in libata-acpi.c, but it would be nicer if it was integrated in the same way that PCI devices are. > 2. The dock station driver has to inform the bay driver that an undock > event took place, right? Yeah. > But you still have to deal with mounted filesystems, no matter if it a > cardbus or a cdrom. Wouldn't we need something like 'save removal' > triggered from userspace like you maybe know from 'the other' operating > system? Yes, there's a need for a mechanism to deal with all of this safely, but the same is true of any storage device that can be hotplugged (USB, firewire, anything in a hotplug bay...) -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote: > I don't prefer any solution, whether doing it inside the kernel, or doing > it in userspace. What would be good would be to know what's the 'right' > way to go, or at least what both kernel people and userspace people can > agree on so that we can find a solution across distributions, whatever. > I'm currently just looking how to integrate the generic dock and bay > driver into the openSUSE distribution, and this seems to be quite hard, > especially because of the above mentioned already working solution ;-) If the kernel knows that a bay device has just been added or removed, it makes sense for the device removal to take place in the kernel rather than bouncing it out to userspace and then back into the kernel. Pulling out a cardbus card doesn't require us to run a userspace helper to detach the hardware. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Mon 19. Mar - 13:22:43, Matthew Garrett wrote: > On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote: > > > I don't prefer any solution, whether doing it inside the kernel, or doing > > it in userspace. What would be good would be to know what's the 'right' > > way to go, or at least what both kernel people and userspace people can > > agree on so that we can find a solution across distributions, whatever. > > I'm currently just looking how to integrate the generic dock and bay > > driver into the openSUSE distribution, and this seems to be quite hard, > > especially because of the above mentioned already working solution ;-) > > If the kernel knows that a bay device has just been added or removed, it > makes sense for the device removal to take place in the kernel rather > than bouncing it out to userspace and then back into the kernel. Pulling > out a cardbus card doesn't require us to run a userspace helper to > detach the hardware. Yes, makes sense to me. So if this is the way to go, we would need two things: 1. libata integration into the bay driver 2. The dock station driver has to inform the bay driver that an undock event took place, right? But you still have to deal with mounted filesystems, no matter if it a cardbus or a cdrom. Wouldn't we need something like 'save removal' triggered from userspace like you maybe know from 'the other' operating system? Regards, Holger - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007, Holger Macht wrote: > It doesn't work, I've already tried. The bay driver only emits an event if > you really try to remove the bay, but not on docking/undocking. Ah, now I understand what you mean. Looks like we really need the dock driver to sort of like act as a bus. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote: > On Sun, 18 Mar 2007, Holger Macht wrote: > > those ThinkPads where it is needed. Afterwards it does the corresponding > > dock/undock request on ibm_acpi. And this works reliably good what I can > > see from the feedback I already got. But for this to work, userspace would > > It should work with the generic bay device too, but I have no ideas about > dock. But you'll need to deal with udev with the new bay device, something > I am not too happy about. These things are ACPI events, they should remain > so unless all other ACPI events are going to become uevents. It doesn't work, I've already tried. The bay driver only emits an event if you really try to remove the bay, but not on docking/undocking. Regards, Holger - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007, Holger Macht wrote: > those ThinkPads where it is needed. Afterwards it does the corresponding > dock/undock request on ibm_acpi. And this works reliably good what I can > see from the feedback I already got. But for this to work, userspace would It should work with the generic bay device too, but I have no ideas about dock. But you'll need to deal with udev with the new bay device, something I am not too happy about. These things are ACPI events, they should remain so unless all other ACPI events are going to become uevents. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun, 18 Mar 2007, Tejun Heo wrote: > Kristen Carlson Accardi wrote: > >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > >> > >> 2. It will do the right thing on plug and unplug. This means telling the > >> rest of the kernel to disable the device in the bay, for example. Right > >> now > >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > >> leave libata to scream blood murder until it disables its end due to too > >> many retries, for example; > > :-) Yeah :) Try it with old ide, and the results are not... pretty. libata new EH *rules*. > > Personally - I think tighter integration to libata here would be beneficial. > > Once libata acpi support is straightened out, if we can store acpi handles > > associated with libata devices, we can perhaps have a mechanism of obtaining > > ata_device structs so that we can have a nice way of telling libata to > > delete devices etc. I am hoping libata-acpi will be straightened out for > > 2.6.22. > > I dunno what the thread is really about but can't this be dealt within > acpid? Finding out the correct scsi host node can be tricky but I think It could, yes. But to me the kernel looks like the proper place for this one. Not to mention that we *really* should know the ACPI namespace -> kernel device mapping in kernel, instead of doing half-assed things in userspace to call back into kernel land later... it may come in handy for other things (proper ACPI/driver exclusion of access to devices, for one), not just libata matters and dock/bay ejects. It is not like it is a policy thing. The only possible correct path to follow when doing an eject is to disable the devices and buses in the "it will be powered off" side of the ejection hardware. And depending on userspace for this is just (IMHO) ugly and error-prone. The kernel really should know how to do it, and doing it is *easy* as long as you know the mapping (which you should know for other reasons). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Sun 18. Mar - 14:38:42, Tejun Heo wrote: > Hello, > > Kristen Carlson Accardi wrote: > >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > >> > >> 2. It will do the right thing on plug and unplug. This means telling the > >> rest of the kernel to disable the device in the bay, for example. Right > >> now > >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > >> leave libata to scream blood murder until it disables its end due to too > >> many retries, for example; > > :-) > > > Personally - I think tighter integration to libata here would be beneficial. > > Once libata acpi support is straightened out, if we can store acpi handles > > associated with libata devices, we can perhaps have a mechanism of obtaining > > ata_device structs so that we can have a nice way of telling libata to > > delete devices etc. I am hoping libata-acpi will be straightened out for > > 2.6.22. > > I dunno what the thread is really about but can't this be dealt within > acpid? Finding out the correct scsi host node can be tricky but I think > it can be done reliably by jumping through some sysfs whoops. Once > you're there, telling libata to kill or probe is really easy. That's actually what I've created dockutils [1] for. What it basically does is 'echo 1 > /sys/devices/.../delete' on undock, and 'echo "- - -" > /sys/class/scsi_host/*/scan' on dock to get the bay device back to life on those ThinkPads where it is needed. Afterwards it does the corresponding dock/undock request on ibm_acpi. And this works reliably good what I can see from the feedback I already got. But for this to work, userspace would actually need an event on docking and preferably would need to do the ACPI undock itself. Both things are not possible with the generic dock driver currently. And I don't think it matters much if libata's hotplug capabilities are improved in this case, userspace just needs some time to interact with the user in case there is more to do like unmounting filesystems inside the bay etc... I don't prefer any solution, whether doing it inside the kernel, or doing it in userspace. What would be good would be to know what's the 'right' way to go, or at least what both kernel people and userspace people can agree on so that we can find a solution across distributions, whatever. I'm currently just looking how to integrate the generic dock and bay driver into the openSUSE distribution, and this seems to be quite hard, especially because of the above mentioned already working solution ;-) Just my 2 cents, Holger [1] http://en.opensuse.org/Dockutils - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
Hello, Kristen Carlson Accardi wrote: >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries); >> >> 2. It will do the right thing on plug and unplug. This means telling the >> rest of the kernel to disable the device in the bay, for example. Right now >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and >> leave libata to scream blood murder until it disables its end due to too >> many retries, for example; :-) > Personally - I think tighter integration to libata here would be beneficial. > Once libata acpi support is straightened out, if we can store acpi handles > associated with libata devices, we can perhaps have a mechanism of obtaining > ata_device structs so that we can have a nice way of telling libata to > delete devices etc. I am hoping libata-acpi will be straightened out for > 2.6.22. I dunno what the thread is really about but can't this be dealt within acpid? Finding out the correct scsi host node can be tricky but I think it can be done reliably by jumping through some sysfs whoops. Once you're there, telling libata to kill or probe is really easy. http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CONFIG_IBM_BAY
On Thu, 15 Mar 2007 16:31:24 -0300 Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > > I think we should focus our efforts on a generic (non platform specific) > > solution that can work across many laptops (i.e. ACPI_BAY). Let's make > > Agreed, as long as that doesn't mean we have to pollute ACPI_BAY with a > truckload of crap required to deal with vendor/model-specific idioticities. > I hope ThinkPads are not like that, but I am not sure, and I'd feel bad > about adding a lot of quirks to ACPI_BAY because of ThinkPad weirdness :p So for the dock driver I supplied an interface to allow interested subsystems to register handlers to be called by the dock driver during dock events. This allowed me to let individual subsystems do whatever unique things they needed to do when the dock was either inserted or removed. For the bay driver, we could actually provide a mechanism to allow platform specific drivers to take advantage of the generic stuff, but then have the bay driver call a registered handler to do some weird specific thing - this way at least we are sharing the bulk of our code and weird stuff can be contained somewhere else. > > Otherwise, it would be best to allow model-specific modules to provide extra > functionality for ACPI_BAY, that way we have generic code, and we can > contain the braindamage to where it belongs (e.g. in ibm-acpi). > > > so if you do have time to work on this, that would be great. I am happy > > to test on the set of laptops I've got. > > I will see what I can do. My "first approach" at a requirements list for a > proper bay module are as follows: > > 1. It will handle all device types (ATAPI, PATA, SATA, batteries); > > 2. It will do the right thing on plug and unplug. This means telling the > rest of the kernel to disable the device in the bay, for example. Right now > we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and > leave libata to scream blood murder until it disables its end due to too > many retries, for example; Personally - I think tighter integration to libata here would be beneficial. Once libata acpi support is straightened out, if we can store acpi handles associated with libata devices, we can perhaps have a mechanism of obtaining ata_device structs so that we can have a nice way of telling libata to delete devices etc. I am hoping libata-acpi will be straightened out for 2.6.22. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
