Load partially USB composite device

[loïc tourlonias]

Hi everybody,

In my project I have an USB composite device (a LTE modem) which use
USB to communicate with the processor. This device has several
interface to communicate but I do not use all of them. In particular,
it loads cdc_ether device which I don't use and I have an undesired
ethXX which interferes with a service in my system.

To schematize, let's say my device is loaded on port 2 of usb1, I have
the following USB topology:
- 1-2:1.0: tty
- 1-2:1.1: tty
- 1-2:1.2: tty
- 1-2:1.3: tty
- 1-2:1.4: tty
- 1-2:1.5: eth (not desired)

Is there a way to prevent this specific ethXX to mount?

I've already tried to create a udev rules, but I don't manage to stop
the loading process.
Here is a summary of my tries:
1/ I couldn't use the /sys/bus/usb1/.../1-2/activated file in my udev
rule because it's an USB composite device and I want to use the tty
interfaces but not the eth interface

2/ I have tried to stop the udev loading process, but setting MODALIAS
environment variable to a NULL-string doesn(t do the trick and
last-rule udev option has been removed in my udev version (1.8.2).

3/ I have tried to create a custom environment variable IGNORE_ETH and
modify my last rule which run modprobe with the modalias variable. In
the logs I see that modprobe isn't called by udev rules, but the
cdc_ether device is loaded all the same.

4/ I have think of creating a stub cdc_ether driver and use the
/etc/modprobe.d/my_file.conf to preempt the loading for my specific
usb composite device but this solution is ugly and I'm not sure it
will work.

Any idea will be great.
Best Regads
Loic

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Kernel build warnings

[Amit Kumar]

On Tue, Aug 8, 2017 at 11:48 AM  wrote:

> On Tue, 08 Aug 2017 05:36:34 -, Amit Kumar said:
>
> > When I compile arm64/defconfig kernel with W=1, build emits a lot of
> > warnings. When patch is required to be "build clean" then why warnings
> are
> > there?  I want to understand.
>
> The warnings that come out with the default W=0 are by an large indicative
> of code that's syntactically correct, but probably *do* have unintended
> semantics, so those should be fixed up properly.
>
> The problem with W=1 is that although W=1 will generate a lot of warnings,
> a
> lot of them are things we don't actually want to go out of our way to fix.
> That's because W=1 turns on a *lot* of nitpicking "did you really mean to
> do
> that?" warnings - and in kernel code, yes, we often really *did* mean to do
> that.
>
> Now, *some* of them do indeed call for fixing.  But make sure that you're
> fixing an *actual* problem, where the warning indicates an actual bug.  All
> too often, we get patches that just shut the warning up, and don't fix a
> bug - or even worse, introduce bugs where there weren't any before.
>
> There's also something to be said for fixing warnings that are in .h files,
> because they end up emitting warnings for multiple .c files.  A while back,
> I submitted a short series of "low hanging fruit" patches against the
> drivers/staging/lustre tree - the big win was a one-liner that silenced a
> macro in all 231 places it was used.  But again - make sure the patch is
> an improvement, and not just papering over an issue.
>

Thank you for reply.

I have noticed that there are mostly missing prototype, variable set but
not used, macro related and dtc warning unit not used in device tree.

As I navigate source, I'll understand which I should hunt for.

Last but not least, according to your suggestion, I'll hunt these warnings
when I create patch. I'll not create patch to get rid of warnings.

  Regards,
Amit Kumar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies