mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Daniel Danzberger <dd@embedd.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gnss/usb: Add U-blox 8/M8 device id
Date: Tue, 14 Jan 2025 17:10:28 +0100	[thread overview]
Message-ID: <Z4aMdJwB22EQbMwK@hovoldconsulting.com> (raw)
In-Reply-To: <d9f641491ec83c5f96ee547001dd8bd7ed5ae5a6.camel@embedd.com>

Hi Daniel,

and sorry about the late follow up on this.

On Sat, Nov 23, 2024 at 11:38:42AM +0100, Daniel Danzberger wrote:

> this is the lsusb -v output:
> --
> root@test1:~# lsusb -v -s  001:002 
> 
> Bus 001 Device 002: ID 1546:01a8 u-blox AG - www.u-blox.com u-blox GNSS receiver
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               1.10
>   bDeviceClass            2 [unknown]
>   bDeviceSubClass         0 [unknown]
>   bDeviceProtocol         0 

Not sure why your lsusb says unknown here, but this is a CDC-ACM device:

  bDeviceClass            2 Communications

>   bMaxPacketSize0        64
>   idVendor           0x1546 u-blox AG - www.u-blox.com
>   idProduct          0x01a8 u-blox GNSS receiver
>   bcdDevice            3.01
>   iManufacturer           1 u-blox AG - www.u-blox.com
>   iProduct                2 u-blox GNSS receiver
>   iSerial                 0 
>   bNumConfigurations      1

>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         2 [unknown]
>       bInterfaceSubClass      2 [unknown]
>       bInterfaceProtocol      1 

      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)

>       iInterface              0 
>       CDC Header:
>         bcdCDC               1.10
>       CDC ACM:
>         bmCapabilities       0x02
>           line coding and serial state
>       CDC Call Management:
>         bmCapabilities       0x03
>           call management
>           use DataInterface
>         bDataInterface          1
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval             255
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass        10 [unknown]
>       bInterfaceSubClass      0 [unknown]
>       bInterfaceProtocol    255 

      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol    255 Vendor specific

>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x01  EP 1 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
> Device Status:     0x0001
>   Self Powered

These device are currently handled by the cdc-acm driver and there is
currently no point in moving them to a different driver (and potentially
breaking people's setups).

I have one of these here myself, and the fact that we already have a
driver for them was the reason for me not adding it to the GNSS USB
driver already (I even think I used this device when writing the
driver).

> On Tue, 2024-10-29 at 13:03 +0100, Johan Hovold wrote:
> > On Sat, Oct 26, 2024 at 09:58:57AM +0200, Daniel Danzberger wrote:
> > > Adds support for U-Blox 8 GNSS devices
> > 
> > Please post the output of lsusb -v (or usb-devices) for this device.
> > 
> > IIRC this is a USB CDC device, which is already managed by the cdc-acm
> > driver.

Johan

  reply	other threads:[~2025-01-14 16:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-26  7:58 Daniel Danzberger
2024-10-29 12:03 ` Johan Hovold
2024-11-23 10:38   ` Daniel Danzberger
2025-01-14 16:10     ` Johan Hovold [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-09-07  6:44 Daniel Danzberger
2023-10-16 12:30 ` Johan Hovold

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=Z4aMdJwB22EQbMwK@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=dd@embedd.com \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®