On Fri, Sep 06, 2013 at 11:37:28PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2013 at 06:24:42PM +0800, Huang Rui wrote:
> > It add a remote wakeup pci quirk for some special AMD platforms. This
> > quirk filters southbridge revision which is 0x39 or 0x3a.
> >
> > Signed-off-by: Huang Rui <[email protected]>
> > ---
> > drivers/usb/host/pci-quirks.c | 14 +++++++++++++-
> > drivers/usb/host/pci-quirks.h | 1 +
> > 2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> > index 2c76ef1..d440e73 100644
> > --- a/drivers/usb/host/pci-quirks.c
> > +++ b/drivers/usb/host/pci-quirks.c
> > @@ -140,9 +140,11 @@ int usb_amd_find_chipset_info(void)
> > rev = info.smbus_dev->revision;
> > if (rev >= 0x11 && rev <= 0x18)
> > info.sb_type = 2;
> > + if (rev >= 0x39 && rev <= 0x3a)
> > + info.sb_type = 4;
>
> You are adding another "type" here, yet we have no information on what
> these "types" mean. Can you please use an enumerated type, or a #define
> at the least, for all of these so we can start to tell them apart?
>
> Also, what does 39 and 3a mean? Please use a #define with a name we can
> understand so that others can know what this means.
>
Hi Greg,
I've got the approvement to open the chipset platform names. :)
So I wil use enumerated type or #define to describe the platforms. We
always use SMBus device id and revision to distinguish different
chipset platforms.
> > }
> >
> > - if (info.sb_type == 0) {
> > + if (info.sb_type == 0 || info.sb_type == 4) {
>
> Why type 4 here?
>
Because type 4 is a new chipset and usb_amd_find_chipset_info is only
for AMD PLL quirk at old platforms. So it should go out the function
like type 0 (undefined type).
> > if (info.smbus_dev) {
> > pci_dev_put(info.smbus_dev);
> > info.smbus_dev = NULL;
> > @@ -197,6 +199,16 @@ commit:
> > }
> > EXPORT_SYMBOL_GPL(usb_amd_find_chipset_info);
> >
> > +int usb_amd_remote_wakeup_quirk(void)
> > +{
> > + if (amd_chipset.sb_type != 4)
> > + return 0;
> > +
> > + printk(KERN_DEBUG "QUIRK: Enable AMD remote wakeup fix\n");
>
> dev_dbg() please?
>
OK, will do it.
> > + return 1;
> > +}
> > +EXPORT_SYMBOL_GPL(usb_amd_remote_wakeup_quirk);
>
> Nothing calls this function, so why have you added it here?
>
> The way you have broken up the patches is a bit odd. You are creating
> functions that aren't called yet, but do not describe this in the
> changelog information, so people reviewing the patch would just assume
> they are not needed at all (hint, like I just did...)
>
> Please provide a better description, and justification, if you create a
> new function, otherwise we will assume it is not needed at all.
>
Actually, I have a little confused. Assume that we write a core level
function, and it would be called in host controller level such as
xhci-*, ehci-*. Should I split the codes from core and host in two
pathes or write one patch included core and host level updates?
Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
