linux-kernel - Re: [PATCH v5 3/5] media: platform: mediatek: isp

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: <15c7bc8119b10168f2de146bbbf743869193eba3.camel@mediatek.com>
Date: Tue, 30 Jul 2024 02:11:45 +0000
From: CK Hu (胡俊光) <ck.hu@...iatek.com>
To: "jstephan@...libre.com" <jstephan@...libre.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"mchehab@...nel.org" <mchehab@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
	Andy Hsieh (謝智皓) <Andy.Hsieh@...iatek.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	Louis Kuo (郭德寧) <louis.kuo@...iatek.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	"laurent.pinchart@...asonboard.com" <laurent.pinchart@...asonboard.com>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "fsylvestre@...libre.com"
	<fsylvestre@...libre.com>, "angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>, "pnguyen@...libre.com"
	<pnguyen@...libre.com>
Subject: Re: [PATCH v5 3/5] media: platform: mediatek: isp_30: add mediatek
 ISP3.0 sensor interface

On Mon, 2024-07-29 at 14:46 +0200, Julien Stephan wrote:
>  	 
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>  Le jeu. 18 juil. 2024 à 04:44, CK Hu (胡俊光) <ck.hu@...iatek.com> a écrit :
> >
> > Hi, Julien:
> >
> > On Thu, 2024-07-04 at 15:36 +0200, Julien Stephan wrote:
> > >
> > > External email : Please do not click links or open attachments until you have verified the sender or the content.
> > >  From: Louis Kuo <louis.kuo@...iatek.com>
> > >
> > > This will add the mediatek ISP3.0 seninf (sensor interface) driver found
> > > on several Mediatek SoCs such as the mt8365.
> > >
> > > Then seninf module has 4 physical CSI-2 inputs. Depending on the soc they
> > > may not be all connected.
> > >
> > > Signed-off-by: Louis Kuo <louis.kuo@...iatek.com>
> > > Signed-off-by: Phi-bang Nguyen <pnguyen@...libre.com>
> > > Signed-off-by: Florian Sylvestre <fsylvestre@...libre.com>
> > > Co-developed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> > > Co-developed-by: Julien Stephan <jstephan@...libre.com>
> > > Signed-off-by: Julien Stephan <jstephan@...libre.com>
> > > ---
> >
> > [snip]
> >
> > > +static const struct mtk_seninf_conf seninf_8365_conf = {
> > > +.model = "mtk-camsys-3.0",
> > > +.nb_inputs = 4,
> > > +.nb_muxes = 6,
> > > +.nb_outputs = 4,
> > > +};
> > > +
> >
> > I think you should directly define these value as symbols because now
> > only support one SoC.
> >
> > #define MODEL     "mtk-camsys-3.0"
> > #define INPUT_NR  4
> > #define MUTEX_NR  6
> > #define OUTPUT_NR 4
> >
> > Because we don't know which SoC would be upstream later, maybe the next
> > SoC would be
> >
> > static const struct mtk_seninf_conf seninf_83xx_conf = {
> >         .model = "mtk-camsys-3.0",
> >         .nb_inputs = 4,
> >         .nb_muxes = 6,
> >         .nb_outputs = 4,
> >         .support_xxx = true;
> > };
> >
> > then model, nb_inputs, nb_muxes, and nb_outputs has no difference, so
> > it's not necessary to define them as variable. So define them as
> > constant now, and when next SoC upstream, then we know which one would
> > be variable.
> >
> 
> Hi CK,
> 
> Thank you for your feedback on this series.
> We already discussed this in an early version of the series (see
> https://lore.kernel.org/all/2dd412f0-86cb-3ae0-305d-0e8192b9128a@collabora.com/).
> 

Sorry for losing some information. This is not a red flag for me.

> I also discussed with internal teams in Mediatek about the folder
> architecture. If this is not a red flag for you, I 'll let it as is.

The folder architecture is a red flag for me.
Your reason is just "MediaTek internal teams want it".
I think no one would accept this reason.
Please provide more acceptable reason.

Regards,
CK

> 
> I will fix other comments you did and that I forgot to add in previous versions.
> 
> Cheers
> Julien
> 
> > Regards,
> > CK
> >
> >
> >
> > ************* MEDIATEK Confidentiality Notice ********************
> > The information contained in this e-mail message (including any
> > attachments) may be confidential, proprietary, privileged, or otherwise
> > exempt from disclosure under applicable laws. It is intended to be
> > conveyed only to the designated recipient(s). Any use, dissemination,
> > distribution, printing, retaining or copying of this e-mail (including its
> > attachments) by unintended recipient(s) is strictly prohibited and may
> > be unlawful. If you are not an intended recipient of this e-mail, or believe
> > that you have received this e-mail in error, please notify the sender
> > immediately (by replying to this e-mail), delete any and all copies of
> > this e-mail (including any attachments) from your system, and do not
> > disclose the content of this e-mail to any other person. Thank you!