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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZKH4LXKHX8G1WK7a@valkosipuli.retiisi.eu>
Date:   Sun, 2 Jul 2023 22:20:29 +0000
From:   Sakari Ailus <sakari.ailus@....fi>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Jean-Michel Hautbois <jeanmichel.hautbois@...asonboard.com>,
        dave.stevenson@...pberrypi.com, devicetree@...r.kernel.org,
        kernel-list@...pberrypi.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        linux-rpi-kernel@...ts.infradead.org, lukasz@...y.st,
        mchehab@...nel.org, naush@...pberrypi.com, robh@...nel.org,
        tomi.valkeinen@...asonboard.com,
        bcm-kernel-feedback-list@...adcom.com, stefan.wahren@...e.com
Subject: Re: [PATCH v5 04/11] media: bcm2835-unicam: Add support for
 CCP2/CSI2 camera interface

Hi Laurent,

On Mon, Jul 03, 2023 at 01:01:38AM +0300, Laurent Pinchart wrote:
> > > > > > > If the hardware doesn't support lane remapping for CCP2, then that should
> > > > > > > be reflected in DT bindings, i.e. data-lanes isn't relevant. There's no
> > > > > > > need to check that here.
> > > > > > 
> > > > > > Should the above check for CSI-2 be dropped as well then ?
> > > > > 
> > > > > Same for CSI-2, too: if there's nothing to configure there (lane remapping)
> > > > > there's no need to validate that part of the DT either.
> > > > 
> > > > OK, I'll drop that.
> > > 
> > > Actually, I'm wondering if it would make sense to tell the parsing
> > > functions whether lane reordering is supported or not. The checks could
> > > then be moved to the framework. What do you think ?
> > 
> > I'm not sure how useful this check would be in the first place: if you have
> > hardware that can reorder the lanes, the framework doesn't know what to
> > check there (if anything) and otherwise there's little point in the
> > entire check.
> 
> Isn't it good to tell users that something is wrong instead of accepting
> the invalid configuration and let them wonder why the device isn't
> working ? Users in this case would be system integrators, not end
> users, but we have lots of debugging information in the kernel aimed for
> them already.

In which of the two cases above the framework could do something useful
there? For devices where you can reorder the lanes or for those where you
can't?

-- 
Sakari Ailus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