From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Songjun Wu <songjun.wu@microchip.com>,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Javi Merino <javi.merino@kernel.org>,
Robert Jarzmik <robert.jarzmik@free.fr>,
Markus Elfring <elfring@users.sourceforge.net>,
devel@driverdev.osuosl.org,
Yannick Fertre <yannick.fertre@st.com>,
linux-samsung-soc@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
Michal Simek <michal.simek@xilinx.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Ludovic Desroches <ludovic.desroches@microchip.com>,
Kukjin Kim <kgene@kernel.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Tuukka Toivonen <tuukka.toivonen@intel.com>,
Steve Longerbeam <slongerbeam@gmail.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Linux Media Mailing List <linux-media@vger.kernel.o>
Subject: Re: [PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure
Date: Fri, 29 Sep 2017 06:27:13 -0300 [thread overview]
Message-ID: <20170929062119.192e4fd1@vento.lan> (raw)
In-Reply-To: <20170928120920.ywgbtikkrts25qlj@valkosipuli.retiisi.org.uk>
Em Thu, 28 Sep 2017 15:09:21 +0300
Sakari Ailus <sakari.ailus@iki.fi> escreveu:
> Hi Mauro,
>
> On Wed, Sep 27, 2017 at 06:46:56PM -0300, Mauro Carvalho Chehab wrote:
> > The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> > struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> > match criteria requires just a device name.
> >
> > So, it doesn't make sense to enclose those into structs,
> > as the criteria can go directly into the union.
> >
> > That makes easier to document it, as we don't need to document
> > weird senseless structs.
>
> The idea is that in the union, there's a struct which is specific to the
> match_type field. I wouldn't call it senseless.
Why a struct for each specific match_type is **needed**? It it is not
needed, then it is senseless per definition :-)
In the specific case of fwnode, there's already a named struct
for fwnode_handle. The only thing is that it is declared outside
enum v4l2_async_match_type. So, I don't see any reason to do things
like:
struct {
struct fwnode_handle *fwnode;
} fwnode;
If you're in doubt about that, think on how would you document
both fwnode structs. Both fwnode structs specify the match
criteria if %V4L2_ASYNC_MATCH_FWNODE.
The same applies to this:
struct {
const char *name;
} device_name;
Both device_name and name specifies the match criteria if
%V4L2_ASYNC_MATCH_DEVNAME.
>
> In the two cases there's just a single field in the containing struct. You
> could remove the struct in that case as you do in this patch, and just use
> the field. But I think the result is less clean and so I wouldn't make this
> change.
It is actually cleaner without the stucts.
Without the useless struct, if one wants to match a firmware node, it
should be doing:
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
And that' it. For anyone that reads the above code, even not knowing
all details of "match", is clear that the match criteria is whatever
of_fwnode_handle() returns.
Now, on this:
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
It sounds that something is missing, as only one field of match.fwnode
was specified. Anyone not familiar with that non-conventional usage of
a struct with just one struct field inside would need to seek for the
header file declaring the struct. That would consume a lot of time for
code reviewers for no good reason.
The same apply for devname search:
In this case:
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name.name = imxsd->devname;
I would be expecting something else to be filled at device_name's
struct, for example to specify a case sensitive or case insensitive
match criteria, to allow seeking for a device's substring, or to
allow using other struct device fields to narrow the seek.
With this:
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name = imxsd->devname;
It is clear that the match criteria is fully specified.
> The confusion comes possibly from the fact that the struct is named the
> same as the field in the struct. These used to be called of and node, but
> with the fwnode property framework the references to the fwnode are, well,
> typically similarly called "fwnode". There's no underlying firmware
> interface with that name, fwnode property API is just an API.
The duplicated "fwnode" name only made it more evident that we don't
need to enclose a single match criteria field inside a struct.
Thanks,
Mauro
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: "Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
"Songjun Wu" <songjun.wu@microchip.com>,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Sylwester Nawrocki" <s.nawrocki@samsung.com>,
"Javi Merino" <javi.merino@kernel.org>,
"Robert Jarzmik" <robert.jarzmik@free.fr>,
"Markus Elfring" <elfring@users.sourceforge.net>,
devel@driverdev.osuosl.org,
"Yannick Fertre" <yannick.fertre@st.com>,
linux-samsung-soc@vger.kernel.org,
"Jonathan Corbet" <corbet@lwn.net>,
"Michal Simek" <michal.simek@xilinx.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Ludovic Desroches" <ludovic.desroches@microchip.com>,
"Kukjin Kim" <kgene@kernel.org>,
"Hans Verkuil" <hans.verkuil@cisco.com>,
"Tuukka Toivonen" <tuukka.toivonen@intel.com>,
"Steve Longerbeam" <slongerbeam@gmail.com>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Alexandre Torgue" <alexandre.torgue@st.com>,
"Rob Herring" <robh@kernel.org>,
linux-renesas-soc@vger.kernel.org,
"Mauro Carvalho Chehab" <mchehab@infradead.org>,
"Benoit Parrot" <bparrot@ti.com>,
"Julia Lawall" <Julia.Lawall@lip6.fr>,
"Hugues Fruchet" <hugues.fruchet@st.com>,
"Petr Cvek" <petr.cvek@tul.cz>,
"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
linux-arm-kernel@lists.infradead.org,
"Hyun Kwon" <hyun.kwon@xilinx.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Tomasz Figa" <tfiga@chromium.org>,
"Todor Tomov" <todor.tomov@linaro.org>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Gustavo A. R. Silva" <garsilva@embeddedor.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Ramesh Shanmugasundaram"
<ramesh.shanmugasundaram@bp.renesas.com>,
"Guennadi Liakhovetski" <g.liakhovetski@gmx.de>
Subject: Re: [PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure
Date: Fri, 29 Sep 2017 06:27:13 -0300 [thread overview]
Message-ID: <20170929062119.192e4fd1@vento.lan> (raw)
In-Reply-To: <20170928120920.ywgbtikkrts25qlj@valkosipuli.retiisi.org.uk>
Em Thu, 28 Sep 2017 15:09:21 +0300
Sakari Ailus <sakari.ailus@iki.fi> escreveu:
> Hi Mauro,
>
> On Wed, Sep 27, 2017 at 06:46:56PM -0300, Mauro Carvalho Chehab wrote:
> > The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> > struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> > match criteria requires just a device name.
> >
> > So, it doesn't make sense to enclose those into structs,
> > as the criteria can go directly into the union.
> >
> > That makes easier to document it, as we don't need to document
> > weird senseless structs.
>
> The idea is that in the union, there's a struct which is specific to the
> match_type field. I wouldn't call it senseless.
Why a struct for each specific match_type is **needed**? It it is not
needed, then it is senseless per definition :-)
In the specific case of fwnode, there's already a named struct
for fwnode_handle. The only thing is that it is declared outside
enum v4l2_async_match_type. So, I don't see any reason to do things
like:
struct {
struct fwnode_handle *fwnode;
} fwnode;
If you're in doubt about that, think on how would you document
both fwnode structs. Both fwnode structs specify the match
criteria if %V4L2_ASYNC_MATCH_FWNODE.
The same applies to this:
struct {
const char *name;
} device_name;
Both device_name and name specifies the match criteria if
%V4L2_ASYNC_MATCH_DEVNAME.
>
> In the two cases there's just a single field in the containing struct. You
> could remove the struct in that case as you do in this patch, and just use
> the field. But I think the result is less clean and so I wouldn't make this
> change.
It is actually cleaner without the stucts.
Without the useless struct, if one wants to match a firmware node, it
should be doing:
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
And that' it. For anyone that reads the above code, even not knowing
all details of "match", is clear that the match criteria is whatever
of_fwnode_handle() returns.
Now, on this:
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
It sounds that something is missing, as only one field of match.fwnode
was specified. Anyone not familiar with that non-conventional usage of
a struct with just one struct field inside would need to seek for the
header file declaring the struct. That would consume a lot of time for
code reviewers for no good reason.
The same apply for devname search:
In this case:
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name.name = imxsd->devname;
I would be expecting something else to be filled at device_name's
struct, for example to specify a case sensitive or case insensitive
match criteria, to allow seeking for a device's substring, or to
allow using other struct device fields to narrow the seek.
With this:
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name = imxsd->devname;
It is clear that the match criteria is fully specified.
> The confusion comes possibly from the fact that the struct is named the
> same as the field in the struct. These used to be called of and node, but
> with the fwnode property framework the references to the fwnode are, well,
> typically similarly called "fwnode". There's no underlying firmware
> interface with that name, fwnode property API is just an API.
The duplicated "fwnode" name only made it more evident that we don't
need to enclose a single match criteria field inside a struct.
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: mchehab@infradead.org (Mauro Carvalho Chehab)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure
Date: Fri, 29 Sep 2017 06:27:13 -0300 [thread overview]
Message-ID: <20170929062119.192e4fd1@vento.lan> (raw)
In-Reply-To: <20170928120920.ywgbtikkrts25qlj@valkosipuli.retiisi.org.uk>
Em Thu, 28 Sep 2017 15:09:21 +0300
Sakari Ailus <sakari.ailus@iki.fi> escreveu:
> Hi Mauro,
>
> On Wed, Sep 27, 2017 at 06:46:56PM -0300, Mauro Carvalho Chehab wrote:
> > The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> > struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> > match criteria requires just a device name.
> >
> > So, it doesn't make sense to enclose those into structs,
> > as the criteria can go directly into the union.
> >
> > That makes easier to document it, as we don't need to document
> > weird senseless structs.
>
> The idea is that in the union, there's a struct which is specific to the
> match_type field. I wouldn't call it senseless.
Why a struct for each specific match_type is **needed**? It it is not
needed, then it is senseless per definition :-)
In the specific case of fwnode, there's already a named struct
for fwnode_handle. The only thing is that it is declared outside
enum v4l2_async_match_type. So, I don't see any reason to do things
like:
struct {
struct fwnode_handle *fwnode;
} fwnode;
If you're in doubt about that, think on how would you document
both fwnode structs. Both fwnode structs specify the match
criteria if %V4L2_ASYNC_MATCH_FWNODE.
The same applies to this:
struct {
const char *name;
} device_name;
Both device_name and name specifies the match criteria if
%V4L2_ASYNC_MATCH_DEVNAME.
>
> In the two cases there's just a single field in the containing struct. You
> could remove the struct in that case as you do in this patch, and just use
> the field. But I think the result is less clean and so I wouldn't make this
> change.
It is actually cleaner without the stucts.
Without the useless struct, if one wants to match a firmware node, it
should be doing:
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
And that' it. For anyone that reads the above code, even not knowing
all details of "match", is clear that the match criteria is whatever
of_fwnode_handle() returns.
Now, on this:
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
It sounds that something is missing, as only one field of match.fwnode
was specified. Anyone not familiar with that non-conventional usage of
a struct with just one struct field inside would need to seek for the
header file declaring the struct. That would consume a lot of time for
code reviewers for no good reason.
The same apply for devname search:
In this case:
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name.name = imxsd->devname;
I would be expecting something else to be filled at device_name's
struct, for example to specify a case sensitive or case insensitive
match criteria, to allow seeking for a device's substring, or to
allow using other struct device fields to narrow the seek.
With this:
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name = imxsd->devname;
It is clear that the match criteria is fully specified.
> The confusion comes possibly from the fact that the struct is named the
> same as the field in the struct. These used to be called of and node, but
> with the fwnode property framework the references to the fwnode are, well,
> typically similarly called "fwnode". There's no underlying firmware
> interface with that name, fwnode property API is just an API.
The duplicated "fwnode" name only made it more evident that we don't
need to enclose a single match criteria field inside a struct.
Thanks,
Mauro
next prev parent reply other threads:[~2017-09-29 9:27 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 21:46 [PATCH v2 00/17] V4L cleanups and documentation improvements Mauro Carvalho Chehab
2017-09-27 21:46 ` [PATCH v2 01/17] media: tuner-types: add kernel-doc markups for struct tunertype Mauro Carvalho Chehab
2017-09-27 21:46 ` [PATCH v2 02/17] media: v4l2-common: get rid of v4l2_routing dead struct Mauro Carvalho Chehab
2017-10-13 11:23 ` Laurent Pinchart
2017-10-13 13:24 ` Hans Verkuil
2017-12-18 14:11 ` Mauro Carvalho Chehab
2017-12-18 14:51 ` Sean Young
2017-09-27 21:46 ` [PATCH v2 03/17] media: v4l2-common: get rid of struct v4l2_discrete_probe Mauro Carvalho Chehab
2017-10-13 11:21 ` Laurent Pinchart
2017-10-13 13:27 ` Hans Verkuil
2017-09-27 21:46 ` [PATCH v2 04/17] media: v4l2-common.h: document ancillary functions Mauro Carvalho Chehab
2017-10-13 11:30 ` Laurent Pinchart
2017-10-13 13:31 ` Hans Verkuil
2017-09-27 21:46 ` [PATCH v2 05/17] media: v4l2-device.h: document ancillary macros Mauro Carvalho Chehab
2017-10-13 12:33 ` Laurent Pinchart
2017-12-18 14:58 ` Mauro Carvalho Chehab
2017-10-13 15:31 ` Hans Verkuil
2017-09-27 21:46 ` [PATCH v2 06/17] media: v4l2-dv-timings.h: convert comment into kernel-doc markup Mauro Carvalho Chehab
2017-10-13 12:34 ` Laurent Pinchart
2017-10-13 15:31 ` Hans Verkuil
2017-09-27 21:46 ` [PATCH v2 07/17] media: v4l2-event.rst: improve events description Mauro Carvalho Chehab
2017-09-28 12:34 ` Sakari Ailus
2017-10-13 15:40 ` Hans Verkuil
2017-09-27 21:46 ` [PATCH v2 08/17] media: v4l2-ioctl.h: convert debug macros into enum and document Mauro Carvalho Chehab
2017-10-13 12:38 ` Laurent Pinchart
2017-12-18 15:13 ` Mauro Carvalho Chehab
2017-12-18 15:32 ` Laurent Pinchart
2017-12-18 22:21 ` Mauro Carvalho Chehab
2017-10-13 15:41 ` Hans Verkuil
2017-09-27 21:46 ` [PATCH v2 09/17] media: cec-pin.h: convert comments for cec_pin_state into kernel-doc Mauro Carvalho Chehab
2017-10-13 15:48 ` Hans Verkuil
2017-10-13 20:16 ` Mauro Carvalho Chehab
2017-09-27 21:46 ` [PATCH v2 10/17] media: rc-core.rst: add an introduction for RC core Mauro Carvalho Chehab
2017-09-27 21:46 ` [PATCH v2 11/17] media: rc-core.h: minor adjustments at rc_driver_type doc Mauro Carvalho Chehab
2017-09-27 21:46 ` [PATCH v2 12/17] media: v4l2-fwnode.h: better describe bus union at fwnode endpoint struct Mauro Carvalho Chehab
2017-09-28 12:15 ` Sakari Ailus
2017-10-13 12:42 ` Laurent Pinchart
2017-09-27 21:46 ` [PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure Mauro Carvalho Chehab
2017-09-27 21:46 ` Mauro Carvalho Chehab
2017-09-27 21:46 ` Mauro Carvalho Chehab
2017-09-28 9:06 ` Sylwester Nawrocki
2017-09-28 9:06 ` Sylwester Nawrocki
2017-09-28 12:09 ` Sakari Ailus
2017-09-28 12:09 ` Sakari Ailus
2017-09-28 12:09 ` Sakari Ailus
2017-09-29 9:27 ` Mauro Carvalho Chehab [this message]
2017-09-29 9:27 ` Mauro Carvalho Chehab
2017-09-29 9:27 ` Mauro Carvalho Chehab
2017-09-29 22:05 ` Sakari Ailus
2017-09-29 22:05 ` Sakari Ailus
2017-12-18 19:04 ` Mauro Carvalho Chehab
2017-12-18 19:04 ` Mauro Carvalho Chehab
2017-09-28 12:53 ` [RESEND PATCH " Sakari Ailus
2017-09-28 12:53 ` Sakari Ailus
2017-09-27 21:46 ` [PATCH v2 14/17] media: v4l2-async: better describe match union at async match struct Mauro Carvalho Chehab
2017-10-13 12:49 ` Laurent Pinchart
2017-12-18 19:10 ` Mauro Carvalho Chehab
2017-09-27 21:46 ` [PATCH v2 15/17] media: v4l2-ctrls: document nested members of structs Mauro Carvalho Chehab
2017-10-13 12:54 ` Laurent Pinchart
2017-09-27 21:46 ` [PATCH v2 16/17] media: videobuf2-core: improve kernel-doc markups Mauro Carvalho Chehab
2017-09-29 12:04 ` Marek Szyprowski
2017-09-27 21:47 ` [PATCH v2 17/17] media: media-entity.h: add kernel-doc markups for nested structs Mauro Carvalho Chehab
2017-09-28 12:50 ` [PATCH v2 00/17] V4L cleanups and documentation improvements Sakari Ailus
2017-09-28 12:53 ` [RESEND PATCH v2 13/17] media: v4l2-async: simplify v4l2_async_subdev structure Mauro Carvalho Chehab
2017-09-28 12:53 ` Mauro Carvalho Chehab
2017-09-28 12:53 ` Mauro Carvalho Chehab
2017-09-28 13:02 ` Sylwester Nawrocki
2017-09-28 13:02 ` Sylwester Nawrocki
2017-09-28 13:27 ` Sakari Ailus
2017-09-28 13:27 ` Sakari Ailus
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=20170929062119.192e4fd1@vento.lan \
--to=mchehab@infradead.org \
--cc=corbet@lwn.net \
--cc=devel@driverdev.osuosl.org \
--cc=elfring@users.sourceforge.net \
--cc=hans.verkuil@cisco.com \
--cc=javi.merino@kernel.org \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-media@vger.kernel.o \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=ludovic.desroches@microchip.com \
--cc=michal.simek@xilinx.com \
--cc=p.zabel@pengutronix.de \
--cc=prabhakar.csengg@gmail.com \
--cc=robert.jarzmik@free.fr \
--cc=s.nawrocki@samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=slongerbeam@gmail.com \
--cc=songjun.wu@microchip.com \
--cc=tuukka.toivonen@intel.com \
--cc=yannick.fertre@st.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.