On Mon, Jul 13, 2020 at 07:24:11PM -0300, Daniel Gutson wrote:
> On Mon, Jul 6, 2020 at 6:54 AM Arnd Bergmann wrote:
>
> > On Mon, Jul 6, 2020 at 11:20 AM Arnd Bergmann wrote:
> > >
> > > > Because of these reasons, I'm proposing a misc (not-device) driver
> > that supports
> > > > many Intel ar
On Fri, Jul 3, 2020 at 10:43 PM Daniel Gutson wrote:
> After analyzing the intel-spi driver, I came up to these observations that
> led me conclude that it is not what I need to use:
>
> * Some SPI Controllers have 0x as their VID DID bytes in the PCI config
> space. This causes that the PC
On Mon, Jul 6, 2020 at 11:20 AM Arnd Bergmann wrote:
>
> > Because of these reasons, I'm proposing a misc (not-device) driver that
> > supports
> > many Intel architectures (and families) to expose the information.
> > I understand your proposal to first enhance existing _device_ drivers, but I
>
On Fri, Jul 3, 2020 at 10:43 PM Daniel Gutson wrote:
> On Tue, Jun 30, 2020 at 5:58 PM Arnd Bergmann wrote:
>
> After analyzing the intel-spi driver, I came up to these observations that led
> me conclude that it is not what I need to use:
>
> * Some SPI Controllers have 0x as their VID DID b
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on soc/for-next linus/master v5.8-rc3 next-20200701]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Tue, Jun 30, 2020 at 9:08 PM Daniel Gutson wrote:
> On Tue, Jun 30, 2020 at 5:58 AM Arnd Bergmann wrote:
>> On Tue, Jun 30, 2020 at 12:59 AM Daniel Gutson
>> wrote:
>> The description should start with a little more background for those that
>> don't already know what this driver is for. Wha
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 <
> gre...@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 <
> > > gre...@l
On Tue, Jun 30, 2020 at 05:28:32PM +0200, Greg Kroah-Hartman 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 <
> > gre...@linuxfoundation.org> wrote:
> >
> > > On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wro
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 <
> gre...@linuxfoundation.org> wrote:
>
> > On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wrote:
> > > This kernel module exports configuration attributes for the
> > > sy
On Tue, Jun 30, 2020 at 02:57:11PM +0100, Richard Hughes wrote:
> On Tue, 30 Jun 2020 at 09:56, Greg Kroah-Hartman
> wrote:
> > Again, which makes it seem like securityfs is not the thing for this, as
> > it describes the hardware, not a security model which is what securityfs
> > has been for in
On Tue, Jun 30, 2020 at 4:43 PM Daniel Gutson wrote:
> On Tue, Jun 30, 2020 at 5:56 AM Greg Kroah-Hartman
> wrote:
>> On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wrote:
>> Why is this going in securityfs at all? Why not just sysfs as it is a
>> CPU attribute, right?
>
> Richard alre
On Tue, Jun 30, 2020 at 3:57 PM Richard Hughes wrote:
>
> On Tue, 30 Jun 2020 at 09:56, Greg Kroah-Hartman
> wrote:
> > Again, which makes it seem like securityfs is not the thing for this, as
> > it describes the hardware, not a security model which is what securityfs
> > has been for in the pas
On Tue, 30 Jun 2020 at 09:56, Greg Kroah-Hartman
wrote:
> Again, which makes it seem like securityfs is not the thing for this, as
> it describes the hardware, not a security model which is what securityfs
> has been for in the past, right?
It describes the hardware platform. From a fwupd perspec
On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wrote:
> +EXPORT_SYMBOL_GPL(spi_read_sbase);
Why are you exporting symbols? Nothing in this patch uses them.
And that's the spi_* namespace for the SPI core, not your tiny driver,
why pollute the global namespace in a confusing way like thi
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 Cont
On Tue, Jun 30, 2020 at 12:59 AM 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 re
On Mon, Jun 29, 2020 at 07:59:32PM -0300, Daniel Gutson wrote:
> --- /dev/null
> +++ b/drivers/misc/spi_lpc/bios_data_access.h
> @@ -0,0 +1,181 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * SPI LPC flash platform security driver
> + *
> + * Copyright 2020 (c) Daniel Gutson (daniel.gut...
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 Cont
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on soc/for-next linus/master v5.8-rc3 next-20200629]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
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
20 matches
Mail list logo
