All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries
Date: Wed, 5 May 2021 12:30:15 +0200	[thread overview]
Message-ID: <adb9be8a-70c7-b515-48c3-7e372e5d8801@redhat.com> (raw)
In-Reply-To: <CAHp75VcHEMaZ67yy7TD8f8Nk=+oiLT-vRCt9A6fT9K6LeR78Ew@mail.gmail.com>

Hi,

On 5/5/21 12:02 PM, Andy Shevchenko wrote:
> On Wed, May 5, 2021 at 12:28 PM Hans de Goede <hdegoede@redhat.com> wrote:
>> On 5/5/21 11:17 AM, Andy Shevchenko wrote:
>>> On Wed, May 5, 2021 at 12:07 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
>>>>> On Monday, May 3, 2021, Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> wrote:
>>>
>>> ...
>>>
>>>>>     +               fwnode = device_get_next_child_node(kdev, fwnode);
>>>
>>>>> Who is dropping reference counting on fwnode ?
>>>>
>>>> We are dealing with ACPI fwnode-s here and those are not ref-counted, they
>>>> are embedded inside a struct acpi_device and their lifetime is tied to
>>>> that struct. They should probably still be ref-counted (with the count
>>>> never dropping to 0) so that the generic fwnode functions behave the same
>>>> anywhere but atm the ACPI nodes are not refcounted, see: acpi_get_next_subnode()
>>>> in drivers/acpi/property.c which is the get_next_child_node() implementation
>>>> for ACPI fwnode-s.
>>>
>>> Yes, ACPI currently is exceptional, but fwnode API is not.
>>> If you may guarantee that this case won't ever be outside of ACPI
>>
>> Yes I can guarantee that currently this code (which is for the i915
>> driver only) only deals with ACPI fwnodes.
>>
>>> and
>>> even though if ACPI won't ever gain a reference counting for fwnodes,
>>> we can leave it as is.
>>
>> Would it not be better to add fake ref-counting to the ACPI fwnode
>> next_child_node() op though. I believe just getting a reference
>> on the return value there should work fine; and then all fwnode
>> implementations would be consistent ?
> 
> But it's already there by absent put/get callbacks.

Ah, I completely missed that the put/get-s are actually done
through function pointers in fwnode_operations. I assumed that there
was a kref embedded inside the fwnode_handle struct and that they
operated directly on that.

So this whole discussion is entirely based on that misunderstanding,
my bad, sorry.

So yes you are right, things are already consistent thanks to the
absent put/get callbacks.

But we do really need to document the behavior better here
in the kdoc for fwnode_get_next_child_node() and
device_get_next_child_node().

of_get_next_child has this bit, which applies to those too:

 *      Returns a node pointer with refcount incremented, use of_node_put() on
 *      it when done. Returns NULL when prev is the last child. Decrements the
 *      refcount of prev.

I'll prepare a patch to add this to the kdoc for fwnode_get_next_child_node()
and device_get_next_child_node() once I'm done with readying v3 of this series.

Regards,

Hans


WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	"platform-driver-x86@vger.kernel.org"
	<platform-driver-x86@vger.kernel.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries
Date: Wed, 5 May 2021 12:30:15 +0200	[thread overview]
Message-ID: <adb9be8a-70c7-b515-48c3-7e372e5d8801@redhat.com> (raw)
In-Reply-To: <CAHp75VcHEMaZ67yy7TD8f8Nk=+oiLT-vRCt9A6fT9K6LeR78Ew@mail.gmail.com>

Hi,

On 5/5/21 12:02 PM, Andy Shevchenko wrote:
> On Wed, May 5, 2021 at 12:28 PM Hans de Goede <hdegoede@redhat.com> wrote:
>> On 5/5/21 11:17 AM, Andy Shevchenko wrote:
>>> On Wed, May 5, 2021 at 12:07 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
>>>>> On Monday, May 3, 2021, Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> wrote:
>>>
>>> ...
>>>
>>>>>     +               fwnode = device_get_next_child_node(kdev, fwnode);
>>>
>>>>> Who is dropping reference counting on fwnode ?
>>>>
>>>> We are dealing with ACPI fwnode-s here and those are not ref-counted, they
>>>> are embedded inside a struct acpi_device and their lifetime is tied to
>>>> that struct. They should probably still be ref-counted (with the count
>>>> never dropping to 0) so that the generic fwnode functions behave the same
>>>> anywhere but atm the ACPI nodes are not refcounted, see: acpi_get_next_subnode()
>>>> in drivers/acpi/property.c which is the get_next_child_node() implementation
>>>> for ACPI fwnode-s.
>>>
>>> Yes, ACPI currently is exceptional, but fwnode API is not.
>>> If you may guarantee that this case won't ever be outside of ACPI
>>
>> Yes I can guarantee that currently this code (which is for the i915
>> driver only) only deals with ACPI fwnodes.
>>
>>> and
>>> even though if ACPI won't ever gain a reference counting for fwnodes,
>>> we can leave it as is.
>>
>> Would it not be better to add fake ref-counting to the ACPI fwnode
>> next_child_node() op though. I believe just getting a reference
>> on the return value there should work fine; and then all fwnode
>> implementations would be consistent ?
> 
> But it's already there by absent put/get callbacks.

