linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <Mario.Limonciello@dell.com>
To: Hans de Goede <hdegoede@redhat.com>,
	Divya Bharathi <divya27392@gmail.com>,
	"dvhart@infradead.org" <dvhart@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>,
	"Bharathi, Divya" <Divya.Bharathi@Dell.com>,
	"Ksr, Prasanth" <Prasanth.Ksr@dell.com>,
	Richard Hughes <rhughes@redhat.com>,
	Jared Dominguez <jaredz@redhat.com>
Subject: RE: [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems
Date: Tue, 22 Sep 2020 18:02:54 +0000	[thread overview]
Message-ID: <DM6PR19MB263605096186885BF90680E3FA3B0@DM6PR19MB2636.namprd19.prod.outlook.com> (raw)
In-Reply-To: <01c6632a-4e21-dfc0-c5d8-42a7016bfa16@redhat.com>

> 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 least 5 different interfaces.
> 
> It is bad enough that we already have to deal with having 5+
> different firmware interfaces for this and worse even for silly
> things like setting the brightness level for the kbd backlight,
> which is such a trivial thing that you would think PC vendors
> should be able to sit down and agree on a single ACPI API for it.
> 
> We are NOT going to take this lets all do our own thing approach and
> also let this trickle up in the stack to the kernel <-> userspace API!
> 
> One of the tasks of the kernel is to act as a HAL and this clearly
> falls under that. Imagine if userspace code would need to use different
> kernel APIs for storage/filesystem accesses depending on if they were
> running on a Dell or a Lenovo machines. Or having different APIs to
> access the network depending on the machine vendor...
> 
> So I'm sorry, but I'm drawing a line in the sand here, unless you can
> come up with some really convincing NEW arguments why this needs to
> be a Dell specific interface, the Dell firmware-attributes code must
> use a generic sysfs-ABI/class to get accepted upstream.
> 
> Note that I think the currently suggested private Dell ABI is actually
> pretty suitable for such a generic sysfs-ABI/class, so I'm not asking
> you to make a lot of changes here.
> 
> Regards,
> 
> Hans

We'll try this for the v4 patch series. 


  reply	other threads:[~2020-09-22 19:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 14:31 [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems Divya Bharathi
2020-08-08 18:37 ` Limonciello, Mario
2020-08-10  8:27   ` Andy Shevchenko
2020-09-01  9:49 ` Hans de Goede
2020-09-01 14:17   ` Limonciello, Mario
2020-09-14  9:13     ` Hans de Goede
2020-09-14  9:13     ` Hans de Goede
2020-09-14 16:06       ` Limonciello, Mario
2020-09-17 10:11         ` Hans de Goede
2020-09-17 16:18           ` Limonciello, Mario
2020-09-21 10:02             ` Hans de Goede
2020-09-21 15:26               ` Limonciello, Mario
2020-09-22  8:57                 ` Hans de Goede
2020-09-22  9:14                   ` Hans de Goede
2020-09-22 18:02                     ` Limonciello, Mario [this message]
2020-09-22  9:02                 ` Hans de Goede
2020-09-01 10:09 ` Hans de Goede
2020-09-01 14:22   ` Limonciello, Mario
2020-09-14  8:45     ` Hans de Goede
2020-09-14  8:57       ` Hans de Goede
2020-09-01 11:41 ` Hans de Goede
2020-09-02  8:04   ` Andy Shevchenko
2020-09-03 14:27     ` Limonciello, Mario
2020-09-14  9:53       ` 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=DM6PR19MB263605096186885BF90680E3FA3B0@DM6PR19MB2636.namprd19.prod.outlook.com \
    --to=mario.limonciello@dell.com \
    --cc=Divya.Bharathi@Dell.com \
    --cc=Prasanth.Ksr@dell.com \
    --cc=divya27392@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=hdegoede@redhat.com \
    --cc=jaredz@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rhughes@redhat.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;
as well as URLs for NNTP newsgroup(s).