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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxx>
> > > Signed-off-by: Phi-bang Nguyen <pnguyen@xxxxxxxxxxxx>
> > > Signed-off-by: Florian Sylvestre <fsylvestre@xxxxxxxxxxxx>
> > > Co-developed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > > Co-developed-by: Julien Stephan <jstephan@xxxxxxxxxxxx>
> > > Signed-off-by: Julien Stephan <jstephan@xxxxxxxxxxxx>
> > > ---
> >
> > [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@xxxxxxxxxxxxx/).
>
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!