Ah, I completely missed that the put/get-s are actually done
through function pointers in fwnode_operations. I assumed that there
was a kref embedded inside the fwnode_handle struct and that they
operated directly on that.

So this whole discussion is entirely based on that misunderstanding,
my bad, sorry.

So yes you are right, things are already consistent thanks to the
absent put/get callbacks.

But we do really need to document the behavior better here
in the kdoc for fwnode_get_next_child_node() and
device_get_next_child_node().

of_get_next_child has this bit, which applies to those too:

 *      Returns a node pointer with refcount incremented, use of_node_put() on
 *      it when done. Returns NULL when prev is the last child. Decrements the
 *      refcount of prev.

I'll prepare a patch to add this to the kdoc for fwnode_get_next_child_node()
and device_get_next_child_node() once I'm done with readying v3 of this series.

Regards,

Hans

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	Maxime Ripard <mripard@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"platform-driver-x86@vger.kernel.org"
	<platform-driver-x86@vger.kernel.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries
Date: Wed, 5 May 2021 12:30:15 +0200	[thread overview]
Message-ID: <adb9be8a-70c7-b515-48c3-7e372e5d8801@redhat.com> (raw)
In-Reply-To: <CAHp75VcHEMaZ67yy7TD8f8Nk=+oiLT-vRCt9A6fT9K6LeR78Ew@mail.gmail.com>

Hi,

On 5/5/21 12:02 PM, Andy Shevchenko wrote:
> On Wed, May 5, 2021 at 12:28 PM Hans de Goede <hdegoede@redhat.com> wrote:
>> On 5/5/21 11:17 AM, Andy Shevchenko wrote:
>>> On Wed, May 5, 2021 at 12:07 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
>>>>> On Monday, May 3, 2021, Hans de Goede <hdegoede@redhat.com <mailto:hdegoede@redhat.com>> wrote:
>>>
>>> ...
>>>
>>>>>     +               fwnode = device_get_next_child_node(kdev, fwnode);
>>>
>>>>> Who is dropping reference counting on fwnode ?
>>>>
>>>> We are dealing with ACPI fwnode-s here and those are not ref-counted, they
>>>> are embedded inside a struct acpi_device and their lifetime is tied to
>>>> that struct. They should probably still be ref-counted (with the count
>>>> never dropping to 0) so that the generic fwnode functions behave the same
>>>> anywhere but atm the ACPI nodes are not refcounted, see: acpi_get_next_subnode()
>>>> in drivers/acpi/property.c which is the get_next_child_node() implementation
>>>> for ACPI fwnode-s.
>>>
>>> Yes, ACPI currently is exceptional, but fwnode API is not.
>>> If you may guarantee that this case won't ever be outside of ACPI
>>
>> Yes I can guarantee that currently this code (which is for the i915
>> driver only) only deals with ACPI fwnodes.
>>
>>> and
>>> even though if ACPI won't ever gain a reference counting for fwnodes,
>>> we can leave it as is.
>>
>> Would it not be better to add fake ref-counting to the ACPI fwnode
>> next_child_node() op though. I believe just getting a reference
>> on the return value there should work fine; and then all fwnode
>> implementations would be consistent ?
> 
> But it's already there by absent put/get callbacks.

Ah, I completely missed that the put/get-s are actually done
through function pointers in fwnode_operations. I assumed that there
was a kref embedded inside the fwnode_handle struct and that they
operated directly on that.

So this whole discussion is entirely based on that misunderstanding,
my bad, sorry.

So yes you are right, things are already consistent thanks to the
absent put/get callbacks.

But we do really need to document the behavior better here
in the kdoc for fwnode_get_next_child_node() and
device_get_next_child_node().

of_get_next_child has this bit, which applies to those too:

 *      Returns a node pointer with refcount incremented, use of_node_put() on
 *      it when done. Returns NULL when prev is the last child. Decrements the
 *      refcount of prev.

I'll prepare a patch to add this to the kdoc for fwnode_get_next_child_node()
and device_get_next_child_node() once I'm done with readying v3 of this series.

Regards,

