linux-kernel - Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver

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: <20200519090357.GD3877@valkosipuli.retiisi.org.uk>
Date:   Tue, 19 May 2020 12:03:57 +0300
From:   Sakari Ailus <sakari.ailus@....fi>
To:     Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
Cc:     Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>,
        linux-renesas-soc@...r.kernel.org, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Jacopo Mondi <jacopo@...ndi.org>,
        Niklas Söderlund 
        <niklas.soderlund@...natech.se>, Hans Verkuil <hverkuil@...all.nl>,
        Hyun Kwon <hyunk@...inx.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
Subject: Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver

Hi Kieran,

On Tue, May 19, 2020 at 09:55:24AM +0100, Kieran Bingham wrote:
> Hi Sakari,
> 
> On 19/05/2020 09:10, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Mon, May 18, 2020 at 12:45:18PM +0100, Kieran Bingham wrote:
> >> Hi Sakari,
> >>
> >> There are only fairly minor comments here, fix ups will be included in a
> >> v10.
> >>
> >> Is there anything major blocking integration?
> > 
> > Not that I can see. But please see my comments below.
> 
> Thanks,
> 
> We might have some more work tidying up the DT validation anyway which
> has come too late, and perhaps is going to bump this to v5.9 now anyway.
> 
> I can still try but ... ;-S
> 
> At least hopefully now we /can/ see a path to integration though.
> 
> I probably don't care if it's 5.8 or 5.9 as long as it's not 8.5 ;-)
> 
> >>
> >> Regards
> >>
> >> Kieran
> >>
> >>
> >>
> >> On 16/05/2020 22:51, Sakari Ailus wrote:
> >>> Hi Kieran,
> >>>
> >>> Thanks for the update.
> >>>
> >>> On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
> >>>
> >>> ...
> >>>
> >>>> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
> >>>> +				  struct v4l2_subdev_pad_config *cfg,
> >>>> +				  struct v4l2_subdev_mbus_code_enum *code)
> >>>> +{
> >>>> +	if (code->pad || code->index > 0)
> >>>> +		return -EINVAL;
> >>>> +
> >>>> +	code->code = MEDIA_BUS_FMT_UYVY8_2X8;
> >>>
> >>> Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
> >>> variant of the format is generally used on the serial busses. This choice
> >>> was made when serial busses were introduced.
> >>
> >> Ok - I presume this doesn't really have much effect anyway, they just
> >> have to match for the transmitter/receiver?
> > 
> > In this case, yes. But it's harder to change later, so let's indeed do that
> > now.
> 
> Yes indeed, I have to change my test scripts for the new configuration
> (or we should update the scripts to get the configuration from the
> device ;D)
> 
> 
> >> But it makes sense to me, so I'll update to the 1x16 variant.
> > 
> > ...
> 
> done anyway ;-)
> 
> I see the ADV748x is using the 2x8 variants though ... (all the more
> reason for our scripts to /get/ the correct version when propagating
> formats).
> 
> Perhaps I should/could add the 1x16 formats to the ADV748x too. (later)

It's a driver bug, yes.

> 
> 
> >>> And as you don't, you also won't know which frequencies are known to be
> >>> safe to use. That said, perhaps where this device is used having a random
> >>> frequency on that bus could not be an issue. Perhaps.
> >>
> >> Does this generate a range? or a list of static supported frequencies?
> >>
> >> We configure the pixel clock based upon the number of cameras connected,
> >> and their pixel rates etc ...
> >>
> >> Are you saying that the frequency of this clock should be validated to
> >> be a specific range? or are you talking about a different frequency?
> > 
> > It depends on the system. In general, only frequencies known to be safe
> > should be used. If this one has enough shielding to guarantee there won't
> > be problems in using a random frequency in the entire range, is there a
> > guarantee that will be the case for all systems with this chip?
> 
> I have no idea here... Maybe Niklas knows more having dealt more with
> the RCar-VIN/CSI parts.
> 
> It seems like this is something we can add later if necessary, by
> extending the descriptions in the DT?

Works for me.

Niklas, any idea?

-- 
Regards,

Sakari Ailus