option: Add support for Quectel EP06

[Johan Hovold <johan@kernel.org>]

On Wed, Jan 31, 2018 at 04:35:34PM -0600, Dan Williams wrote:
> 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 we have already started reusing entries, but the names have not
always been made generic in the process. I think Bjørn may have proposed
a generic naming scheme at some point, but that essentially just meant
we encoded the two masks in the name. Then we may just move over to
encoding the masks directly in driver_data instead, at least if 16 bits
is enough.

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

Yeah, we should probably consider moving over to something like that.
16 bits would at least be enough for the devices we currently have
blacklists for.

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