Hans

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-05-05 10:30 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 15:46 [PATCH 0/9] drm + usb-type-c: Add support for out-of-band hotplug notification (v2) Hans de Goede
2021-05-03 15:46 ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46 ` Hans de Goede
2021-05-03 15:46 ` [PATCH 1/9] drm/connector: Give connector sysfs devices there own device_type Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-03 15:46 ` [PATCH 2/9] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-04  7:57   ` Andy Shevchenko
2021-05-04  7:57     ` [Intel-gfx] " Andy Shevchenko
2021-05-03 15:46 ` [PATCH 3/9] drm/connector: Add drm_connector_find_by_fwnode() function (v2) Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-04  8:00   ` Andy Shevchenko
2021-05-04  8:00     ` [Intel-gfx] " Andy Shevchenko
2021-05-04 11:53     ` Hans de Goede
2021-05-04 11:53       ` [Intel-gfx] " Hans de Goede
2021-05-04 11:53       ` Hans de Goede
2021-05-04 12:35       ` Andy Shevchenko
2021-05-04 12:35         ` [Intel-gfx] " Andy Shevchenko
2021-05-04 12:35         ` Andy Shevchenko
2021-05-03 15:46 ` [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2) Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-04 15:10   ` Heikki Krogerus
2021-05-04 15:10     ` [Intel-gfx] " Heikki Krogerus
2021-05-04 15:10     ` Heikki Krogerus
2021-05-04 15:35     ` Hans de Goede
2021-05-04 15:35       ` [Intel-gfx] " Hans de Goede
2021-05-04 15:35       ` Hans de Goede
2021-05-05  9:50       ` Heikki Krogerus
2021-05-05  9:50         ` [Intel-gfx] " Heikki Krogerus
2021-05-05  9:50         ` Heikki Krogerus
2021-05-05 10:42         ` Hans de Goede
2021-05-05 10:42           ` [Intel-gfx] " Hans de Goede
2021-05-05 10:42           ` Hans de Goede
2021-05-03 15:46 ` [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-04  7:52   ` Andy Shevchenko
2021-05-04  7:52     ` [Intel-gfx] " Andy Shevchenko
2021-05-04 14:56     ` Heikki Krogerus
2021-05-04 14:56       ` [Intel-gfx] " Heikki Krogerus
2021-05-04 14:56       ` Heikki Krogerus
2021-05-05  9:07     ` Hans de Goede
2021-05-05  9:07       ` [Intel-gfx] " Hans de Goede
2021-05-05  9:07       ` Hans de Goede
2021-05-05  9:17       ` Andy Shevchenko
2021-05-05  9:17         ` [Intel-gfx] " Andy Shevchenko
2021-05-05  9:17         ` Andy Shevchenko
2021-05-05  9:28         ` Hans de Goede
2021-05-05  9:28           ` [Intel-gfx] " Hans de Goede
2021-05-05  9:28           ` Hans de Goede
2021-05-05 10:02           ` Andy Shevchenko
2021-05-05 10:02             ` [Intel-gfx] " Andy Shevchenko
2021-05-05 10:02             ` Andy Shevchenko
2021-05-05 10:30             ` Hans de Goede [this message]
2021-05-05 10:30               ` [Intel-gfx] " Hans de Goede
2021-05-05 10:30               ` Hans de Goede
2021-05-05 12:55               ` Andy Shevchenko
2021-05-05 12:55                 ` [Intel-gfx] " Andy Shevchenko
2021-05-05 12:55                 ` Andy Shevchenko
2021-05-05 10:28         ` Sakari Ailus
2021-05-05 10:28           ` [Intel-gfx] " Sakari Ailus
2021-05-05 10:28           ` Sakari Ailus
2021-05-03 15:46 ` [PATCH 6/9] drm/i915/dp: Add support for out-of-bound hotplug events Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-03 15:46 ` [PATCH 7/9] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-03 15:46 ` [PATCH 8/9] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-05 10:17   ` Heikki Krogerus
2021-05-05 10:17     ` [Intel-gfx] " Heikki Krogerus
2021-05-05 10:17     ` Heikki Krogerus
2021-05-05 10:44     ` Hans de Goede
2021-05-05 10:44       ` [Intel-gfx] " Hans de Goede
2021-05-05 10:44       ` Hans de Goede
2021-05-03 15:46 ` [PATCH 9/9] platform/x86/intel_cht_int33fe: Correct "displayport" fwnode reference Hans de Goede
2021-05-03 15:46   ` [Intel-gfx] " Hans de Goede
2021-05-03 15:46   ` Hans de Goede
2021-05-19 13:37   ` Hans de Goede
2021-05-19 13:37     ` [Intel-gfx] " Hans de Goede
2021-05-19 13:37     ` Hans de Goede
2021-05-03 20:25 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm + usb-type-c: Add support for out-of-band hotplug notification (rev2) Patchwork
2021-05-04 15:22 ` [PATCH 0/9] drm + usb-type-c: Add support for out-of-band hotplug notification (v2) Heikki Krogerus
2021-05-04 15:22   ` [Intel-gfx] " Heikki Krogerus
2021-05-04 15:22   ` Heikki Krogerus
  -- strict thread matches above, loose matches on Subject: below --
2021-04-28 21:52 [PATCH 0/9] drm + usb-type-c: Add support for out-of-band hotplug notification Hans de Goede
2021-04-28 21:52 ` [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries Hans de Goede
2021-04-28 21:52   ` 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=adb9be8a-70c7-b515-48c3-7e372e5d8801@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=airlied@linux.ie \
    --cc=andy.shevchenko@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.