Re: [PATCH 1/2] cxacru: Create sysfs attributes in atm_startinstead of bind

[Andrew Morton]

On Fri, 04 May 2007 18:03:22 +0100
Simon Arlott <simon@xxxxxxxxxxx> wrote:

> Since usbatm doesn't set the usb_interface driver data until after calling bind 
> and heavy_init, it would be NULL when the sysfs attributes are read. Reading the 
> MAC address from atm_dev before atm_dev exists would have been be possible too.
> 
> Calling create_device_file in atm_start will avoid this problem, and the data 
> is useless until the first status poll runs. However, it must be ready before a 
> status poll does a printk on line status change otherwise userspace could react 
> before the files exist.
> 
> For completeness I've moved remove_device_file to atm_stop so it's not called in 
> unbind when it's not needed.
> 

This patch is mysteriously mangled.

> 
> drivers/usb/atm/cxacru.c |   45 +++++++++++++++++++++++++--------------------
> 1 files changed, 25 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
> index 0b12ace..4ecb4c7 100644
> --- a/drivers/usb/atm/cxacru.c
> +++ b/drivers/usb/atm/cxacru.c
> @@ -618,10 +618,22 @@ static int cxacru_card_status(struct cxacru_data *instance)
> 	return 0;
> }
> 
> +static void cxacru_remove_device_files(struct usbatm_data *usbatm_instance,
> +		struct atm_dev *atm_dev)
> +{
> +	struct usb_interface *intf = usbatm_instance->usb_intf;
> +
> +	#define CXACRU_DEVICE_REMOVE_FILE(_name) \
> +		device_remove_file(&intf->dev, &dev_attr_##_name);
> +	CXACRU_ALL_FILES(REMOVE);
> +	#undef CXACRU_DEVICE_REMOVE_FILE
> +}
> +
> static int cxacru_atm_start(struct usbatm_data *usbatm_instance,
> 		struct atm_dev *atm_dev)
> {

See, that "^{" should have been "^ {".  Something has gobbled the leading
space.

Anyway, after some futzing around I was able to determine that this patch
is identical to the one I already have.  Ho hum.

-
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/