[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb
Subject:    Re: [PATCH] option: Add support for Quectel EP06
From:       Dan Williams <dcbw () redhat ! com>
Date:       2018-01-31 22:35:34
Message-ID: 1517438134.20308.4.camel () redhat ! com
[Download RAW message or body]

On Wed, 2018-01-31 at 16:32 -0600, Dan Williams wrote:
> On Thu, 2018-02-01 at 09:17 +1100, Johan Hovold wrote:
> > On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote:
> > > Hi Johan,
> > > 
> > > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold <johan@kernel.org>
> > > wrote:
> > > > This will probably have to do for now, but we already have
> > > > another
> > > > blacklist struct with the same content which we could rename
> > > > and
> > > > reuse.
> > > 
> > > I noticed the same, but wasn't quite sure about the policy on
> > > renaming/recycling and added a new blacklist entry. I can rename
> > > the
> > > entry and update references as part of this commit. What would be
> > > an
> > > appropriate name, something straight-forward like
> > > "net_intf4_intf5_blacklist"?
> > 
> > Yeah, the policy isn't entirely clear to me either. ;) The
> > net_blacklist
> > are used to blacklist a single network interface, but here the
> > other
> > interface was used for ADB and for the other driver it was for an
> > audio
> > interface I think.
> 
> When I added/consolidated this feature a long time back I didn't
> think
> we'd end up with as many common entries as we have.  I think it's
> fine
> to re-use use a common entry, but if you do and the common entry is
> named after a vendor/model, then make it generic.

IIRC I considered just dumping the BIT(x) into the .driver_info but
then we'd only have 16 bits for each of send_setup and reserved on 32-
bit arches and I wasn't sure that was enough.  I've seen some devices
with lots of interfaces.  But doing it this way might have been clearer
than a sidecar struct like option_blacklist_info.

Dan

> Dan
> 
> > You can just add the duplicate entry for now and if this comes up
> > again,
> > we'll figure out a new (naming) policy.
> > 
> > Thanks,
> > Johan
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > usb"
> > in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]