linux-kernel - Re: Kernel 5.2.8 - au0828

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALaQ_hoaoT+fzJZvEjCr6snjQme13LF2aph8cfvBCP5qta_QNQ@mail.gmail.com>
Date:   Mon, 19 Aug 2019 18:02:18 -0500
From:   Nathan Royce <nroycea+kernel@...il.com>
To:     shuah <shuah@...nel.org>
Cc:     Brad Love <brad@...tdimension.cc>, sean@...s.org,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Kernel 5.2.8 - au0828 - Tuner Is Busy

(resubmitting due to non "reply-to-all"):

Bugger, I just sent a reply to your last message, but it bounced back with:
*****
550 5.7.1 Content-Policy reject msg: The message contains HTML
subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is
accepted.! BF:<U 0.466751>; S1728494AbfHSVzk
*****
I just switched this email to plain-text and will resubmit my previous
email as plain-text.

Anyway, yeah, all I did in au0828-cards.c was add my 0x0400 like:
*****
 { USB_DEVICE(0x2040, 0x7281),
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x05e1, 0x0400),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x05e1, 0x0480),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
*****

That's all I've ever had to do. I never knew about the quirks-table.h.
I'll take a look.
I saw in the log the 0x05e1 addition was made in 2016, but maybe it
only applies to the Media Controller API change requirement now (thus,
not having caused any problems in the past since the API wasn't being
used).

I've never sent in a patch before (anywhere. I just point out a
problem and let the dev code it in their style). Also I don't want to
be a bother in case something even that small could somehow break
something else, especially for something "off-brand"(?).
I never really minded building the module by itself.

I've just now started the build for linux-5.2.y with the
quirks-table.h change along with au0828-cards.c.
Thanks for that heads-up. Hopefully that does the trick (whatever the
trick/quirk is).

On Mon, Aug 19, 2019 at 4:44 PM shuah <shuah@...nel.org> wrote:
>
> On 8/19/19 2:49 PM, shuah wrote:
> > Hi Nathan,
> >
> > Just catching up with this thread. Let me know what you find. Can you
> > build your own kernel and see what you can find?
> >
>
> You said you make changes to the
>
> "Whenever I update my kernel, I edit the
> ./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
> 0x400 device.
> I've been doing it for years and it's been working fine... until now..."
>
> Please send me the changes you make to the file. I see the following
> WOODBURY devices. I am assuming you add 0x400 entry.
>
> { USB_DEVICE(0x05e1, 0x0480),
>                  .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>          { USB_DEVICE(0x2040, 0x8200),
>                  .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>
>
> There is another table in sound/usb/quirks-table.h for AU0828
> devices. In addition to 812658d88d26, 66354f18fe5f makes change
> to this table to add a flag. I see two entries in that table:
>
> AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"),
> AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"),
>
> Since these drivers are now coupled doing resource sharing,
> could it be that with your change to au02828 device table,
> your changes are bow incomplete.
>
> I don't have a Woodbury device though. This is something to
> try.
>
> Did you consider sending patch to add your device variant,
> so you don't have to keep making this change whenever you
> go to a new kernel?
>
> thanks,
> -- Shuah