linux-kernel - Re: [PATCH v2 1/7] media: uvcvideo: Use pr

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: <9d439214e8c83ebf7b93dccca2f848fbaf75b9d4.camel@perches.com>
Date:   Wed, 04 Nov 2020 13:51:29 -0800
From:   Joe Perches <joe@...ches.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Ricardo Ribalda <ribalda@...omium.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/7] media: uvcvideo: Use pr_cont() macro

On Wed, 2020-11-04 at 23:42 +0200, Laurent Pinchart wrote:
> Hi Joe,

Hi Laurent.

> On Wed, Nov 04, 2020 at 11:29:30AM -0800, Joe Perches wrote:
> > On Wed, 2020-11-04 at 19:07 +0100, Ricardo Ribalda wrote:
> > > Replace all the uses of printk(KERN_CONT ... with pr_cont().
> > 
> > Perhaps remove the uvc_printk macro and uses and use the more
> > common pr_fmt and pr_<level> mechanisms.
> 
> I'd actually go for dev_* instead, to give some context. It's fairly
> common to have multiple UVC devices connected to a system, so printing
> the device name would be useful. It can still be wrapped with
> uvc_printk() if we want to wrap the cast from uvc_device to a struct
> device (we should actually try to get the device corresponding to the
> USB interface where available, so we should use uvc_streaming->intf->dev
> where possible, and fallback to uvc_device->udev->dev otherwise), or
> drop the wrapper completely.

Of course yes.  I was not going to look around and update the existing
call sites to find whatever controlling uvc_device * or other struct *
to a real device that exists though.

It's not even clear from the changes that an appropriate pointer to
some struct exists in all the functions.

That's work for someone that knows the actual subsystem and I do not.

cheers, Joe