public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Carlo Caione <carlo@endlessm.com>
Subject: Re: [PATCH] ACPI / LPSS: Add device link for CHT SD card dependency on I2C
Date: Mon, 04 Dec 2017 16:00:43 +0100	[thread overview]
Message-ID: <2244973.KDCVUlUVYl@aspire.rjw.lan> (raw)
In-Reply-To: <ea27da62-aa15-24ed-d35f-73ca9a5f40b8@intel.com>

On Monday, December 4, 2017 3:41:45 PM CET Adrian Hunter wrote:
> On 04/12/17 16:33, Hans de Goede wrote:
> > Hi,
> > 
> > On 04-12-17 15:30, Adrian Hunter wrote:
> >> On 04/12/17 15:48, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> Wouldn't it be easier to use the ACPI _DEP tracking for this, e.g.
> >>
> >> It is using _DEP, see acpi_lpss_dep()
> >>
> >>> add something like this to the the probe function:
> >>>
> >>>      struct acpi_device = ACPI_COMPANION(device);
> >>>
> >>>      if (acpi_device->dep_unmet)
> >>>          return -EPROBE_DEFER;
> >>>
> >>> No idea if this will work, but if it does work, using the deps described
> >>> in the ACPI tables seems like a better solution then hardcoding this.
> >>
> >> That would not work because there are other devices listed in the _DEP
> >> method so dep_unmet is always true.  So we are left checking _DEP but only
> >> for specific device dependencies.
> > 
> > Ugh, understood thank you for explaining this. Perhaps it is a good idea
> > to mention in the commit message why acpi_dev->dep_unmet cannot be used
> > here?
> 
> dep_unmet predates device links, but now we have device links, they are
> better anyway.

Right (they cover PM too, for example), but it would be good to note why
it is necessary to hardcode the links information in the code.

Thanks,
Rafael


  reply	other threads:[~2017-12-04 15:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 12:32 [PATCH] ACPI / LPSS: Add device link for CHT SD card dependency on I2C Adrian Hunter
2017-12-04 13:48 ` Hans de Goede
2017-12-04 14:30   ` Adrian Hunter
2017-12-04 14:33     ` Hans de Goede
2017-12-04 14:41       ` Adrian Hunter
2017-12-04 15:00         ` Rafael J. Wysocki [this message]
2017-12-05 14:25           ` Adrian Hunter
2017-12-05 15:05             ` Rafael J. Wysocki
2017-12-04 14:56       ` Rafael J. Wysocki
2017-12-04 13:56 ` Carlo Caione
2017-12-04 15:52   ` Adrian Hunter

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=2244973.KDCVUlUVYl@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=adrian.hunter@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=carlo@endlessm.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael.j.wysocki@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox