From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751388AbdJECoz (ORCPT ); Wed, 4 Oct 2017 22:44:55 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:41170 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbdJECox (ORCPT ); Wed, 4 Oct 2017 22:44:53 -0400 Date: Wed, 4 Oct 2017 19:44:51 -0700 From: Darren Hart To: Mario.Limonciello@dell.com Cc: andy.shevchenko@gmail.com, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, luto@kernel.org, quasisec@google.com, pali.rohar@gmail.com Subject: Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI Message-ID: <20171005024451.GI25018@fury> References: <20170930021657.GF13307@fury> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 30, 2017 at 07:56:33PM +0000, Mario.Limonciello@dell.com wrote: > > -----Original Message----- > > From: Darren Hart [mailto:dvhart@infradead.org] > > Sent: Friday, September 29, 2017 9:17 PM > > To: Limonciello, Mario > > Cc: Andy Shevchenko ; LKML > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; Andy Lutomirski > > ; quasisec@google.com; pali.rohar@gmail.com > > Subject: Re: [PATCH v3 0/8] Introduce support for Dell SMBIOS over WMI > > > > On Wed, Sep 27, 2017 at 11:02:12PM -0500, Mario Limonciello wrote: ... > > My other concern is the freeform structure around creating the file > > operations in each driver for the chardev IOCTL. It seems like we need > > some kind of defined mapping from METHOD index to IOCTL number, or else > > some way to advertise what it is? > > > > I was originally thinking it would be a good way to do this cleanly too, but my > main concern is this one character device may handle multiple methods problem. > If you map method instance (index) to ioctl number you will most likely run into > clashes. So maybe it's worth not allowing that? > > So I've got another idea. How about instead of a variety of freeform ioctl per driver, > provide three ioctl functions for all the character devices that come in through > the WMI bus to use (say IOC 'W') with either read, write or write/read. The WMI bus > should be able to know which driver to pass it on to by the character device used. > This is not something I have any experience with. I see you added it to v4, so let's see what others have to say there. -- Darren Hart VMware Open Source Technology Center