Re: [RFC] USB: driver for iphone charging

Re: [RFC] USB: driver for iphone charging

[Bodo Eggert]

Greg KH <greg@kroah.com> wrote:

> my berry_charge code that adds support for charging the iphone when it
> is plugged into a Linux machine.

This should be a runtime option, because you may want to build a non-module
kernel and not charge the phone while running your laptop on battery.
-- 
Top 100 things you don't want the sysadmin to say:
72. My leave starts tomorrow.

Friß, Spammer: MYowdIc@7eggert.dyndns.org

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Greg KH]

On Fri, Aug 24, 2007 at 12:51:19PM +0200, Bodo Eggert wrote:
> Greg KH <greg@kroah.com> wrote:
> 
> > my berry_charge code that adds support for charging the iphone when it
> > is plugged into a Linux machine.
> 
> This should be a runtime option, because you may want to build a non-module
> kernel and not charge the phone while running your laptop on battery.

Then just don't build this module if you are creating such a kernel :)

Same thing goes for the existing blackberry charge driver too...

thanks,

greg k-h

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Bodo Eggert]

On Fri, 24 Aug 2007, Greg KH wrote:
> On Fri, Aug 24, 2007 at 12:51:19PM +0200, Bodo Eggert wrote:
> > Greg KH <greg@kroah.com> wrote:

> > > my berry_charge code that adds support for charging the iphone when it
> > > is plugged into a Linux machine.
> > 
> > This should be a runtime option, because you may want to build a non-module
> > kernel and not charge the phone while running your laptop on battery.
> 
> Then just don't build this module if you are creating such a kernel :)
> 
> Same thing goes for the existing blackberry charge driver too...

So I have to reboot if I want to charge my (blackberry|iphone) on my 
laptop?

Even if you say installing 850 KB of software (modutils) in order to 
toggle charging an iphone is sane, having to (un)load a module is not
user-friendly.

-- 
"'Multiple exclamation marks,' he went on, shaking his head, 'are a 
sure sign of a diseased mind.'"
	-- Terry Pratchett in "Eric"

Re: [RFC] USB: driver for iphone charging

[Oliver Neukum]

Am Freitag 24 August 2007 schrieb Greg KH:

Hi,

> +static int select_configuration(struct usb_device *udev)
> +{
> +       char *dummy_buffer = kzalloc(2, GFP_KERNEL);
> +       int retval;
> +
> +       if (!dummy_buffer)
> +               return -ENOMEM;
> +
> +       dbg(&udev->dev, "Calling set_configuration\n");
> +       retval = usb_driver_set_configuration(udev, 3);
> +       if (retval) {
> +               dev_err(&udev->dev, "Set Configuration failed :%d.\n", retval);
> +               goto exit;
> +       }
> +
> +       dbg(&udev->dev, "Sending first magic command\n");
> +       retval = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0x40, 0x40,
> +                                0x6400, 0, dummy_buffer, 0, 100);
> +

int usb_driver_set_configuration(struct usb_device *udev, int config)
{
	struct set_config_request *req;

	req = kmalloc(sizeof(*req), GFP_KERNEL);
	if (!req)
		return -ENOMEM;
	req->udev = udev;
	req->config = config;
	INIT_WORK(&req->work, driver_set_config_work);

	usb_get_dev(udev);
	schedule_work(&req->work);
	return 0;
}

This schedules the change via a workqueue, so you'll be reprobed. If you
fire of the first vendor command you are doing so before the configuration
is changed. How is this supposed to work?

	Regards
		Oliver

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Alan Stern]

On Fri, 24 Aug 2007, Oliver Neukum wrote:

> This schedules the change via a workqueue, so you'll be reprobed. If you
> fire of the first vendor command you are doing so before the configuration
> is changed. How is this supposed to work?

I would do it like this:

static int iphone_probe(struct usb_interface *intf,
			const struct usb_device_id *id)
{
	struct usb_device *udev = interface_to_usbdev(intf);
	int rc;

	if (udev->actconfig->desc.bConfigurationValue != 3) {
		dbg(&udev->dev, "Calling set_configuration\n");
		rc = usb_driver_set_configuration(udev, 3);
	} else {
		dbg(&udev->dev, "Configuration set, sending magic comand\n");
		rc = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
				0x40, (USB_DIR_OUT | USB_TYPE_VENDOR |
					USB_RECIP_DEVICE),
				0x6400, 0, NULL, 0, 1000);
	}
	if (rc)
		dev_err(&udev->dev, "Command failed: %d\n", rc);

	/* we don't really want to bind to the device, userspace programs can
	 * handle the syncing just fine, so get outta here. */
	return -ENODEV;
}

Alan Stern

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Oliver Neukum]

Am Freitag 24 August 2007 schrieb Alan Stern:
> On Fri, 24 Aug 2007, Oliver Neukum wrote:
> 
> > This schedules the change via a workqueue, so you'll be reprobed. If you
> > fire of the first vendor command you are doing so before the configuration
> > is changed. How is this supposed to work?
> 
> I would do it like this:

That makes sense. However, Greg's version might work by putting
out a magic init sequence and then changing the configuration.
Then it would just be coded in an obscure way.

However, does this really belong into kernel space? We have been
knowing that user space infrastructure for configuration selection
is necessary and this seems like a fine starting point.

	Regards
		Oliver

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Greg KH]

