public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>,
	Linux USB Mailing List <linux-usb@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: gadget: net2280: Remove pci_class from PCI_TABLE
Date: Wed, 27 Aug 2014 13:22:04 -0700	[thread overview]
Message-ID: <20140827202204.GA13047@kroah.com> (raw)
In-Reply-To: <CAPybu_1-pgEc5cwRPggm60UHKCceQZGAiyzjGqOhDZJedbkE8w@mail.gmail.com>

On Wed, Aug 27, 2014 at 09:39:43PM +0200, Ricardo Ribalda Delgado wrote:
> Hello Greg
> 
> 
> 
> 
> 
> On Wed, Aug 27, 2014 at 9:25 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Aug 27, 2014 at 03:00:29PM +0200, Ricardo Ribalda Delgado wrote:
> >> Defining the vendor and the product id should be enough to discriminate
> >> the device.
> >>
> >> The reason for this patch is that there is a missmatch betweed the
> >> modalias showed by sysfs and the modalias generated by file2alias.
> >>
> >> One expects the programming interface in uppercase and the other
> >> generates it in lowercase.
> >
> > I don't understand, what is wrong here?  Who does it in uppercase and
> > who in lower?  And does it matter?  It's just a numeric value that
> > should not be used as a string compare.
> >
> 
> In pci-sysfs: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/pci-sysfs.c#n175
> 
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
>     char *buf)
> {
> struct pci_dev *pci_dev = to_pci_dev(dev);
> 
> return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x\n",
>       pci_dev->vendor, pci_dev->device,
>       pci_dev->subsystem_vendor, pci_dev->subsystem_device,
>       (u8)(pci_dev->class >> 16), (u8)(pci_dev->class >> 8),
>       (u8)(pci_dev->class));
> }
> 
> 
> In file2alias: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/file2alias.c
> 
> #define ADD(str, sep, cond, field)                              \
> do {                                                            \
>         strcat(str, sep);                                       \
>         if (cond)                                               \
>                 sprintf(str + strlen(str),                      \
>                         sizeof(field) == 1 ? "%02X" :           \
>                         sizeof(field) == 2 ? "%04X" :           \
>                         sizeof(field) == 4 ? "%08X" : "",       \
>                         field);                                 \
>         else                                                    \
>                 sprintf(str + strlen(str), "*");                \
> } while(0)
> 
> 
> ADD(alias, "bc", baseclass_mask == 0xFF, baseclass);
> ADD(alias, "sc", subclass_mask == 0xFF, subclass);
> ADD(alias, "i", interface_mask == 0xFF, interface);
> 
> 
> 
> >> This means that some implementations modprobe will fail to load the
> >> driver.
> >
> > What implementations fail to work?  Shouldn't we fix the root of the
> > problem and not just patch up all drivers to display incorrect data?
> 
> At least the implementation of kmod in yocproject does a case sensitive match.
> 
> 
> I have already sent a patch to fix what I consider the root of the problem
> 
> https://lkml.org/lkml/2014/8/27/242

No, the root cause of the problem is a userspace tool looking at a hex
value as a string and not a number.  It doesn't matter if we print it in
upper or lower case, it's a digit, not a string.  Do the numeric
compare, not a string compare.

> > And I mean incorrect, as you are changing the values here from being
> > very specific, to being much broader.
> >
> 
> Not many drivers define the pci interface and there is no other driver
> that has the same vendor  and product id. Therefore I see no hurt in
> adding both patches, one to make the driver broader, and another to
> fix pci-sysfs.
> 
> Also, the change on pci-sysfs might affect more stuff and therefore
> take longer to be applied.

As we have been printing the value to userspace in this way for well
over a decade now, and nothing has changed, I say it's a userspace bug
that you should fix instead.  Don't work around broken user programs in
the kernel by changing something that has been stable for 10+ years.

Ok, sorry, not 10+ years, the commit was written May of 2005, so 9
years.

Fix your module loading code please.

thanks,

greg k-h

  reply	other threads:[~2014-08-27 20:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 13:00 [PATCH] usb: gadget: net2280: Remove pci_class from PCI_TABLE Ricardo Ribalda Delgado
2014-08-27 19:25 ` Greg Kroah-Hartman
2014-08-27 19:39   ` Ricardo Ribalda Delgado
2014-08-27 20:22     ` Greg Kroah-Hartman [this message]
2014-08-27 21:03       ` Ricardo Ribalda Delgado
2014-08-27 21:11         ` Greg Kroah-Hartman
2014-08-27 21:09       ` Bjørn Mork
2014-08-27 23:43         ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140827202204.GA13047@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=balbi@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=ricardo.ribalda@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox