From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756513AbdJJORx (ORCPT ); Tue, 10 Oct 2017 10:17:53 -0400 Received: from esa8.dell-outbound.iphmx.com ([68.232.149.218]:32998 "EHLO esa8.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756485AbdJJORu (ORCPT ); Tue, 10 Oct 2017 10:17:50 -0400 From: X-LoopCount0: from 10.166.132.195 X-IronPort-AV: E=Sophos;i="5.42,505,1500958800"; d="scan'208";a="158604295" X-DLP: DLP_GlobalPCIDSS To: CC: , , , , , , , , , Subject: RE: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface Thread-Topic: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface Thread-Index: AQHTQc/5PzXjQJ0A502wMRl8JYqs+qLdHQbg Date: Tue, 10 Oct 2017 14:17:48 +0000 Message-ID: References: <411980beb5697e312145ef268516f4cc7c585b8f.1507589249.git.mario.limonciello@dell.com> <20171010135920.GD8662@kroah.com> In-Reply-To: <20171010135920.GD8662@kroah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.18.86] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9AEHwOe016566 > -----Original Message----- > From: Greg KH [mailto:greg@kroah.com] > Sent: Tuesday, October 10, 2017 8:59 AM > To: Limonciello, Mario > Cc: dvhart@infradead.org; Andy Shevchenko ; > LKML ; platform-driver-x86@vger.kernel.org; > Andy Lutomirski ; quasisec@google.com; > pali.rohar@gmail.com; rjw@rjwysocki.net; mjg59@google.com; hch@lst.de > Subject: Re: [PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce > userspace interface > > On Mon, Oct 09, 2017 at 05:51:52PM -0500, Mario Limonciello wrote: > > + ret = device_create_file(&wdev->dev, &priv->req_buf_size_attr); > > + if (ret) > > + goto fail_create_sysfs; > > Why isn't the "WMI core" creating this sysfs file? Why have per-driver > sysfs files, making all of the different apis totally different? It's a > "common" attribute that they are all going to have to provide, right? > I hadn't really thought about that. I suppose it's entirely reasonable to have a way that all WMI ioctls for future drivers will advertise the size of their expected buffer the same way. So this does beg a question to others on this distribution who have worked on WMI drivers- do you know of any WM**/ methods with multiple instances that use different buffer sizes, or is it reasonable to expect that the buffer size is consistent between instances? Even in advanced MOF designs I haven't seen it, but this makes me wonder if an attribute should be created for every instance to be future proof. (For example $GUID/required_buffer_size/instance0, $GUID/required_buffer_size/instance1 etc) > That way you also don't race with userspace :) > > thanks, > > greg k-h