From: David Woodhouse <dwmw2@infradead.org> To: Catalin Marinas <catalin.marinas@arm.com> Cc: Hanjun Guo <hanjun.guo@linaro.org>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Jeremy Linton <jeremy.linton@arm.com>, linux-arm-kernel@lists.infradead.org, steve.glendinning@shawell.net, netdev@vger.kernel.org, grant.likely@linaro.org, Suravee.Suthikulpanit@amd.com Subject: Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT Date: Thu, 24 Sep 2015 12:52:38 +0100 [thread overview] Message-ID: <1443095558.74600.84.camel@infradead.org> (raw) In-Reply-To: <20150924103152.GG13823@e104818-lin.cambridge.arm.com> [-- Attachment #1: Type: text/plain, Size: 2600 bytes --] Hi Catalin, I understand your concerns, but I'm still not convinced of your conclusion. On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote: > PRP0001 opens the door to any DT-like properties in ACPI and, knowing > how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if > we haven't already; not all the developments are done in the open). No. That door is wide open already — people can already do whatever they like in _DSD properties. If they're going to screw up DT properties, they'll screw up ACPI-only _DSD properties just the same. You speak of maintaining "tight control of the _DSD properties that are going to be used in ACPI tables"... but if you're going to confiscate their crackpipe and stand over them while they work, you can do that just as well whether they're using "PRP0001" or "FOO1234" as their HID value. In that sense, the HID is entirely orthogonal. And think about it... we *really* don't want a given peripheral device to have *different* bindings depending on whether it's discovered with a specific ACPI HID, vs. when it's discovered via DT or the PRP0001 HID. That way lies complete insanity. In some ways, your proposal would be actively *counterproductive*. You say you want to train people *not* to keep patching the kernel. But where they *could* have just used PRP0001 and used a pre-existing kernel, you then tell them "oh, but now you need to patch the kernel because we want you to make up a new HID and not be compatible with what already exists." If you go down this road, I predict we'll start seeing *separate* drivers for identical components, because the bindings for DT vs. ACPI properties are different. We really don't want that. > The pro ARM ACPI camp has been very vocal against DT in the server > space. I'd like to seem them as vocal about PRP0001, unless they find it > acceptable (and should apologise for bashing DT ;)). Fundamentally, that DT vs. ACPI distinction has gone away with the introduction of _DSD. We *need* the flexibility that we gain from being able to provide device properties rather than inventing a new HID for every permutation, and with that flexibility comes a certain amount of responsibility to do things sensibly. People have not always designed their bindings sensibly. But that isn't going to be magically solved in the ACPI world, unless you *do* actually stand over them with their crackpipe in your hand, as I joked above. And eschewing PRP0001 really doesn't help you with that. It just makes things harder. -- dwmw2 [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: dwmw2@infradead.org (David Woodhouse) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT Date: Thu, 24 Sep 2015 12:52:38 +0100 [thread overview] Message-ID: <1443095558.74600.84.camel@infradead.org> (raw) In-Reply-To: <20150924103152.GG13823@e104818-lin.cambridge.arm.com> Hi Catalin, I understand your concerns, but I'm still not convinced of your conclusion. On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote: > PRP0001 opens the door to any DT-like properties in ACPI and, knowing > how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if > we haven't already; not all the developments are done in the open). No. That door is wide open already ? people can already do whatever they like in _DSD properties. If they're going to screw up DT properties, they'll screw up ACPI-only _DSD properties just the same. You speak of maintaining "tight control of the _DSD properties that are going to be used in ACPI tables"... but if you're going to confiscate their crackpipe and stand over them while they work, you can do that just as well whether they're using "PRP0001" or "FOO1234" as their HID value. In that sense, the HID is entirely orthogonal. And think about it... we *really* don't want a given peripheral device to have *different* bindings depending on whether it's discovered with a specific ACPI HID, vs. when it's discovered via DT or the PRP0001 HID. That way lies complete insanity. In some ways, your proposal would be actively *counterproductive*. You say you want to train people *not* to keep patching the kernel. But where they *could* have just used PRP0001 and used a pre-existing kernel, you then tell them "oh, but now you need to patch the kernel because we want you to make up a new HID and not be compatible with what already exists." If you go down this road, I predict we'll start seeing *separate* drivers for identical components, because the bindings for DT vs. ACPI properties are different. We really don't want that. > The pro ARM ACPI camp has been very vocal against DT in the server > space. I'd like to seem them as vocal about PRP0001, unless they find it > acceptable (and should apologise for bashing DT ;)). Fundamentally, that DT vs. ACPI distinction has gone away with the introduction of _DSD. We *need* the flexibility that we gain from being able to provide device properties rather than inventing a new HID for every permutation, and with that flexibility comes a certain amount of responsibility to do things sensibly. People have not always designed their bindings sensibly. But that isn't going to be magically solved in the ACPI world, unless you *do* actually stand over them with their crackpipe in your hand, as I joked above. And eschewing PRP0001 really doesn't help you with that. It just makes things harder. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150924/3c02fec3/attachment-0001.bin>
next prev parent reply other threads:[~2015-09-24 11:52 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-08-12 22:06 [PATCH 0/2] Enable smsc911x for use with ACPI Jeremy Linton 2015-08-12 22:06 ` Jeremy Linton 2015-08-12 22:06 ` [PATCH 1/2] Add a matching set of device_ functions for determining mac/phy Jeremy Linton 2015-08-12 22:06 ` Jeremy Linton 2015-08-12 22:13 ` Florian Fainelli 2015-08-12 22:13 ` Florian Fainelli 2015-08-14 15:55 ` Jeremy Linton 2015-08-14 15:55 ` Jeremy Linton 2015-08-13 11:57 ` Robin Murphy 2015-08-13 11:57 ` Robin Murphy 2015-08-13 14:24 ` Jeremy Linton 2015-08-13 14:24 ` Jeremy Linton 2015-08-12 22:06 ` [PATCH 2/2] Convert smsc911x to use ACPI as well as DT Jeremy Linton 2015-08-12 22:06 ` Jeremy Linton 2015-08-13 8:27 ` Graeme Gregory 2015-08-13 8:27 ` Graeme Gregory 2015-08-13 9:01 ` Lorenzo Pieralisi 2015-08-13 9:01 ` Lorenzo Pieralisi 2015-08-13 9:38 ` Graeme Gregory 2015-08-13 9:38 ` Graeme Gregory 2015-08-13 10:30 ` Lorenzo Pieralisi 2015-08-13 10:30 ` Lorenzo Pieralisi 2015-09-09 16:10 ` Marc Zyngier 2015-09-09 16:10 ` Marc Zyngier 2015-09-23 17:22 ` Jeremy Linton 2015-09-23 17:22 ` Jeremy Linton 2015-09-23 17:46 ` Marc Zyngier 2015-09-23 17:46 ` Marc Zyngier 2015-09-23 17:57 ` Sudeep Holla 2015-09-23 17:57 ` Sudeep Holla 2015-09-24 9:20 ` Catalin Marinas 2015-09-24 9:20 ` Catalin Marinas 2015-11-02 15:48 ` Jeremy Linton 2015-11-02 15:48 ` Jeremy Linton 2015-09-23 18:41 ` David Woodhouse 2015-09-23 18:41 ` David Woodhouse 2015-09-23 20:51 ` Rafael J. Wysocki 2015-09-23 20:51 ` Rafael J. Wysocki 2015-09-23 21:03 ` David Woodhouse 2015-09-23 21:03 ` David Woodhouse 2015-09-23 23:56 ` Hanjun Guo 2015-09-23 23:56 ` Hanjun Guo 2015-09-24 8:16 ` David Woodhouse 2015-09-24 8:16 ` David Woodhouse 2015-09-24 10:31 ` Catalin Marinas 2015-09-24 10:31 ` Catalin Marinas 2015-09-24 11:52 ` David Woodhouse [this message] 2015-09-24 11:52 ` David Woodhouse 2015-09-24 14:01 ` Lorenzo Pieralisi 2015-09-24 14:01 ` Lorenzo Pieralisi 2015-09-24 14:31 ` David Woodhouse 2015-09-24 14:31 ` David Woodhouse 2015-09-24 15:15 ` Catalin Marinas 2015-09-24 15:15 ` Catalin Marinas 2015-09-24 18:10 ` David Woodhouse 2015-09-24 18:10 ` David Woodhouse 2015-09-25 15:28 ` Catalin Marinas 2015-09-25 15:28 ` Catalin Marinas 2015-09-26 2:16 ` Rafael J. Wysocki 2015-09-26 2:16 ` Rafael J. Wysocki 2015-09-26 15:20 ` David Woodhouse 2015-09-26 15:20 ` David Woodhouse 2015-10-01 2:23 ` Al Stone 2015-10-01 2:23 ` Al Stone 2015-10-06 0:20 ` Charles Garcia-Tobin 2015-10-06 0:20 ` Charles Garcia-Tobin 2015-10-06 11:08 ` David Woodhouse 2015-10-06 11:08 ` David Woodhouse 2015-10-08 0:11 ` Rafael J. Wysocki 2015-10-08 0:11 ` Rafael J. Wysocki 2015-08-14 0:00 ` [PATCH 0/2] Enable smsc911x for use with ACPI David Miller 2015-08-14 0:00 ` David Miller
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=1443095558.74600.84.camel@infradead.org \ --to=dwmw2@infradead.org \ --cc=Suravee.Suthikulpanit@amd.com \ --cc=catalin.marinas@arm.com \ --cc=grant.likely@linaro.org \ --cc=hanjun.guo@linaro.org \ --cc=jeremy.linton@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=netdev@vger.kernel.org \ --cc=rafael.j.wysocki@intel.com \ --cc=steve.glendinning@shawell.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: linkBe 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.