>
> I think this could be `dev_info()`, but definitely not `dev_err()`. Although
> I'd
> personally move the logging from here to the probe function if you want to log
> which features are available. `ret` is necessarily 1 here, so I don't think
> printing it
> provides additional information.
To
> -Original Message-
> From: Rajneesh Bhardwaj
> Sent: Monday, March 8, 2021 11:32
> To: Limonciello, Mario
> Cc: David E. Box; hdego...@redhat.com; mgr...@linux.intel.com;
> sasha.nef...@intel.com; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.ke
>
> [EXTERNAL EMAIL]
>
> Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
> programmed in the Tiger Lake GBE controller is not large enough to allow
> the platform to enter Package C10, which in turn prevents the platform from
> achieving its low power target during suspend-to-
> -Original Message-
> From: mark gross
> Sent: Thursday, February 18, 2021 16:49
> To: Limonciello, Mario
> Cc: Hans De Goede; Mark Gross; LKML; platform-driver-...@vger.kernel.org;
> Bharathi, Divya; Alexander Naumann
> Subject: Re: [PATCH] platform/x86: dell-w
> -Original Message-
> From: Hans de Goede
> Sent: Saturday, January 30, 2021 15:44
> To: Limonciello, Mario; Mark Gross
> Cc: LKML; platform-driver-...@vger.kernel.org
> Subject: Re: [PATCH] platform/x86: dell-wmi-sysman: fix a NULL pointer
> dereference
&g
+Divya, +Prasanth, +Perry
> -Original Message-
> From: Limonciello, Mario
> Sent: Friday, January 29, 2021 11:27
> To: Hans De Goede; Mark Gross
> Cc: LKML; platform-driver-...@vger.kernel.org; Limonciello, Mario
> Subject: [PATCH] platform/x86: dell-wmi-sysman:
l.com; broo...@kernel.org; alsa-de...@alsa-project.org;
> >> linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; Yuan,
> >> Perry; Limonciello, Mario
> >> Subject: [PATCH v3 3/3] ASoC: rt715:add micmute led state control supports
> >>
> >> From:
rg;
> linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; Yuan,
> Perry; Limonciello, Mario
> Subject: [PATCH v3 2/3] x86/platform/dell-privacy-wmi: add document for dell
> privacy driver
>
> From: Perry Yuan
>
> Describe the Dell Privacy feature capabilities
rg;
> linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org; Yuan,
> Perry; Limonciello, Mario
> Subject: [PATCH v3 3/3] ASoC: rt715:add micmute led state control supports
>
> From: Perry Yuan
>
> Some new Dell system is going to support audio internal micphone
> privac
> > -Original Message-
> > From: Pierre-Louis Bossart
> > Sent: 2021年1月12日 2:07
> > To: Yuan, Perry; oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com
> > Cc: alsa-de...@alsa-project.org; Limonciello, Mario; lgirdw...@gmail.com;
> > linux-kernel
Dell Customer Communication - Confidential
Perry,
For discussion in public mailing lists you'll have to make sure that you get
Dell's mail service to turn off this clause and resend:
>
> Dell Customer Communication - Confidential
>
> -Original Message-
> From: Yuan, Perry
> Sent: Monday, January 4, 2021 3:10
> To: Mark Brown
> Cc: oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com;
> lgirdw...@gmail.com; alsa-de...@alsa-project.org; linux-
> ker...@vger.kernel.org; Limonciello, Mario
> Su
> > Absolutely - I'll ask them to look into this again.
> >
> we need to explain why on Windows systems required 1s and on Linux
> systems up to 2.5s - otherwise it is not reliable approach - you will
> encounter others buggy system.
> (ME not POR on the Linux systems - is only one possible answer
> Hi All,
>
> Sasha (and the other intel-wired-lan folks), thank you for investigating this
> further and for coming up with a better solution.
>
> Mario, thank you for implementing the new scheme.
>
Sure.
> I've tested this patch set on a Lenovo X1C8 with vPRO and AMT enabled in the
> BIOS
>
>
> Based on the earlier thread you had referenced and his comment here it
> sounds like while adding time will work for most cases, it doesn't
> solve it for all cases. The problem is as a vendor you are usually
> stuck looking for a solution that will work for all cases which can
> lead to thing
> First of all thank you for working on this.
>
> I must say though that I don't like the approach taken here very
> much.
>
> This is not so much a criticism of this series as it is a criticism
> of the earlier decision to simply disable s0ix on all devices
> with the i219-LM + and active ME.
I
> -Original Message-
> From: Alexander Duyck
> Sent: Friday, December 4, 2020 15:27
> To: Limonciello, Mario
> Cc: Jeff Kirsher; Tony Nguyen; intel-wired-lan; LKML; Linux PM; Netdev; Jakub
> Kicinski; Sasha Netfin; Aaron Brown; Stefan Assmann; David Miller; David
>
>
> Hi,
>
> +Cc Mario
>
> On 11/25/20 7:50 AM, Qinglang Miao wrote:
> > Fix to return the error code -ENODEV when fails to init wmi and
> > smm.
> >
> > Fixes: 41e36f2f85af ("platform/x86: dell-smbios: Link all dell-smbios-*
> modules together")
> > Reported-by: Hulk Robot
> > Signed-off-by: Qi
> >
> > Again, if anything in this flow doesn't happen HW mic mute is still
> activated,
> > just will take longer (for duration of timeout) and have popping noise.
>
> Thank you, can we put this in a comment in the driver please ?
Yes, I agree. I suggested to Perry that his next submission of t
> > Pressing the mute key activates a time delayed circuit to physically cut
> > off the mute. The LED is in the same circuit, so it reflects the true
> > state of the HW mute. The reason for the EC "ack" is so that software
> > can first invoke a SW mute before the HW circuit is cut off. Withou
> >> Given we're effectively ending up with the combination of runtime PM turned
> >> on by udev rules, do we need something like this for that ID:
> >>
> >>
> https://github.com/torvalds/linux/commit/6a7c533d4a1854f54901a065d8c672e890400
> d8a
> >>
> >> @Mika Westerberg should 8086:a0ed be quirked
>
> On Wed, Nov 11, 2020 at 07:21:07AM +, Yuan, Perry wrote:
> > > > +status = acpi_evaluate_object(NULL, ACPI_PRIVACY_EC_ACK, NULL,
> > > NULL);
> > > > +if (ACPI_FAILURE(status)) {
> > > > +dev_err(led_cdev->dev, "Error setting privacy audio EC ack
> > > value: %d\n",status);
> One note... I'll double check, but on my XPS 13 9380, as I recall, I
> have to manually disable autosuspend on all of the XHCI controllers
> and internal hubs after running "powertop --auto-tune", or else any
> external mouse attached to said USB device will be dead to the world
> for 2-3 seco
> On Tue, Nov 10, 2020 at 05:45:43PM +0000, Limonciello, Mario wrote:
> > > > I guess what Bastien is getting at is for newer devices supported by
> class
> > > > drivers rather than having to store an allowlist in udev rules, can we
> set
> > > &g
> > I guess what Bastien is getting at is for newer devices supported by class
> > drivers rather than having to store an allowlist in udev rules, can we set
> > the allowlist in the kernel instead. Then distributions that either don't
> > use systemd or don't regularly update udev rules from syst
>
> On Tue, Nov 10, 2020 at 11:57:07AM +0100, Bastien Nocera wrote:
> > Hey,
> >
> > systemd has been shipping this script to enable auto-suspend on a
> > number of USB and PCI devices:
> >
> https://github.com/systemd/systemd/blob/master/tools/chromiumos/gen_autosuspen
> d_rules.py
> >
> > The pr
> -Original Message-
> From: Christian Kujau
> Sent: Tuesday, November 3, 2020 17:41
> To: Limonciello, Mario; Andy Lutomirski; platform-driver-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Subject: acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2
> -Original Message-
> From: Mark Brown
> Sent: Tuesday, November 3, 2020 12:32
> To: Limonciello, Mario
> Cc: Pierre-Louis Bossart; Yuan, Perry; oder_ch...@realtek.com; alsa-
> de...@alsa-project.org; lgirdw...@gmail.com; linux-kernel@vger.kernel.org;
> ti...@s
> -Original Message-
> From: Mark Brown
> Sent: Tuesday, November 3, 2020 12:00
> To: Pierre-Louis Bossart
> Cc: Yuan, Perry; oder_ch...@realtek.com; alsa-de...@alsa-project.org;
> lgirdw...@gmail.com; Limonciello, Mario; linux-kernel@vger.kernel.org;
> ti...@s
> -Original Message-
> From: Pierre-Louis Bossart
> Sent: Tuesday, November 3, 2020 10:13
> To: Mark Brown; Yuan, Perry
> Cc: oder_ch...@realtek.com; alsa-de...@alsa-project.org; lgirdw...@gmail.com;
> Limonciello, Mario; linux-kernel@vger.kernel.org; ti...@suse.com
>
> This was present in previous versions too, but I just noticed this are you
> sure that using
> .string.pointer is correct here? That seems wrong since the pointer gets
> allocated by
> the Linux ACPI core, so it is not under influence of the AML code?
>
> I think you want / need to use ".integer
> > +
> > + print_hex_dump_bytes("set attribute data: ", DUMP_PREFIX_NONE, buffer,
> buffer_size);
>
> This seems to be a debugging left-over?
Yes it was for debugging, but its configurable to turn on by dynamic
debug as I can tell. Is that not correct?
> As far as I know, the profiles affect the thermal behavior like "how long to
> wait before starting the fan and at what temperature" or "how fast to run the
> fan with the current cpu load and temperature".
>
> The only way that firmware uses to "control" performance should be the odvp0
> DPTF
> On Wed, 2020-10-07 at 15:58 +0000, Limonciello, Mario wrote:
> >
> > > On Mon, 2020-10-05 at 12:58 +0000, Limonciello, Mario wrote:
> > > > > On modern systems CPU/GPU/... performance is often dynamically
> > > > > configurable
> > > &
> On Mon, 2020-10-05 at 12:58 +0000, Limonciello, Mario wrote:
> > > On modern systems CPU/GPU/... performance is often dynamically
> > > configurable
> > > in the form of e.g. variable clock-speeds and TPD. The performance
> > > is often
> >
> > From: Intel-wired-lan On Behalf Of
> > Mario Limonciello
> > Sent: Sunday, September 27, 2020 9:40 PM
> > To: Kirsher, Jeffrey T ; intel-wired-
> > l...@lists.osuosl.org
> > Cc: perry.y...@dell.com; yijun.s...@dell.com; linux-kernel@vger.kernel.org;
> > Mario Limonciello
> > Subject: [Intel
> On 2020-10-05 12:11 p.m., Limonciello, Mario wrote:
> >>
> >> Excuse my ignorance, but I don't really see why this interface would be
> tied
> >> to
> >> ACPI devices? Why is it not possible to write a driver that implements this
> >> int
> 2020. október 5., hétfő 14:58 keltezéssel, Limonciello, Mario írta:
> > > On modern systems CPU/GPU/... performance is often dynamically
> configurable
> > > in the form of e.g. variable clock-speeds and TPD. The performance is
> often
> > > automatically ad
> On modern systems CPU/GPU/... performance is often dynamically configurable
> in the form of e.g. variable clock-speeds and TPD. The performance is often
> automatically adjusted to the load by some automatic-mechanism (which may
> very well live outside the kernel).
>
> These auto performance-a
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
>
> Sorry for not addressing this during earlier reviews, but why is this
> check here. Is read-only access to the settings by normal users
> considered harmful ?
>
The best answer I can give is that this is exposing data
> > + possible_values:A file that can be read to obtain the
> > possible
> > + values of the . Values are
> > separated using
> > + semi-colon (``;``).
> why not use set notation from math classes assuming inter
> -Original Message-
> From: Hans de Goede
> Sent: Wednesday, September 30, 2020 10:37
> To: Limonciello, Mario; Barnabás Pőcze; Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; Takashi
> Iwai
> Subject: Re: Keyboard reg
> -Original Message-
> From: Hans de Goede
> Sent: Wednesday, September 30, 2020 8:28
> To: Limonciello, Mario; Barnabás Pőcze; Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; Takashi
> Iwai
> Subject: Re: Keyboard reg
>
> I requested on the Ubuntu bug for someone to provide these.
>
Joe Barnett was kind enough to share two ACPI dumps to compare.
Not affected:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394/+attachment/5415318/+files/1.2.0.acpidump
Affected:
https://bugs.launchpad.net/ubuntu/+sou
> > > >> I'm afraid that the only answer which I have to these questions
> > > >> is not helpful, but in my experience it is true: "firmware sucks".
> > > >
> > > > So FWIW there is a Dell 2-in-1 that has been conflated into this same
> issue.
> > > > https://bugs.launchpad.net/ubuntu/+source/linux
> -Original Message-
> From: Hans de Goede
> Sent: Tuesday, September 29, 2020 7:54
> To: Limonciello, Mario; Barnabás Pőcze; Takashi Iwai
> Cc: Andy Shevchenko; platform-driver-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: Keyboard reg
>I'm afraid that the only answer which I have to these questions
>is not helpful, but in my experience it is true: "firmware sucks".
So FWIW there is a Dell 2-in-1 that has been conflated into this same issue.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822394
Something that is confusin
>
> I really prefer min_value and max_value here, those have 2 advantages:
>
> 1. min/max is used almost everywhere in the kernel/sysfs for things like this,
> upper-/lower-bound feels a bit like archaic Enlish to me.
>
> 2. The _value postfix makes it immediately clear that they are the bou
So I do want to preface this response by mentioning that Dell's implementation
is based off the PLDM specification from the DMTF.
https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf
A lot of the nomenclature that has been already proposed to change followed
nomenclature
> -Original Message-
> From: Randy Dunlap
> Sent: Wednesday, September 23, 2020 12:12
> To: Divya Bharathi; dvh...@infradead.org
> Cc: LKML; platform-driver-...@vger.kernel.org; Bharathi, Divya; Hans de Goede;
> Andy Shevchenko; mark gross; Limonciello, Mario; Ksr, Pras
> So I've been thinking more about this and to me this whole argument
> sounds a lot like we just want to have our own little corner to
> play in, without needing to worry about what other vendors do.
>
> And then Lenovo, and HP and who knows else will all want the same
> and we and up with at lea
>
> > +
> > + "integer"-type specific properties:
> > +
> > + min_value: A file that can be read to obtain the lower
> > + bound value of the
> > +
> > + max_value: A file that can be read to obtain the upper
> > + bound value of the
>
>
> Well if different schemes are supported and each scheme has its own type,
> then I would expect there to be say / e.g.:
>
> /sys/class/firmware-attributes/dell/authentication/admin-password
> (with a type of "password") and:
> /sys/class/firmware-attributes/dell/authentication/admin-hotp
> (w
> > Those are very different flows to get to and change the same "types" of
> data. By Dell's interface
> > being Dell specific we can guarantee that the documented flow works how it
> should.
>
> Documenting the flow could be part of the documentation for the
> different passwd types.
In the c
>
> On 9/4/20 4:28 PM, Divya Bharathi wrote:
> > diff --git a/drivers/platform/x86/dell-wmi-biosattr-interface.c
> b/drivers/platform/x86/dell-wmi-biosattr-interface.c
> > new file mode 100644
> > index ..dda38d448fec
> > --- /dev/null
> > +++ b/drivers/platform/x86/dell-wmi-biosattr-i
> So my thinking here is as follows:
>
> 1. AFAIK other vendors may want to do something similar in the near future
> 2. The interface you (Dell) have come up with looks pretty generic / complete
> to me
>
> > Would those possible options
> > be hardcoded in their kernel driver?
>
> Maybe, so th
Andy,
Thanks for your feedback.
>
> > > +bool get_pending_changes(void)
> > > +{
> > > + struct wmi_interface_priv *priv;
> > > +
> > > + priv = get_first_interface_priv();
> > > + if (priv)
> > > + return priv->pending_changes;
>
> > > + return 0;
>
> 0 is not boole
> Going forward I will be helping Andy and Darren with maintaining the
> drivers/platform/x86/* drivers.
>
> So one of the first things which I'm doing with that hat on,
> is review this patch.
Congrats on the new responsibilities :)
>
> So first of all some comments on the userspace (sysfs) AP
>
> "A read-only attribute enumerating if a reboot is pending on any BIOS
> attribute
> change."
> does not really seem to make much sense. I guess what this is trying to say
> is:
>
> "This read-only attribute reads 1 if a reboot is necessary to apply pending
> BIOS
> attribute changes"?
>
>
> > I don't see the purpose of this line of discussion. VMD has been in the
> > kernel for 5 years. We are constantly working on better support.
>
> Please just work with the platform people to allow the host to disable
> VMD. That is the only really useful value add here.
Can you further elabor
L; platform-driver-...@vger.kernel.org; Bharathi, Divya; Limonciello,
> Mario; Ksr, Prasanth
> Subject: [PATCH] Introduce support for Systems Management Driver over WMI for
> Dell Systems
>
>
> [EXTERNAL EMAIL]
>
> From: Divya Bharathi
>
> The Dell WMI Systems Management Driver pro
> The values here seem very Dell specific, but this is going into a
> generic sysfs path. Really stuff here should be as vendor independent as
> possible. If these values don't correspond to a wider industry
> specification it probably makes sense to make this something Dell
> specific.
Worth
> -Original Message-
> From: Lu Baolu
> Sent: Tuesday, July 21, 2020 6:07 PM
> To: Limonciello, Mario; Joerg Roedel
> Cc: baolu...@linux.intel.com; Ashok Raj; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org; Koba Ko; io...@lists.linux-foundation.org
> Su
> -Original Message-
> From: iommu On Behalf Of Lu
> Baolu
> Sent: Monday, July 20, 2020 7:17 PM
> To: Joerg Roedel
> Cc: Ashok Raj; linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Koba
> Ko; io...@lists.linux-foundation.org
> Subject: [PATCH 1/1] iommu/vt-d: Skip TE disabling on qui
> -Original Message-
> From: iommu On Behalf Of Koba Ko
> Sent: Sunday, June 14, 2020 10:47 PM
> To: David Woodhouse; Lu Baolu; Joerg Roedel
> Cc: io...@lists.linux-foundation.org; Kai Heng Feng; Linux Kernel Mailing
> List
> Subject: [Issue]platform/x86: iommu: System can't shutdown becau
65 matches
Mail list logo
