linux-kernel - RE: [PATCH v1 2/2] usb:cdns3 Add Cadence USB3 DRD Driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sgywgzfb.fsf@linux.intel.com>
Date:   Mon, 17 Dec 2018 13:34:00 +0200
From:   Felipe Balbi <balbi@...nel.org>
To:     Pawel Laszczak <pawell@...ence.com>,
        "devicetree\@vger.kernel.org" <devicetree@...r.kernel.org>,
        Kishon Vijay Abraham I <kishon@...com>
Cc:     "gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
        "rogerq\@ti.com" <rogerq@...com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        Alan Douglas <adouglas@...ence.com>,
        "jbergsagel\@ti.com" <jbergsagel@...com>,
        "nsekhar\@ti.com" <nsekhar@...com>, "nm\@ti.com" <nm@...com>,
        Suresh Punnoose <sureshp@...ence.com>,
        "peter.chen\@nxp.com" <peter.chen@....com>,
        Pawel Jez <pjez@...ence.com>, Rahul Kumar <kurahul@...ence.com>
Subject: RE: [PATCH v1 2/2] usb:cdns3 Add Cadence USB3 DRD Driver


Hi,

Pawel Laszczak <pawell@...ence.com> writes:
>>>>> +	case USB_REQ_SET_ISOCH_DELAY:
>>>>> +		sprintf(str, "Set Isochronous Delay Delay: %d ns", wValue);
>>>>> +		break;
>>>>> +	default:
>>>>> +		sprintf(str,
>>>>> +			"SETUP BRT: %02x BR: %02x V: %04x I: %04x L: %04x\n",
>>>>> +			bRequestType, bRequest,
>>>>> +			wValue, wIndex, wLength);
>>>>> +	}
>>>>> +
>>>>> +	return str;
>>>>> +}
>>>>
>>>>All of these are a flat out copy of dwc3's implementation. It's much,
>>>>much better to turn dwc3's implementation into a generic, reusable
>>>>library function then spinning your own as a duplicated effort.
>>> I agree,
>>> It would be nice to have a set of decoding function  in some generic library. It could be used
>>> also by other drivers.
>>> Who should do this ?
>>
>>since you're the first to reuse it, then it should be you :-)
>
> So I can prepare debug.h  in drivers/usb/gadget directory. 

no, not there. Host drivers can rely on it too, if they want. Let's have
it on drivers/usb/common/debug.c (or some other name) and a header under include/linux/usb/

> Function form drivers/usb/dwc3/debug.h that could be common are: 
>
> static inline void dwc3_decode_get_status(__u8 t, __u16 i, __u16 l, char *str)
> static inline void dwc3_decode_get_set_descriptor(__u8 t, __u8 b, __u16 v,
> 						  __u16 i, __u16 l, char *str)
> static inline void dwc3_decode_set_clear_feature(__u8 t, __u8 b, __u16 v, __u16 i, char *str)												
> static inline void dwc3_decode_set_address(__u16 v, char *str)
> static inline void dwc3_decode_get_set_descriptor(__u8 t, __u8 b, __u16 v, __u16 i, __u16 l, char *str)						  
> static inline void dwc3_decode_get_configuration(__u16 l, char *str)
> static inline void dwc3_decode_set_configuration(__u8 v, char *str)
> static inline void dwc3_decode_get_intf(__u16 i, __u16 l, char *str)
> static inline void dwc3_decode_set_intf(__u8 v, __u16 i, char *str)
> static inline void dwc3_decode_synch_frame(__u16 i, __u16 l, char *str)
> static inline const char *dwc3_decode_ctrl(char *str, __u8 bRequestType, __u8 bRequest, __u16 wValue, __u16 wIndex, __u16 wLength)
>
> After changed it could looks like: 
> static inline void usb_decode_get_status(__u8 bRequestType, __u16 wIndex, __u16 wLength, char *str)
> static inline void usb _decode_get_set_descriptor(__u8 bRequestType, __u8 bRequest, __u16 wValue,
> 						  __u16 wIndex, __u16 wLength, char *str)
> static inline void usb_decode_set_clear_feature(__u8 bRequestType, __u8 bRequest, __u16 wValue, __u16 wIndex, char *str)												
> static inline void usb_decode_set_address(__u16 v, char *str)
> static inline void usb_decode_get_set_descriptor(__u8 bRequestType, __u8 bRequest, __u16 wValue, __u16 wIndex, __u16 wLength, char *str)						  
> static inline void usb_decode_get_configuration(__u16 wLength, char *str)
> static inline void usb_decode_set_configuration(__u8 wValue, char *str)
> static inline void usb_decode_get_intf(__u16 wIndex, __u16 wLength, char *str)
> static inline void usb_decode_set_intf(__u8 wValue, __u16 wIndex, char *str)
> static inline void usb_decode_synch_frame(__u16 wIndex, __u16 wLength, char *str)
> static inline const char * usb _decode_ctrl(char *str, __u8 bRequestType, __u8 bRequest, __u16 wValue, __u16 wIndex, __u16 wLength)
>
> Sorry but I prefer some more significant names :)

meh, no worries

> For me functions in drivers/usb/dwc3/debug.h looks ok, but I think that could be better to
> add additional usb_decode_test_mode and usb_decode_device_feature and little simplify usb_decode_get_set_descriptor. 

sure, just propose patches. Just make sure that your patches do a single
thing per patch. Meaning, first you add a patch moving functions to
drivers/usb/common and updating dwc3, then you add another to decode
test mode (then update dwc3), and another simplifying set_descriptor.

> What do you think about this?
>
> One more question. 
> Can I add drivers/usb/gadget/debug.h file  as part of my  set patches, or this should be done as separate, new patch ? 

Your first patch moving functions from dwc3 should move them somewhere ;)

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)