All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Biju Das <biju.das.jz@bp.renesas.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Andi Shyti <andi.shyti@kernel.org>,
	linux-renesas-soc@vger.kernel.org,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>
Subject: Re: [PATCH 2/4] usb: typec: tcpci_rt1711h: Convert enum->pointer for data in the match tables
Date: Tue, 22 Aug 2023 14:44:44 +0300	[thread overview]
Message-ID: <ZOSfrHUDpaax1FS4@smile.fi.intel.com> (raw)
In-Reply-To: <CAMuHMdU_4Mg==Jh14K0ecVXfLCDt-RbNia5gCwLPjPj3tBQbsA@mail.gmail.com>

On Tue, Aug 22, 2023 at 09:21:19AM +0200, Geert Uytterhoeven wrote:
> On Mon, Aug 21, 2023 at 7:09 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Aug 21, 2023 at 05:40:05PM +0200, Geert Uytterhoeven wrote:
> > > On Mon, Aug 21, 2023 at 5:25 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Mon, Aug 21, 2023 at 03:27:43PM +0200, Geert Uytterhoeven wrote:
> > > > > On Mon, Aug 21, 2023 at 3:04 PM Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > > On Sun, Aug 20, 2023 at 07:44:00PM +0100, Biju Das wrote:

...

> > > > > > For all your work likes this as I noted in the reply to Guenter that
> > > > > > the couple of the selling points here are:
> > > > > > 1) avoidance of the pointer abuse in OF table
> > > > > >    (we need that to be a valid pointer);
> > > > >
> > > > > There is no pointer abuse: both const void * (in e.g. of_device_id)
> > > > > and kernel_ulong_t (in e.g. i2c_device_id) can be used by drivers
> > > > > to store a magic cookie, being either a pointer, or an integer value.
> > > > > The same is true for the various unsigned long and void * "driver_data"
> > > > > fields in subsystem-specific driver structures.
> > > >
> > > > (void *)5 is the abuse of the pointer.
> > > > We carry something which is not a valid pointer from kernel perspective.
> > >
> > > But the data field is not required to be a valid pointer.
> > > What kind and type of information it represents is specific to the driver.
> >
> > Where to find necessary information which is not always an integer constant.
> > For example, for the driver data that has callbacks it can't be invalid pointer.
> 
> If the driver uses it to store callbacks, of course it needs to be a
> valid pointer. But that is internal to the driver.  It is not that
> we're passing random integer values to a function that expects a
> pointer that can actually be dereferenced.
> 
> > Since OF ID table structure is universal, it uses pointers. Maybe you need to
> > update it to use plain integer instead?
> 
> It is fairly common in the kernel to use void * to indicate a
> driver-specific cookie, being either a real pointer or an integral
> value, that is passed verbatim.  See also e.g. the "dev" parameter
> of request_irq().

Yes, that parameter is void * due to calling kfree(free_irq(...)).
So, that's argument for my concerns.

> > I think there is no more sense to continue this. We have to admit we have
> > a good disagreement on this and I do not see any way I can agree with your
> > arguments. Note, I'm fine if you "fix" OF ID structure to use kernel_ulong_t.
> 
> of_device_id is also used in userspace (e.g. modutils), but I believe
> that uses a copy of the structure definition, not the definition from
> the kernel headers.

Nope, it uses the very same mod_devicetable.h in both.

> Still, changing the type would be a lot of work,
> for IMHO no real gain.

So, stale mate here, then?

> > The only objection there is that it may not carry on the const qualifier,
> > which I personally find being a huge downside of the whole driver_data.
> > I believe you haven't objected that.
> 
> Having const is nice, indeed.

At least something we have agreed on :-)

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2023-08-22 11:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-20 18:43 [PATCH 0/4] onvert enum->pointer for data in the rt1711h match tables Biju Das
2023-08-20 18:43 ` [PATCH 1/4] usb: typec: tcpci_rt1711h: Make similar OF and ID table Biju Das
2023-08-20 18:44 ` [PATCH 2/4] usb: typec: tcpci_rt1711h: Convert enum->pointer for data in the match tables Biju Das
2023-08-21 13:04   ` Andy Shevchenko
2023-08-21 13:27     ` Geert Uytterhoeven
2023-08-21 15:24       ` Andy Shevchenko
2023-08-21 15:40         ` Geert Uytterhoeven
2023-08-21 16:05           ` Guenter Roeck
2023-08-21 17:08           ` Andy Shevchenko
2023-08-22  7:21             ` Geert Uytterhoeven
2023-08-22 11:44               ` Andy Shevchenko [this message]
2023-08-22 12:00                 ` Geert Uytterhoeven
2023-08-22 12:08                   ` Andy Shevchenko
2023-08-22 12:51                     ` Biju Das
2023-08-22 13:23                       ` Andy Shevchenko
2023-08-23 14:49                     ` Andi Shyti
2023-08-23 15:10                       ` Geert Uytterhoeven
2023-08-23 15:20                         ` Greg Kroah-Hartman
2023-08-23 15:36                       ` Dmitry Torokhov
2023-08-21 16:45     ` Biju Das
2023-08-20 18:44 ` [PATCH 3/4] usb: typec: tcpci_rt1711h: Add rxdz_sel variable to struct rt1711h_chip_info Biju Das
2023-08-21 13:06   ` Andy Shevchenko
2023-08-21 13:33     ` Geert Uytterhoeven
2023-08-21 15:26       ` Andy Shevchenko
2023-08-20 18:44 ` [PATCH 4/4] usb: typec: tcpci_rt1711h: Add enable_pd30_extended_message feature bit " Biju Das
2023-08-21 13:08   ` Andy Shevchenko
2023-08-21 14:12     ` Guenter Roeck

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=ZOSfrHUDpaax1FS4@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=andi.shyti@kernel.org \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    /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.