On Fri, Aug 24, 2007 at 04:23:13PM +0200, Oliver Neukum wrote:
> Am Freitag 24 August 2007 schrieb Alan Stern:
> > On Fri, 24 Aug 2007, Oliver Neukum wrote:
> > 
> > > This schedules the change via a workqueue, so you'll be reprobed. If you
> > > fire of the first vendor command you are doing so before the configuration
> > > is changed. How is this supposed to work?
> > 
> > I would do it like this:
> 
> That makes sense. However, Greg's version might work by putting
> out a magic init sequence and then changing the configuration.
> Then it would just be coded in an obscure way.

Without any docs, this is all obscure :)

> However, does this really belong into kernel space? We have been
> knowing that user space infrastructure for configuration selection
> is necessary and this seems like a fine starting point.

The berry_charge driver is also one that might be done in userspace, but
it turns out that people update their kernel much more than they do
userspace packages...

thanks,

greg k-h

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Greg KH]

On Fri, Aug 24, 2007 at 10:08:46AM -0400, Alan Stern wrote:
> On Fri, 24 Aug 2007, Oliver Neukum wrote:
> 
> > This schedules the change via a workqueue, so you'll be reprobed. If you
> > fire of the first vendor command you are doing so before the configuration
> > is changed. How is this supposed to work?
> 
> I would do it like this:
> 
> static int iphone_probe(struct usb_interface *intf,
> 			const struct usb_device_id *id)
> {
> 	struct usb_device *udev = interface_to_usbdev(intf);
> 	int rc;
> 
> 	if (udev->actconfig->desc.bConfigurationValue != 3) {
> 		dbg(&udev->dev, "Calling set_configuration\n");
> 		rc = usb_driver_set_configuration(udev, 3);
> 	} else {
> 		dbg(&udev->dev, "Configuration set, sending magic comand\n");
> 		rc = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> 				0x40, (USB_DIR_OUT | USB_TYPE_VENDOR |
> 					USB_RECIP_DEVICE),
> 				0x6400, 0, NULL, 0, 1000);
> 	}
> 	if (rc)
> 		dev_err(&udev->dev, "Command failed: %d\n", rc);
> 
> 	/* we don't really want to bind to the device, userspace programs can
> 	 * handle the syncing just fine, so get outta here. */
> 	return -ENODEV;
> }

Yeah, that would make more sense, if that is what is needed.

Can someone with a iphone test this out?  If you look at how the
berry_charge driver does it, the set_config stuff happens after the
magic command.  As I don't have an iphone, nor have I ever seen any
dumps of the command streams, I don't really know if the set_config
message really is necessary or not.

thanks,

greg k-h

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Alan Stern]

On Fri, 24 Aug 2007, Greg KH wrote:

> Can someone with a iphone test this out?  If you look at how the
> berry_charge driver does it, the set_config stuff happens after the
> magic command.  As I don't have an iphone, nor have I ever seen any
> dumps of the command streams, I don't really know if the set_config
> message really is necessary or not.

You know, now that I think back on it, it may be that the Set-Config
really does have to come after the magic command.  Perhaps it triggers
the changeover.  In which case the subroutine should look like this:

static int iphone_probe(struct usb_interface *intf,
			const struct usb_device_id *id)
{
	struct usb_device *udev = interface_to_usbdev(intf);
	int rc;

	if (udev->actconfig->desc.bConfigurationValue != 3) {
		dbg(&udev->dev, "Sending magic comand\n");
		rc = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
				0x40, (USB_DIR_OUT | USB_TYPE_VENDOR |
					USB_RECIP_DEVICE),
				0x6400, 0, NULL, 0, 1000);
		if (rc)
			dev_err(&udev->dev, "Command failed: %d\n", rc);
		else {
			dbg(&udev->dev, "Calling set_configuration\n");
			rc = usb_driver_set_configuration(udev, 3);
			if (rc)
				dev_err(&udev->dev, "Set-Config failed: %d\n",
						rc);
		}
	}

	/* we don't really want to bind to the device, userspace programs can
	 * handle the syncing just fine, so get outta here. */
	return -ENODEV;
}

However Oliver's point is well taken.  This simple sort of manipulation
could easily be done by a user program, started up by udev.

Alan Stern

Re: [linux-usb-devel] [RFC] USB: driver for iphone charging

[Matt Colyer]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Fri, 2007-08-24 at 14:55 -0400, Alan Stern wrote:
> On Fri, 24 Aug 2007, Greg KH wrote:
> 
> > Can someone with a iphone test this out?  If you look at how the
> > berry_charge driver does it, the set_config stuff happens after the
> > magic command.  As I don't have an iphone, nor have I ever seen any
> > dumps of the command streams, I don't really know if the set_config
> > message really is necessary or not.
> 
> You know, now that I think back on it, it may be that the Set-Config
> really does have to come after the magic command.  Perhaps it triggers
> the changeover.  In which case the subroutine should look like this:
> 
Hi all,
 I was the one who wrote the patch initially (sorry I haven't been able
to chime in sooner). It turns out that the configuration must be set
after the magic command (I tried both versions of the code tonight and
only the one which changes the configuration after the command works).
That said, I am not opposed to using a userspace program to accomplish
this task (I tried to pursue that avenue at first and couldn't find a
way to do, probably because it doesn't exist yet). I don't really have
much experience in this area, so I am not really sure how to proceed.

However the other part of this puzzle is that when you call lsusb the
iPhone disconnects from the bus. Greg suggested that it might be an
issue with the USB_SUSPEND support being broken on the iPhone and he
suggested I tried adding it to the quirks.c file. I'll be sure to let
you guys know when I figure it out.

-Matt

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]