All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yuan, Perry" <Perry.Yuan@dell.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Perry Yuan <perry979106@gmail.com>,
	"oder_chiou@realtek.com" <oder_chiou@realtek.com>,
	"perex@perex.cz" <perex@perex.cz>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"mgross@linux.intel.com" <mgross@linux.intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"Limonciello, Mario" <Mario.Limonciello@dell.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>,
	"broonie@kernel.org" <broonie@kernel.org>
Subject: RE: [PATCH v3 1/3] platform/x86: dell-privacy: Add support for Dell hardware privacy
Date: Fri, 5 Mar 2021 02:56:57 +0000	[thread overview]
Message-ID: <SJ0PR19MB4528BF867F9CAB88675A6B5584969@SJ0PR19MB4528.namprd19.prod.outlook.com> (raw)
In-Reply-To: <882f4b80-c182-4038-39bd-eddb2ecc7800@linux.intel.com>

Hi Pierre

> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> Sent: 2021年2月17日 22:24
> To: Perry Yuan; Yuan, Perry; oder_chiou@realtek.com; perex@perex.cz;
> tiwai@suse.com; hdegoede@redhat.com; mgross@linux.intel.com
> Cc: alsa-devel@alsa-project.org; Limonciello, Mario; linux-
> kernel@vger.kernel.org; lgirdwood@gmail.com; platform-driver-
> x86@vger.kernel.org; broonie@kernel.org
> Subject: Re: [PATCH v3 1/3] platform/x86: dell-privacy: Add support for Dell
> hardware privacy
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> 
> On 2/17/21 6:47 AM, Perry Yuan wrote:
> > Hi Pierre:
> > On 2021/2/16 22:56, Pierre-Louis Bossart wrote:
> >>
> >>>>> +static const struct acpi_device_id privacy_acpi_device_ids[] = {
> >>>>> +    {"PNP0C09", 0},
> >>>>> +    { },
> >>>>> +};
> >>>>> +MODULE_DEVICE_TABLE(acpi, privacy_acpi_device_ids);
> >>>>> +
> >>>>> +static struct platform_driver dell_privacy_platform_drv = {
> >>>>> +    .driver = {
> >>>>> +        .name = PRIVACY_PLATFORM_NAME,
> >>>>> +        .acpi_match_table = ACPI_PTR(privacy_acpi_device_ids),
> >>>>> +    },
> >>>>
> >>>> no .probe?
> >>> Originally i added the probe here, but it cause the driver  .probe
> >>> called twice. after i use platform_driver_probe to register the
> >>> driver loading process, the duplicated probe issue resolved.
> >>>
> >>> I
> >>>>
> >>>>> +    .remove = dell_privacy_acpi_remove, };
> >>>>> +
> >>>>> +int __init dell_privacy_acpi_init(void) {
> >>>>> +    int err;
> >>>>> +    struct platform_device *pdev;
> >>>>> +    int privacy_capable = wmi_has_guid(DELL_PRIVACY_GUID);
> >>>>> +
> >>>>> +    if (!wmi_has_guid(DELL_PRIVACY_GUID))
> >>>>> +        return -ENODEV;
> >>>>> +
> >>>>> +    privacy_acpi = kzalloc(sizeof(*privacy_acpi), GFP_KERNEL);
> >>>>> +    if (!privacy_acpi)
> >>>>> +        return -ENOMEM;
> >>>>> +
> >>>>> +    pdev = platform_device_register_simple(
> >>>>> +            PRIVACY_PLATFORM_NAME, PLATFORM_DEVID_NONE, NULL,
> 0);
> >>>>> +    if (IS_ERR(pdev)) {
> >>>>> +        err = PTR_ERR(pdev);
> >>>>> +        goto pdev_err;
> >>>>> +    }
> >>>>> +    err = platform_driver_probe(&dell_privacy_platform_drv,
> >>>>> +            dell_privacy_acpi_probe);
> >>>>> +    if (err)
> >>>>> +        goto pdrv_err;
> >>>>
> >>>> why is the probe done here? Put differently, what prevents you from
> >>>> using a 'normal' platform driver, and do the leds_setup in the
> >>>> .probe()?
> >>> At first ,I used the normal platform driver framework, however tt
> >>> cause the driver  .probe called twice. after i use
> >>> platform_driver_probe to register the driver loading process, the
> >>> duplicated probe issue resolved.
> >>
> >> This sounds very odd...
> >>
> >> this looks like a conflict with the ACPI subsystem finding a device
> >> and probing the driver that's associated with the PNP0C09 HID, and
> >> then this module __init  creating a device manually which leads to a
> >> second probe
> >>
> >> Neither the platform_device_register_simple() nor
> >> platform_driver_probe() seem necessary?Because this privacy acpi
> >> driver file has dependency on the ec handle,
> > so i want to determine if the driver can be loaded basing on the EC ID
> > PNP0C09 matching.
> >
> > So far,It works well for me to register the privacy driver with  the
> > register sequence.
> > Dose it hurt to keep current registering process with
> > platform_driver_probe used?
> 
> Sorry, I don't understand why you need to list PNP0C09 HID in a matching
> table if it's not used to probe anything.
> 
> The purpose of those matching tables is that when this HID is found, the core
> will invoke the probe callback with no need for any manual intervention.
> 
> If you want to do things manually with the module init, that's fine, it's the
> combination of the two that I find questionable.
> 
> It's like having both a manual and automatic transmission in a car, with the
> automatic transmission not coupled to the wheels.

I understand your point,I have removed the PNP0C09 ID from V4 patch.
Thanks for your suggestion very much !

Perry 

  reply	other threads:[~2021-03-05  2:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 17:17 [PATCH v3 1/3] platform/x86: dell-privacy: Add support for Dell hardware privacy Perry Yuan
2021-01-12 17:17 ` Perry Yuan
2021-01-12 17:39 ` Randy Dunlap
2021-01-12 17:39   ` Randy Dunlap
2021-01-16 15:10   ` Perry Yuan
2021-01-16 15:10     ` Perry Yuan
2021-02-14  7:23   ` Perry Yuan
2021-02-14  7:23     ` Perry Yuan
2021-01-12 19:00 ` Pierre-Louis Bossart
2021-01-12 19:00   ` Pierre-Louis Bossart
2021-02-16  6:48   ` Perry Yuan
2021-02-16 14:56     ` Pierre-Louis Bossart
2021-02-17 12:47       ` Perry Yuan
2021-02-17 14:23         ` Pierre-Louis Bossart
2021-03-05  2:56           ` Yuan, Perry [this message]
2021-03-05  2:56             ` Yuan, Perry

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=SJ0PR19MB4528BF867F9CAB88675A6B5584969@SJ0PR19MB4528.namprd19.prod.outlook.com \
    --to=perry.yuan@dell.com \
    --cc=Mario.Limonciello@dell.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=oder_chiou@realtek.com \
    --cc=perex@perex.cz \
    --cc=perry979106@gmail.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tiwai@suse.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.