All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Limonciello, Mario" <Mario.Limonciello@amd.com>,
	Mark Gross <mgross@linux.intel.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>
Cc: "open list:X86 PLATFORM DRIVERS" 
	<platform-driver-x86@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"S-k, Shyam-sundar" <Shyam-sundar.S-k@amd.com>,
	"Goswami, Sanket" <Sanket.Goswami@amd.com>
Subject: Re: [PATCH v3 1/5] ACPI / x86: Add support for LPS0 callback handler
Date: Mon, 14 Mar 2022 14:37:20 +0100	[thread overview]
Message-ID: <8841ecb6-6c2c-164f-76df-54c4410faa20@redhat.com> (raw)
In-Reply-To: <BL1PR12MB5157664C2AA7D80E7DF48EC9E20F9@BL1PR12MB5157.namprd12.prod.outlook.com>

Hi,

On 3/14/22 14:32, Limonciello, Mario wrote:
> [Public]
> 
>>> +int acpi_register_lps0_callbacks(struct lps0_callback_handler *arg)
>>> +{
>>> +	struct lps0_callback_handler *handler;
>>> +
>>> +	if (!lps0_device_handle || sleep_no_lps0)
>>> +		return -ENODEV;
>>> +
>>> +	handler = kmalloc(sizeof(*handler), GFP_KERNEL);
>>> +	if (!handler)
>>> +		return -ENOMEM;
>>> +	handler->prepare_late_callback = arg->prepare_late_callback;
>>> +	handler->restore_early_callback = arg->restore_early_callback;
>>> +	handler->context = arg->context;
>>> +
>>> +	mutex_lock(&lps0_callback_handler_mutex);
>>> +	list_add(&handler->list_node, &lps0_callback_handler_head);
>>> +	mutex_unlock(&lps0_callback_handler_mutex);
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(acpi_register_lps0_callbacks);
>>
>> Typically with calls like these we simply let the caller own the struct
>> lps0_callback_handler
>> and only make the list_add() call here. Typically the struct
>> lps0_callback_handler will
>> be embedded in the driver_data of the driver registering the handler and it
>> will
>> call the unregister function before free-ing its driver_data.
>>
> 
> When I put this together I was modeling it off of `struct acpi_wakeup_handler`
> which the handling and the use in the kernel doesn't seem to follow the design pattern
> you describe.

Ah, fair enough. Whatever Rafael prefers works for me.

I pointed this out, because making this change would also make 4/5 a bit
cleaner. You are recreating the same struct lps0_callback_handler on
stack twice there, which looked weird to me.

Note if Rafael wants to stick with the approach from this v3, then
I guess that the approach in 4/5 is fine. 
> Rafael - can you please confirm which direction you want to see here for this?

Regards,

Hans



> 
>>> +
>>> +void acpi_unregister_lps0_callbacks(struct lps0_callback_handler *arg)
>>> +{
>>> +	struct lps0_callback_handler *handler;
>>> +
>>> +	mutex_lock(&lps0_callback_handler_mutex);
>>> +	list_for_each_entry(handler, &lps0_callback_handler_head,
>> list_node) {
>>> +		if (handler->prepare_late_callback == arg-
>>> prepare_late_callback &&
>>> +		    handler->restore_early_callback == arg-
>>> restore_early_callback &&
>>> +		    handler->context == arg->context) {
>>> +			list_del(&handler->list_node);
>>> +			kfree(handler);
>>> +			break;
>>> +		}
>>> +	}
>>> +	mutex_unlock(&lps0_callback_handler_mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(acpi_unregister_lps0_callbacks);
>>
>> And this then becomes just lock, list_del, unlock.
>>
>> Regards,
>>
>> Hans


  reply	other threads:[~2022-03-14 13:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14  5:03 [PATCH v3 1/5] ACPI / x86: Add support for LPS0 callback handler Mario Limonciello
2022-03-14  5:03 ` [PATCH v3 2/5] ACPI / x86: Pass the constraints checking result to LPS0 callback Mario Limonciello
2022-03-14  5:03 ` [PATCH v3 3/5] ACPI / x86: Check LPI constraints by default Mario Limonciello
2022-03-14  5:03 ` [PATCH v3 4/5] platform/x86: amd-pmc: Move to later in the suspend process Mario Limonciello
2022-03-14  5:03 ` [PATCH v3 5/5] platform/x86: amd-pmc: Drop CPU QoS workaround Mario Limonciello
2022-03-14  9:05 ` [PATCH v3 1/5] ACPI / x86: Add support for LPS0 callback handler Hans de Goede
2022-03-14 13:32   ` Limonciello, Mario
2022-03-14 13:37     ` Hans de Goede [this message]
2022-03-16 15:02       ` Rafael J. Wysocki
2022-03-16 15:34         ` Rafael J. Wysocki
2022-03-16 15:43           ` Limonciello, Mario
2022-03-16 15:52             ` Rafael J. Wysocki
2022-03-16 16:43               ` Limonciello, Mario
2022-03-16 17:27                 ` Rafael J. Wysocki
2022-03-15  1:01     ` David E. Box
2022-03-14  9:12 ` Lukas Wunner
2022-03-14 13:28   ` Limonciello, Mario

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=8841ecb6-6c2c-164f-76df-54c4410faa20@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=Mario.Limonciello@amd.com \
    --cc=Sanket.Goswami@amd.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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.