Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3813174ybt; Tue, 30 Jun 2020 11:44:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPepY5Ax9e1ht3ydYrb1OvTszmAEwp/GRchp8ZL0yCEiv5hwnlzr0PsxjMmZzUIZ4r+qDF X-Received: by 2002:aa7:cfc8:: with SMTP id r8mr25198608edy.125.1593542206907; Tue, 30 Jun 2020 11:36:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593542206; cv=none; d=google.com; s=arc-20160816; b=rDmZV6JT4xUOIY8r4BeFWH9C+WZ1IJDnXL9ABUizl8qxQB+AYx6C7XXRP274LLIgxq 9pz4VCPAWr/aXyd7IBj/zHVBCWLDukF6HLR1QzuFC8n3CoT0UWgEOX4PS2fIlrJWRmdv AYr1N4Xejb+thb2YvMUyI+bgq+IkKG8n/s5pBFaEtrM1xQVX7cmNrhoSHv0PTSf6V2lU vAsq1q2X/zK1uRPuWI6EL/4J6TKSTszwy2U1Z69v4k9MDma2/tkaTEFCHGkf0qnJ7siE uhW8+U1JLaa3JphZ/LAdQ6aKZiGjz4e7EFLw/Om1K9eiXF8i3qtGt+m14KCMKX7yjbvX r9oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=CQZJ5XGAe7pE1VVJGvtBZlNjBAE5r++G8Py0JfA7sEY=; b=KAnif4x6hydLVxria8qp2wFKn18m+XJzoyQU8rLpsgTFIeI9uIw2CpGwpXerZpUdwL MuAoOFDwx1RU3Fp+FpvxM3lJrV7SbZhihpbzHTpBC0AjQGjHq1ErI+OsM1suMbT2rXBq 279ayhuOzJJJ8JfTM3YyO6ILq+AcMxgObSXKZ4YAb5eZY1S/3OyGQqW8zycmB+A1mYfd Tz8xk/+/oCwhtmlmUnDgYbQF05mGxu6JVbzgOEhC1uUSHZsXaQ3KzzSsR85006kty5Xj s0au+ZiFJgueCXiQXi40EcoiWXtwfg6SHcT0PRovnnsjnq+EcQM/YRJf3gptRtencjW3 OLiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GaJ5lgCZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oz40si2372450ejb.432.2020.06.30.11.36.24; Tue, 30 Jun 2020 11:36:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GaJ5lgCZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731280AbgF3QzZ (ORCPT + 99 others); Tue, 30 Jun 2020 12:55:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:52390 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729867AbgF3QzY (ORCPT ); Tue, 30 Jun 2020 12:55:24 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0F65220759; Tue, 30 Jun 2020 16:55:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593536124; bh=mpfmjdG6IGcV2SNI0L4bL1NPbP75BRIegyv1s5x/4Rk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GaJ5lgCZfx1p6/8DR6gcC7f4PdAAro1Kp4brzrSPcLu0+ul58C6pkVAQqfWn+S+vZ c1lF5qQpGryKQr/WAXOvgxce3O/Tl4nwSLqrv1nFoDYlVr5Ltu41dTOUNjb4vY94uE Y1eDsaCYM7dxzcWFMBczjsmV2cF/paXNYxoworTw= Date: Tue, 30 Jun 2020 18:55:12 +0200 From: Greg Kroah-Hartman To: Daniel Gutson Cc: Derek Kiernan , Arnd Bergmann , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Richard Hughes , Alex Bazhaniuk Subject: Re: [PATCH] SPI LPC information kernel module Message-ID: <20200630165512.GA1894898@kroah.com> References: <20200629225932.5036-1-daniel.gutson@eclypsium.com> <20200630085641.GD637809@kroah.com> <20200630152832.GB1780940@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 30, 2020 at 01:18:28PM -0300, Daniel Gutson wrote: > On Tue, Jun 30, 2020 at 12:28 PM Greg Kroah-Hartman < > gregkh@linuxfoundation.org> wrote: > > > On Tue, Jun 30, 2020 at 11:42:58AM -0300, Daniel Gutson wrote: > > > On Tue, Jun 30, 2020 at 5:56 AM Greg Kroah-Hartman < > > > gregkh@linuxfoundation.org> wrote: > > > > > > > On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wrote: > > > > > This kernel module exports configuration attributes for the > > > > > system SPI chip. > > > > > This initial version exports the BIOS Write Enable (bioswe), > > > > > BIOS Lock Enable (ble), and the SMM Bios Write Protect (SMM_BWP) > > > > > fields of the Bios Control register. The idea is to keep adding more > > > > > flags, not only from the BC but also from other registers in > > following > > > > > versions. > > > > > > > > > > The goal is that the attributes are avilable to fwupd when SecureBoot > > > > > is turned on. > > > > > > > > > > A technical note: I check if *ppos == BUFFER_SIZE in the reading > > function > > > > > to exit early and avoid an extra access to the HW, for example when > > using > > > > > the 'cat' command, which causes two read operations. > > > > > > > > Why not use the simple_* functions which should prevent that type of > > > > thing? > > > > > > > > > > a hint please? I don't see how to do it with simple_read_from_buffer, I > > > need to return in the read fop the amount of read bytes, but don't know > > > how to mark EOF. Because of that, 'cat' reads again just for me to tell > > it > > > there's nothing else to read. > > > > That's fine, the kernel does not tell userspace "EOF", that is up to the > > libc to determine. If you read the data from the hardware once, and > > keep it in your buffer, simple_read_from_buffer() will handle all of > > that logic for you, please let it do that. > > > > The only way I see to do this is to dynamically allocate the buffer in the > open fop, in order to avoid concurrency issues. > Is this correct? Or use a lock, depends on what you want to do here. But sysfs should handle all of this for you, when you switch to it. > > > We debated this but didn't find a better match, since cpu/arch-specific > > > seemed too core to put informational drivers. > > > Do you have a suggestion? > > > > Make it explicitly hardware specific in your userspace location. > > > > What do you mean by "your userspace location"? Where your files show up to userspace. sysfs is a hierarchy, don't put hardware-specific stuff at the "root" of it, otherwise that doesn't make any sense. Look at what is there today for examples of what to do. good luck! greg k-h