public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: linux-media@vger.kernel.org, Bingbu Cao <bingbu.cao@intel.com>
Subject: Re: [PATCH v1 3/3] media: intel/ipu6: Constify ipu6_buttress_ctrl structure
Date: Mon, 10 Mar 2025 12:18:25 +0100	[thread overview]
Message-ID: <Z87KgbCzYU6nzpxF@linux.intel.com> (raw)
In-Reply-To: <Z86_UII900cD9fkk@kekkonen.localdomain>

On Mon, Mar 10, 2025 at 10:30:40AM +0000, Sakari Ailus wrote:
> Hi Stanislaw,
> 
> On Mon, Mar 10, 2025 at 09:37:55AM +0100, Stanislaw Gruszka wrote:
> > Hi Sakari,
> > 
> > On Fri, Mar 07, 2025 at 07:45:03AM +0000, Sakari Ailus wrote:
> > > >  ipu6_bus_initialize_device(struct pci_dev *pdev, struct device *parent,
> > > > -			   void *pdata, struct ipu6_buttress_ctrl *ctrl,
> > > > +			   void *pdata, const struct ipu6_buttress_ctrl *ctrl,
> > > 
> > > pdata should be const, too, btw.
> > > 
> > > >  			   char *name);
> > > >  int ipu6_bus_add_device(struct ipu6_bus_device *adev);
> > > >  void ipu6_bus_del_devices(struct pci_dev *pdev);
> > > > diff --git a/drivers/media/pci/intel/ipu6/ipu6-buttress.c b/drivers/media/pci/intel/ipu6/ipu6-buttress.c
> > > > index 787fcbd1df09..f8fdc07a953c 100644
> > > > --- a/drivers/media/pci/intel/ipu6/ipu6-buttress.c
> > > > +++ b/drivers/media/pci/intel/ipu6/ipu6-buttress.c
> > > > @@ -443,7 +443,7 @@ irqreturn_t ipu6_buttress_isr_threaded(int irq, void *isp_ptr)
> > > >  	return ret;
> > > >  }
> > > >  
> > > > -int ipu6_buttress_power(struct device *dev, struct ipu6_buttress_ctrl *ctrl,
> > > > +int ipu6_buttress_power(struct device *dev, const struct ipu6_buttress_ctrl *ctrl,
> > > >  			bool on)
> > > 
> > > But this is over 80.
> > 
> > On official kernel doc the limit is 100 (with 80 being preferred).
> > I run chackpatch.pl on this patch and it was just fine.
> 
> The Media tree driver documentation suggests:
> 
> $ ./scripts/checkpatch.pl --strict --max-line-length=80

TBH, in context of ipu6 enforcing 80 characters instead of 100,
frequently makes more harm then good IMHO, for example:

const struct ipu6_isys_pixelformat ipu6_isys_pfmts[] = {
	{ V4L2_PIX_FMT_SBGGR12, 16, 12, MEDIA_BUS_FMT_SBGGR12_1X12,
	  IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },
	{ V4L2_PIX_FMT_SGBRG12, 16, 12, MEDIA_BUS_FMT_SGBRG12_1X12,
	  IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },
	{ V4L2_PIX_FMT_SGRBG12, 16, 12, MEDIA_BUS_FMT_SGRBG12_1X12,
	  IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },
	{ V4L2_PIX_FMT_SRGGB12, 16, 12, MEDIA_BUS_FMT_SRGGB12_1X12,
vs:

const struct ipu6_isys_pixelformat ipu6_isys_pfmts[] = {
	{ V4L2_PIX_FMT_SBGGR12, 16, 12, MEDIA_BUS_FMT_SBGGR12_1X12, IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },
	{ V4L2_PIX_FMT_SGBRG12, 16, 12, MEDIA_BUS_FMT_SGBRG12_1X12, IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },
	{ V4L2_PIX_FMT_SGRBG12, 16, 12, MEDIA_BUS_FMT_SGRBG12_1X12, IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },
	{ V4L2_PIX_FMT_SRGGB12, 16, 12, MEDIA_BUS_FMT_SRGGB12_1X12, IPU6_FW_ISYS_FRAME_FORMAT_RAW16 },


Or:
		if (type && ((!pfmt->is_meta &&
			      type != V4L2_BUF_TYPE_VIDEO_CAPTURE) ||
			     (pfmt->is_meta &&
			      type != V4L2_BUF_TYPE_META_CAPTURE)))
			continue;

vs:

		if (type && ((!pfmt->is_meta && type != V4L2_BUF_TYPE_VIDEO_CAPTURE) ||
			     (pfmt->is_meta && type != V4L2_BUF_TYPE_META_CAPTURE)))
			continue;


Do we really need 80 chars limit in ipu drivers ? 

Regards
Stanislaw


  reply	other threads:[~2025-03-10 11:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06 13:06 [PATCH v1 0/3] media: intel/ipu6: minor cleanups Stanislaw Gruszka
2025-03-06 13:06 ` [PATCH v1 1/3] media: intel/ipu6: Remove unused IPU6_BUS_NAM Stanislaw Gruszka
2025-03-06 13:06 ` [PATCH v1 2/3] media: intel/ipu6: Remove ipu6_buttress_ctrl started field Stanislaw Gruszka
2025-03-06 13:06 ` [PATCH v1 3/3] media: intel/ipu6: Constify ipu6_buttress_ctrl structure Stanislaw Gruszka
2025-03-07  7:45   ` Sakari Ailus
2025-03-10  8:37     ` Stanislaw Gruszka
2025-03-10 10:30       ` Sakari Ailus
2025-03-10 11:18         ` Stanislaw Gruszka [this message]
2025-03-10 13:01           ` Sakari Ailus
2025-03-10  9:21 ` [PATCH v1 0/3] media: intel/ipu6: minor cleanups Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z87KgbCzYU6nzpxF@linux.intel.com \
    --to=stanislaw.gruszka@linux.intel.com \
    --cc=bingbu.cao@intel.com \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox