RE: [PATCH v4] platform/x86: intel_pmc_core: export platform global_reset via sysfs.

[Winkler, Tomas]

> Hi,
> 
> On 4/7/21 8:51 AM, Winkler, Tomas wrote:
> >>>
> >>> During PCH (platform/board) manufacturing process a global reset has
> >>> to be induced in order for configuration changes take the effect
> >>> upon following platform reset.
> >>> This setting was commonly done by accessing PMC registers via
> >>> /dev/mem but due to security concern /dev/mem access is much
> >>> restricted, hence the reason for exposing this setting via dedicated sysfs
> interface.
> >>> To prevent post manufacturing abuse the register is protected by
> >>> hardware locking.
> >>
> >> The purpose of this reset functionality is not entirely clear to me.
> >>
> >> Is this only used during production of a board? Or is this also
> >> something which a user/reseller may use as part of a factory-reset
> procedure?
> >
> > Board production and refurbishing of the board. I can try to rephrase but I
> thought all the info is in the commit message.
> > As a runtime feature a user can check that her/his platform is correctly
> sealed.
> 
> Manufacturing is clear, refurbishing is very much not clear, do you mean
> actually desoldering the chip and replacing it with a new one ?
> 
> >> If this is only used once during production, then I'm not sure if
> >> introducing a sysfs file for this is desirable.
> >
> > What do you suggest, than?  I'm just guessing is where are you heading
> > so the answer is that the manufacturing is often already run on the
> production OS installation,  w/o going into details swapping or reconfiguring
> the OS is not always an option.
> > The manufacturer is also a user of ours.
> 
> Ok, so lets compromise here, please make use of the visibility sysfs attribute
> callback, which returns a umask and make the file read-only at the umask
> level if it has been sealed, to make it clear to users that they cannot write 
> to
> it, the -EACCES error means 'Permission denied' so if the user is already root
> they are going to get mightily confused if ls -l shows the file is writable.
Okay, it seems a better solution if the file is the global reset,  
but maybe this path should not be taken if we rename it to  
extended_test_mode_register3, than it's better to get EACCESS on a specific bit.
> 
> Also on set you are checking that the written value is bit 20, and on show you
> are showing the contents of the "Extended Test Mode Register 3" in hex, or
> at least those bits you are willing to show.

The intention was to left the user space behave same as with direct register 
access (/dev/mem)

> So in essence what you are doing here is giving userspace (some) access to
> the "Extended Test Mode Register 3", I would prefer to spell that out
> explicitly. The global_reset sysfs file name to me too much hints at something
> which the user can trigger / use while it is not intended for user usage.

Yeah, Global reset is maybe too ambiguous name in a general context, this is 
not the standard platform reset. 

I've left it in register form in order to keep the user space as it has access 
to the register (/dev/mem)
> 
> Also the Documentation/ABI/testing/sysfs-platform-intel-pm file pretty much
> describes this as direct register access rather then as some reset mechanism.
> 
> So I think it would be better to call the new file
> extended_test_mode_register3, this will also be useful if we need to provide
> access to other bits in the same register later; and this will be a good
> template to follow if we need to provide some access to other registers later
> too.

Need to sync with David on that he pointed just ow, that he plans to expose 
some more bits. 

> Regards,
> 
> Hans
> 
> 
> 
> >
> >>
> >> Can you please provide a new version where the purpsoe of the newly
> >> introduced sysfs file is made more clear, both in the commit-msg as
> >> well as in
> >> the:
> > Okay I can do that.
> >>
> >> Documentation/ABI/testing/sysfs-platform-intel-pmc
> >>
> >> File ?
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >>>
> >>> The register in MMIO space is defined for Cannon Lake and newer PCHs.
> >>>
> >>> Cc: David E Box 
> >>> Reviewed-by: Andy Shevchenko 
> >>> Signed-off-by: Tamar Mashiah 
> >>> Signed-off-by: Tomas Winkler 
> >>> ---
> >>> 2:
> >>> 1. Add locking for reading the ET3 register  (Andy) 2. Fix few style
> >>> issues (Andy)
> >>> V3:
> >>&

RE: [PATCH v4] platform/x86: intel_pmc_core: export platform global_reset via sysfs.

[Winkler, Tomas]

> >
> > During PCH (platform/board) manufacturing process a global reset has
> > to be induced in order for configuration changes take the effect upon
> > following platform reset.
> > This setting was commonly done by accessing PMC registers via /dev/mem
> > but due to security concern /dev/mem access is much restricted, hence
> > the reason for exposing this setting via dedicated sysfs interface.
> > To prevent post manufacturing abuse the register is protected by
> > hardware locking.
> 
> The purpose of this reset functionality is not entirely clear to me.
> 
> Is this only used during production of a board? Or is this also something
> which a user/reseller may use as part of a factory-reset procedure?

Board production and refurbishing of the board. I can try to rephrase but I 
thought all the info is in the commit message. 
As a runtime feature a user can check that her/his platform is correctly 
sealed. 
> 
> If this is only used once during production, then I'm not sure if introducing 
> a
> sysfs file for this is desirable.

What do you suggest, than?  I'm just guessing is where are you heading so the 
answer is that the manufacturing
is often already run on the production OS installation,  w/o going into details 
swapping or reconfiguring the OS is not always an option.
The manufacturer is also a user of ours.

> 
> Can you please provide a new version where the purpsoe of the newly
> introduced sysfs file is made more clear, both in the commit-msg as well as in
> the:
Okay I can do that.
> 
> Documentation/ABI/testing/sysfs-platform-intel-pmc
> 
> File ?
> 
> Regards,
> 
> Hans
> 
> 
> 
> >
> > The register in MMIO space is defined for Cannon Lake and newer PCHs.
> >
> > Cc: David E Box 
> > Reviewed-by: Andy Shevchenko 
> > Signed-off-by: Tamar Mashiah 
> > Signed-off-by: Tomas Winkler 
> > ---
> > 2:
> > 1. Add locking for reading the ET3 register  (Andy) 2. Fix few style
> > issues (Andy)
> > V3:
> > 1. Resend
> > v4:
> > 1. Fix return statement (Andy)
> > 2. Specify manufacturing process (Enrico)
> >
> >  .../ABI/testing/sysfs-platform-intel-pmc  | 11 +++
> >  MAINTAINERS   |  1 +
> >  drivers/platform/x86/intel_pmc_core.c | 97 +++
> >  drivers/platform/x86/intel_pmc_core.h |  6 ++
> >  4 files changed, 115 insertions(+)
> >  create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-pmc
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-intel-pmc
> > b/Documentation/ABI/testing/sysfs-platform-intel-pmc
> > new file mode 100644
> > index ..7ce00e77fbcd
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-platform-intel-pmc
> > @@ -0,0 +1,11 @@
> > +What:  /sys/devices/platform//global_reset
> > +Date:  Apr 2021
> > +KernelVersion: 5.13
> > +Contact:   "Tomas Winkler" 
> > +Description:
> > +   Display global reset setting bits for PMC.
> > +   * bit 31 - global reset is locked
> > +   * bit 20 - global reset is set
> > +   Writing bit 20 value to the global_reset will induce
> > +   a platform global reset upon consequent platform reset.
> > +   in case the register is not locked.
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 04f68e0cda64..618676eba8c8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9166,6 +9166,7 @@ M:Rajneesh Bhardwaj
> 
> >  M: David E Box 
> >  L: platform-driver-...@vger.kernel.org
> >  S: Maintained
> > +F: Documentation/ABI/testing/sysfs-platform-intel-pmc
> >  F: drivers/platform/x86/intel_pmc_core*
> >
> >  INTEL PMIC GPIO DRIVERS
> > diff --git a/drivers/platform/x86/intel_pmc_core.c
> > b/drivers/platform/x86/intel_pmc_core.c
> > index ee2f757515b0..8afc198550a4 100644
> > --- a/drivers/platform/x86/intel_pmc_core.c
> > +++ b/drivers/platform/x86/intel_pmc_core.c
> > @@ -401,6 +401,7 @@ static const struct pmc_reg_map cnp_reg_map = {
> > .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
> > .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
> > .ltr_ignore_max = CNP_NUM_IP_IGN_ALLOWED,
> > +   .etr3_offset = ETR3_OFFSET,
> >  };
> >
> >  static const struct pmc_reg_map icl_reg_map = { @@ -418,6 +419,7 @@
> > static const struct pmc_reg_map icl_reg_map = {
> > .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
> > .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
> > .ltr_ignore_max = ICL_NUM_IP_IGN_ALLOWED,
> > +   .etr3_offset = ETR3_OFFSET,
> >  };
> >
> >  static const struct pmc_bit_map tgl_clocksource_status_map[] = { @@
> > -585,6 +587,7 @@ static const struct pmc_reg_map tgl_reg_map = {
> > .lpm_sts = tgl_lpm_maps,
> > .lpm_status_offset = TGL_LPM_STATUS_OFFSET,
> > .lpm_live_status_offset = TGL_LPM_LIVE_STATUS_OFFSET,
> > +   .etr3_offset = ETR3_OFFSET,
> >  };
> >
> >  static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int
> > reg_offset) @@ -603,6 +606,99 @@ static inline u64
> pmc_core_adjust_slp_s0_step(struct 

RE: [PATCH] platform/x86: intel_pmc_core: export platform global_reset via sysfs.

[Winkler, Tomas]

> -Original Message-
> From: Enrico Weigelt, metux IT consult 
> Sent: Friday, April 02, 2021 16:32
> To: Winkler, Tomas ; Rajneesh Bhardwaj
> ; Box, David E ; Hans
> de Goede ; Mark Gross 
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Mashiah, Tamar ; Andy Shevchenko
> 
> Subject: Re: [PATCH] platform/x86: intel_pmc_core: export platform
> global_reset via sysfs.
> 
> On 01.04.21 23:31, Tomas Winkler wrote:
> 
> Hi,
> 
> > During PCH manufacturing a global reset has to be induced in order for
> > configuration changes take affect upon following platform reset.
> > This setting was commonly done by accessing PMC registers via /dev/mem
> > but due to security concern /dev/mem access is much restricted, hence
> > the reason for exposing this setting via dedicated sysfs interface.
> > To prevent post manufacturing abuse the register is protected by
> > hardware locking.
> 
> could you please define "manufacturing" ? The chip or board ?
Board
> 
> Is there any use for this, after the machine left the factory ?

Refurbishing, mostly, the register is hw locked after that.

> 
> 
> --mtx
> 
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering i...@metux.net -- +49-151-
> 27565287

RE: [PATCH] watchdog: fix syntactic kernel-doc issues

[Winkler, Tomas]

> On 3/21/21 11:53 PM, Lukas Bulwahn wrote:
> > The command 'find drivers/watchdog | xargs ./scripts/kernel-doc -none'
> > reports a number of kernel-doc warnings in the watchdog subsystem.
> >
> > Address the kernel-doc warnings that were purely syntactic issues with
> > kernel-doc comments.
> >
> > The remaining kernel-doc warnings are of type "Excess function
> parameter"
> > and "Function parameter or member not described". These warnings
> would
> > need to be addressed in a second pass with a bit more insight into the
> > APIs and purpose of the functions in the watchdog subsystem.
> >
> > Signed-off-by: Lukas Bulwahn 
> 
> Reviewed-by: Guenter Roeck 
Ack for mei_wdt 
Tomas

> 
> > ---
> > Guenter, Wim, please pick this minor clean-up patch.
> >
> >  drivers/watchdog/booke_wdt.c   |  2 +-
> >  drivers/watchdog/eurotechwdt.c |  2 +-
> >  drivers/watchdog/mei_wdt.c |  8 
> >  drivers/watchdog/octeon-wdt-main.c | 12 +++-
> >  drivers/watchdog/pc87413_wdt.c |  2 +-
> >  drivers/watchdog/wdt.c |  4 ++--
> >  drivers/watchdog/wdt_pci.c |  2 +-
> >  7 files changed, 17 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/watchdog/booke_wdt.c
> > b/drivers/watchdog/booke_wdt.c index 7817fb976f9c..5e4dc1a0f2c6
> 100644
> > --- a/drivers/watchdog/booke_wdt.c
> > +++ b/drivers/watchdog/booke_wdt.c
> > @@ -148,7 +148,7 @@ static void __booke_wdt_enable(void *data)  }
> >
> >  /**
> > - * booke_wdt_disable - disable the watchdog on the given CPU
> > + * __booke_wdt_disable - disable the watchdog on the given CPU
> >   *
> >   * This function is called on each CPU.  It disables the watchdog on that
> CPU.
> >   *
> > diff --git a/drivers/watchdog/eurotechwdt.c
> > b/drivers/watchdog/eurotechwdt.c index 2418ebb707bd..ce682942662c
> > 100644
> > --- a/drivers/watchdog/eurotechwdt.c
> > +++ b/drivers/watchdog/eurotechwdt.c
> > @@ -392,7 +392,7 @@ static struct notifier_block eurwdt_notifier = {
> > };
> >
> >  /**
> > - * cleanup_module:
> > + * eurwdt_exit:
> >   *
> >   * Unload the watchdog. You cannot do this with any file handles open.
> >   * If your watchdog is set to continue ticking on close and you
> > unload diff --git a/drivers/watchdog/mei_wdt.c
> > b/drivers/watchdog/mei_wdt.c index e023d7d90d66..c7a7235e6224 100644
> > --- a/drivers/watchdog/mei_wdt.c
> > +++ b/drivers/watchdog/mei_wdt.c
> > @@ -105,7 +105,7 @@ struct mei_wdt {
> >  #endif /* CONFIG_DEBUG_FS */
> >  };
> >
> > -/*
> > +/**
> >   * struct mei_mc_hdr - Management Control Command Header
> >   *
> >   * @command: Management Control (0x2) @@ -121,7 +121,7 @@ struct
> > mei_mc_hdr {  };
> >
> >  /**
> > - * struct mei_wdt_start_request watchdog start/ping
> > + * struct mei_wdt_start_request - watchdog start/ping
> >   *
> >   * @hdr: Management Control Command Header
> >   * @timeout: timeout value
> > @@ -134,7 +134,7 @@ struct mei_wdt_start_request {  } __packed;
> >
> >  /**
> > - * struct mei_wdt_start_response watchdog start/ping response
> > + * struct mei_wdt_start_response - watchdog start/ping response
> >   *
> >   * @hdr: Management Control Command Header
> >   * @status: operation status
> > @@ -474,7 +474,7 @@ static void mei_wdt_rx(struct mei_cl_device *cldev)
> > complete(>response);
> >  }
> >
> > -/*
> > +/**
> >   * mei_wdt_notif - callback for event notification
> >   *
> >   * @cldev: bus device
> > diff --git a/drivers/watchdog/octeon-wdt-main.c
> > b/drivers/watchdog/octeon-wdt-main.c
> > index fde9e739b436..298c070884c4 100644
> > --- a/drivers/watchdog/octeon-wdt-main.c
> > +++ b/drivers/watchdog/octeon-wdt-main.c
> > @@ -119,7 +119,7 @@ static int cpu2core(int cpu)  }
> >
> >  /**
> > - * Poke the watchdog when an interrupt is received
> > + * octeon_wdt_poke_irq - Poke the watchdog when an interrupt is
> > + received
> >   *
> >   * @cpl:
> >   * @dev_id:
> > @@ -153,7 +153,7 @@ static irqreturn_t octeon_wdt_poke_irq(int cpl,
> > void *dev_id)  extern int prom_putchar(char c);
> >
> >  /**
> > - * Write a string to the uart
> > + * octeon_wdt_write_string - Write a string to the uart
> >   *
> >   * @str:String to write
> >   */
> > @@ -165,7 +165,7 @@ static void octeon_wdt_write_string(const char
> > *str)  }
> >
> >  /**
> > - * Write a hex number out of the uart
> > + * octeon_wdt_write_hex() - Write a hex number out of the uart
> >   *
> >   * @value:  Number to display
> >   * @digits: Number of digits to print (1 to 16)
> > @@ -192,6 +192,8 @@ static const char reg_name[][3] = {  };
> >
> >  /**
> > + * octeon_wdt_nmi_stage3:
> > + *
> >   * NMI stage 3 handler. NMIs are handled in the following manner:
> >   * 1) The first NMI handler enables CVMSEG and transfers from
> >   * the bootbus region into normal memory. It is careful to not @@
> > -513,7 +515,7 @@ static struct watchdog_device octeon_wdt = {
> >
> >  static enum cpuhp_state octeon_wdt_online;
> >  /**
> > - * Module/ driver initialization.
> > + * 

RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface

[Winkler, Tomas]

> On Thu, Mar 4, 2021 at 8:54 PM Winkler, Tomas 
> wrote:
> > > Winkler, Tomas  writes:
> > > >> "Winkler, Tomas"  writes:
> > > >>
> > > >> >> The user space API is achieved via a number of synchronous
> IOCTLs.
> > > >> >>
> > > >> >>   * RPMB_IOC_VER_CMD - simple versioning API
> > > >> >>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
> > > >> >>   * RPMB_IOC_PKEY_CMD - one time programming of access key
> > > >> >>   * RPMB_IOC_COUNTER_CMD - query the write counter
> > > >> >>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
> > > >> >>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
> > > >> >>
> > > >> >> The keys used for programming and writing blocks to the device
> > > >> >> are key_serial_t handles as provided by the keyctl() interface.
> > > >> >>
> > > >> >> [AJB: here there are two key differences between this and the
> > > >> >> original proposal. The first is the dropping of the sequence
> > > >> >> of preformated frames in favour of explicit actions. The
> > > >> >> second is the introduction of key_serial_t and the keyring API
> > > >> >> for referencing the key to use]
> > > >> >
> > > >> > Putting it gently I'm not sure this is good idea, from the
> > > >> > security point of
> > > >> view.
> > > >> > The key has to be possession of the one that signs the frames
> > > >> > as they are,
> > > >> it doesn't mean it is linux kernel keyring, it can be other party
> > > >> on different system.
> > > >> > With this approach you will make the other usecases not applicable.
> > > >> > It is less then trivial to move key securely from one system to
> another.
> > > >>
> > > >> OK I can understand the desire for such a use-case but it does
> > > >> constrain the interface on the kernel with access to the hardware
> > > >> to purely providing a pipe to the raw hardware while also having
> > > >> to expose the details of the HW to userspace.
> > > > This is the use case in Android. The key is in the "trusty" which
> > > > different os running in a virtual environment. The file storage
> > > > abstraction is implemented there. I'm not sure the point of
> > > > constraining the kernel, can you please elaborate on that.
> > >
> > > Well the kernel is all about abstracting differences not baking in
> assumptions.
> > > However can I ask a bit more about this security model?
> > > Is the secure enclave just a separate userspace process or is it in
> > > a separate virtual machine? Is it accessible at all by the kernel running 
> > > the
> driver?
> >
> > It's not an assumption this is working for few years already
> > (https://source.android.com/security/trusty#application_services)
> > The model is that you have a trusted environment (TEE)  in which can be in
> any of the form you described above.
> > And there is established agreement via the RPMB key that TEE is only
> > entity that can produce content to be stored on RPBM, The RPMB
> hardware also ensure that nobody can catch it in the middle and replay that
> storage event.
> >
> > My point is that interface you are suggesting is not covering all possible
> usages of RPMB, actually usages that are already in place.
> 
> It turned out that the application that we (Linaro) need does have the same
> requirements and needs to store the key in a TEE, transferring the message
> with the MAC into the kernel, rather than keeping the key stored in user
> space or kernel.
> 
> However, after I had a look at the nvme-rpmb user space implementation, I
> found that this is different, and always expects the key to be stored in a 
> local
> file:
> https://github.com/linux-nvme/nvme-cli/blob/master/nvme-rpmb.c#L878


This doesn't make it very safe

> This both works with the same kernel interface though, as the kernel would
> still get the data along with the HMAC, rather than having the key stored in
> the kernel, but it does mean that the frame gets passed to the kernel in a
> device specific layout, with at least nvme using an incompatible layout from
> everything else.

NVMe is not by JEDEC so this layout is different and there are some changes but 
the overall storage operations are the same story.
 I do have a solution also for NVME inclusion into the framework. I haven't 
published that part yet.  
It won't support virtio part,  as this requires some legal work to include that 
into  virtio spec.

Thanks
Tomas


 
> Arnd

RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface

[Winkler, Tomas]

> 
> Winkler, Tomas  writes:
> 
> >> "Winkler, Tomas"  writes:
> >>
> >> >> The user space API is achieved via a number of synchronous IOCTLs.
> >> >>
> >> >>   * RPMB_IOC_VER_CMD - simple versioning API
> >> >>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
> >> >>   * RPMB_IOC_PKEY_CMD - one time programming of access key
> >> >>   * RPMB_IOC_COUNTER_CMD - query the write counter
> >> >>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
> >> >>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
> >> >>
> >> >> The keys used for programming and writing blocks to the device are
> >> >> key_serial_t handles as provided by the keyctl() interface.
> >> >>
> >> >> [AJB: here there are two key differences between this and the
> >> >> original proposal. The first is the dropping of the sequence of
> >> >> preformated frames in favour of explicit actions. The second is
> >> >> the introduction of key_serial_t and the keyring API for
> >> >> referencing the key to use]
> >> >
> >> > Putting it gently I'm not sure this is good idea, from the security
> >> > point of
> >> view.
> >> > The key has to be possession of the one that signs the frames as
> >> > they are,
> >> it doesn't mean it is linux kernel keyring, it can be other party on
> >> different system.
> >> > With this approach you will make the other usecases not applicable.
> >> > It is less then trivial to move key securely from one system to another.
> >>
> >> OK I can understand the desire for such a use-case but it does
> >> constrain the interface on the kernel with access to the hardware to
> >> purely providing a pipe to the raw hardware while also having to
> >> expose the details of the HW to userspace.
> > This is the use case in Android. The key is in the "trusty" which
> > different os running in a virtual environment. The file storage
> > abstraction is implemented there. I'm not sure the point of
> > constraining the kernel, can you please elaborate on that.
> 
> Well the kernel is all about abstracting differences not baking in 
> assumptions.
> However can I ask a bit more about this security model?
> Is the secure enclave just a separate userspace process or is it in a separate
> virtual machine? Is it accessible at all by the kernel running the driver?

It's not an assumption this is working for few years already 
(https://source.android.com/security/trusty#application_services) 
The model is that you have a trusted environment (TEE)  in which can be in any 
of the form you described above.
And there is established agreement via the RPMB key that TEE is only entity 
that can produce content to be stored on RPBM,
The RPMB hardware also ensure that nobody can catch it in the middle and replay 
that storage event. 

My point is that interface you are suggesting is not covering all possible 
usages of RPMB, actually usages that are already in place.

> The fact that key id is passed down into the kernel doesn't have to imply the
> kernel does the final cryptographic operation. In the ARM world you could
> make a call to the secure world to do the operation for you. I note the
> keyctl() interface already has support for going to userspace to make queries
> of the keyring.  Maybe what is really needed is an abstraction for the kernel
> to delegate the MAC calculation to some other trusted process that also
> understands the keyid.

Sure but that you want need to make sure that the entity that creates the 
content has the right to use this specific key, so you will need to create 
another channel of trust. 
And this trust has to be established somewhere at the manufacturing time. 

> >
> > Also doesn't this break down after a PROGRAM_KEY event as
> >> the key will have had to traverse into the "untrusted" kernel?
> >
> > This is one in a life event of the card happening on the manufacturing
> > floor, maybe even not performed on Linux.
> 
> In an off list conversation it was suggested that maybe the PROGRAM_KEY
> ioctl should be disabled for locked down kernels to dissuade production use
> of the facility (it is handy for testing t

This is really protected by the hardware,  also once you are programming key 
your platform would be rather sealed already at least it's TEE environment, as 
this is the other part that knows the key.

> >> I wonder if virtio-rpmb may be of help here? You could wrap up up the
> >> front- end in the security domain that has the keys although I don't
> >> know how easy it would be for a backend to work with real hardware?
> >
> > I'm open to see any proposal, not sure I can wrap may head about it right
> now.
> >
> > Anyway I was about to send the new round of my code,  but let's come to
> common ground first.
> >
> 
> OK - I'll see what the others say.
> 
> --
> Alex Bennée

RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface

[Winkler, Tomas]

> "Winkler, Tomas"  writes:
> 
> >> The user space API is achieved via a number of synchronous IOCTLs.
> >>
> >>   * RPMB_IOC_VER_CMD - simple versioning API
> >>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
> >>   * RPMB_IOC_PKEY_CMD - one time programming of access key
> >>   * RPMB_IOC_COUNTER_CMD - query the write counter
> >>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
> >>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
> >>
> >> The keys used for programming and writing blocks to the device are
> >> key_serial_t handles as provided by the keyctl() interface.
> >>
> >> [AJB: here there are two key differences between this and the
> >> original proposal. The first is the dropping of the sequence of
> >> preformated frames in favour of explicit actions. The second is the
> >> introduction of key_serial_t and the keyring API for referencing the
> >> key to use]
> >
> > Putting it gently I'm not sure this is good idea, from the security point of
> view.
> > The key has to be possession of the one that signs the frames as they are,
> it doesn't mean it is linux kernel keyring, it can be other party on different
> system.
> > With this approach you will make the other usecases not applicable. It
> > is less then trivial to move key securely from one system to another.
> 
> OK I can understand the desire for such a use-case but it does constrain the
> interface on the kernel with access to the hardware to purely providing a
> pipe to the raw hardware while also having to expose the details of the HW
> to userspace. 
This is the use case in Android. The key is in the "trusty" which different os 
running in a  virtual environment. The file storage abstraction is 
implemented there.
I'm not sure the point of constraining the kernel, can you please elaborate on 
that.

Also doesn't this break down after a PROGRAM_KEY event as
> the key will have had to traverse into the "untrusted" kernel?

This is one in a life event of the card happening on the manufacturing floor, 
maybe even not performed on Linux.

> I wonder if virtio-rpmb may be of help here? You could wrap up up the front-
> end in the security domain that has the keys although I don't know how easy
> it would be for a backend to work with real hardware?

I'm open to see any proposal, not sure I can wrap may head about it right now. 

Anyway I was about to send the new round of my code,  but let's come to common 
ground first. 

Thanks
Tomas

> 
> > We all wished it can be abstracted more but the frames has to come
> already signed, and the key material is inside the frame.
> > Thanks
> > Tomas
> >
> >
> >>
> >> Signed-off-by: Alex Bennée 
> >> Cc: Ulf Hansson 
> >> Cc: Linus  Walleij 
> >> Cc: Arnd Bergmann 
> >> Cc: Ilias Apalodimas 
> >> Cc: Tomas Winkler 
> >> Cc: Alexander Usyskin 
> >> Cc: Avri Altman 
> >> ---
> >>  .../userspace-api/ioctl/ioctl-number.rst  |   1 +
> >>  MAINTAINERS   |   1 +
> >>  drivers/char/rpmb/Kconfig |   7 +
> >>  drivers/char/rpmb/Makefile|   1 +
> >>  drivers/char/rpmb/cdev.c  | 246 ++
> >>  drivers/char/rpmb/core.c  |  10 +-
> >>  drivers/char/rpmb/rpmb-cdev.h |  17 ++
> >>  include/linux/rpmb.h  |  10 +
> >>  include/uapi/linux/rpmb.h |  68 +
> >>  9 files changed, 357 insertions(+), 4 deletions(-)  create mode
> >> 100644 drivers/char/rpmb/cdev.c  create mode 100644
> >> drivers/char/rpmb/rpmb- cdev.h  create mode 100644
> >> include/uapi/linux/rpmb.h
> >>
> >> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> index a4c75a28c839..0ff2d4d81bb0 100644
> >> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> >> @@ -344,6 +344,7 @@ Code  Seq#Include File
> >> Comments
> >>  0xB5  00-0F  uapi/linux/rpmsg.h  
> >> <mailto:linux-
> >> remotep...@vger.kernel.org>
> >>  0xB6  alllinux/fpga-dfl.h
> >>  0xB7  alluapi/linux/remoteproc_cdev.h
> >> <mailto:linux-
> >> remotep...@vger.kernel.org>
> >> +0xB8  80-8F  uapi/linux/rpmb.h  

RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface

[Winkler, Tomas]

> 
> The user space API is achieved via a number of synchronous IOCTLs.
> 
>   * RPMB_IOC_VER_CMD - simple versioning API
>   * RPMB_IOC_CAP_CMD - query of underlying capabilities
>   * RPMB_IOC_PKEY_CMD - one time programming of access key
>   * RPMB_IOC_COUNTER_CMD - query the write counter
>   * RPMB_IOC_WBLOCKS_CMD - write blocks to device
>   * RPMB_IOC_RBLOCKS_CMD - read blocks from device
> 
> The keys used for programming and writing blocks to the device are
> key_serial_t handles as provided by the keyctl() interface.
> 
> [AJB: here there are two key differences between this and the original
> proposal. The first is the dropping of the sequence of preformated frames in
> favour of explicit actions. The second is the introduction of key_serial_t and
> the keyring API for referencing the key to use]

Putting it gently I'm not sure this is good idea, from the security point of 
view.
The key has to be possession of the one that signs the frames as they are, it 
doesn't mean it is linux kernel keyring, it can be other party on different 
system.
With this approach you will make the other usecases not applicable. It is less 
then trivial to move key securely from one system to another.
We all wished it can be abstracted more but the frames has to come already 
signed, and the key material is inside the frame. 
Thanks
Tomas


> 
> Signed-off-by: Alex Bennée 
> Cc: Ulf Hansson 
> Cc: Linus  Walleij 
> Cc: Arnd Bergmann 
> Cc: Ilias Apalodimas 
> Cc: Tomas Winkler 
> Cc: Alexander Usyskin 
> Cc: Avri Altman 
> ---
>  .../userspace-api/ioctl/ioctl-number.rst  |   1 +
>  MAINTAINERS   |   1 +
>  drivers/char/rpmb/Kconfig |   7 +
>  drivers/char/rpmb/Makefile|   1 +
>  drivers/char/rpmb/cdev.c  | 246 ++
>  drivers/char/rpmb/core.c  |  10 +-
>  drivers/char/rpmb/rpmb-cdev.h |  17 ++
>  include/linux/rpmb.h  |  10 +
>  include/uapi/linux/rpmb.h |  68 +
>  9 files changed, 357 insertions(+), 4 deletions(-)  create mode 100644
> drivers/char/rpmb/cdev.c  create mode 100644 drivers/char/rpmb/rpmb-
> cdev.h  create mode 100644 include/uapi/linux/rpmb.h
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index a4c75a28c839..0ff2d4d81bb0 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -344,6 +344,7 @@ Code  Seq#Include File
> Comments
>  0xB5  00-0F  uapi/linux/rpmsg.h  
>  remotep...@vger.kernel.org>
>  0xB6  alllinux/fpga-dfl.h
>  0xB7  alluapi/linux/remoteproc_cdev.h
>  remotep...@vger.kernel.org>
> +0xB8  80-8F  uapi/linux/rpmb.h   
>  m...@vger.kernel.org>
>  0xC0  00-0F  linux/usb/iowarrior.h
>  0xCA  00-0F  uapi/misc/cxl.h
>  0xCA  10-2F  uapi/misc/ocxl.h
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 076f3983526c..c60b41b6e6bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15374,6 +15374,7 @@ M:?
>  L:   linux-kernel@vger.kernel.org
>  S:   Supported
>  F:   drivers/char/rpmb/*
> +F:   include/uapi/linux/rpmb.h
>  F:   include/linux/rpmb.h
> 
>  RTL2830 MEDIA DRIVER
> diff --git a/drivers/char/rpmb/Kconfig b/drivers/char/rpmb/Kconfig index
> 431c2823cf70..9068664a399a 100644
> --- a/drivers/char/rpmb/Kconfig
> +++ b/drivers/char/rpmb/Kconfig
> @@ -9,3 +9,10 @@ config RPMB
> access RPMB partition.
> 
> If unsure, select N.
> +
> +config RPMB_INTF_DEV
> + bool "RPMB character device interface /dev/rpmbN"
> + depends on RPMB && KEYS
> + help
> +   Say yes here if you want to access RPMB from user space
> +   via character device interface /dev/rpmb%d
> diff --git a/drivers/char/rpmb/Makefile b/drivers/char/rpmb/Makefile index
> 24d4752a9a53..f54b3f30514b 100644
> --- a/drivers/char/rpmb/Makefile
> +++ b/drivers/char/rpmb/Makefile
> @@ -3,5 +3,6 @@
> 
>  obj-$(CONFIG_RPMB) += rpmb.o
>  rpmb-objs += core.o
> +rpmb-$(CONFIG_RPMB_INTF_DEV) += cdev.o
> 
>  ccflags-y += -D__CHECK_ENDIAN__
> diff --git a/drivers/char/rpmb/cdev.c b/drivers/char/rpmb/cdev.c new file
> mode 100644 index ..55f66720fd03
> --- /dev/null
> +++ b/drivers/char/rpmb/cdev.c
> @@ -0,0 +1,246 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(c) 2015 - 2019 Intel Corporation.
> + */
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "rpmb-cdev.h"
> +
> +static dev_t rpmb_devt;
> +#define RPMB_MAX_DEVS  MINORMASK
> +
> +#define RPMB_DEV_OPEN0  /** single open bit (position) */
> +
> +/**
> + * rpmb_open - the open function
> + *
> + * @inode: pointer to inode structure
> 

RE: [PATCH] mtd: use refcount to prevent corruption

[Winkler, Tomas]

> 
> Tomas,
> 
> - Ursprüngliche Mail -
> >> As Richard was saying, we are really open to enhance MTD refcounting.
> >>
> >> However, the issue you are facing is, IMHO, not related to MTD but to
> MFD.
> >> There should be a way to avoid MFD to vanish by taking a reference of
> >> it through mtd->_get_device(). I don't think addressing the case
> >> where MFD vanishes while MTD (as a user) is still active is the right
> approach.
> >
> > I think it won't work because MFD sub-driver remove() is called   and it
> must
> > succeed because the main device  is not accessible unlike glueubi
> > which just returns -EBUSY.
> 
> Well, the trick in glubi (and other MTDs with "hotplug" support) is not to
> reject removal of the sub-device. ->_put_device() is of return type void.
> The key is grabbing a reference on the sub-device in ->_get_device() such
> that the layer below doesn't even try to remove while the MTD is in use.

I understand that. But in that case the kernel is in the mercy of user space to 
close the handle,  
the whole perception here is that of hotplug that the device is  physically 
removed it cannot wait 
for the user space to complete. What's the fix is trying to do is to bail out 
gracefully.

> > so we postpone the mtd unregister to  mtd_info->_put_device()  but it
> > that state we have nothing to hold on as the device is gone in
> > remove() User will fail anyway, as the underlying device is not
> > functional in that state.
> > Anyway I've tried your suggestion, the kernel is crashing, hope I
> > haven't done some silly bug.
> 
> Can you point us to the affected code?
> This would help a lot to understand the issue better.
> I'm sure we can find a solution.

Got green light on releasing the patches will send soon.


Thanks
Tomas

RE: [char-misc-next 6/6] mei: bus: add client dma interface

[Winkler, Tomas]

> 
> On Sat, Feb 06, 2021 at 03:04:34PM +, Winkler, Tomas wrote:
> > > On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote:
> > > > From: Alexander Usyskin 
> > > >
> > > > Expose the client dma mapping via mei client bus interface.
> > > >
> > > > Signed-off-by: Alexander Usyskin 
> > > > Signed-off-by: Tomas Winkler 
> > > > ---
> > > >  drivers/misc/mei/bus.c | 46
> > > ++
> > > >  drivers/misc/mei/hw.h  |  5 +
> > > >  include/linux/mei_cl_bus.h |  3 +++
> > > >  3 files changed, 54 insertions(+)
> > > >
> > > > diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index
> > > > 34fb5e541fe5..d430710a5fe5 100644
> > > > --- a/drivers/misc/mei/bus.c
> > > > +++ b/drivers/misc/mei/bus.c
> > > > @@ -636,6 +636,52 @@ static void mei_cl_bus_vtag_free(struct
> > > mei_cl_device *cldev)
> > > > kfree(cl_vtag);
> > > >  }
> > > >
> > > > +void *mei_cldev_dma_map(struct mei_cl_device *cldev, u8
> > > > +buffer_id, size_t size) {
> > > > +   struct mei_device *bus;
> > > > +   struct mei_cl *cl;
> > > > +   int ret;
> > > > +
> > > > +   if (!cldev || !buffer_id || !size)
> > > > +   return ERR_PTR(-EINVAL);
> > > > +
> > > > +   if (!IS_ALIGNED(size, MEI_FW_PAGE_SIZE)) {
> > > > +   dev_err(>dev, "Map size should be aligned to 
> > > > %lu\n",
> > > > +   MEI_FW_PAGE_SIZE);
> > > > +   return ERR_PTR(-EINVAL);
> > > > +   }
> > > > +
> > > > +   cl = cldev->cl;
> > > > +   bus = cldev->bus;
> > > > +
> > > > +   mutex_lock(>device_lock);
> > > > +   ret = mei_cl_dma_alloc_and_map(cl, NULL, buffer_id, size);
> > > > +   mutex_unlock(>device_lock);
> > > > +   if (ret)
> > > > +   return ERR_PTR(ret);
> > > > +   return cl->dma.vaddr;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(mei_cldev_dma_map);
> > >
> > > Why are you exporting symbols without a user of them?
> > >
> > > That's a sure way to get them removed by someone right after this
> > > lands in the tree :)
> > >
> > > Please only add infrastructure for when you have a real user.
> > You are right,  the user is coming from wifi tree. We need merge before
> they do.
> > If you prefer we can merge that all from the wifi tree.
> 
> That wasn't documented well at all in your changelog comment :(
Note taken.  
> It can go through whatever tree needs it.
If possible please merge our changes already here, and let the wifi guys to 
finish their task in their tree, in their own time.
Thanks
Tomas

RE: [char-misc-next 6/6] mei: bus: add client dma interface

[Winkler, Tomas]

> On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote:
> > From: Alexander Usyskin 
> >
> > Expose the client dma mapping via mei client bus interface.
> >
> > Signed-off-by: Alexander Usyskin 
> > Signed-off-by: Tomas Winkler 
> > ---
> >  drivers/misc/mei/bus.c | 46
> ++
> >  drivers/misc/mei/hw.h  |  5 +
> >  include/linux/mei_cl_bus.h |  3 +++
> >  3 files changed, 54 insertions(+)
> >
> > diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index
> > 34fb5e541fe5..d430710a5fe5 100644
> > --- a/drivers/misc/mei/bus.c
> > +++ b/drivers/misc/mei/bus.c
> > @@ -636,6 +636,52 @@ static void mei_cl_bus_vtag_free(struct
> mei_cl_device *cldev)
> > kfree(cl_vtag);
> >  }
> >
> > +void *mei_cldev_dma_map(struct mei_cl_device *cldev, u8 buffer_id,
> > +size_t size) {
> > +   struct mei_device *bus;
> > +   struct mei_cl *cl;
> > +   int ret;
> > +
> > +   if (!cldev || !buffer_id || !size)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   if (!IS_ALIGNED(size, MEI_FW_PAGE_SIZE)) {
> > +   dev_err(>dev, "Map size should be aligned to %lu\n",
> > +   MEI_FW_PAGE_SIZE);
> > +   return ERR_PTR(-EINVAL);
> > +   }
> > +
> > +   cl = cldev->cl;
> > +   bus = cldev->bus;
> > +
> > +   mutex_lock(>device_lock);
> > +   ret = mei_cl_dma_alloc_and_map(cl, NULL, buffer_id, size);
> > +   mutex_unlock(>device_lock);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> > +   return cl->dma.vaddr;
> > +}
> > +EXPORT_SYMBOL_GPL(mei_cldev_dma_map);
> 
> Why are you exporting symbols without a user of them?
> 
> That's a sure way to get them removed by someone right after this lands in
> the tree :)
> 
> Please only add infrastructure for when you have a real user.
You are right,  the user is coming from wifi tree. We need merge before they do.
If you prefer we can merge that all from the wifi tree. 


Thanks
Tomas

RE: [char-misc-next 1/6] mei: use sprintf in tx_queue_limit_show sysfs

[Winkler, Tomas]

> On Sat, Feb 06, 2021 at 04:43:20PM +0200, Tomas Winkler wrote:
> > Using of snprintf is discouraged in sysfs.
> > For simple u8 it is safe to use sprintf.
> >
> > Signed-off-by: Tomas Winkler 
> > ---
> >  drivers/misc/mei/main.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index
> > 9f6682033ed7..24a05f45b639 100644
> > --- a/drivers/misc/mei/main.c
> > +++ b/drivers/misc/mei/main.c
> > @@ -1026,7 +1026,7 @@ static ssize_t tx_queue_limit_show(struct device
> *device,
> > size = dev->tx_queue_limit;
> > mutex_unlock(>device_lock);
> >
> > -   return snprintf(buf, PAGE_SIZE, "%u\n", size);
> > +   return sprintf(buf, "%u\n", size);
> 
> If you are going to do this, why not just convert it to use sysfs_emit()
> instead?

I thought it's an overkill, but if you prefer that I will resubmit. 

Thanks
Tomas

RE: [PATCH] mtd: use refcount to prevent corruption

[Winkler, Tomas]

> Hi Tomas,
> 
> "Winkler, Tomas"  wrote on Thu, 28 Jan 2021
> 08:53:43 +:
> 
> > > Tomas,
> > >
> > > - Ursprüngliche Mail -
> > > >> >> Can you please explain a little more what devices are involved?
> > > >> >> Does it implement _get_device() and _put_device()?
> > > >> > No this is not connected to those handlers of the underlying
> > > >> > device and those won't help.
> > > >> > I have a spi device provided by MFD framework so it can go away
> anytime.
> > > >>
> > > >> Can it go away physically or just in software?
> > > > Software, but since this is mfd it's basically hotplug. The kernel
> > > > is crashing when I simulate hardware failure.
> > > >>
> > > >> Usually the pattern is that you make sure in the device driver
> > > >> that nobody can orphan the MTD while it is in use.
> > > >> e.g. drivers/mtd/ubi/gluebi.c does so. In _get_device() it grabs
> > > >> a reference on the underlying UBI volume to make sure it cannot
> > > >> go away while the MTD (on top of UBI) is in use.
> > > >
> > > > I can try that if it helps, because we are simulating possible
> > > > lower level crash.
> > > > In an case I believe that the proper refcouting is much more
> > > > robust solution, than the current one.
> > > > I'd appreciate if someone can review the actual implementation.
> > >
> > > This happens right now, I try to understand why exactly the current
> > > way is not good in enough. :-)
> > >
> > > Your approach makes sure that the MTD itself does not go away while
> > > it has users but how does this help in the case where the underlying
> > > MFD just vanishes?
> > > The MTD can be in use and the MFD can go away while e.g. mtd_read()
> > > or such takes place.
> >
> > Read will fail, but kernel won't crash on access to memory that was freed.
> 
> As Richard was saying, we are really open to enhance MTD refcounting.
> 
> However, the issue you are facing is, IMHO, not related to MTD but to MFD.
> There should be a way to avoid MFD to vanish by taking a reference of it
> through mtd->_get_device(). I don't think addressing the case where MFD
> vanishes while MTD (as a user) is still active is the right approach.

I think it won't work because MFD sub-driver remove() is called   and it must 
succeed because the main device  is not accessible unlike glueubi which just 
returns -EBUSY.
so we postpone the mtd unregister to  mtd_info->_put_device()  but it that 
state we have nothing to hold
on as the device is gone in remove()
User will fail anyway, as the underlying device is not functional in that state.
Anyway I've tried your suggestion, the kernel is crashing, hope I haven't done 
some silly bug.

Thanks
Tomas

RE: [PATCH] mtd: use refcount to prevent corruption

[Winkler, Tomas]

> Tomas,
> 
> - Ursprüngliche Mail -
> >> >> Can you please explain a little more what devices are involved?
> >> >> Does it implement _get_device() and _put_device()?
> >> > No this is not connected to those handlers of the underlying device
> >> > and those won't help.
> >> > I have a spi device provided by MFD framework so it can go away anytime.
> >>
> >> Can it go away physically or just in software?
> > Software, but since this is mfd it's basically hotplug. The kernel is
> > crashing when I simulate hardware failure.
> >>
> >> Usually the pattern is that you make sure in the device driver that
> >> nobody can orphan the MTD while it is in use.
> >> e.g. drivers/mtd/ubi/gluebi.c does so. In _get_device() it grabs a
> >> reference on the underlying UBI volume to make sure it cannot go away
> >> while the MTD (on top of UBI) is in use.
> >
> > I can try that if it helps, because we are simulating possible lower
> > level crash.
> > In an case I believe that the proper refcouting is much more robust
> > solution, than the current one.
> > I'd appreciate if someone can review the actual implementation.
> 
> This happens right now, I try to understand why exactly the current way is not
> good in enough. :-)
> 
> Your approach makes sure that the MTD itself does not go away while it has
> users but how does this help in the case where the underlying MFD just
> vanishes?
> The MTD can be in use and the MFD can go away while e.g. mtd_read() or such
> takes place.

Read will fail, but kernel won't crash on access to memory that was freed.

Thanks
Tomas

RE: [PATCH] mtd: use refcount to prevent corruption

[Winkler, Tomas]

> 
> - Ursprüngliche Mail -
> >> > When underlying device is removed mtd core will crash in case user
> >> > space is still holding an open handle to a mtd device node.
> >> > A proper refcounting is needed so device is release only when a
> >> > partition has no active users. The current simple counter is not
> >> > sufficient.
> >>
> >> Can you please explain a little more what devices are involved?
> >> Does it implement _get_device() and _put_device()?
> > No this is not connected to those handlers of the underlying device
> > and those won't help.
> > I have a spi device provided by MFD framework so it can go away anytime.
> 
> Can it go away physically or just in software?
Software, but since this is mfd it's basically hotplug. The kernel is crashing 
when I simulate hardware failure.
> 
> Usually the pattern is that you make sure in the device driver that nobody can
> orphan the MTD while it is in use.
> e.g. drivers/mtd/ubi/gluebi.c does so. In _get_device() it grabs a reference 
> on
> the underlying UBI volume to make sure it cannot go away while the MTD (on
> top of UBI) is in use.

I can try that if it helps, because we are simulating possible lower level 
crash. 
In an case I believe that the proper refcouting is much more robust solution, 
than the current one.
I'd appreciate if someone can review the actual implementation. 

Thanks
Tomas

RE: [PATCH] mtd: use refcount to prevent corruption

[Winkler, Tomas]

> Subject: Re: [PATCH] mtd: use refcount to prevent corruption
> 
> Tomas,
> 
> - Ursprüngliche Mail -
> > Von: "Tomas Winkler" 
> > An: "Miquel Raynal" , "richard"
> > , "Vignesh Raghavendra" , "linux-mtd"
> > , "linux-kernel"
> > 
> > CC: "Tomas Winkler" 
> > Gesendet: Mittwoch, 27. Januar 2021 21:03:19
> > Betreff: [PATCH] mtd: use refcount to prevent corruption
> 
> > When underlying device is removed mtd core will crash in case user
> > space is still holding an open handle to a mtd device node.
> > A proper refcounting is needed so device is release only when a
> > partition has no active users. The current simple counter is not
> > sufficient.
> 
> Can you please explain a little more what devices are involved?
> Does it implement _get_device() and _put_device()?
No this is not connected to those handlers of the underlying device and those 
won't help. 
I have a spi device provided by MFD framework so it can go away anytime. 
My solution tries to  replace the current simple partition reference counting.  
In previous solution it will return -EBUSY on partition that is held but will 
remove the actual parent device, leading to crash.
Also w/o reference counting there is no process to actually remove the 
partition that was previously busy.

Thanks
Tomas



> 
> Thanks,
> //richard

RE: [watchdog] watchdog: mei_wdt: request stop on unregister

[Winkler, Tomas]

> 
> Tomas,
> 
> On Thu, Jan 07, 2021 at 04:12:15PM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > On Thu, Jan 07, 2021 at 09:57:30PM +0200, Tomas Winkler wrote:
> > > From: Alexander Usyskin 
> > >
> > > Send the stop command to the firmware on watchdog unregister to
> > > eleminate false event on suspend.
> > >
> >
> > Normally the watchdog driver would not be expected to unregister
> > during suspend, only when the driver is manually unloaded.
> > To support suspend/resume, other watchdog drivers implement
> > suspend/resume functions to stop the watchdog on suspend and to
> > restart it on resume. Unloading a watchdog driver on suspend would
> > also have odd implications for userspace watchdog daemons.
> >
> > On top of that, it should not actually be possible to unregister a
> > watchdog while it is in use (because it is open in that case and
> > should be marked as busy). watchdog_stop_on_unregister() only serves
> > as backup in case someone actually manages to unload the driver while
> > the watchdog is running. The function was implemented to avoid calls
> > to stop the watchdog in the remove function because I can not
> > mathematically prove that there are no situations where the watchdog
> > is unloaded while running.
> > However, I have not actually been able to do that.
> >
> > Are you sure this patch is doing what you expect it to do ?
> >
> 
> I have not heard anything back. I tried to understand how this patch would
> resolve a problem during suspend/resume, but I didn't find anything.

Sorry,  I've already prepared better commit message,  just had to move the 
attention to other issues.

> 
> Can you maybe add a log message showing the false event that is prevented
> with this patch, and some context explaining how the patch fixes the
> problem ?

The MEI watchdog device lives on mei client bus and currently this bus has a 
special behavior, on suspend it destroys all the devices that are present on 
the bus.
This is due to fact that  the context in the MEI firmware is also lost on 
suspend and the resume is always a fresh start. 

Thanks
Tomas


> 
> Thanks,
> Guenter
> 
> > Thanks,
> > Guenter
> >
> > > Cc: 
> > > Signed-off-by: Alexander Usyskin 
> > > Signed-off-by: Tomas Winkler 
> > > ---
> > >  drivers/watchdog/mei_wdt.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> > > index 5391bf3e6b11..c5967d8b4256 100644
> > > --- a/drivers/watchdog/mei_wdt.c
> > > +++ b/drivers/watchdog/mei_wdt.c
> > > @@ -382,6 +382,7 @@ static int mei_wdt_register(struct mei_wdt *wdt)
> > >
> > >   watchdog_set_drvdata(>wdd, wdt);
> > >   watchdog_stop_on_reboot(>wdd);
> > > + watchdog_stop_on_unregister(>wdd);
> > >
> > >   ret = watchdog_register_device(>wdd);
> > >   if (ret)
> > > --
> > > 2.26.2
> > >

RE: [char-misc-next 13/13] mei: virtio: virtualization frontend driver

[Winkler, Tomas]

> 
> On Tue, Aug 18, 2020 at 02:51:47PM +0300, Tomas Winkler wrote:
> > +#ifndef VIRTIO_ID_MEI
> > +#define VIRTIO_ID_MEI 0xFFFE /* virtio mei */ #endif
> 
> Just noticed now that this driver landed upstream.  Can I ask that you guys
> please register IDs with the virtio TC and not just pick a number at random?
> In particular this is way outside allowed range.
> 
> IDs should also be listed in include/uapi/linux/virtio_ids.h
> 
> If people just pick random numbers like this collistions are unavoidable.
> 
> List of IDs is part of virtio spec, chapter "Device Types".
> 
> Please do this change now before this goes out to production!
Okay,  this was assigned by ACRN, my impression was it's already registered.
Will take care of.
Thanks
Tomas

RE: [PATCH v4 47/52] docs: mei.rst: fix a C expression markup

[Winkler, Tomas]

> Sphinx 3.x doesn't allow expressions using :c:func markup:
> 
>   ./Documentation/driver-api/mei/mei.rst:41: WARNING: Unparseable
> C cross-reference: 'close(int fd)'
>   Invalid C declaration: Expected end of definition. [error at 5]
> close(int fd)
> -^
> 
> So, convert it into a :c:expr.
> 
> Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Tomas Winkler 

> ---
>  Documentation/driver-api/mei/mei.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-
> api/mei/mei.rst
> index cea0b69ec216..4f2ced4ccdc6 100644
> --- a/Documentation/driver-api/mei/mei.rst
> +++ b/Documentation/driver-api/mei/mei.rst
> @@ -38,7 +38,7 @@ Because some of the Intel ME features can change the
> system
>  configuration, the driver by default allows only a privileged
>  user to access it.
> 
> -The session is terminated calling :c:func:`close(int fd)`.
> +The session is terminated calling :c:expr:`close(fd)`.
> 
>  A code snippet for an application communicating with Intel AMTHI client:
> 
> --
> 2.26.2

RE: [char-misc-next V2] mei: hdcp: fix mei_hdcp_verify_mprime() input paramter

[Winkler, Tomas]

> > Hi Tomas,
> >
> > On 7/30/20 02:02, Tomas Winkler wrote:
> > > wired_cmd_repeater_auth_stream_req_in has a variable length array at
> > > the end. we use struct_size() overflow macro to determine the size
> > > for the allocation and sending size.
> > >
> >
> > My comments here:
> > https://lore.kernel.org/lkml/66c9950c-ef54-423e-467f-
> > 38a9f7afb...@embeddedor.com/
> Strange,  it haven't landed in my mailbox
> 
> 
> > still stand...
> 
> 
> 1. I don't think it should go to stable, true  there was bug but it wasn't
> triggered because there is only one stream.


I'm changing my mind on that, this is a pretty security issue, it should be 
fixed in stable. 

> 2. In any case if we want to backport to stable, than all those fancy overflow
> macros are not there yet, need to rewrite the patch.
> 2. We cannot flex_array_size() as the streams in hdcp_port_data is not an
> array, I'm not going to change it in this patch.

Last, forgot to thanks you for your persistent and thoroughly review. 
 
> >
> > > Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with
> > > flexible-array member)
> > > Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with
> > > flexible-array member)
> 
> > You have repeated the same commit twice, above.
> Will fix
>  Also, a Fixes tag for the
> 
> > commit from Feb 2019 that I talk about here:
> > https://lore.kernel.org/lkml/66c9950c-ef54-423e-467f-
> > 38a9f7afb...@embeddedor.com/
> Will add
> > should be included in this changelog text.
> >
> > --
> > Gustavo
> >
> > > Cc: Ramalingam C 
> > > Cc: Gustavo A. R. Silva 
> > > Signed-off-by: Tomas Winkler 
> > > ---
> > > V2: Check for allocation failure.
> > >  drivers/misc/mei/hdcp/mei_hdcp.c | 40
> > > +++-
> > >  1 file changed, 24 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > > index d1d3e025ca0e..f1205e0060db 100644
> > > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > > @@ -546,38 +546,46 @@ static int mei_hdcp_verify_mprime(struct
> > > device
> > *dev,
> > > struct hdcp_port_data *data,
> > > struct hdcp2_rep_stream_ready
> > *stream_ready)  {
> > > - struct wired_cmd_repeater_auth_stream_req_in
> > > - verify_mprime_in = { { 0 } };
> > > + struct wired_cmd_repeater_auth_stream_req_in *verify_mprime_in;
> > >   struct wired_cmd_repeater_auth_stream_req_out
> > >   verify_mprime_out = { { 0 } };
> > >   struct mei_cl_device *cldev;
> > >   ssize_t byte;
> > > + size_t cmd_size;
> > >
> > >   if (!dev || !stream_ready || !data)
> > >   return -EINVAL;
> > >
> > >   cldev = to_mei_cl_device(dev);
> > >
> > > - verify_mprime_in.header.api_version = HDCP_API_VERSION;
> > > - verify_mprime_in.header.command_id =
> > WIRED_REPEATER_AUTH_STREAM_REQ;
> > > - verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
> > > - verify_mprime_in.header.buffer_len =
> > > + cmd_size = struct_size(verify_mprime_in, streams, data->k);
> > > + if (cmd_size == SIZE_MAX)
> > > + return -EINVAL;
> > > +
> > > + verify_mprime_in = kzalloc(cmd_size, GFP_KERNEL);
> > > + if (!verify_mprime_in)
> > > + return -ENOMEM;
> > > +
> > > + verify_mprime_in->header.api_version = HDCP_API_VERSION;
> > > + verify_mprime_in->header.command_id =
> > WIRED_REPEATER_AUTH_STREAM_REQ;
> > > + verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS;
> > > + verify_mprime_in->header.buffer_len =
> > >
> > WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
> > >
> > > - verify_mprime_in.port.integrated_port_type = data->port_type;
> > > - verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
> > > - verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > > + verify_mprime_in->port.integrated_port_type = data->port_type;
> > > + verify_mprime_in->port.physical_port = (u8)data->fw_ddi;
> > > + verify_mprime_in->port.attached_transcoder = (u8)data->fw_tc;
> > > +
> > > + memcpy(verify_mprime_in->m_prime, stream_ready->m_prime,
> > HDCP_2_2_MPRIME_LEN);
> > > + drm_hdcp_cpu_to_be24(verify_mprime_in->seq_num_m, data-
> > >seq_num_m);
> > >
> > > - memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> > > -HDCP_2_2_MPRIME_LEN);
> > > - drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data-
> > >seq_num_m);
> > > - memcpy(verify_mprime_in.streams, data->streams,
> > > + memcpy(verify_mprime_in->streams, data->streams,
> > >  array_size(data->k, sizeof(*data->streams)));
> > >
> > > - verify_mprime_in.k = cpu_to_be16(data->k);
> > > + verify_mprime_in->k = cpu_to_be16(data->k);
> > >
> > > - byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
> > > -   sizeof(verify_mprime_in));
> > > + byte = mei_cldev_send(cldev, (u8 *)_mprime_in, cmd_size);
> > > + kfree(verify_mprime_in);
> > >   if (byte < 0) {
> > >   

RE: [char-misc-next V2] mei: hdcp: fix mei_hdcp_verify_mprime() input paramter

[Winkler, Tomas]

> Hi Tomas,
> 
> On 7/30/20 02:02, Tomas Winkler wrote:
> > wired_cmd_repeater_auth_stream_req_in has a variable length array at
> > the end. we use struct_size() overflow macro to determine the size for
> > the allocation and sending size.
> >
> 
> My comments here:
> https://lore.kernel.org/lkml/66c9950c-ef54-423e-467f-
> 38a9f7afb...@embeddedor.com/
Strange,  it haven't landed in my mailbox 


> still stand...


1. I don't think it should go to stable, true  there was bug but it wasn't 
triggered because there is only one stream.
2. In any case if we want to backport to stable, than all those fancy overflow 
macros are not there yet, need to rewrite the patch.
2. We cannot flex_array_size() as the streams in hdcp_port_data is not an 
array, I'm not going to change it in this patch. 

> 
> > Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with
> > flexible-array member)
> > Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with
> > flexible-array member)

> You have repeated the same commit twice, above.
Will fix 
 Also, a Fixes tag for the

> commit from Feb 2019 that I talk about here:
> https://lore.kernel.org/lkml/66c9950c-ef54-423e-467f-
> 38a9f7afb...@embeddedor.com/
Will add 
> should be included in this changelog text.
> 
> --
> Gustavo
> 
> > Cc: Ramalingam C 
> > Cc: Gustavo A. R. Silva 
> > Signed-off-by: Tomas Winkler 
> > ---
> > V2: Check for allocation failure.
> >  drivers/misc/mei/hdcp/mei_hdcp.c | 40
> > +++-
> >  1 file changed, 24 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index d1d3e025ca0e..f1205e0060db 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -546,38 +546,46 @@ static int mei_hdcp_verify_mprime(struct device
> *dev,
> >   struct hdcp_port_data *data,
> >   struct hdcp2_rep_stream_ready
> *stream_ready)  {
> > -   struct wired_cmd_repeater_auth_stream_req_in
> > -   verify_mprime_in = { { 0 } };
> > +   struct wired_cmd_repeater_auth_stream_req_in *verify_mprime_in;
> > struct wired_cmd_repeater_auth_stream_req_out
> > verify_mprime_out = { { 0 } };
> > struct mei_cl_device *cldev;
> > ssize_t byte;
> > +   size_t cmd_size;
> >
> > if (!dev || !stream_ready || !data)
> > return -EINVAL;
> >
> > cldev = to_mei_cl_device(dev);
> >
> > -   verify_mprime_in.header.api_version = HDCP_API_VERSION;
> > -   verify_mprime_in.header.command_id =
> WIRED_REPEATER_AUTH_STREAM_REQ;
> > -   verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
> > -   verify_mprime_in.header.buffer_len =
> > +   cmd_size = struct_size(verify_mprime_in, streams, data->k);
> > +   if (cmd_size == SIZE_MAX)
> > +   return -EINVAL;
> > +
> > +   verify_mprime_in = kzalloc(cmd_size, GFP_KERNEL);
> > +   if (!verify_mprime_in)
> > +   return -ENOMEM;
> > +
> > +   verify_mprime_in->header.api_version = HDCP_API_VERSION;
> > +   verify_mprime_in->header.command_id =
> WIRED_REPEATER_AUTH_STREAM_REQ;
> > +   verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS;
> > +   verify_mprime_in->header.buffer_len =
> >
>   WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
> >
> > -   verify_mprime_in.port.integrated_port_type = data->port_type;
> > -   verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
> > -   verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > +   verify_mprime_in->port.integrated_port_type = data->port_type;
> > +   verify_mprime_in->port.physical_port = (u8)data->fw_ddi;
> > +   verify_mprime_in->port.attached_transcoder = (u8)data->fw_tc;
> > +
> > +   memcpy(verify_mprime_in->m_prime, stream_ready->m_prime,
> HDCP_2_2_MPRIME_LEN);
> > +   drm_hdcp_cpu_to_be24(verify_mprime_in->seq_num_m, data-
> >seq_num_m);
> >
> > -   memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> > -  HDCP_2_2_MPRIME_LEN);
> > -   drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data-
> >seq_num_m);
> > -   memcpy(verify_mprime_in.streams, data->streams,
> > +   memcpy(verify_mprime_in->streams, data->streams,
> >array_size(data->k, sizeof(*data->streams)));
> >
> > -   verify_mprime_in.k = cpu_to_be16(data->k);
> > +   verify_mprime_in->k = cpu_to_be16(data->k);
> >
> > -   byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
> > - sizeof(verify_mprime_in));
> > +   byte = mei_cldev_send(cldev, (u8 *)_mprime_in, cmd_size);
> > +   kfree(verify_mprime_in);
> > if (byte < 0) {
> > dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> > return byte;
> >

RE: [char-misc-next] Revert "mei: hdcp: Replace one-element array with flexible-array member"

[Winkler, Tomas]

> On Tue, 2020-07-28 at 22:14 +0000, Winkler, Tomas wrote:
> > > -Original Message-
> > > From: Gustavo A. R. Silva 
> []
> > > I'm using this command:
> > >
> > > $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> > >
> > > and this is the output for both files:
> > >
> > > $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> > > drivers/misc/mei/hdcp/mei_hdcp.c Arnd Bergmann 
> > > (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
> > >  (supporter:CHAR and MISC DRIVERS)
> > > linux- ker...@vger.kernel.org (open list) $
> > > scripts/get_maintainer.pl --nokeywords -- nogit --nogit-fallback
> > > drivers/misc/mei/hdcp/mei_hdcp.h Arnd Bergmann 
> > > (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
> > >  (supporter:CHAR and MISC DRIVERS)
> > > linux- ker...@vger.kernel.org (open list) For some reason you don't
> > > appear on the list above. Do you see anything wrong with the command
> I'm running to get the maintainers and lists?
> >
> > Not sure, it should be caught by drivers/misc/mei/* ?
> 
> No, this pattern matches _only_ files in that particular directory and not any
> files in any subdirectory.
> 
> > Maybe it is not recursive?
> 
> It depends on the pattern.
> Patterns with trailing slashes match subdirectories too.
> 
> from MAINTAINERS:
> 
>   F: *Files* and directories wildcard patterns.
>  A trailing slash includes all files and subdirectory files.
>  F:   drivers/net/all files in and below drivers/net
>  F:   drivers/net/*   all files in drivers/net, but not below
>  F:   */net/* all files in "any top level directory"/net
>  One pattern per line.  Multiple F: lines acceptable.
> 
> 
> > Need to check the script,
> > frankly I usually check this manually.  prob
> >
> > INTEL MANAGEMENT ENGINE (mei)
> > M:  Tomas Winkler 
> > L:  linux-kernel@vger.kernel.org
> > S:  Supported
> > F:  Documentation/driver-api/mei/*
> > F:  drivers/misc/mei/*
> 
> You probably want:
> 
> F:drivers/misc/mei/
Yes, thanks.
Tomas

RE: [char-misc-next] Revert "mei: hdcp: Replace one-element array with flexible-array member"

[Winkler, Tomas]

> 
> Tomas,
> 
> Please, see some comments below...
> 
> On 7/28/20 17:29, Winkler, Tomas wrote:
> >>>>>
> >>>>> Hi Tomas,
> >>>>>
> >>>>> On 7/28/20 16:41, Tomas Winkler wrote:
> >>>>>> Greg please revert, this commit it changes size of struct
> >>>>>> wired_cmd_repeater_auth_stream_req_in, this is not what firmware
> >>>>>> is expecting.
> >>>>>
> >>>>> Could you elaborate on what's the firmware expecting, exactly?
> >>>> struct wired_cmd_repeater_auth_stream_req_in {
> >>>>   -  struct hdcp2_streamid_type  streams[1];
> >>>>   +  struct hdcp2_streamid_type  streams[];
> >>>> }
> >>>>
> >>>> But then you have, which you haven't changed to + 1 byte =
> >>>> mei_cldev_send(cldev, (u8 *)_mprime_in,
> >>>>   sizeof(verify_mprime_in));
> >>>>
> 
> I don't think the fix for this is to add 1 byte, if any, it seems to be 
> sizeof(*data-
> >streams), or sizeof(struct hdcp2_streamid_type) what needs to be added.
> 
> But it might be better to code something like this, instead:
> 
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index e6c3dc595617..7fe63c915548 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -572,12 +572,12 @@ static int mei_hdcp_verify_mprime(struct device
> *dev,
>HDCP_2_2_MPRIME_LEN);
> drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data-
> >seq_num_m);
> memcpy(verify_mprime_in.streams, data->streams,
> -  (data->k * sizeof(struct hdcp2_streamid_type)));
> +  (data->k * sizeof(*data->streams)));
> 
> verify_mprime_in.k = cpu_to_be16(data->k);
> 
> byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
> - sizeof(verify_mprime_in));
> + struct_size(_mprime_in, streams,
> + data->k));
> if (byte < 0) {
> dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> return byte;
> 
> struct_size(_mprime_in, streams, data->k) will give us the size, in
> bytes, of struct wired_cmd_repeater_auth_stream_req_in plus the size in
> bytes for the streams[] flexible-array, which is determined by struct
> hdcp2_streamid_type and
> data->k.
> 
> What do you think?
I think I will talk to the firmware guys tomorrow morning... 

> 
> See more comments below...
> 
> >>>
> >>> I see, this is the kind of feedback I need from people that knows
> >>> the code better. Thanks!
> >>>
> >>>> But that's not the major point. Point is that we should be able to
> >>>> review and test the code before it is merged.  You haven't run it, right?
> >>>> There is MAINTAINERS file for a reason.
> >>>>
> >>>
> >>> I'm using this command:
> >>>
> >>> $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> >>>
> >>> and this is the output for both files:
> >>>
> >>> $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> >>> drivers/misc/mei/hdcp/mei_hdcp.c Arnd Bergmann 
> >>> (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
> >>>  (supporter:CHAR and MISC DRIVERS)
> >>> linux- ker...@vger.kernel.org (open list) $
> >>> scripts/get_maintainer.pl --nokeywords -- nogit --nogit-fallback
> >>> drivers/misc/mei/hdcp/mei_hdcp.h Arnd Bergmann 
> >>> (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
> >>>  (supporter:CHAR and MISC DRIVERS)
> >>> linux- ker...@vger.kernel.org (open list)
> >>
> >>
> >>> For some reason you don't appear on the list above. Do you see
> >>> anything wrong with the command I'm running to get the maintainers
> >>> and
> >> lists?
> >>
> >> Not sure, it should be caught by drivers/misc/mei/* ?
> >> Maybe it is not recursive? Need to check the script, frankly I
> >> usually check this manually.
> >>
> >> INTEL MANAGEMENT ENGINE (mei)
> >> M:  Tomas Winkler 
> >> L:  linux-kernel@vger.kernel.org
> >> S:  Supported
> >> F:  Documentation/driver-api/mei/*
> >> F:  drivers/misc/mei/*
> >> F:  drivers/watchdog/mei_wdt.c
> >

RE: [char-misc-next] Revert "mei: hdcp: Replace one-element array with flexible-array member"

[Winkler, Tomas]

> > >>
> > >> Hi Tomas,
> > >>
> > >> On 7/28/20 16:41, Tomas Winkler wrote:
> > >>> Greg please revert, this commit it changes size of struct
> > >>> wired_cmd_repeater_auth_stream_req_in, this is not what firmware
> > >>> is expecting.
> > >>
> > >> Could you elaborate on what's the firmware expecting, exactly?
> > > struct wired_cmd_repeater_auth_stream_req_in {
> > >   -   struct hdcp2_streamid_type  streams[1];
> > >   +   struct hdcp2_streamid_type  streams[];
> > > }
> > >
> > > But then you have, which you haven't changed to + 1 byte =
> > > mei_cldev_send(cldev, (u8 *)_mprime_in,
> > >   sizeof(verify_mprime_in));
> > >
> >
> > I see, this is the kind of feedback I need from people that knows the
> > code better. Thanks!
> >
> > > But that's not the major point. Point is that we should be able to
> > > review and test the code before it is merged.  You haven't run it, right?
> > > There is MAINTAINERS file for a reason.
> > >
> >
> > I'm using this command:
> >
> > $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> >
> > and this is the output for both files:
> >
> > $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> > drivers/misc/mei/hdcp/mei_hdcp.c Arnd Bergmann 
> > (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
> >  (supporter:CHAR and MISC DRIVERS) linux-
> > ker...@vger.kernel.org (open list) $ scripts/get_maintainer.pl
> > --nokeywords -- nogit --nogit-fallback
> > drivers/misc/mei/hdcp/mei_hdcp.h Arnd Bergmann 
> > (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
> >  (supporter:CHAR and MISC DRIVERS) linux-
> > ker...@vger.kernel.org (open list)
> 
> 
> > For some reason you don't appear on the list above. Do you see
> > anything wrong with the command I'm running to get the maintainers and
> lists?
> 
> Not sure, it should be caught by drivers/misc/mei/* ?
> Maybe it is not recursive? Need to check the script, frankly I usually check 
> this
> manually.
> 
> INTEL MANAGEMENT ENGINE (mei)
> M:  Tomas Winkler 
> L:  linux-kernel@vger.kernel.org
> S:  Supported
> F:  Documentation/driver-api/mei/*
> F:  drivers/misc/mei/*
> F:  drivers/watchdog/mei_wdt.c
> F:  include/linux/mei_cl_bus.h
> F:  include/uapi/linux/mei.h
> F:  samples/mei/*
> 

It's not recursive, when I add drivers/misc/mei/hdcp/* . It works correctly 
I will post a patch.

Thanks
Tomas


> 
> >
> > Thanks
> > --
> > Gustavo
> >
> > >>
> > >>> I really do not appreciate that the code is bypassing driver
> > >>> maintaner review, I think this is a minimum we can ask for, this
> > >>> is not for a first time.
> > >>>
> > >>> This reverts commit c56967d674e361ebe716e66992e3c5332b25ac1f.
> > >>>
> > >>> Cc: Gustavo A. R. Silva 
> > >>> Signed-off-by: Tomas Winkler 
> > >>> ---
> > >>>  drivers/misc/mei/hdcp/mei_hdcp.c | 2 +-
> > >>> drivers/misc/mei/hdcp/mei_hdcp.h | 2 +-
> > >>>  2 files changed, 2 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > >>> b/drivers/misc/mei/hdcp/mei_hdcp.c
> > >>> index d1d3e025ca0e..e6c3dc595617 100644
> > >>> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > >>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > >>> @@ -572,7 +572,7 @@ static int mei_hdcp_verify_mprime(struct
> > >>> device
> > >> *dev,
> > >>>HDCP_2_2_MPRIME_LEN);
> > >>> drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data-
> > seq_num_m);
> > >>> memcpy(verify_mprime_in.streams, data->streams,
> > >>> -  array_size(data->k, sizeof(*data->streams)));
> > >>> +  (data->k * sizeof(struct hdcp2_streamid_type)));
> > >>>
> > >>> verify_mprime_in.k = cpu_to_be16(data->k);
> > >>>
> > >>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> > >>> b/drivers/misc/mei/hdcp/mei_hdcp.h
> > >>> index 834757f5e072..18ffc773fa18 100644
> > >>> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> > >>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> > >>> @@ -358,7 +358,7 @@ struct
> wired_cmd_repeater_auth_stream_req_in
> > {
> > >>> u8
> > >>  seq_num_m[HDCP_2_2_SEQ_NUM_LEN];
> > >>> u8  m_prime[HDCP_2_2_MPRIME_LEN];
> > >>> __be16  k;
> > >>> -   struct hdcp2_streamid_type  streams[];
> > >>> +   struct hdcp2_streamid_type  streams[1];
> > >>>  } __packed;
> > >>>
> > >>>  struct wired_cmd_repeater_auth_stream_req_out {
> > >>>

RE: [char-misc-next] Revert "mei: hdcp: Replace one-element array with flexible-array member"

[Winkler, Tomas]

> -Original Message-
> From: Gustavo A. R. Silva 
> Sent: Wednesday, July 29, 2020 01:15
> To: Winkler, Tomas ; Greg Kroah-Hartman
> 
> Cc: Usyskin, Alexander ; linux-
> ker...@vger.kernel.org; Gustavo A . R . Silva 
> Subject: Re: [char-misc-next] Revert "mei: hdcp: Replace one-element array
> with flexible-array member"
> 
> 
> 
> On 7/28/20 17:01, Winkler, Tomas wrote:
> >
> >
> >> -Original Message-
> >> From: Gustavo A. R. Silva 
> >> Sent: Wednesday, July 29, 2020 00:57
> >> To: Winkler, Tomas ; Greg Kroah-Hartman
> >> 
> >> Cc: Usyskin, Alexander ; linux-
> >> ker...@vger.kernel.org; Gustavo A . R . Silva 
> >> Subject: Re: [char-misc-next] Revert "mei: hdcp: Replace one-element
> >> array with flexible-array member"
> >>
> >> Hi Tomas,
> >>
> >> On 7/28/20 16:41, Tomas Winkler wrote:
> >>> Greg please revert, this commit it changes size of struct
> >>> wired_cmd_repeater_auth_stream_req_in, this is not what firmware is
> >>> expecting.
> >>
> >> Could you elaborate on what's the firmware expecting, exactly?
> > struct wired_cmd_repeater_auth_stream_req_in {
> >   - struct hdcp2_streamid_type  streams[1];
> >   + struct hdcp2_streamid_type  streams[];
> > }
> >
> > But then you have, which you haven't changed to + 1 byte =
> > mei_cldev_send(cldev, (u8 *)_mprime_in,
> >   sizeof(verify_mprime_in));
> >
> 
> I see, this is the kind of feedback I need from people that knows the code
> better. Thanks!
> 
> > But that's not the major point. Point is that we should be able to
> > review and test the code before it is merged.  You haven't run it, right?
> > There is MAINTAINERS file for a reason.
> >
> 
> I'm using this command:
> 
> $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> 
> and this is the output for both files:
> 
> $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback
> drivers/misc/mei/hdcp/mei_hdcp.c Arnd Bergmann 
> (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
>  (supporter:CHAR and MISC DRIVERS) linux-
> ker...@vger.kernel.org (open list) $ scripts/get_maintainer.pl --nokeywords --
> nogit --nogit-fallback drivers/misc/mei/hdcp/mei_hdcp.h Arnd Bergmann
>  (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman
>  (supporter:CHAR and MISC DRIVERS) linux-
> ker...@vger.kernel.org (open list)


> For some reason you don't appear on the list above. Do you see anything
> wrong with the command I'm running to get the maintainers and lists?

Not sure, it should be caught by drivers/misc/mei/* ?  
Maybe it is not recursive? Need to check the script, 
frankly I usually check this manually. 

INTEL MANAGEMENT ENGINE (mei)
M:  Tomas Winkler 
L:  linux-kernel@vger.kernel.org
S:  Supported
F:  Documentation/driver-api/mei/*
F:  drivers/misc/mei/*
F:  drivers/watchdog/mei_wdt.c
F:  include/linux/mei_cl_bus.h
F:  include/uapi/linux/mei.h
F:  samples/mei/*


> 
> Thanks
> --
> Gustavo
> 
> >>
> >>> I really do not appreciate that the code is bypassing driver
> >>> maintaner review, I think this is a minimum we can ask for, this is
> >>> not for a first time.
> >>>
> >>> This reverts commit c56967d674e361ebe716e66992e3c5332b25ac1f.
> >>>
> >>> Cc: Gustavo A. R. Silva 
> >>> Signed-off-by: Tomas Winkler 
> >>> ---
> >>>  drivers/misc/mei/hdcp/mei_hdcp.c | 2 +-
> >>> drivers/misc/mei/hdcp/mei_hdcp.h | 2 +-
> >>>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >>> b/drivers/misc/mei/hdcp/mei_hdcp.c
> >>> index d1d3e025ca0e..e6c3dc595617 100644
> >>> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >>> @@ -572,7 +572,7 @@ static int mei_hdcp_verify_mprime(struct device
> >> *dev,
> >>>  HDCP_2_2_MPRIME_LEN);
> >>>   drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data-
> seq_num_m);
> >>>   memcpy(verify_mprime_in.streams, data->streams,
> >>> -array_size(data->k, sizeof(*data->streams)));
> >>> +(data->k * sizeof(struct hdcp2_streamid_type)));
> >>>
> >>>   verify_mprime_in.k = cpu_to_be16(data->k);
> >>>
> >>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> >>> b/drivers/misc/mei/hdcp/mei_hdcp.h
> >>> index 834757f5e072..18ffc773fa18 100644
> >>> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> >>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> >>> @@ -358,7 +358,7 @@ struct wired_cmd_repeater_auth_stream_req_in
> {
> >>>   u8
> >>seq_num_m[HDCP_2_2_SEQ_NUM_LEN];
> >>>   u8  m_prime[HDCP_2_2_MPRIME_LEN];
> >>>   __be16  k;
> >>> - struct hdcp2_streamid_type  streams[];
> >>> + struct hdcp2_streamid_type  streams[1];
> >>>  } __packed;
> >>>
> >>>  struct wired_cmd_repeater_auth_stream_req_out {
> >>>

RE: [char-misc-next] Revert "mei: hdcp: Replace one-element array with flexible-array member"

[Winkler, Tomas]

> -Original Message-
> From: Gustavo A. R. Silva 
> Sent: Wednesday, July 29, 2020 00:57
> To: Winkler, Tomas ; Greg Kroah-Hartman
> 
> Cc: Usyskin, Alexander ; linux-
> ker...@vger.kernel.org; Gustavo A . R . Silva 
> Subject: Re: [char-misc-next] Revert "mei: hdcp: Replace one-element array
> with flexible-array member"
> 
> Hi Tomas,
> 
> On 7/28/20 16:41, Tomas Winkler wrote:
> > Greg please revert, this commit it changes size of struct
> > wired_cmd_repeater_auth_stream_req_in, this is not what firmware is
> > expecting.
> 
> Could you elaborate on what's the firmware expecting, exactly?
struct wired_cmd_repeater_auth_stream_req_in {
  - struct hdcp2_streamid_type  streams[1];
  + struct hdcp2_streamid_type  streams[];
}

But then you have, which you haven't changed to + 1
byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
  sizeof(verify_mprime_in));

But that's not the major point. Point is that we should be able to review
and test the code before it is merged.  You haven't run it, right? 
There is MAINTAINERS file for a reason. 


> 
> Thanks
> --
> Gustavo
> 
> > I really do not appreciate that the code is bypassing driver maintaner
> > review, I think this is a minimum we can ask for, this is not for a
> > first time.
> >
> > This reverts commit c56967d674e361ebe716e66992e3c5332b25ac1f.
> >
> > Cc: Gustavo A. R. Silva 
> > Signed-off-by: Tomas Winkler 
> > ---
> >  drivers/misc/mei/hdcp/mei_hdcp.c | 2 +-
> > drivers/misc/mei/hdcp/mei_hdcp.h | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index d1d3e025ca0e..e6c3dc595617 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -572,7 +572,7 @@ static int mei_hdcp_verify_mprime(struct device
> *dev,
> >HDCP_2_2_MPRIME_LEN);
> > drm_hdcp_cpu_to_be24(verify_mprime_in.seq_num_m, data-
> >seq_num_m);
> > memcpy(verify_mprime_in.streams, data->streams,
> > -  array_size(data->k, sizeof(*data->streams)));
> > +  (data->k * sizeof(struct hdcp2_streamid_type)));
> >
> > verify_mprime_in.k = cpu_to_be16(data->k);
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> > b/drivers/misc/mei/hdcp/mei_hdcp.h
> > index 834757f5e072..18ffc773fa18 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> > @@ -358,7 +358,7 @@ struct wired_cmd_repeater_auth_stream_req_in {
> > u8
>   seq_num_m[HDCP_2_2_SEQ_NUM_LEN];
> > u8  m_prime[HDCP_2_2_MPRIME_LEN];
> > __be16  k;
> > -   struct hdcp2_streamid_type  streams[];
> > +   struct hdcp2_streamid_type  streams[1];
> >  } __packed;
> >
> >  struct wired_cmd_repeater_auth_stream_req_out {
> >

RE: [char-misc-next V2] mei: add device kind to sysfs

[Winkler, Tomas]

> 
> On Tue, Jul 28, 2020 at 09:28:36PM +0300, Tomas Winkler wrote:
> > +/**
> > + * kind_show - display device kind
> > + *
> > + * @device: device pointer
> > + * @attr: attribute pointer
> > + * @buf: char out buffer
> > + *
> > + * Return: number of the bytes printed into buf or error
> 
> No need for kernel doc for static sysfs attributes, but ok...
> 
> > + */
> > +static ssize_t kind_show(struct device *device,
> > +struct device_attribute *attr, char *buf) {
> > +   struct mei_device *dev = dev_get_drvdata(device);
> > +   ssize_t ret = 0;
> 
> No need to initialize this.
Right, a leftover from an earlier version. 
> 
> > +
> > +   mutex_lock(>device_lock);
> > +   if (dev->kind)
> > +   ret = sprintf(buf, "%s\n", dev->kind);
> > +   else
> > +   ret = sprintf(buf, "%s\n", "mei");
> > +   mutex_unlock(>device_lock);
> 
> Why do you need a lock?  kind can not change, so what are you trying to
> protect from?
There might be firmware initiated reset but in this particular case you are 
right,  the lock is not needed.

Will resend. 

RE: [char-misc-next] mei: add device type

[Winkler, Tomas]

> -Original Message-
> From: Greg Kroah-Hartman 
> Sent: Tuesday, July 28, 2020 18:54
> To: Winkler, Tomas 
> Cc: Usyskin, Alexander ; linux-
> ker...@vger.kernel.org
> Subject: Re: [char-misc-next] mei: add device type
> 
> On Tue, Jul 28, 2020 at 06:25:46PM +0300, Tomas Winkler wrote:
> > From: Alexander Usyskin 
> >
> > Some of the device heads are not generic and have specific purpose, we
> > need to announce it to the user space so it can detect and correct
> > device node via matching attributes.
> >
> > Generic devices are marked as 'mei' while special purpose their own
> > names. Currently we are adding 'itouch' string for Intel IPTS devices.
> >
> > Signed-off-by: Alexander Usyskin 
> > Signed-off-by: Tomas Winkler 
> > ---
> >  drivers/misc/mei/hw-me.c   | 12 
> >  drivers/misc/mei/hw-me.h   |  5 +
> >  drivers/misc/mei/hw-txe.c  |  1 +
> >  drivers/misc/mei/main.c| 27 +++
> >  drivers/misc/mei/mei_dev.h |  4 
> >  drivers/misc/mei/pci-me.c  |  8 
> >  6 files changed, 53 insertions(+), 4 deletions(-)
> 
> No Documentation/ABI/ update for this new sysfs file?

Hmm, looks like I've forgot to 'git add' 
Thanks
Tomas

RE: [PATCH v2] mei: Avoid the use of one-element arrays

[Winkler, Tomas]

> 
> Hi Tomas,
> 
> Please, see my comments below...
> 
> On 7/22/20 14:04, Winkler, Tomas wrote:
> >
> >>
> >> Hi all,
> >>
> >> Friendly ping: who can take this? :)
> >>
> >> Thanks
> >> --
> >> Gustavo
> >>
> >> On 7/14/20 16:45, Gustavo A. R. Silva wrote:
> >>> One-element arrays are being deprecated[1]. Replace the one-element
> >>> arrays with a simple value type u8 reserved, once this is just a
> >>> placeholder for alignment.
> >>>
> >>> Also, while there, use the preferred form for passing a size of a struct.
> >>> The alternative form where struct name is spelled out hurts
> >>> readability and introduces an opportunity for a bug when the
> >>> variable type is changed but the corresponding sizeof that is passed
> >>> as argument is
> >> not.
> >>>
> >>> [1] https://github.com/KSPP/linux/issues/79
> >>>
> >>> Signed-off-by: Gustavo A. R. Silva 
> >>> ---
> >>> Changes in v2:
> >>>  - Use a more concise changelog text.
> >>>
> >>>  drivers/misc/mei/hbm.c | 4 ++--
> >>>  drivers/misc/mei/hw.h  | 6 +++---
> >>>  2 files changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c index
> >>> a44094cdbc36..f020d5594154 100644
> >>> --- a/drivers/misc/mei/hbm.c
> >>> +++ b/drivers/misc/mei/hbm.c
> >>> @@ -408,14 +408,14 @@ static int mei_hbm_add_cl_resp(struct
> >>> mei_device *dev, u8 addr, u8 status)  {
> >>>   struct mei_msg_hdr mei_hdr;
> >>>   struct hbm_add_client_response resp;
> >>> - const size_t len = sizeof(struct hbm_add_client_response);
> >>> + const size_t len = sizeof(resp);
> >>>   int ret;
> >>>
> >>>   dev_dbg(dev->dev, "adding client response\n");
> >>>
> >>>   mei_hbm_hdr(_hdr, len);
> >>>
> >>> - memset(, 0, sizeof(struct hbm_add_client_response));
> >>> + memset(, 0, len);
> >>>   resp.hbm_cmd = MEI_HBM_ADD_CLIENT_RES_CMD;
> >>>   resp.me_addr = addr;
> >>>   resp.status  = status;
> >
> > This should be probably in a different patch it's not related to the second
> part.


Frankly I will post other version of this that cleans the whole file. 

> >
> >>> diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h index
> >>> b1a8d5ec88b3..8c0297f0e7f3 100644
> >>> --- a/drivers/misc/mei/hw.h
> >>> +++ b/drivers/misc/mei/hw.h
> > I have second thoughts of this part as all reserved fields in this
> > file are of form u8 reserved[X], so we will lose that uniformity with
> > this change, you have to look at the file as whole not just at the patch.  
> > So I
> prefer we drop that part of the patch.
> >
> 
> This is actually the main point of this patch: the removal of one-element
> arrays.
> And yeah, every place in the kernel that uses the form that you mention will
> see it's uniformity slightly modified, and that's for a good cause: the 
> removal
> of one-element arrays, so we can enable bounds checking.

I was going over https://github.com/KSPP/linux/issues/79, I'm not sure this all 
related  to flexible arrays,
those are just reserved struct members. So because it's hard to identify a 
legitimate usage of single element arrays
we are going to kill them all? It's more esthetic / readability issue here but 
there might be some legit use case for one element array, no?


> 
> Thanks
> --
> Gustavo
> 
> >>> @@ -346,13 +346,13 @@ struct hbm_add_client_request {
> >>>   * @hbm_cmd: bus message command header
> >>>   * @me_addr: address of the client in ME
> >>>   * @status: if HBMS_SUCCESS then the client can now accept
> connections.
> >>> - * @reserved: reserved
> >>> + * @reserved: reserved for alignment.
> >>>   */
> >>>  struct hbm_add_client_response {
> >>>   u8 hbm_cmd;
> >>>   u8 me_addr;
> >>>   u8 status;
> >>> - u8 reserved[1];
> >>> + u8 reserved;
> >>>  } __packed;
> >>>
> >>>  /**
> >>> @@ -461,7 +461,7 @@ struct hbm_notification {
> >>>   u8 hbm_cmd;
> >>>   u8 me_addr;
> >>>   u8 host_addr;
> >>> - u8 reserved[1];
> >>> + u8 reserved;
> >>>  } __packed;
> >>>
> >>>  /**
> >>>

RE: [PATCH v2] mei: Avoid the use of one-element arrays

[Winkler, Tomas]

> 
> Hi all,
> 
> Friendly ping: who can take this? :)
> 
> Thanks
> --
> Gustavo
> 
> On 7/14/20 16:45, Gustavo A. R. Silva wrote:
> > One-element arrays are being deprecated[1]. Replace the one-element
> > arrays with a simple value type u8 reserved, once this is just a
> > placeholder for alignment.
> >
> > Also, while there, use the preferred form for passing a size of a struct.
> > The alternative form where struct name is spelled out hurts
> > readability and introduces an opportunity for a bug when the variable
> > type is changed but the corresponding sizeof that is passed as argument is
> not.
> >
> > [1] https://github.com/KSPP/linux/issues/79
> >
> > Signed-off-by: Gustavo A. R. Silva 
> > ---
> > Changes in v2:
> >  - Use a more concise changelog text.
> >
> >  drivers/misc/mei/hbm.c | 4 ++--
> >  drivers/misc/mei/hw.h  | 6 +++---
> >  2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c index
> > a44094cdbc36..f020d5594154 100644
> > --- a/drivers/misc/mei/hbm.c
> > +++ b/drivers/misc/mei/hbm.c
> > @@ -408,14 +408,14 @@ static int mei_hbm_add_cl_resp(struct mei_device
> > *dev, u8 addr, u8 status)  {
> > struct mei_msg_hdr mei_hdr;
> > struct hbm_add_client_response resp;
> > -   const size_t len = sizeof(struct hbm_add_client_response);
> > +   const size_t len = sizeof(resp);
> > int ret;
> >
> > dev_dbg(dev->dev, "adding client response\n");
> >
> > mei_hbm_hdr(_hdr, len);
> >
> > -   memset(, 0, sizeof(struct hbm_add_client_response));
> > +   memset(, 0, len);
> > resp.hbm_cmd = MEI_HBM_ADD_CLIENT_RES_CMD;
> > resp.me_addr = addr;
> > resp.status  = status;

This should be probably in a different patch it's not related to the second 
part.

> > diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h index
> > b1a8d5ec88b3..8c0297f0e7f3 100644
> > --- a/drivers/misc/mei/hw.h
> > +++ b/drivers/misc/mei/hw.h
I have second thoughts of this part as all reserved fields in this file are of 
form u8 reserved[X], 
so we will lose that uniformity with this change, you have to look at the file 
as whole
not just at the patch.  So I prefer we drop that part of the patch. 

> > @@ -346,13 +346,13 @@ struct hbm_add_client_request {
> >   * @hbm_cmd: bus message command header
> >   * @me_addr: address of the client in ME
> >   * @status: if HBMS_SUCCESS then the client can now accept connections.
> > - * @reserved: reserved
> > + * @reserved: reserved for alignment.
> >   */
> >  struct hbm_add_client_response {
> > u8 hbm_cmd;
> > u8 me_addr;
> > u8 status;
> > -   u8 reserved[1];
> > +   u8 reserved;
> >  } __packed;
> >
> >  /**
> > @@ -461,7 +461,7 @@ struct hbm_notification {
> > u8 hbm_cmd;
> > u8 me_addr;
> > u8 host_addr;
> > -   u8 reserved[1];
> > +   u8 reserved;
> >  } __packed;
> >
> >  /**
> >

RE: [PATCH] mei: Replace HTTP links with HTTPS ones

[Winkler, Tomas]

> 
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM as HTTPS
> traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
Acked-by: Tomas Winkler 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov
> ' v5.7..master
> 
>  If there are any URLs to be removed completely  or at least not (just)
> HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
> 
>  drivers/misc/mei/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
> 9d7b3719bfa0..f5fd5b786607 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -9,7 +9,7 @@ config INTEL_MEI
> if selected /dev/mei misc device will be created.
> 
> For more information see
> -   
> +   
> 
>  config INTEL_MEI_ME
>   tristate "ME Enabled Intel Chipsets"
> --
> 2.27.0

RE: [PATCH][next] mei: Avoid the use of one-element arrays

[Winkler, Tomas]

> 
> On Tue, Jul 14, 2020 at 05:54:32PM +, Winkler, Tomas wrote:
> > >
> > > There is a regular need in the kernel to provide a way to declare
> > > having a dynamically sized set of trailing elements in a structure.
> > > Kernel code should always use “flexible array members”[1] for these
> > > cases or, as in this particular case, replace the one-element array
> > > with a simple value type u8 reserved once this is just a placeholder
> > > for alignment. The older style of one-element or zero-length arrays
> should no longer be used[2].
> > >
> > > Also, while there, use the preferred form for passing a size of a struct.
> > > The alternative form where struct name is spelled out hurts
> > > readability and introduces an opportunity for a bug when the
> > > variable type is changed but the corresponding sizeof that is passed as
> argument is not.
> > >
> > > [1] https://en.wikipedia.org/wiki/Flexible_array_member
> > > [2] https://github.com/KSPP/linux/issues/79
> > >
> > > Signed-off-by: Gustavo A. R. Silva 
> > I'm okay with the patch but in this case the description is a bit off.
> > In this case there was no intention for a flexible arrays its just a 
> > reserved
> field.
> >
> 
> The reserved field is actually mentioned in the description:
> 
> "... or, as in this particular case, replace the one-element array with a 
> simple
> value type u8 reserved once this is just a placeholder for alignment."

Right, but it looks not connected to overall context, it looks like not very 
clean reuse of a commit message.
I would say that this reserved[1] rather had confused the detection scripts you 
are using for the  cleanup you are doing. 
Again, I'm okay with the patch, but if you can  reword the commit message it 
would be even more okay.

> 
> Thanks
> --
> Gustavo
> 
> > > ---
> > >  drivers/misc/mei/hbm.c | 4 ++--
> > >  drivers/misc/mei/hw.h  | 6 +++---
> > >  2 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c index
> > > a44094cdbc36..f020d5594154 100644
> > > --- a/drivers/misc/mei/hbm.c
> > > +++ b/drivers/misc/mei/hbm.c
> > > @@ -408,14 +408,14 @@ static int mei_hbm_add_cl_resp(struct
> > > mei_device *dev, u8 addr, u8 status)  {
> > >   struct mei_msg_hdr mei_hdr;
> > >   struct hbm_add_client_response resp;
> > > - const size_t len = sizeof(struct hbm_add_client_response);
> > > + const size_t len = sizeof(resp);
> > >   int ret;
> > >
> > >   dev_dbg(dev->dev, "adding client response\n");
> > >
> > >   mei_hbm_hdr(_hdr, len);
> > >
> > > - memset(, 0, sizeof(struct hbm_add_client_response));
> > > + memset(, 0, len);
> > >   resp.hbm_cmd = MEI_HBM_ADD_CLIENT_RES_CMD;
> > >   resp.me_addr = addr;
> > >   resp.status  = status;
> > > diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h index
> > > b1a8d5ec88b3..8c0297f0e7f3 100644
> > > --- a/drivers/misc/mei/hw.h
> > > +++ b/drivers/misc/mei/hw.h
> > > @@ -346,13 +346,13 @@ struct hbm_add_client_request {
> > >   * @hbm_cmd: bus message command header
> > >   * @me_addr: address of the client in ME
> > >   * @status: if HBMS_SUCCESS then the client can now accept
> connections.
> > > - * @reserved: reserved
> > > + * @reserved: reserved for alignment.
> > >   */
> > >  struct hbm_add_client_response {
> > >   u8 hbm_cmd;
> > >   u8 me_addr;
> > >   u8 status;
> > > - u8 reserved[1];
> > > + u8 reserved;
> > >  } __packed;
> > >
> > >  /**
> > > @@ -461,7 +461,7 @@ struct hbm_notification {
> > >   u8 hbm_cmd;
> > >   u8 me_addr;
> > >   u8 host_addr;
> > > - u8 reserved[1];
> > > + u8 reserved;
> > >  } __packed;
> > >
> > >  /**
> > > --
> > > 2.27.0
> >

RE: [PATCH][next] mei: Avoid the use of one-element arrays

[Winkler, Tomas]

> 
> There is a regular need in the kernel to provide a way to declare having a
> dynamically sized set of trailing elements in a structure.
> Kernel code should always use “flexible array members”[1] for these cases
> or, as in this particular case, replace the one-element array with a simple
> value type u8 reserved once this is just a placeholder for alignment. The 
> older
> style of one-element or zero-length arrays should no longer be used[2].
> 
> Also, while there, use the preferred form for passing a size of a struct.
> The alternative form where struct name is spelled out hurts readability and
> introduces an opportunity for a bug when the variable type is changed but
> the corresponding sizeof that is passed as argument is not.
> 
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] https://github.com/KSPP/linux/issues/79
> 
> Signed-off-by: Gustavo A. R. Silva 
I'm okay with the patch but in this case the description is a bit off. 
In this case there was no intention for a flexible arrays its just a reserved 
field. 

> ---
>  drivers/misc/mei/hbm.c | 4 ++--
>  drivers/misc/mei/hw.h  | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c index
> a44094cdbc36..f020d5594154 100644
> --- a/drivers/misc/mei/hbm.c
> +++ b/drivers/misc/mei/hbm.c
> @@ -408,14 +408,14 @@ static int mei_hbm_add_cl_resp(struct mei_device
> *dev, u8 addr, u8 status)  {
>   struct mei_msg_hdr mei_hdr;
>   struct hbm_add_client_response resp;
> - const size_t len = sizeof(struct hbm_add_client_response);
> + const size_t len = sizeof(resp);
>   int ret;
> 
>   dev_dbg(dev->dev, "adding client response\n");
> 
>   mei_hbm_hdr(_hdr, len);
> 
> - memset(, 0, sizeof(struct hbm_add_client_response));
> + memset(, 0, len);
>   resp.hbm_cmd = MEI_HBM_ADD_CLIENT_RES_CMD;
>   resp.me_addr = addr;
>   resp.status  = status;
> diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h index
> b1a8d5ec88b3..8c0297f0e7f3 100644
> --- a/drivers/misc/mei/hw.h
> +++ b/drivers/misc/mei/hw.h
> @@ -346,13 +346,13 @@ struct hbm_add_client_request {
>   * @hbm_cmd: bus message command header
>   * @me_addr: address of the client in ME
>   * @status: if HBMS_SUCCESS then the client can now accept connections.
> - * @reserved: reserved
> + * @reserved: reserved for alignment.
>   */
>  struct hbm_add_client_response {
>   u8 hbm_cmd;
>   u8 me_addr;
>   u8 status;
> - u8 reserved[1];
> + u8 reserved;
>  } __packed;
> 
>  /**
> @@ -461,7 +461,7 @@ struct hbm_notification {
>   u8 hbm_cmd;
>   u8 me_addr;
>   u8 host_addr;
> - u8 reserved[1];
> + u8 reserved;
>  } __packed;
> 
>  /**
> --
> 2.27.0

RE: [PATCH v3 1/2] scsi: ufs: Add SPDX GPL-2.0 to replace GPL v2 boilerplate

[Winkler, Tomas]

> boilerplate
> 
> On Sat, 2020-06-06 at 23:20 +, Winkler, Tomas wrote:
> > >
> > > From: Bean Huo 
> > >
> > > Add SPDX GPL-2.0 to UFS driver files that specified the GPL version
> > > 2 license,
> > > remove the full boilerplate text.
> > >
> > > Signed-off-by: Bean Huo 
> >
> > LGTM.
> > Thanks
> > Tomas
> 
> Hi Tomas
> 
> would you please add your viewed or acked tag for this patch?
> thanks,

Reviewed-by: Tomas Winkler 

> Bean
> 
> 
> >
> > > ---
> > >  drivers/scsi/ufs/ufs.h   | 27 +--
> > >  drivers/scsi/ufs/ufshcd-pci.c| 25 +
> > >  drivers/scsi/ufs/ufshcd-pltfrm.c | 27 +--
> > >  drivers/scsi/ufs/ufshcd.c| 30 +---
> > > --
> > >  drivers/scsi/ufs/ufshcd.h| 27 +--
> > >  drivers/scsi/ufs/ufshci.h| 27 +--
> > >  6 files changed, 6 insertions(+), 157 deletions(-)
> > >
> > > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h index
> > > c70845d41449..7df4bdc813d6 100644
> > > --- a/drivers/scsi/ufs/ufs.h
> > > +++ b/drivers/scsi/ufs/ufs.h
> > > @@ -1,36 +1,11 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > >  /*
> > >   * Universal Flash Storage Host controller driver
> > > - *
> > > - * This code is based on drivers/scsi/ufs/ufs.h
> > >   * Copyright (C) 2011-2013 Samsung India Software Operations
> > >   *
> > >   * Authors:
> > >   *   Santosh Yaraganavi 
> > >   *   Vinayak Holikatti 
> > > - *
> > > - * This program is free software; you can redistribute it and/or
> > > - * modify it under the terms of the GNU General Public License
> > > - * as published by the Free Software Foundation; either version 2
> > > - * of the License, or (at your option) any later version.
> > > - * See the COPYING file in the top-level directory or visit
> > > - * <http://www.gnu.org/licenses/gpl-2.0.html>
> > > - *
> > > - * This program is distributed in the hope that it will be useful,
> > > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > - * GNU General Public License for more details.
> > > - *
> > > - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> > > - * without warranty of any kind. You are solely responsible for
> > > - * determining the appropriateness of using and distributing
> > > - * the program and assume all risks associated with your exercise
> > > - * of rights with respect to the program, including but not limited
> > > - * to infringement of third party rights, the risks and costs of
> > > - * program errors, damage to or loss of data, programs or
> > > equipment,
> > > - * and unavailability or interruption of operations. Under no
> > > - * circumstances will the contributor of this Program be liable for
> > > - * any damages of any kind arising from your use or distribution of
> > > - * this program.
> > >   */
> > >
> > >  #ifndef _UFS_H
> > > diff --git a/drivers/scsi/ufs/ufshcd-pci.c
> > > b/drivers/scsi/ufs/ufshcd-pci.c index 8f78a8151499..f407b13883ac
> > > 100644
> > > --- a/drivers/scsi/ufs/ufshcd-pci.c
> > > +++ b/drivers/scsi/ufs/ufshcd-pci.c
> > > @@ -1,3 +1,4 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > >  /*
> > >   * Universal Flash Storage Host controller PCI glue driver
> > >   *
> > > @@ -7,30 +8,6 @@
> > >   * Authors:
> > >   *   Santosh Yaraganavi 
> > >   *   Vinayak Holikatti 
> > > - *
> > > - * This program is free software; you can redistribute it and/or
> > > - * modify it under the terms of the GNU General Public License
> > > - * as published by the Free Software Foundation; either version 2
> > > - * of the License, or (at your option) any later version.
> > > - * See the COPYING file in the top-level directory or visit
> > > - * <http://www.gnu.org/licenses/gpl-2.0.html>
> > > - *
> > > - * This program is distributed in the hope that it will be useful,
> > > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > - * MERCHANTA

RE: [PATCH v3 2/2] scsi: ufs: remove wrapper function ufshcd_setup_clocks()

[Winkler, Tomas]

> 
> From: Bean Huo 
> 
> The static function ufshcd_setup_clocks() is just a wrapper around
> __ufshcd_setup_clocks(), remove it. Rename original function wrapped
> __ufshcd_setup_clocks() to new ufshcd_setup_clocks().

Not sure about this change, we have only one call with skip_ref_clock set to 
true, the original code actually make sense from readability stand point. 

> 
> Signed-off-by: Bean Huo 
> ---
>  drivers/scsi/ufs/ufshcd.c | 32 
>  1 file changed, 12 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> ec4f55211648..531d0b7878db 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -215,9 +215,7 @@ static int ufshcd_eh_host_reset_handler(struct
> scsi_cmnd *cmd);  static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int
> tag);  static void ufshcd_hba_exit(struct ufs_hba *hba);  static int
> ufshcd_probe_hba(struct ufs_hba *hba, bool async); -static int
> __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> -  bool skip_ref_clk);
> -static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> +static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on, bool
> +skip_ref_clk);
>  static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);  static inline void
> ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);  static int
> ufshcd_host_reset_and_restore(struct ufs_hba *hba); @@ -1497,7 +1495,7
> @@ static void ufshcd_ungate_work(struct work_struct *work)
>   }
> 
>   spin_unlock_irqrestore(hba->host->host_lock, flags);
> - ufshcd_setup_clocks(hba, true);
> + ufshcd_setup_clocks(hba, true, false);
> 
>   ufshcd_enable_irq(hba);
> 
> @@ -1655,10 +1653,10 @@ static void ufshcd_gate_work(struct work_struct
> *work)
>   ufshcd_disable_irq(hba);
> 
>   if (!ufshcd_is_link_active(hba))
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>   else
>   /* If link is active, device ref_clk can't be switched off */
> - __ufshcd_setup_clocks(hba, false, true);
> + ufshcd_setup_clocks(hba, false, true);
> 
>   /*
>* In case you are here to cancel this work the gating state @@ -
> 7683,8 +7681,7 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
>   return 0;
>  }
> 
> -static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> - bool skip_ref_clk)
> +static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on, bool
> +skip_ref_clk)
>  {
>   int ret = 0;
>   struct ufs_clk_info *clki;
> @@ -7747,11 +7744,6 @@ static int __ufshcd_setup_clocks(struct ufs_hba
> *hba, bool on,
>   return ret;
>  }
> 
> -static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on) -{
> - return  __ufshcd_setup_clocks(hba, on, false);
> -}
> -
>  static int ufshcd_init_clocks(struct ufs_hba *hba)  {
>   int ret = 0;
> @@ -7858,7 +7850,7 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
>   if (err)
>   goto out_disable_hba_vreg;
> 
> - err = ufshcd_setup_clocks(hba, true);
> + err = ufshcd_setup_clocks(hba, true, false);
>   if (err)
>   goto out_disable_hba_vreg;
> 
> @@ -7880,7 +7872,7 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
>  out_disable_vreg:
>   ufshcd_setup_vreg(hba, false);
>  out_disable_clks:
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>  out_disable_hba_vreg:
>   ufshcd_setup_hba_vreg(hba, false);
>  out:
> @@ -7896,7 +7888,7 @@ static void ufshcd_hba_exit(struct ufs_hba *hba)
>   if (ufshcd_is_clkscaling_supported(hba))
>   if (hba->devfreq)
>   ufshcd_suspend_clkscaling(hba);
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>   ufshcd_setup_hba_vreg(hba, false);
>   hba->is_powered = false;
>   ufs_put_device_desc(hba);
> @@ -8259,10 +8251,10 @@ static int ufshcd_suspend(struct ufs_hba *hba,
> enum ufs_pm_op pm_op)
>   ufshcd_disable_irq(hba);
> 
>   if (!ufshcd_is_link_active(hba))
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>   else
>   /* If link is active, device ref_clk can't be switched off */
> - __ufshcd_setup_clocks(hba, false, true);
> + ufshcd_setup_clocks(hba, false, true);
> 
>   hba->clk_gating.state = CLKS_OFF;
>   trace_ufshcd_clk_gating(dev_name(hba->dev), hba-
> >clk_gating.state); @@ -8321,7 +8313,7 @@ static int ufshcd_resume(struct
> ufs_hba *hba, enum ufs_pm_op pm_op)
> 
>   ufshcd_hba_vreg_set_hpm(hba);
>   /* Make sure clocks are enabled before accessing controller */
> - ret = ufshcd_setup_clocks(hba, true);
> + ret = ufshcd_setup_clocks(hba, true, false);
>   

RE: [PATCH v3 1/2] scsi: ufs: Add SPDX GPL-2.0 to replace GPL v2 boilerplate

[Winkler, Tomas]

> 
> From: Bean Huo 
> 
> Add SPDX GPL-2.0 to UFS driver files that specified the GPL version 2 license,
> remove the full boilerplate text.
> 
> Signed-off-by: Bean Huo 
LGTM.
Thanks
Tomas

> ---
>  drivers/scsi/ufs/ufs.h   | 27 +--
>  drivers/scsi/ufs/ufshcd-pci.c| 25 +
>  drivers/scsi/ufs/ufshcd-pltfrm.c | 27 +--
>  drivers/scsi/ufs/ufshcd.c| 30 +-
>  drivers/scsi/ufs/ufshcd.h| 27 +--
>  drivers/scsi/ufs/ufshci.h| 27 +--
>  6 files changed, 6 insertions(+), 157 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h index
> c70845d41449..7df4bdc813d6 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -1,36 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>  /*
>   * Universal Flash Storage Host controller driver
> - *
> - * This code is based on drivers/scsi/ufs/ufs.h
>   * Copyright (C) 2011-2013 Samsung India Software Operations
>   *
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - * See the COPYING file in the top-level directory or visit
> - * 
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> - * without warranty of any kind. You are solely responsible for
> - * determining the appropriateness of using and distributing
> - * the program and assume all risks associated with your exercise
> - * of rights with respect to the program, including but not limited
> - * to infringement of third party rights, the risks and costs of
> - * program errors, damage to or loss of data, programs or equipment,
> - * and unavailability or interruption of operations. Under no
> - * circumstances will the contributor of this Program be liable for
> - * any damages of any kind arising from your use or distribution of
> - * this program.
>   */
> 
>  #ifndef _UFS_H
> diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c 
> index
> 8f78a8151499..f407b13883ac 100644
> --- a/drivers/scsi/ufs/ufshcd-pci.c
> +++ b/drivers/scsi/ufs/ufshcd-pci.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
>  /*
>   * Universal Flash Storage Host controller PCI glue driver
>   *
> @@ -7,30 +8,6 @@
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - * See the COPYING file in the top-level directory or visit
> - * 
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> - * without warranty of any kind. You are solely responsible for
> - * determining the appropriateness of using and distributing
> - * the program and assume all risks associated with your exercise
> - * of rights with respect to the program, including but not limited
> - * to infringement of third party rights, the risks and costs of
> - * program errors, damage to or loss of data, programs or equipment,
> - * and unavailability or interruption of operations. Under no
> - * circumstances will the contributor of this Program be liable for
> - * any damages of any kind arising from your use or distribution of
> - * this program.
>   */
> 
>  #include "ufshcd.h"
> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c 
> b/drivers/scsi/ufs/ufshcd-pltfrm.c
> index 76f9be71c31b..3db0af66c71c 100644
> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> @@ -1,36 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
>  /*
>   * Universal Flash Storage Host controller Platform bus based glue driver
> - *
> - * This code is based on drivers/scsi/ufs/ufshcd-pltfrm.c
>   * Copyright (C) 2011-2013 Samsung India Software Operations
>   *
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it 

RE: [PATCH v1] scsi: ufs: Add SPDX GPL-2.0 to replace GPL v2 boilerplate

[Winkler, Tomas]

> 
> From: Bean Huo 
> 
> Add SPDX GPL-2.0 to replace GPL v2 boilerplate, and remove wrapper
> function ufshcd_setup_clocks()

You don't do that in a single patch, please split. 

> 
> Signed-off-by: Bean Huo 
> ---
>  drivers/scsi/ufs/ufshcd-pltfrm.c | 26 +-
>  drivers/scsi/ufs/ufshcd.c| 62 +++-
>  drivers/scsi/ufs/ufshcd.h| 27 +-
>  3 files changed, 15 insertions(+), 100 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c 
> b/drivers/scsi/ufs/ufshcd-pltfrm.c
> index 76f9be71c31b..8b76a2acc80c 100644
> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> @@ -1,36 +1,12 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Universal Flash Storage Host controller Platform bus based glue driver
> - *
>   * This code is based on drivers/scsi/ufs/ufshcd-pltfrm.c
>   * Copyright (C) 2011-2013 Samsung India Software Operations
>   *
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - * See the COPYING file in the top-level directory or visit
> - * 
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> - * without warranty of any kind. You are solely responsible for
> - * determining the appropriateness of using and distributing
> - * the program and assume all risks associated with your exercise
> - * of rights with respect to the program, including but not limited
> - * to infringement of third party rights, the risks and costs of
> - * program errors, damage to or loss of data, programs or equipment,
> - * and unavailability or interruption of operations. Under no
> - * circumstances will the contributor of this Program be liable for
> - * any damages of any kind arising from your use or distribution of
> - * this program.
>   */
> 
>  #include 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> f283b9eb97ac..e5ec68fc9fc7 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1,40 +1,12 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Universal Flash Storage Host controller driver Core
> - *
> - * This code is based on drivers/scsi/ufs/ufshcd.c
>   * Copyright (C) 2011-2013 Samsung India Software Operations
>   * Copyright (c) 2013-2016, The Linux Foundation. All rights reserved.
>   *
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - * See the COPYING file in the top-level directory or visit
> - * 
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> - * without warranty of any kind. You are solely responsible for
> - * determining the appropriateness of using and distributing
> - * the program and assume all risks associated with your exercise
> - * of rights with respect to the program, including but not limited
> - * to infringement of third party rights, the risks and costs of
> - * program errors, damage to or loss of data, programs or equipment,
> - * and unavailability or interruption of operations. Under no
> - * circumstances will the contributor of this Program be liable for
> - * any damages of any kind arising from your use or distribution of
> - * this program.
> - *
> - * The Linux Foundation chooses to take subject only to the GPLv2
> - * license terms, and distributes only under these terms.
>   */
> 
>  #include 
> @@ -243,9 +215,7 @@ static int ufshcd_eh_host_reset_handler(struct
> scsi_cmnd *cmd);  static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int
> tag);  static void ufshcd_hba_exit(struct ufs_hba *hba);  static int
> ufshcd_probe_hba(struct ufs_hba *hba, bool async); -static int
> __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> -  bool skip_ref_clk);
> -static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> +static int ufshcd_setup_clocks(struct ufs_hba *hba, 

RE: [PATCH] mei: me: Add itouch device IDs for SPT / ICP

[Winkler, Tomas]

> 
> >
> > > These device IDs can be found on Microsoft Surface devices.
> > >
> > > Signed-off-by: Dorian Stoll 
> >
> > This need to be done differently because of the server platforms conflict.
> > I have patches for that I will post short, though we are not
> > officially supporting those devices under Linux, It will be hard to 
> > maintain,
> as currently on the MS surface enables it as far as I know.
> >
> 
> Thank you for your response!
> 
> If you don't mind, could you elaborate on these devices not being supported
> under Linux? Is it just that the functionality they provide (Intel Precise 
> Touch
> & Stylus / iTouch / IPTS) won't be supported? Because that I already know,
> and it is not the intent of this patch. Or do you mean that the entire MEI
> interface won't be supported for these devices?

Just the iTouch.

> 
> Some context on this patch: I am part of a small team of volunteers who try
> to make the MS Surface devices usable under linux, including the
> touchscreen (which uses IPTS as of the Surface Pro 4).

Nice work.

> The IPTS driver connects to the device over the MEI bus, but the MEI device is
> provided by the iTouch devices. Currently we build our own kernels with this
> patch applied to allow the driver to work. All of this is loosely based on a
> driver that Intel published a few years ago.

Yes, I'm fully aware of that code base.
 
> Since the driver is otherwise pretty much standalone,
You do depend on i915, that's the hard part.
> my hope was that
> adding these IDs would make it easier to develop / install our driver without
> having to recompile the entire kernel (i.e. using DKMS). At least until the
> driver has matured enough and is ready for upstream submission itself.
> Especially since other iTouch devices have their device IDs added already.

Agree. 
 
> That this would cause conflicts is unfortunate. Judging purely by your words
> - without having any deeper knowledge about the MEI bus - it seems that it
> might be possible to fix these conflicts? If thats true, I hope it would also 
> be
> possible to add these IDs, so that just the MEI interface to IPTS becomes
> supported - 

Yes, I'm working on that just now.

> I don't expect you to support the entire IPTS technology.

Yep, unfortunately it's not going to be funded by my wife.

> > > ---
> > >  drivers/misc/mei/hw-me-regs.h | 2 ++
> > >  drivers/misc/mei/pci-me.c | 2 ++
> > >  2 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-
> > > regs.h index 9392934e3a06..90e7d3020fa5 100644
> > > --- a/drivers/misc/mei/hw-me-regs.h
> > > +++ b/drivers/misc/mei/hw-me-regs.h
> > > @@ -59,6 +59,7 @@
> > >
> > >  #define MEI_DEV_ID_SPT0x9D3A  /* Sunrise Point */
> > >  #define MEI_DEV_ID_SPT_2  0x9D3B  /* Sunrise Point 2 */
> > > +#define MEI_DEV_ID_SPT_4  0x9D3E  /* Sunrise Point 4 (iTouch) */
> > >  #define MEI_DEV_ID_SPT_H  0xA13A  /* Sunrise Point H */
> > >  #define MEI_DEV_ID_SPT_H_20xA13B  /* Sunrise Point H 2 */
> > >
> > > @@ -90,6 +91,7 @@
> > >  #define MEI_DEV_ID_CDF0x18D3  /* Cedar Fork */
> > >
> > >  #define MEI_DEV_ID_ICP_LP 0x34E0  /* Ice Lake Point LP */
> > > +#define MEI_DEV_ID_ICP_LP_4   0x34E4  /* Ice Lake Point LP 4 (iTouch)
> */
> > >
> > >  #define MEI_DEV_ID_JSP_N  0x4DE0  /* Jasper Lake Point N */
> > >
> > > diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
> > > index
> > > a1ed375fed37..5e621e90d8d4 100644
> > > --- a/drivers/misc/mei/pci-me.c
> > > +++ b/drivers/misc/mei/pci-me.c
> > > @@ -68,6 +68,7 @@ static const struct pci_device_id mei_me_pci_tbl[]
> > > = {
> > >
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT, MEI_ME_PCH8_CFG)},
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_2, MEI_ME_PCH8_CFG)},
> > > + {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_4, MEI_ME_PCH8_CFG)},
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H, MEI_ME_PCH8_SPS_CFG)},
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H_2, MEI_ME_PCH8_SPS_CFG)},
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_LBG, MEI_ME_PCH12_SPS_CFG)},
> @@ -94,6
> > > +95,7 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_H_3, MEI_ME_PCH8_CFG)},
> > >
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
> > > + {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP_4, MEI_ME_PCH12_CFG)},
> > >
> > >   {MEI_PCI_DEVICE(MEI_DEV_ID_TGP_LP, MEI_ME_PCH15_CFG)},
> > >
> > > --
> > > 2.26.2
> > >
> >
> >

RE: [PATCH] mei: me: Add itouch device IDs for SPT / ICP

[Winkler, Tomas]

> These device IDs can be found on Microsoft Surface devices.
> 
> Signed-off-by: Dorian Stoll 

This need to be done differently because of the server platforms conflict.
I have patches for that I will post short, though we are not officially 
supporting those devices under Linux, 
It will be hard to maintain,  as currently on the MS surface enables it as far 
as I know.

> ---
>  drivers/misc/mei/hw-me-regs.h | 2 ++
>  drivers/misc/mei/pci-me.c | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-
> regs.h index 9392934e3a06..90e7d3020fa5 100644
> --- a/drivers/misc/mei/hw-me-regs.h
> +++ b/drivers/misc/mei/hw-me-regs.h
> @@ -59,6 +59,7 @@
> 
>  #define MEI_DEV_ID_SPT0x9D3A  /* Sunrise Point */
>  #define MEI_DEV_ID_SPT_2  0x9D3B  /* Sunrise Point 2 */
> +#define MEI_DEV_ID_SPT_4  0x9D3E  /* Sunrise Point 4 (iTouch) */
>  #define MEI_DEV_ID_SPT_H  0xA13A  /* Sunrise Point H */
>  #define MEI_DEV_ID_SPT_H_20xA13B  /* Sunrise Point H 2 */
> 
> @@ -90,6 +91,7 @@
>  #define MEI_DEV_ID_CDF0x18D3  /* Cedar Fork */
> 
>  #define MEI_DEV_ID_ICP_LP 0x34E0  /* Ice Lake Point LP */
> +#define MEI_DEV_ID_ICP_LP_4   0x34E4  /* Ice Lake Point LP 4 (iTouch) */
> 
>  #define MEI_DEV_ID_JSP_N  0x4DE0  /* Jasper Lake Point N */
> 
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index
> a1ed375fed37..5e621e90d8d4 100644
> --- a/drivers/misc/mei/pci-me.c
> +++ b/drivers/misc/mei/pci-me.c
> @@ -68,6 +68,7 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
> 
>   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT, MEI_ME_PCH8_CFG)},
>   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_2, MEI_ME_PCH8_CFG)},
> + {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_4, MEI_ME_PCH8_CFG)},
>   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H, MEI_ME_PCH8_SPS_CFG)},
>   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H_2, MEI_ME_PCH8_SPS_CFG)},
>   {MEI_PCI_DEVICE(MEI_DEV_ID_LBG, MEI_ME_PCH12_SPS_CFG)},
> @@ -94,6 +95,7 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
>   {MEI_PCI_DEVICE(MEI_DEV_ID_CMP_H_3, MEI_ME_PCH8_CFG)},
> 
>   {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
> + {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP_4, MEI_ME_PCH12_CFG)},
> 
>   {MEI_PCI_DEVICE(MEI_DEV_ID_TGP_LP, MEI_ME_PCH15_CFG)},
> 
> --
> 2.26.2
> 

RE: [PATCH] treewide: Replace zero-length array with flexible-array

[Winkler, Tomas]

> -Original Message-
> From: Gustavo A. R. Silva 
> Sent: Thursday, May 07, 2020 21:54
> To: Winkler, Tomas 
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] treewide: Replace zero-length array with flexible-array


Ack. 

> 
> The current codebase makes use of the zero-length array language extension to
> the C90 standard, but the preferred mechanism to declare variable-length types
> such as these ones is a flexible array member[1][2], introduced in C99:
> 
> struct foo {
> int stuff;
> struct boo array[];
> };
> 
> By making use of the mechanism above, we will get a compiler warning in case
> the flexible array does not occur last in the structure, which will help us 
> prevent
> some kind of undefined behavior bugs from being inadvertently introduced[3]
> to the codebase from now on.
> 
> Also, notice that, dynamic memory allocations won't be affected by this 
> change:
> 
> "Flexible array members have incomplete type, and so the sizeof operator may
> not be applied. As a quirk of the original implementation of zero-length 
> arrays,
> sizeof evaluates to zero."[1]
> 
> sizeof(flexible-array-member) triggers a warning because flexible array
> members have incomplete type[1]. There are some instances of code in which
> the sizeof operator is being incorrectly/erroneously applied to zero-length
> arrays and the result is zero. Such instances may be hiding some bugs. So, 
> this
> work (flexible-array member conversions) will also help to get completely rid 
> of
> those sorts of issues.
> 
> This issue was found with the help of Coccinelle.
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  samples/mei/mei-amt-version.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/samples/mei/mei-amt-version.c b/samples/mei/mei-amt-version.c
> index 32234481ad7d..ad3e56042f96 100644
> --- a/samples/mei/mei-amt-version.c
> +++ b/samples/mei/mei-amt-version.c
> @@ -267,7 +267,7 @@ struct amt_host_if_msg_header {  struct
> amt_host_if_resp_header {
>   struct amt_host_if_msg_header header;
>   uint32_t status;
> - unsigned char data[0];
> + unsigned char data[];
>  } __attribute__((packed));
> 
>  const uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d,  \

RE: [BUG]is there a refcount leak in function mei_me_cl_rm_by_uuid?

[Winkler, Tomas]

> -Original Message-
> From: 亿一 
> Sent: Wednesday, May 06, 2020 17:47
> To: Winkler, Tomas 
> Cc: linux-kernel@vger.kernel.org
> Subject: [BUG]is there a refcount leak in function mei_me_cl_rm_by_uuid?

Unfortunately you are correct,  but currently it is very hard to hit the issue 
in real life.
The patch is coming. 
Thanks
Tomas


> 
> HI, all
> When reviewing function mei_me_cl_rm_by_uuid， I notice that function
> __mei_me_cl_by_uuid increases me_cl refcount and function _mei_me_cl_del
> delete a list node with decrement me_cl refcount , actually here cause a
> refcount leak as we haven't release the refcount by __mei_me_cl_by_uuid  ?
> similar issue happens in mei_me_cl_rm_by_uuid_id too.
> 
> void mei_me_cl_rm_by_uuid(struct mei_device *dev, const uuid_le *uuid) {
> struct mei_me_client *me_cl;
> 
> dev_dbg(dev->dev, "remove %pUl\n", uuid);
> 
> down_write(>me_clients_rwsem);
> me_cl = __mei_me_cl_by_uuid(dev, uuid); /* increase a refcount */
> __mei_me_cl_del(dev, me_cl); /* release the refcount with a list node 
> deteled
> */
> up_write(>me_clients_rwsem);
> }
> 
> Best regards,
> 
> Lin Yi.

RE: [PATCH v1 1/1] scsi: ufs: Add command logging infrastructure

[Winkler, Tomas]

> Add the necessary infrastructure to keep timestamp history of commands,
> events and other useful info for debugging complex issues. This helps in
> diagnosing events leading upto failure.

Why not use tracepoints, for that?
Thanks
Tomas

> Signed-off-by: Can Guo 
> ---
>  drivers/scsi/ufs/Kconfig  |  12 +++
>  drivers/scsi/ufs/ufshcd.c | 214
> +++---
>  drivers/scsi/ufs/ufshcd.h |  24 +-
>  3 files changed, 218 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index
> 0b845ab..afc70cb 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -50,6 +50,18 @@ config SCSI_UFSHCD
> However, do not compile this as a module if your root file system
> (the one containing the directory /) is located on a UFS device.
> 
> +config SCSI_UFSHCD_CMD_LOGGING
> + bool "Universal Flash Storage host controller driver layer command
> logging support"
> + depends on SCSI_UFSHCD
> + help
> +   This selects the UFS host controller driver layer command logging.
> +   UFS host controller driver layer command logging records all the
> +   command information sent from UFS host controller for debugging
> +   purpose.
> +
> +   Select this if you want above mentioned debug information captured.
> +   If unsure, say N.
> +
>  config SCSI_UFSHCD_PCI
>   tristate "PCI bus based UFS Controller support"
>   depends on SCSI_UFSHCD && PCI
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> c28c144..f3faa85 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -91,6 +91,9 @@
>  /* default delay of autosuspend: 2000 ms */  #define
> RPM_AUTOSUSPEND_DELAY_MS 2000
> 
> +/* Maximum command logging entries */
> +#define UFSHCD_MAX_CMD_LOGGING   20
> +
>  #define ufshcd_toggle_vreg(_dev, _vreg, _on) \
>   ({  \
>   int _ret;   \
> @@ -328,14 +331,135 @@ static void ufshcd_add_tm_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
>   >input_param1);
>  }
> 
> -static void ufshcd_add_command_trace(struct ufs_hba *hba,
> - unsigned int tag, const char *str)
> +static inline void ufshcd_add_command_trace(struct ufs_hba *hba,
> + struct ufshcd_cmd_log_entry *entry)
> +{
> + if (trace_ufshcd_command_enabled()) {
> + u32 intr = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
> +
> + trace_ufshcd_command(dev_name(hba->dev), entry->str,
> entry->tag,
> +  entry->doorbell, entry->transfer_len, intr,
> +  entry->lba, entry->cmd_id);
> + }
> +}
> +
> +#ifdef CONFIG_SCSI_UFSHCD_CMD_LOGGING
> +static void ufshcd_cmd_log_init(struct ufs_hba *hba) {
> + /* Allocate log entries */
> + if (!hba->cmd_log.entries) {
> + hba->cmd_log.entries =
> kcalloc(UFSHCD_MAX_CMD_LOGGING,
> + sizeof(struct ufshcd_cmd_log_entry), GFP_KERNEL);
> + if (!hba->cmd_log.entries)
> + return;
> + dev_dbg(hba->dev, "%s: cmd_log.entries initialized\n",
> + __func__);
> + }
> +}
> +
> +static void __ufshcd_cmd_log(struct ufs_hba *hba, char *str, char *cmd_type,
> +  unsigned int tag, u8 cmd_id, u8 idn, u8 lun,
> +  sector_t lba, int transfer_len) {
> + struct ufshcd_cmd_log_entry *entry;
> +
> + if (!hba->cmd_log.entries)
> + return;
> +
> + entry = >cmd_log.entries[hba->cmd_log.pos];
> + entry->lun = lun;
> + entry->str = str;
> + entry->cmd_type = cmd_type;
> + entry->cmd_id = cmd_id;
> + entry->lba = lba;
> + entry->transfer_len = transfer_len;
> + entry->idn = idn;
> + entry->doorbell = ufshcd_readl(hba,
> REG_UTP_TRANSFER_REQ_DOOR_BELL);
> + entry->tag = tag;
> + entry->tstamp = ktime_get();
> + entry->outstanding_reqs = hba->outstanding_reqs;
> + entry->seq_num = hba->cmd_log.seq_num;
> + hba->cmd_log.seq_num++;
> + hba->cmd_log.pos = (hba->cmd_log.pos + 1) %
> UFSHCD_MAX_CMD_LOGGING;
> +
> + ufshcd_add_command_trace(hba, entry);
> +}
> +
> +static void ufshcd_cmd_log(struct ufs_hba *hba, char *str, char *cmd_type,
> + unsigned int tag, u8 cmd_id, u8 idn)
> +{
> + __ufshcd_cmd_log(hba, str, cmd_type, tag, cmd_id, idn, 0, 0, 0); }
> +
> +static void ufshcd_dme_cmd_log(struct ufs_hba *hba, char *str, u8
> +cmd_id) {
> + ufshcd_cmd_log(hba, str, "dme", 0, cmd_id, 0); }
> +
> +static void ufshcd_print_cmd_log(struct ufs_hba *hba) {
> + int i;
> + int pos;
> + struct ufshcd_cmd_log_entry *p;
> +
> + if (!hba->cmd_log.entries)
> + return;
> +
> + pos = hba->cmd_log.pos;
> + for (i = 0; i < 

RE: Could not read FW version, FW version command failed -5

[Winkler, Tomas]

> Dear Tomas,
> 
> 
> Testing Fedora 30 with Linux 5.2.11 on an old Dell OptiPlex 980, Linux 
> log the message below.
> 
> [   15.964298] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could
> not read FW version
> [   15.964301] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW
> version command failed -5
> 
> The prints happen in `drivers/misc/mei/bus-fixup.c`.
> 
> ret = 0;
> bytes_recv = __mei_cl_recv(cldev->cl, buf, sizeof(buf), 0,
>MKHI_RCV_TIMEOUT);
> if (bytes_recv < 0 || (size_t)bytes_recv < MKHI_FWVER_LEN(1)) {
> /*
>  * Should be at least one version block,
>  * error out if nothing found
>  */
> dev_err(>dev, "Could not read FW version\n");
> return -EIO;
> }
> 
> The Web is full of these messages, so it does seem like a normal 
> condition on certain devices. Do you know the reason? Do older Intel 
> MEs support this?

Wow, this quite an old system ~ 2009, the FW version has a bit different format 
there, it was overlooked,  will look at that ASAP, thanks for the report. 
Tomas

RE: [PATCH -next] scsi: ufs: Use kmemdup in ufshcd_read_string_desc()

[Winkler, Tomas]

> Use kmemdup rather than duplicating its implementation
> 
> Signed-off-by: YueHaibing 
LGTM, ACK.
Tomas
 
> ---
>  drivers/scsi/ufs/ufshcd.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> acf298da054c..6d5e2f5d8468 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -3309,12 +3309,11 @@ int ufshcd_read_string_desc(struct ufs_hba *hba,
> u8 desc_index,
>   str[ret++] = '\0';
> 
>   } else {
> - str = kzalloc(uc_str->len, GFP_KERNEL);
> + str = kmemdup(uc_str, uc_str->len, GFP_KERNEL);
>   if (!str) {
>   ret = -ENOMEM;
>   goto out;
>   }
> - memcpy(str, uc_str, uc_str->len);
>   ret = uc_str->len;
>   }
>  out:
> 
> 

RE: [char-misc-next] mei: me: add Tiger Lake point LP device ID

[Winkler, Tomas]

Oops,  this should go to 5.3-rc6 possibly, not for next. 
Thanks

> 
> Add Tiger Lake Point device ID for TGP LP.
> 
> Signed-off-by: Tomas Winkler 
> ---
>  drivers/misc/mei/hw-me-regs.h | 2 ++
>  drivers/misc/mei/pci-me.c | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
> index 6c0173772162..77f7dff7098d 100644
> --- a/drivers/misc/mei/hw-me-regs.h
> +++ b/drivers/misc/mei/hw-me-regs.h
> @@ -81,6 +81,8 @@
> 
>  #define MEI_DEV_ID_ICP_LP 0x34E0  /* Ice Lake Point LP */
> 
> +#define MEI_DEV_ID_TGP_LP 0xA0E0  /* Tiger Lake Point LP */
> +
>  #define MEI_DEV_ID_MCC0x4B70  /* Mule Creek Canyon (EHL) */
>  #define MEI_DEV_ID_MCC_4  0x4B75  /* Mule Creek Canyon 4 (EHL) */
> 
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index
> 563ebd56c3e5..d5a92c6eadb3 100644
> --- a/drivers/misc/mei/pci-me.c
> +++ b/drivers/misc/mei/pci-me.c
> @@ -98,6 +98,8 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
> 
>   {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
> 
> + {MEI_PCI_DEVICE(MEI_DEV_ID_TGP_LP, MEI_ME_PCH12_CFG)},
> +
>   {MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH12_CFG)},
>   {MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)},
> 
> --
> 2.20.1

RE: linux-next: manual merge of the char-misc tree with the driver-core tree

[Winkler, Tomas]

> 
> Hi all,
> 
> On Thu, 20 Jun 2019 15:35:52 +1000 Stephen Rothwell 
> wrote:
> >
> > Today's linux-next merge of the char-misc tree got a conflict in:
> >
> >   drivers/misc/mei/debugfs.c
> >
> > between commit:
> >
> >   5666d896e838 ("mei: no need to check return value of debugfs_create
> > functions")
> >
> > from the driver-core tree and commit:
> >
> >   b728ddde769c ("mei: Convert to use DEFINE_SHOW_ATTRIBUTE macro")
> >
> > from the char-misc tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This is
> > now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your
> > tree is submitted for merging.  You may also want to consider
> > cooperating with the maintainer of the conflicting tree to minimise
> > any particularly complex conflicts.
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc drivers/misc/mei/debugfs.c
> > index df6bf8b81936,47cfd5005e1b..
> > --- a/drivers/misc/mei/debugfs.c
> > +++ b/drivers/misc/mei/debugfs.c
> > @@@ -233,22 -154,46 +154,21 @@@ void mei_dbgfs_deregister(struct
> mei_de
> >*
> >* @dev: the mei device structure
> >* @name: the mei device name
> >  - *
> >  - * Return: 0 on success, <0 on failure.
> >*/
> >  -int mei_dbgfs_register(struct mei_device *dev, const char *name)
> > +void mei_dbgfs_register(struct mei_device *dev, const char *name)
> >   {
> >  -  struct dentry *dir, *f;
> >  +  struct dentry *dir;
> >
> > dir = debugfs_create_dir(name, NULL);
> >  -  if (!dir)
> >  -  return -ENOMEM;
> >  -
> > dev->dbgfs_dir = dir;
> >
> >  -  f = debugfs_create_file("meclients", S_IRUSR, dir,
> >  -  dev, _dbgfs_meclients_fops);
> >  -  if (!f) {
> >  -  dev_err(dev->dev, "meclients: registration failed\n");
> >  -  goto err;
> >  -  }
> >  -  f = debugfs_create_file("active", S_IRUSR, dir,
> >  -  dev, _dbgfs_active_fops);
> >  -  if (!f) {
> >  -  dev_err(dev->dev, "active: registration failed\n");
> >  -  goto err;
> >  -  }
> >  -  f = debugfs_create_file("devstate", S_IRUSR, dir,
> >  -  dev, _dbgfs_devstate_fops);
> >  -  if (!f) {
> >  -  dev_err(dev->dev, "devstate: registration failed\n");
> >  -  goto err;
> >  -  }
> >  -  f = debugfs_create_file("allow_fixed_address", S_IRUSR | S_IWUSR,
> dir,
> >  -  >allow_fixed_address,
> >  -  _dbgfs_allow_fa_fops);
> >  -  if (!f) {
> >  -  dev_err(dev->dev, "allow_fixed_address: registration
> failed\n");
> >  -  goto err;
> >  -  }
> >  -  return 0;
> >  -err:
> >  -  mei_dbgfs_deregister(dev);
> >  -  return -ENODEV;
> >  +  debugfs_create_file("meclients", S_IRUSR, dir, dev,
> > -   _dbgfs_fops_meclients);
> > ++  _dbgfs_meclients_fops);
> >  +  debugfs_create_file("active", S_IRUSR, dir, dev,
> > -   _dbgfs_fops_active);
> > ++  _dbgfs_active_fops);
> >  +  debugfs_create_file("devstate", S_IRUSR, dir, dev,
> > -   _dbgfs_fops_devstate);
> > ++  _dbgfs_devstate_fops);
> >  +  debugfs_create_file("allow_fixed_address", S_IRUSR | S_IWUSR, dir,
> >  +  >allow_fixed_address,
> > -   _dbgfs_fops_allow_fa);
> > ++  _dbgfs_allow_fa_fops);
> >   }
> > -
> 
> I am still getting this conflict (the commit ids may have changed).
> Just a reminder in case you think Linus may need to know.

The conflict is resolved correctly,  the conflicts are between Greg's misc-char 
 and driver-core git trees.
Actually I've asked Greg this git expertise question: how the **exact** 
conflict resolution is carried between git trees (before it is finally resolved 
in upstream for all.). 
For next time If anyone has the answer, please let me know.

Thanks
Tomas

RE: [PATCH v2] mei: no need to check return value of debugfs_create functions

[Winkler, Tomas]

> 
> When calling debugfs functions, there is no need to ever check the return
> value.  The function can work or not, but the code logic should never do
> something different based on this.

Maybe need to mention that API has changed in patch ' 
ff9fb72bc07705c00795ca48631f7fffe24d2c6b' in 5.0 
and create_dir() doesn't return NULL but ERR_PTR() and proper checking is done 
inside the debugfs functions.
Not sure how critical is that but, but this should go probably to stable 5.0+ 
as well. 
Ack otherwise. 
> 
> Cc: Tomas Winkler 
> Cc: Arnd Bergmann 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman 
> ---
> v2: break the patch up properly
> 
>  drivers/misc/mei/debugfs.c | 47 +-
>  drivers/misc/mei/main.c|  8 +--
>  drivers/misc/mei/mei_dev.h |  7 ++
>  3 files changed, 14 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c index
> 0970142bcace..df6bf8b81936 100644
> --- a/drivers/misc/mei/debugfs.c
> +++ b/drivers/misc/mei/debugfs.c
> @@ -233,47 +233,22 @@ void mei_dbgfs_deregister(struct mei_device *dev)
>   *
>   * @dev: the mei device structure
>   * @name: the mei device name
> - *
> - * Return: 0 on success, <0 on failure.
>   */
> -int mei_dbgfs_register(struct mei_device *dev, const char *name)
> +void mei_dbgfs_register(struct mei_device *dev, const char *name)
>  {
> - struct dentry *dir, *f;
> + struct dentry *dir;
> 
>   dir = debugfs_create_dir(name, NULL);
> - if (!dir)
> - return -ENOMEM;
> -
>   dev->dbgfs_dir = dir;
> 
> - f = debugfs_create_file("meclients", S_IRUSR, dir,
> - dev, _dbgfs_fops_meclients);
> - if (!f) {
> - dev_err(dev->dev, "meclients: registration failed\n");
> - goto err;
> - }
> - f = debugfs_create_file("active", S_IRUSR, dir,
> - dev, _dbgfs_fops_active);
> - if (!f) {
> - dev_err(dev->dev, "active: registration failed\n");
> - goto err;
> - }
> - f = debugfs_create_file("devstate", S_IRUSR, dir,
> - dev, _dbgfs_fops_devstate);
> - if (!f) {
> - dev_err(dev->dev, "devstate: registration failed\n");
> - goto err;
> - }
> - f = debugfs_create_file("allow_fixed_address", S_IRUSR | S_IWUSR,
> dir,
> - >allow_fixed_address,
> - _dbgfs_fops_allow_fa);
> - if (!f) {
> - dev_err(dev->dev, "allow_fixed_address: registration
> failed\n");
> - goto err;
> - }
> - return 0;
> -err:
> - mei_dbgfs_deregister(dev);
> - return -ENODEV;
> + debugfs_create_file("meclients", S_IRUSR, dir, dev,
> + _dbgfs_fops_meclients);
> + debugfs_create_file("active", S_IRUSR, dir, dev,
> + _dbgfs_fops_active);
> + debugfs_create_file("devstate", S_IRUSR, dir, dev,
> + _dbgfs_fops_devstate);
> + debugfs_create_file("allow_fixed_address", S_IRUSR | S_IWUSR, dir,
> + >allow_fixed_address,
> + _dbgfs_fops_allow_fa);
>  }
> 
> diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index
> ad02097d7fee..f894d1f8a53e 100644
> --- a/drivers/misc/mei/main.c
> +++ b/drivers/misc/mei/main.c
> @@ -984,16 +984,10 @@ int mei_register(struct mei_device *dev, struct
> device *parent)
>   goto err_dev_create;
>   }
> 
> - ret = mei_dbgfs_register(dev, dev_name(clsdev));
> - if (ret) {
> - dev_err(clsdev, "cannot register debugfs ret = %d\n", ret);
> - goto err_dev_dbgfs;
> - }
> + mei_dbgfs_register(dev, dev_name(clsdev));
> 
>   return 0;
> 
> -err_dev_dbgfs:
> - device_destroy(mei_class, devno);
>  err_dev_create:
>   cdev_del(>cdev);
>  err_dev_add:
> diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h index
> fca832fcac57..f71a023aed3c 100644
> --- a/drivers/misc/mei/mei_dev.h
> +++ b/drivers/misc/mei/mei_dev.h
> @@ -718,13 +718,10 @@ bool mei_hbuf_acquire(struct mei_device *dev);
> bool mei_write_is_idle(struct mei_device *dev);
> 
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> -int mei_dbgfs_register(struct mei_device *dev, const char *name);
> +void mei_dbgfs_register(struct mei_device *dev, const char *name);
>  void mei_dbgfs_deregister(struct mei_device *dev);  #else -static inline int
> mei_dbgfs_register(struct mei_device *dev, const char *name) -{
> - return 0;
> -}
> +static inline void mei_dbgfs_register(struct mei_device *dev, const
> +char *name) {}
>  static inline void mei_dbgfs_deregister(struct mei_device *dev) {}  #endif /*
> CONFIG_DEBUG_FS */
> 
> --
> 2.22.0

RE: [RFC PATCH 36/57] drivers: mei: Use class_find_device_by_devt match helper

[Winkler, Tomas]

> -Original Message-
> From: Suzuki K Poulose [mailto:suzuki.poul...@arm.com]
> Sent: Monday, June 03, 2019 18:50
> To: linux-kernel@vger.kernel.org
> Cc: gre...@linuxfoundation.org; raf...@kernel.org; suzuki.poul...@arm.com;
> Winkler, Tomas ; Arnd Bergmann
> 
> Subject: [RFC PATCH 36/57] drivers: mei: Use class_find_device_by_devt match
> helper
> 
> Switch to the generic helper class_find_device_by_devt.

Looks okay, but  you could add me at least to cover later mail, there is very 
little context. 


Thanks
Tomas


> 
> Cc: Tomas Winkler 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Suzuki K Poulose 
> ---
>  drivers/misc/mei/main.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index
> ad02097..243b481 100644
> --- a/drivers/misc/mei/main.c
> +++ b/drivers/misc/mei/main.c
> @@ -858,13 +858,6 @@ static ssize_t dev_state_show(struct device *device,  }
> static DEVICE_ATTR_RO(dev_state);
> 
> -static int match_devt(struct device *dev, const void *data) -{
> - const dev_t *devt = data;
> -
> - return dev->devt == *devt;
> -}
> -
>  /**
>   * dev_set_devstate: set to new device state and notify sysfs file.
>   *
> @@ -880,7 +873,7 @@ void mei_set_devstate(struct mei_device *dev, enum
> mei_dev_state state)
> 
>   dev->dev_state = state;
> 
> - clsdev = class_find_device(mei_class, NULL, >cdev.dev,
> match_devt);
> + clsdev = class_find_device_by_devt(mei_class, NULL, dev->cdev.dev);
>   if (clsdev) {
>   sysfs_notify(>kobj, NULL, "dev_state");
>   put_device(clsdev);
> --
> 2.7.4

RE: [PATCH v3] tpm: Actually fail on TPM errors during "get random"

[Winkler, Tomas]

> On Tue, Apr 02, 2019 at 02:46:25AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Apr 01, 2019 at 12:06:07PM -0700, Kees Cook wrote:
> > > A "get random" may fail with a TPM error, but those codes were
> > > returned as-is to the caller, which assumed the result was the
> > > number of bytes that had been written to the target buffer, which
> > > could lead to a kernel heap memory exposure and over-read.
> > >
> > > This fixes tpm1_get_random() to mask positive TPM errors into -EIO,
> > > as before.
> > >
> > > [   18.092103] tpm tpm0: A TPM error (379) occurred attempting get
> random
> > > [   18.092106] usercopy: Kernel memory exposure attempt detected from
> SLUB object 'kmalloc-64' (offset 0, size 379)!
> > >
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989
> > > Reported-by: Phil Baker 
> > > Reported-by: Craig Robson 
> > > Fixes: 7aee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using
> > > tpm_buf structure")
> > > Cc: Laura Abbott 
> > > Cc: Tomas Winkler 
> > > Cc: Jarkko Sakkinen 
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Kees Cook 
> > > ---
> > > v3: fix never-succeed, limit checks to tpm cmd return (James, Jason)
> > > v2: also fix tpm2 implementation (Jason Gunthorpe)
> > > ---
> > >  drivers/char/tpm/tpm1-cmd.c | 7 +--
> > > drivers/char/tpm/tpm2-cmd.c | 7 +--
> > >  2 files changed, 10 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm1-cmd.c
> > > b/drivers/char/tpm/tpm1-cmd.c index 85dcf2654d11..faacbe1ffa1a
> > > 100644
> > > --- a/drivers/char/tpm/tpm1-cmd.c
> > > +++ b/drivers/char/tpm/tpm1-cmd.c
> > > @@ -510,7 +510,7 @@ struct tpm1_get_random_out {
> > >   *
> > >   * Return:
> > >   * *  number of bytes read
> > > - * * -errno or a TPM return code otherwise
> > > + * * -errno (positive TPM return codes are masked to -EIO)
> > >   */
> > >  int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)  {
> > > @@ -531,8 +531,11 @@ int tpm1_get_random(struct tpm_chip *chip, u8
> > > *dest, size_t max)
> > >
> > >   rc = tpm_transmit_cmd(chip, , sizeof(out->rng_data_len),
> > > "attempting get random");
> > > - if (rc)
> > > + if (rc) {
> > > + if (rc > 0)
> > > + rc = -EIO;
> > >   goto out;
> > > + }
> > >
> > >   out = (struct tpm1_get_random_out
> *)[TPM_HEADER_SIZE];
> > >
> > > diff --git a/drivers/char/tpm/tpm2-cmd.c
> > > b/drivers/char/tpm/tpm2-cmd.c index e74c5b7b64bf..8ffa6af61580
> > > 100644
> > > --- a/drivers/char/tpm/tpm2-cmd.c
> > > +++ b/drivers/char/tpm/tpm2-cmd.c
> > > @@ -301,7 +301,7 @@ struct tpm2_get_random_out {
> > >   *
> > >   * Return:
> > >   *   size of the buffer on success,
> > > - *   -errno otherwise
> > > + *   -errno otherwise ((positive TPM return codes are masked to -EIO)
> > >   */
> > >  int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)  {
> > > @@ -328,8 +328,11 @@ int tpm2_get_random(struct tpm_chip *chip, u8
> *dest, size_t max)
> > >  offsetof(struct tpm2_get_random_out,
> > >   buffer),
> > >  "attempting get random");
> > > - if (err)
> > > + if (err) {
> > > + if (err > 0)
> > > + err = -EIO;
> > >   goto out;
> > > + }
> > >
> > >   out = (struct tpm2_get_random_out *)
> > >   [TPM_HEADER_SIZE];
> > > --
> > > 2.17.1
> > >
> > >
> > > --
> > > Kees Cook
> >
> > Reviewed-by: Jarkko Sakkinen 
> 
> Applied to my master branch. Jason, Tomas, do you want me to add reviewed-
> by's?
Sure, it fixes my patch.

> /Jarkko

RE: [PATCH v3] tpm: Actually fail on TPM errors during "get random"

[Winkler, Tomas]

> 
> A "get random" may fail with a TPM error, but those codes were returned as-is
> to the caller, which assumed the result was the number of bytes that had been
> written to the target buffer, which could lead to a kernel heap memory
> exposure and over-read.
> 
> This fixes tpm1_get_random() to mask positive TPM errors into -EIO, as before.
> 
> [   18.092103] tpm tpm0: A TPM error (379) occurred attempting get random
> [   18.092106] usercopy: Kernel memory exposure attempt detected from SLUB
> object 'kmalloc-64' (offset 0, size 379)!
> 
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989
> Reported-by: Phil Baker 
> Reported-by: Craig Robson 
> Fixes: 7aee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using tpm_buf
> structure")
> Cc: Laura Abbott 
> Cc: Tomas Winkler 
> Cc: Jarkko Sakkinen 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Kees Cook 
> ---
> v3: fix never-succeed, limit checks to tpm cmd return (James, Jason)
> v2: also fix tpm2 implementation (Jason Gunthorpe)
Looks good to me.
Thanks
Tomas

> ---
>  drivers/char/tpm/tpm1-cmd.c | 7 +--  drivers/char/tpm/tpm2-cmd.c | 7
> +--
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index 85dcf2654d11..faacbe1ffa1a 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -510,7 +510,7 @@ struct tpm1_get_random_out {
>   *
>   * Return:
>   * *  number of bytes read
> - * * -errno or a TPM return code otherwise
> + * * -errno (positive TPM return codes are masked to -EIO)
>   */
>  int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)  { @@ -
> 531,8 +531,11 @@ int tpm1_get_random(struct tpm_chip *chip, u8 *dest,
> size_t max)
> 
>   rc = tpm_transmit_cmd(chip, , sizeof(out->rng_data_len),
> "attempting get random");
> - if (rc)
> + if (rc) {
> + if (rc > 0)
> + rc = -EIO;
>   goto out;
> + }
> 
>   out = (struct tpm1_get_random_out
> *)[TPM_HEADER_SIZE];
> 
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index e74c5b7b64bf..8ffa6af61580 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -301,7 +301,7 @@ struct tpm2_get_random_out {
>   *
>   * Return:
>   *   size of the buffer on success,
> - *   -errno otherwise
> + *   -errno otherwise ((positive TPM return codes are masked to -EIO)
>   */
>  int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)  { @@ -
> 328,8 +328,11 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest,
> size_t max)
>  offsetof(struct tpm2_get_random_out,
>   buffer),
>  "attempting get random");
> - if (err)
> + if (err) {
> + if (err > 0)
> + err = -EIO;
>   goto out;
> + }
> 
>   out = (struct tpm2_get_random_out *)
>   [TPM_HEADER_SIZE];
> --
> 2.17.1
> 
> 
> --
> Kees Cook

RE: [char-misc] mei: convert to SPDX license tags

[Winkler, Tomas]

> 
> On Sun, Mar 10, 2019 at 10:14:03AM +, Winkler, Tomas wrote:
> > > Please break this up into two (at the least) patches and resend as a 
> > > series.
> >
> > Can you be please,  more specific what split are you expecting.
> 
> You are doing lots of different types of things in the same patch.
> Break up the logical changes into different patches.  For example, one patch
> that updates copyright years, one that removes boiler plate license crud, and
> another that adds missing spdx lines.
Okay
Thanks
Tomas

RE: [char-misc] mei: convert to SPDX license tags

[Winkler, Tomas]

> On Sun, Mar 10, 2019 at 12:03:23PM +0200, Tomas Winkler wrote:
> > Signed-off-by: Tomas Winkler 
> 
> I can not take patches without any changelog text.

Ok, my mistake. 
> 
> Especially a patch that does not actually do what your subject: line says it 
> does.

Yep, I should be more verbose. 
> 
> > --- a/drivers/misc/mei/Makefile
> > +++ b/drivers/misc/mei/Makefile
> > @@ -1,7 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  #
> >  # Makefile - Intel Management Engine Interface (Intel MEI) Linux
> > driver -# Copyright (c) 2010-2014, Intel Corporation.
> > +# Copyright (c) 2010-2019, Intel Corporation.
> >  #
> >  obj-$(CONFIG_INTEL_MEI) += mei.o
> >  mei-objs := init.o
> 
> As an example, why did you update this copyright line?  That has nothing to do
> with the SPDX identifier :(

Right, will update the commit message. 
> 
> 
> > --- a/drivers/misc/mei/client.c
> > +++ b/drivers/misc/mei/client.c
> > @@ -1,17 +1,8 @@
> > +// SPDX-License-Identifier: GPL-2.0
> >  /*
> > + * Copyright(c) 2003-2019, Intel Corporation. All rights reserved.
> >   *
> >   * Intel Management Engine Interface (Intel MEI) Linux driver
> > - * Copyright (c) 2003-2012, Intel Corporation.
> 
> Are you _SURE_ you mean to change the dates of the copyright in this manner
> for this file (and elsewhere?)  Was the copyright really updated every year 
> for
> the past 7 years?

Yes, this particular file was updated, will go over other files.

> 
> Please break this up into two (at the least) patches and resend as a series.

Can you be please,  more specific what split are you expecting. 
> 
> This patch makes me feel like it is a kernel intern application process patch,
> and that's not good, you all know better than this.  No, sorry, I take that 
> back,
> the intern application patches are of much higher quality...
> 
Have hard time to put the soul into it, where it comes to legal :)
Will fix.
Tomas

RE: [PATCH] mei: expand minor range when registering chrdev region

[Winkler, Tomas]

> 
> On 2/12/19 5:29 PM, Greg KH wrote:
> > On Tue, Feb 12, 2019 at 02:02:52PM +0800, Chengguang Xu wrote:
> >> Actually, total amount of available minor number for a single major
> >> is MINORMARK + 1. So expand minor range when registering chrdev
> >> region.
> >>
> >> Signed-off-by: Chengguang Xu 
> >> ---
> >>   drivers/misc/mei/main.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index
> >> 87281b3695e6..3df54f1e1a8b 100644
> >> --- a/drivers/misc/mei/main.c
> >> +++ b/drivers/misc/mei/main.c
> >> @@ -869,7 +869,7 @@ static const struct file_operations mei_fops = {
> >>
> >>   static struct class *mei_class;
> >>   static dev_t mei_devt;
> >> -#define MEI_MAX_DEVS  MINORMASK
> >> +#define MEI_MAX_DEVS  (MINORMASK + 1)
> > Why is this needed?  Have you really run out of that many minor nodes
> > for this driver?
> 
> Not really, practically maybe we cannot reach to the limit.
> I was just curious why only one minor number left there and assumed that was
> from a mistake(since I've seen similar mistake in other driver).
> However, if it explicitly sets to MINORMASK for some reasons, then it's better
> to keep as is.

I guess this was a boilerplate code, but I'm sure we don't need so many devices.

Thanks
Tomas

RE: [PATCH v3] tpm/tpm_crb: Avoid unaligned reads in crb_recv()

[Winkler, Tomas]

 ()
> 
> On Tue, Feb 05, 2019 at 10:57:19PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Feb 05, 2019 at 02:56:02PM +0000, Winkler, Tomas wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> > > > Sent: Tuesday, February 05, 2019 16:36
> > > > To: Winkler, Tomas 
> > > > Cc: linux-integr...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > linux- security-mod...@vger.kernel.org; sta...@vger.kernel.org;
> > > > James Morris ; Jerry Snitselaar
> > > > 
> > > > Subject: Re: [PATCH v3] tpm/tpm_crb: Avoid unaligned reads in
> > > > crb_recv()
> > > >
> > > > On Tue, Feb 05, 2019 at 11:07:16AM +, Winkler, Tomas wrote:
> > > > > > The current approach to read first 6 bytes from the response
> > > > > > and then tail of the response, can cause the 2nd
> > > > > > memcpy_fromio() to do an unaligned read (e.g. read 32-bit word
> > > > > > from address aligned to a 16-bits), depending on how
> > > > > > memcpy_fromio() is implemented. If this happens, the read will
> > > > > > fail and the memory controller will fill the read with 1's.
> > > > > >
> > > > > > This was triggered by 170d13ca3a2f, which should be probably
> > > > > > refined to check and react to the address alignment. Before
> > > > > > that commit, on
> > > > > > x86
> > > > > > memcpy_fromio() turned out to be memcpy(). By a luck GCC has
> > > > > > done the right thing (from tpm_crb's perspective) for us so
> > > > > > far, but we should not
> > > > rely on that.
> > > > > > Thus, it makes sense to fix this also in tpm_crb, not least
> > > > > > because the fix can be then backported to stable kernels and
> > > > > > make them more robust when compiled in differing environments.
> > > > > >
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Cc: James Morris 
> > > > > > Cc: Tomas Winkler 
> > > > > > Cc: Jerry Snitselaar 
> > > > > > Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> > > > > > Signed-off-by: Jarkko Sakkinen
> > > > > > 
> > > > > > Reviewed-by: Jerry Snitselaar 
> > > > > > ---
> > > > > > v3:
> > > > > > * Fix typo i.e. %s/reminding/remaining/g
> > > > >
> > > > > Why you haven't fixed all the typos I've pointed out? I think you 
> > > > > missed
> that.
> > > >
> > > > I saw only comment about remaining. Was there something else? Can fix.
> > >
> > > https://www.spinics.net/lists/stable/msg283648.html
> > >
> > > 1. unrecovable -> unrecoverable
> > > 2. /* Read 8 bytes (not just 6 bytes, which would cover the tag and
> > > the response  length
> > > > +* fields) in order to make sure that the remaining memory
> > > > +accesses */
> >
> > Thanks and apologies for missing these.
> 
> Fixed comments and applied the patch, thank you. Do I amend your acked-by?

Please, do.
Thanks
Tomas

RE: [PATCH v3] tpm/tpm_crb: Avoid unaligned reads in crb_recv()

[Winkler, Tomas]

> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, February 05, 2019 16:36
> To: Winkler, Tomas 
> Cc: linux-integr...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> security-mod...@vger.kernel.org; sta...@vger.kernel.org; James Morris
> ; Jerry Snitselaar 
> Subject: Re: [PATCH v3] tpm/tpm_crb: Avoid unaligned reads in crb_recv()
> 
> On Tue, Feb 05, 2019 at 11:07:16AM +, Winkler, Tomas wrote:
> > > The current approach to read first 6 bytes from the response and
> > > then tail of the response, can cause the 2nd memcpy_fromio() to do
> > > an unaligned read (e.g. read 32-bit word from address aligned to a
> > > 16-bits), depending on how
> > > memcpy_fromio() is implemented. If this happens, the read will fail
> > > and the memory controller will fill the read with 1's.
> > >
> > > This was triggered by 170d13ca3a2f, which should be probably refined
> > > to check and react to the address alignment. Before that commit, on
> > > x86
> > > memcpy_fromio() turned out to be memcpy(). By a luck GCC has done
> > > the right thing (from tpm_crb's perspective) for us so far, but we should 
> > > not
> rely on that.
> > > Thus, it makes sense to fix this also in tpm_crb, not least because
> > > the fix can be then backported to stable kernels and make them more
> > > robust when compiled in differing environments.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: James Morris 
> > > Cc: Tomas Winkler 
> > > Cc: Jerry Snitselaar 
> > > Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> > > Signed-off-by: Jarkko Sakkinen 
> > > Reviewed-by: Jerry Snitselaar 
> > > ---
> > > v3:
> > > * Fix typo i.e. %s/reminding/remaining/g
> >
> > Why you haven't fixed all the typos I've pointed out? I think you missed 
> > that.
> 
> I saw only comment about remaining. Was there something else? Can fix.

https://www.spinics.net/lists/stable/msg283648.html

1. unrecovable -> unrecoverable
2. /* Read 8 bytes (not just 6 bytes, which would cover the tag and the 
response  length
> +  * fields) in order to make sure that the remaining memory accesses */ 
 
Thanks
Tomas

RE: [PATCH v3] tpm/tpm_crb: Avoid unaligned reads in crb_recv()

[Winkler, Tomas]

> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read will fail and the
> memory controller will fill the read with 1's.
> 
> This was triggered by 170d13ca3a2f, which should be probably refined to check
> and react to the address alignment. Before that commit, on x86
> memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
> thing (from tpm_crb's perspective) for us so far, but we should not rely on 
> that.
> Thus, it makes sense to fix this also in tpm_crb, not least because the fix 
> can be
> then backported to stable kernels and make them more robust when compiled
> in differing environments.
> 
> Cc: sta...@vger.kernel.org
> Cc: James Morris 
> Cc: Tomas Winkler 
> Cc: Jerry Snitselaar 
> Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Jerry Snitselaar 
> ---
> v3:
> * Fix typo i.e. %s/reminding/remaining/g

Why you haven't fixed all the typos I've pointed out? I think you missed that.
Tomas

> v2:
> * There was a trailing double colon in the end of the short summary.
> * Check requested and expected length against TPM_HEADER_SIZE.
> * Add some explanatory comments to crb_recv().
>  drivers/char/tpm/tpm_crb.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index
> 36952ef98f90..ee4df7815912 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -287,19 +287,29 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
>   struct crb_priv *priv = dev_get_drvdata(>dev);
>   unsigned int expected;
> 
> - /* sanity check */
> - if (count < 6)
> + /* A sanity check that the upper layer wants to get at least the header
> +  * as that is the minimum size for any TPM response.
> +  */
> + if (count < TPM_HEADER_SIZE)
>   return -EIO;
> 
> + /* If this bit is set, according to the spec, the TPM is in unrecovable
> +  * condition.
> +  */
>   if (ioread32(>regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
>   return -EIO;
> 
> - memcpy_fromio(buf, priv->rsp, 6);
> - expected = be32_to_cpup((__be32 *) [2]);
> - if (expected > count || expected < 6)
> + /* Read 8 bytes (not just 6 bytes, which would cover the response
> length
> +  * field) in order to make sure that the remaining memory accesses
> will
> +  * be aligned.
> +  */
> + memcpy_fromio(buf, priv->rsp, 8);
> +
> + expected = be32_to_cpup((__be32 *)[2]);
> + if (expected > count || expected < TPM_HEADER_SIZE)
>   return -EIO;
> 
> - memcpy_fromio([6], >rsp[6], expected - 6);
> + memcpy_fromio([8], >rsp[8], expected - 8);
> 
>   return expected;
>  }
> --
> 2.19.1

RE: [PATCH v2] tpm/tpm_crb: Avoid unaligned reads in crb_recv()

[Winkler, Tomas]

> 
> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read will fail and the
> memory controller will fill the read with 1's.
> 
> This was triggered by 170d13ca3a2f, which should be probably refined to check
> and react to the address alignment. Before that commit, on x86
> memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
> thing (from tpm_crb's perspective) for us so far, but we should not rely on 
> that.
> Thus, it makes sense to fix this also in tpm_crb, not least because the fix 
> can be
> then backported to stable kernels and make them more robust when compiled
> in differing environments.
> 
> Cc: sta...@vger.kernel.org
> Cc: James Morris 
> Cc: Tomas Winkler 
> Cc: Jerry Snitselaar 
> Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Jerry Snitselaar 
After fixing the typos you can add my ack. 
Thanks
Tomas

> ---
> v2:
> * There was a trailing double colon in the end of the short summary.
> * Check requested and expected length against TPM_HEADER_SIZE.
> * Add some explanatory comments to crb_recv().
>  drivers/char/tpm/tpm_crb.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index
> 36952ef98f90..c084e61299aa 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -287,19 +287,29 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
>   struct crb_priv *priv = dev_get_drvdata(>dev);
>   unsigned int expected;
> 
> - /* sanity check */
> - if (count < 6)
> + /* A sanity check that the upper layer wants to get at least the header
> +  * as that is the minimum size for any TPM response.
> +  */
> + if (count < TPM_HEADER_SIZE)
>   return -EIO;
> 
> + /* If this bit is set, according to the spec, the TPM is in unrecovable

 ^^^ typo 
> +  * condition.
> +  */
>   if (ioread32(>regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
>   return -EIO;
> 
> - memcpy_fromio(buf, priv->rsp, 6);
> - expected = be32_to_cpup((__be32 *) [2]);
> - if (expected > count || expected < 6)
> + /* Read 8 bytes (not just 6 bytes, which would cover ^^^ tag and^^^ the 
> response
> length
> +  * field ^^^s^^^) in order to make sure that the reminding memory 
> accesses
 
^^^ remaining^^^  
> will
> +  * be aligned.
> +  */
> + memcpy_fromio(buf, priv->rsp, 8);
> +
> + expected = be32_to_cpup((__be32 *)[2]);
> + if (expected > count || expected < TPM_HEADER_SIZE)
>   return -EIO;
> 
> - memcpy_fromio([6], >rsp[6], expected - 6);
> + memcpy_fromio([8], >rsp[8], expected - 8);
> 
>   return expected;
>  }
> --
> 2.19.1

RE: [PATCH] tpm/tpm_crb: Avoid unaligned reads in crb_recv():

[Winkler, Tomas]

> 
> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read will fail and the
> memory controller will fill the read with 1's.
> 
> This was triggered by 170d13ca3a2f, which should be probably refined to check
> and react to the address alignment. Before that commit, on x86
> memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
> thing (from tpm_crb's perspective) for us so far, but we should not rely on 
> that.
> Thus, it makes sense to fix this also in tpm_crb, not least because the fix 
> can be
> then backported to stable kernels and make them more robust when compiled
> in differing environments.
> 
> Cc: sta...@vger.kernel.org
> Cc: Linus Torvalds 
> Cc: James Morris 
> Cc: Tomas Winkler 
> Cc: Jerry Snitselaar 
> Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
> Signed-off-by: Jarkko Sakkinen 
> ---
>  drivers/char/tpm/tpm_crb.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index
> 36952ef98f90..7f47e43aa9f1 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -288,18 +288,18 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
>   unsigned int expected;
> 
>   /* sanity check */
> - if (count < 6)
> + if (count < 8)
>   return -EIO;
Why don't you already enforce reading at least the whole TPM header 10bytes, we 
are reading the whole buffer at one call anyway.
Who every is asking for 8 bytes from the protocol level, is doing something 
wrong.

>   if (ioread32(>regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
>   return -EIO;
> 
> - memcpy_fromio(buf, priv->rsp, 6);
> + memcpy_fromio(buf, priv->rsp, 8);
Maybe a short comment will spare someone looking into git history 
>   expected = be32_to_cpup((__be32 *) [2]);
> - if (expected > count || expected < 6)
> + if (expected > count || expected < 8)
Expected should be at least tpm header, right?
>   return -EIO;
> 
> - memcpy_fromio([6], >rsp[6], expected - 6);
> + memcpy_fromio([8], >rsp[8], expected - 8);
> 
>   return expected;
>  }
Otherwise ready the first 8 bytes looks good. 
Thanks 
Tomas

RE: Getting weird TPM error after rebasing my tree to security/next-general

[Winkler, Tomas]

> -Original Message-
> From: Winkler, Tomas
> Sent: Thursday, January 31, 2019 21:47
> To: 'Linus Torvalds' ; Jarkko Sakkinen
> 
> Cc: Jason Gunthorpe ; James Bottomley
> ; linux-integr...@vger.kernel.org;
> linux-security-mod...@vger.kernel.org; Linux List Kernel Mailing  ker...@vger.kernel.org>
> Subject: RE: Getting weird TPM error after rebasing my tree to security/next-
> general
> 
> 
> >
> > On Thu, Jan 31, 2019 at 10:52 AM Linus Torvalds  > foundation.org> wrote:
> > >
> > > I think what I should do is to just make "memcpy_*io()" do the
> > > "align naturally" thing.
> > >
> > > Let me cook up a patch for you to test.
> >
> > Does this work for you?
> >
> > I haven't tested it at all, but I verified that the generated code
> > seems to make at least some amount of sense.
> >
> >Linus
> 
> So dig into the spec and I think this is a bit relevant.
> 
> TPM TCG according the spec requires that all buffer access is done 
> sequentially
> from the start to end of the payload, Simply In case of skipping or going back
> the transaction is aborted.
> The write transactions should be 1 or power of 2. So in general 6 byte read
> should not work. But I'm sure our hw really obey this restriction.

For alignment of register access the spec specifies:

Some instantiating hardware may have size and alignment restrictions when 
accessing any of the fields in this interface. Some hardware may require access 
to any of data within a field or buffer be performed by reads or writes which 
are naturally aligned. For this reason, software should access the fields and 
buffers defined in this interface using instructions which do not cause an 
access to cross an alignment boundary and should not use string move 
instructions

This is for register address, I'm not sure this spans also for request response 
buffer, but from the behavior looks like it applies there two.

 
Thanks
Tomas

RE: Getting weird TPM error after rebasing my tree to security/next-general

[Winkler, Tomas]

> 
> On Thu, Jan 31, 2019 at 10:52 AM Linus Torvalds  foundation.org> wrote:
> >
> > I think what I should do is to just make "memcpy_*io()" do the "align
> > naturally" thing.
> >
> > Let me cook up a patch for you to test.
> 
> Does this work for you?
> 
> I haven't tested it at all, but I verified that the generated code seems to 
> make
> at least some amount of sense.
> 
>Linus

So dig into the spec and I think this is a bit relevant. 

TPM TCG according the spec requires that all buffer access is done sequentially 
from the start to end of the payload, 
Simply In case of skipping or going back the transaction is aborted. 
The write transactions should be 1 or power of 2. So in general 6 byte read 
should not work. But I'm sure our hw really obey this restriction.

Thanks
Tomas 

RE: [PATCH] scsi: ufs: revamp string descriptor reading

[Winkler, Tomas]

> > Hello Tomas,
> >
> > >
> > > Define new a type: uc_string_id for easier string handling and less
> > > casting. Reduce number or string copies in price of a dynamic
> > > allocation.
> > >
> > > Signed-off-by: Tomas Winkler 
> > Tested-by: Avri Altman 
> >
> > Just one nit - doesn't really matters.
> >
> > Cheers,
> > Avri
> >
> > > ---
> > >  drivers/scsi/ufs/ufs-sysfs.c |  20 ++---
> > >  drivers/scsi/ufs/ufs.h   |   2 +-
> > >  drivers/scsi/ufs/ufshcd.c| 164 +--
> > >  drivers/scsi/ufs/ufshcd.h|   9 +-
> > >  4 files changed, 115 insertions(+), 80 deletions(-)
> >
> >
> > >
> > >   ufs_fixup_device_setup(hba, );
> > > + ufs_put_device_desc();
> > ufs_get_device_desc() and ufs_put_device_desc() actually serves the
> > quirks setup.
> > Make sense to call it from within so the logic is clear and in one place.
> > Might also save ufs_put_device_desc().
> 
> You are right from the current perspective , just I'd need it also for the 
> RPMB
> patches that should follow, then it will have bit larger span than the quirks.
> 

Is this okay, can we merge?
Thanks
Tomas

RE: [PATCH] scsi: ufs: revamp string descriptor reading

[Winkler, Tomas]

> -Original Message-
> From: Avri Altman [mailto:avri.alt...@wdc.com]
> Sent: Tuesday, December 11, 2018 18:18
> To: Winkler, Tomas ; James E . J . Bottomley
> ; Martin K . Petersen
> ; Vinayak Holikatti ;
> Hunter, Adrian 
> Cc: Christoph Hellwig ; Vivek Gautam
> ; Subhash Jadavani
> ; Alex Lemberg ; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] scsi: ufs: revamp string descriptor reading
> 
> Hello Tomas,
> 
> >
> > Define new a type: uc_string_id for easier string handling and less
> > casting. Reduce number or string copies in price of a dynamic
> > allocation.
> >
> > Signed-off-by: Tomas Winkler 
> Tested-by: Avri Altman 
> 
> Just one nit - doesn't really matters.
> 
> Cheers,
> Avri
> 
> > ---
> >  drivers/scsi/ufs/ufs-sysfs.c |  20 ++---
> >  drivers/scsi/ufs/ufs.h   |   2 +-
> >  drivers/scsi/ufs/ufshcd.c| 164 +--
> >  drivers/scsi/ufs/ufshcd.h|   9 +-
> >  4 files changed, 115 insertions(+), 80 deletions(-)
> 
> 
> >
> > ufs_fixup_device_setup(hba, );
> > +   ufs_put_device_desc();
> ufs_get_device_desc() and ufs_put_device_desc() actually serves the quirks
> setup.
> Make sense to call it from within so the logic is clear and in one place.
> Might also save ufs_put_device_desc().

You are right from the current perspective , just I'd need it also for the RPMB 
 patches that should follow,  
then it will have bit larger span than the quirks.

Thanks
Tomas
 
 

RE: [PATCH v9 04/17] tpm: print tpm2_commit_space() error inside tpm2_commit_space()

[Winkler, Tomas]

> 
> On Mon, Nov 19, 2018 at 09:25:22PM +, Winkler, Tomas wrote:
> >
> >
> > >
> > > The error logging for tpm2_commit_space() is in a wrong place. This
> > > commit moves it inside that function.
> > >
> > > Cc: James Bottomley 
> > > Signed-off-by: Jarkko Sakkinen 
> > > Reviewed-by: Stefan Berger 
> > > ---
> > >  drivers/char/tpm/tpm-interface.c | 2 --
> > >  drivers/char/tpm/tpm2-space.c| 9 ++---
> > >  2 files changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm-interface.c
> > > b/drivers/char/tpm/tpm- interface.c index 64510ed81b46..7ac6ada8428c
> > > 100644
> > > --- a/drivers/char/tpm/tpm-interface.c
> > > +++ b/drivers/char/tpm/tpm-interface.c
> > > @@ -277,8 +277,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> > > *chip,
> > >   }
> > >
> > >   rc = tpm2_commit_space(chip, space, ordinal, buf, );
> > > - if (rc)
> > > - dev_err(>dev, "tpm2_commit_space: error %d\n", rc);
> > >
> > >  out:
> > >   /* may fail but do not override previous error value in rc */ diff
> > > --git a/drivers/char/tpm/tpm2-space.c
> > > b/drivers/char/tpm/tpm2-space.c index 1131a8e7b79b..5ecc73988f7c
> > > 100644
> > > --- a/drivers/char/tpm/tpm2-space.c
> > > +++ b/drivers/char/tpm/tpm2-space.c
> > > @@ -501,19 +501,19 @@ int tpm2_commit_space(struct tpm_chip *chip,
> > > struct tpm_space *space,
> > >   rc = tpm2_map_response_header(chip, cc, buf, *bufsiz);
> > >   if (rc) {
> > >   tpm2_flush_space(chip);
> > > - return rc;
> > > + goto out;
> > >   }
> > >
> > >   rc = tpm2_map_response_body(chip, cc, buf, *bufsiz);
> > >   if (rc) {
> > >   tpm2_flush_space(chip);
> > > - return rc;
> > > + goto out;
> > >   }
> > >
> > >   rc = tpm2_save_space(chip);
> > >   if (rc) {
> > >   tpm2_flush_space(chip);
> > > - return rc;
> > > + goto out;
> > >   }
> > >
> > >   *bufsiz = be32_to_cpu(header->length); @@ -526,4 +526,7 @@ int
> > > tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
> > >   memcpy(space->session_buf, chip->work_space.session_buf,
> > > PAGE_SIZE);
> > >
> > >   return 0;
> > > +out:
> > Maybe 'out' is too positive name for an error-only exit point?
> > or you can use if (rc) ... dev_err()
> 
> out_err?
out_err is good, it is used in more places, so it has some of consistency.
Thanks
Tomas



> 
> /Jarkko

RE: [PATCH v9 04/17] tpm: print tpm2_commit_space() error inside tpm2_commit_space()

[Winkler, Tomas]

> 
> On Mon, Nov 19, 2018 at 09:25:22PM +, Winkler, Tomas wrote:
> >
> >
> > >
> > > The error logging for tpm2_commit_space() is in a wrong place. This
> > > commit moves it inside that function.
> > >
> > > Cc: James Bottomley 
> > > Signed-off-by: Jarkko Sakkinen 
> > > Reviewed-by: Stefan Berger 
> > > ---
> > >  drivers/char/tpm/tpm-interface.c | 2 --
> > >  drivers/char/tpm/tpm2-space.c| 9 ++---
> > >  2 files changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm-interface.c
> > > b/drivers/char/tpm/tpm- interface.c index 64510ed81b46..7ac6ada8428c
> > > 100644
> > > --- a/drivers/char/tpm/tpm-interface.c
> > > +++ b/drivers/char/tpm/tpm-interface.c
> > > @@ -277,8 +277,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> > > *chip,
> > >   }
> > >
> > >   rc = tpm2_commit_space(chip, space, ordinal, buf, );
> > > - if (rc)
> > > - dev_err(>dev, "tpm2_commit_space: error %d\n", rc);
> > >
> > >  out:
> > >   /* may fail but do not override previous error value in rc */ diff
> > > --git a/drivers/char/tpm/tpm2-space.c
> > > b/drivers/char/tpm/tpm2-space.c index 1131a8e7b79b..5ecc73988f7c
> > > 100644
> > > --- a/drivers/char/tpm/tpm2-space.c
> > > +++ b/drivers/char/tpm/tpm2-space.c
> > > @@ -501,19 +501,19 @@ int tpm2_commit_space(struct tpm_chip *chip,
> > > struct tpm_space *space,
> > >   rc = tpm2_map_response_header(chip, cc, buf, *bufsiz);
> > >   if (rc) {
> > >   tpm2_flush_space(chip);
> > > - return rc;
> > > + goto out;
> > >   }
> > >
> > >   rc = tpm2_map_response_body(chip, cc, buf, *bufsiz);
> > >   if (rc) {
> > >   tpm2_flush_space(chip);
> > > - return rc;
> > > + goto out;
> > >   }
> > >
> > >   rc = tpm2_save_space(chip);
> > >   if (rc) {
> > >   tpm2_flush_space(chip);
> > > - return rc;
> > > + goto out;
> > >   }
> > >
> > >   *bufsiz = be32_to_cpu(header->length); @@ -526,4 +526,7 @@ int
> > > tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
> > >   memcpy(space->session_buf, chip->work_space.session_buf,
> > > PAGE_SIZE);
> > >
> > >   return 0;
> > > +out:
> > Maybe 'out' is too positive name for an error-only exit point?
> > or you can use if (rc) ... dev_err()
> 
> out_err?
out_err is good, it is used in more places, so it has some of consistency.
Thanks
Tomas



> 
> /Jarkko

RE: [PATCH v9 05/17] tpm: declare struct tpm_header

[Winkler, Tomas]

> 
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo 
> struct tpm_output_header.
> 
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Stefan Berger 
> ---
>  drivers/char/tpm/tpm-interface.c  |  9 -
>  drivers/char/tpm/tpm.h| 27 ---
>  drivers/char/tpm/tpm2-cmd.c   |  4 ++--
>  drivers/char/tpm/tpm2-space.c |  6 +++---
>  drivers/char/tpm/tpm_i2c_atmel.c  |  5 ++---
> drivers/char/tpm/tpm_vtpm_proxy.c |  8 
>  drivers/char/tpm/xen-tpmfront.c   |  2 +-
>  7 files changed, 28 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 7ac6ada8428c..cb0d44c158ae 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -67,7 +67,7 @@ static int tpm_validate_command(struct tpm_chip
> *chip,
>const u8 *cmd,
>size_t len)
>  {
> - const struct tpm_input_header *header = (const void *)cmd;
> + const struct tpm_header *header = (const void *)cmd;


Sometimes it is casted (void *), sometimes (struct tpm_header *)
Better to use one convention 

>   int i;
>   u32 cc;
>   u32 attrs;
> @@ -166,7 +166,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   u8 *buf, size_t bufsiz,
>   unsigned int flags)
>  {
> - struct tpm_output_header *header = (void *)buf;
> + struct tpm_header *header = (void *)buf;
>   int rc;
>   ssize_t len = 0;
>   u32 count, ordinal;
> @@ -316,7 +316,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,  ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
>u8 *buf, size_t bufsiz, unsigned int flags)  {
> - struct tpm_output_header *header = (struct tpm_output_header
> *)buf;
> + struct tpm_header *header = (struct tpm_header *)buf;
>   /* space for header and handles */
>   u8 save[TPM_HEADER_SIZE + 3*sizeof(u32)];
>   unsigned int delay_msec = TPM2_DURATION_SHORT; @@ -381,8
> +381,7 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
> tpm_space *space,
>struct tpm_buf *buf, size_t min_rsp_body_length,
>unsigned int flags, const char *desc)  {
> - const struct tpm_output_header *header =
> - (struct tpm_output_header *)buf->data;
> + const struct tpm_header *header = (struct tpm_header *)buf->data;
>   int err;
>   ssize_t len;
> 
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> 49bca4d1e786..86fa8ac0ae20 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -273,16 +273,13 @@ struct tpm_chip {
> 
>  #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev)
> 
> -struct tpm_input_header {
> - __be16  tag;
> - __be32  length;
> - __be32  ordinal;
> -} __packed;
> -
> -struct tpm_output_header {
> - __be16  tag;
> - __be32  length;
> - __be32  return_code;
> +struct tpm_header {
Does it deserve kdoc? 
> + __be16 tag;
> + __be32 length;
> + union {
> + __be32 ordinal;
> + __be32 return_code;
> + };
>  } __packed;
> 
>  #define TPM_TAG_RQU_COMMAND 193
> @@ -401,8 +398,8 @@ struct tpm_buf {
> 
>  static inline void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal)  
> {
> - struct tpm_input_header *head;
> - head = (struct tpm_input_header *)buf->data;
> + struct tpm_header *head = (struct tpm_header *)buf->data;
> +
>   head->tag = cpu_to_be16(tag);
>   head->length = cpu_to_be32(sizeof(*head));
>   head->ordinal = cpu_to_be32(ordinal);
> @@ -428,14 +425,14 @@ static inline void tpm_buf_destroy(struct tpm_buf
> *buf)
> 
>  static inline u32 tpm_buf_length(struct tpm_buf *buf)  {
> - struct tpm_input_header *head = (struct tpm_input_header *) buf-
> >data;
No blank after ) in casting. 

> + struct tpm_header *head = (struct tpm_header *) buf->data;
> 
>   return be32_to_cpu(head->length);
>  }
> 
>  static inline u16 tpm_buf_tag(struct tpm_buf *buf)  {
> - struct tpm_input_header *head = (struct tpm_input_header *) buf-
> >data;
> + struct tpm_header *head = (struct tpm_header *) buf->data;
> 
>   return be16_to_cpu(head->tag);
>  }
> @@ -444,7 +441,7 @@ static inline void tpm_buf_append(struct tpm_buf
> *buf,
> const unsigned char *new_data,
> unsigned int new_len)
>  {
> - struct tpm_input_header *head = (struct tpm_input_header *) buf-
> >data;
> + struct tpm_header *head = (struct tpm_header *) buf->data;
No blank after ) in casting.
>   u32 len = tpm_buf_length(buf);
> 
>   /* Return silently if overflow has already happened. */ diff --git
> a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index
> 2bcf470c8e5d..ab03f8600f89 100644
> --- 

RE: [PATCH v9 05/17] tpm: declare struct tpm_header

[Winkler, Tomas]

> 
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo 
> struct tpm_output_header.
> 
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Stefan Berger 
> ---
>  drivers/char/tpm/tpm-interface.c  |  9 -
>  drivers/char/tpm/tpm.h| 27 ---
>  drivers/char/tpm/tpm2-cmd.c   |  4 ++--
>  drivers/char/tpm/tpm2-space.c |  6 +++---
>  drivers/char/tpm/tpm_i2c_atmel.c  |  5 ++---
> drivers/char/tpm/tpm_vtpm_proxy.c |  8 
>  drivers/char/tpm/xen-tpmfront.c   |  2 +-
>  7 files changed, 28 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 7ac6ada8428c..cb0d44c158ae 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -67,7 +67,7 @@ static int tpm_validate_command(struct tpm_chip
> *chip,
>const u8 *cmd,
>size_t len)
>  {
> - const struct tpm_input_header *header = (const void *)cmd;
> + const struct tpm_header *header = (const void *)cmd;


Sometimes it is casted (void *), sometimes (struct tpm_header *)
Better to use one convention 

>   int i;
>   u32 cc;
>   u32 attrs;
> @@ -166,7 +166,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   u8 *buf, size_t bufsiz,
>   unsigned int flags)
>  {
> - struct tpm_output_header *header = (void *)buf;
> + struct tpm_header *header = (void *)buf;
>   int rc;
>   ssize_t len = 0;
>   u32 count, ordinal;
> @@ -316,7 +316,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,  ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
>u8 *buf, size_t bufsiz, unsigned int flags)  {
> - struct tpm_output_header *header = (struct tpm_output_header
> *)buf;
> + struct tpm_header *header = (struct tpm_header *)buf;
>   /* space for header and handles */
>   u8 save[TPM_HEADER_SIZE + 3*sizeof(u32)];
>   unsigned int delay_msec = TPM2_DURATION_SHORT; @@ -381,8
> +381,7 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
> tpm_space *space,
>struct tpm_buf *buf, size_t min_rsp_body_length,
>unsigned int flags, const char *desc)  {
> - const struct tpm_output_header *header =
> - (struct tpm_output_header *)buf->data;
> + const struct tpm_header *header = (struct tpm_header *)buf->data;
>   int err;
>   ssize_t len;
> 
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> 49bca4d1e786..86fa8ac0ae20 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -273,16 +273,13 @@ struct tpm_chip {
> 
>  #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev)
> 
> -struct tpm_input_header {
> - __be16  tag;
> - __be32  length;
> - __be32  ordinal;
> -} __packed;
> -
> -struct tpm_output_header {
> - __be16  tag;
> - __be32  length;
> - __be32  return_code;
> +struct tpm_header {
Does it deserve kdoc? 
> + __be16 tag;
> + __be32 length;
> + union {
> + __be32 ordinal;
> + __be32 return_code;
> + };
>  } __packed;
> 
>  #define TPM_TAG_RQU_COMMAND 193
> @@ -401,8 +398,8 @@ struct tpm_buf {
> 
>  static inline void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal)  
> {
> - struct tpm_input_header *head;
> - head = (struct tpm_input_header *)buf->data;
> + struct tpm_header *head = (struct tpm_header *)buf->data;
> +
>   head->tag = cpu_to_be16(tag);
>   head->length = cpu_to_be32(sizeof(*head));
>   head->ordinal = cpu_to_be32(ordinal);
> @@ -428,14 +425,14 @@ static inline void tpm_buf_destroy(struct tpm_buf
> *buf)
> 
>  static inline u32 tpm_buf_length(struct tpm_buf *buf)  {
> - struct tpm_input_header *head = (struct tpm_input_header *) buf-
> >data;
No blank after ) in casting. 

> + struct tpm_header *head = (struct tpm_header *) buf->data;
> 
>   return be32_to_cpu(head->length);
>  }
> 
>  static inline u16 tpm_buf_tag(struct tpm_buf *buf)  {
> - struct tpm_input_header *head = (struct tpm_input_header *) buf-
> >data;
> + struct tpm_header *head = (struct tpm_header *) buf->data;
> 
>   return be16_to_cpu(head->tag);
>  }
> @@ -444,7 +441,7 @@ static inline void tpm_buf_append(struct tpm_buf
> *buf,
> const unsigned char *new_data,
> unsigned int new_len)
>  {
> - struct tpm_input_header *head = (struct tpm_input_header *) buf-
> >data;
> + struct tpm_header *head = (struct tpm_header *) buf->data;
No blank after ) in casting.
>   u32 len = tpm_buf_length(buf);
> 
>   /* Return silently if overflow has already happened. */ diff --git
> a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index
> 2bcf470c8e5d..ab03f8600f89 100644
> --- 

RE: [PATCH v9 04/17] tpm: print tpm2_commit_space() error inside tpm2_commit_space()

[Winkler, Tomas]

> 
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
> 
> Cc: James Bottomley 
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Stefan Berger 
> ---
>  drivers/char/tpm/tpm-interface.c | 2 --
>  drivers/char/tpm/tpm2-space.c| 9 ++---
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 64510ed81b46..7ac6ada8428c 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -277,8 +277,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   }
> 
>   rc = tpm2_commit_space(chip, space, ordinal, buf, );
> - if (rc)
> - dev_err(>dev, "tpm2_commit_space: error %d\n", rc);
> 
>  out:
>   /* may fail but do not override previous error value in rc */ diff --git
> a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c index
> 1131a8e7b79b..5ecc73988f7c 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -501,19 +501,19 @@ int tpm2_commit_space(struct tpm_chip *chip,
> struct tpm_space *space,
>   rc = tpm2_map_response_header(chip, cc, buf, *bufsiz);
>   if (rc) {
>   tpm2_flush_space(chip);
> - return rc;
> + goto out;
>   }
> 
>   rc = tpm2_map_response_body(chip, cc, buf, *bufsiz);
>   if (rc) {
>   tpm2_flush_space(chip);
> - return rc;
> + goto out;
>   }
> 
>   rc = tpm2_save_space(chip);
>   if (rc) {
>   tpm2_flush_space(chip);
> - return rc;
> + goto out;
>   }
> 
>   *bufsiz = be32_to_cpu(header->length); @@ -526,4 +526,7 @@ int
> tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
>   memcpy(space->session_buf, chip->work_space.session_buf,
> PAGE_SIZE);
> 
>   return 0;
> +out:
Maybe 'out' is too positive name for an error-only exit point? 
or you can use if (rc) ... dev_err()
> + dev_err(>dev, "%s: error %d\n", __func__, rc);
> + return rc;
>  }
> --
> 2.19.1

RE: [PATCH v9 04/17] tpm: print tpm2_commit_space() error inside tpm2_commit_space()

[Winkler, Tomas]

> 
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
> 
> Cc: James Bottomley 
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Stefan Berger 
> ---
>  drivers/char/tpm/tpm-interface.c | 2 --
>  drivers/char/tpm/tpm2-space.c| 9 ++---
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 64510ed81b46..7ac6ada8428c 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -277,8 +277,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   }
> 
>   rc = tpm2_commit_space(chip, space, ordinal, buf, );
> - if (rc)
> - dev_err(>dev, "tpm2_commit_space: error %d\n", rc);
> 
>  out:
>   /* may fail but do not override previous error value in rc */ diff --git
> a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c index
> 1131a8e7b79b..5ecc73988f7c 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -501,19 +501,19 @@ int tpm2_commit_space(struct tpm_chip *chip,
> struct tpm_space *space,
>   rc = tpm2_map_response_header(chip, cc, buf, *bufsiz);
>   if (rc) {
>   tpm2_flush_space(chip);
> - return rc;
> + goto out;
>   }
> 
>   rc = tpm2_map_response_body(chip, cc, buf, *bufsiz);
>   if (rc) {
>   tpm2_flush_space(chip);
> - return rc;
> + goto out;
>   }
> 
>   rc = tpm2_save_space(chip);
>   if (rc) {
>   tpm2_flush_space(chip);
> - return rc;
> + goto out;
>   }
> 
>   *bufsiz = be32_to_cpu(header->length); @@ -526,4 +526,7 @@ int
> tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
>   memcpy(space->session_buf, chip->work_space.session_buf,
> PAGE_SIZE);
> 
>   return 0;
> +out:
Maybe 'out' is too positive name for an error-only exit point? 
or you can use if (rc) ... dev_err()
> + dev_err(>dev, "%s: error %d\n", __func__, rc);
> + return rc;
>  }
> --
> 2.19.1

RE: [PATCH v9 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> 
> On Sun, Nov 18, 2018 at 10:52:46PM +, Winkler, Tomas wrote:
> > This is still NACK from my side
> 
> Last time you spoke about tboot intervention but I don't see why as even
> sending a single command is not atomic in the true sense of the word i.e. if
> there was a problem that would already affect the existing code and would
> essentially mean that tboot itself is broken.
So I've consulted the issue, I wasn't not correct in the description. Tboot 
cannot acquire  the locality, unless the host driver relinquish it,
so the issue is opposite, driver is expected to relinquish the locality for 
tboot to work correctly. This is current status, other behavior will need a 
different implementation on both sides. 

Hopes that clears the question.

Thanks

RE: [PATCH v9 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> 
> On Sun, Nov 18, 2018 at 10:52:46PM +, Winkler, Tomas wrote:
> > This is still NACK from my side
> 
> Last time you spoke about tboot intervention but I don't see why as even
> sending a single command is not atomic in the true sense of the word i.e. if
> there was a problem that would already affect the existing code and would
> essentially mean that tboot itself is broken.
So I've consulted the issue, I wasn't not correct in the description. Tboot 
cannot acquire  the locality, unless the host driver relinquish it,
so the issue is opposite, driver is expected to relinquish the locality for 
tboot to work correctly. This is current status, other behavior will need a 
different implementation on both sides. 

Hopes that clears the question.

Thanks

RE: [PATCH v9 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> 
> Call tpm_chip_start() and tpm_chip_stop() in
> 
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
> 
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
> (a command made up just for that driver).
> 
> The consequence of this is that this commit removes the remaining nested
> calls.
> 
> Signed-off-by: Jarkko Sakkinen 

This is still NACK from my side
Tomas

> ---
>  drivers/char/tpm/tpm-chip.c   | 25 -
>  drivers/char/tpm/tpm-interface.c  |  4 
>  drivers/char/tpm/tpm.h|  9 -
>  drivers/char/tpm/tpm2-space.c |  5 -
>  drivers/char/tpm/tpm_vtpm_proxy.c |  3 +--
>  5 files changed, 17 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index
> 65f1561eba81..7ad4d9045e4c 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -41,9 +41,6 @@ static int tpm_request_locality(struct tpm_chip *chip,
> unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->request_locality)
>   return 0;
> 
> @@ -59,9 +56,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return;
> -
>   if (!chip->ops->relinquish_locality)
>   return;
> 
> @@ -74,9 +68,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)
> 
>  static int tpm_cmd_ready(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->cmd_ready)
>   return 0;
> 
> @@ -85,9 +76,6 @@ static int tpm_cmd_ready(struct tpm_chip *chip,
> unsigned int flags)
> 
>  static int tpm_go_idle(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->go_idle)
>   return 0;
> 
> @@ -166,11 +154,17 @@ int tpm_try_get_ops(struct tpm_chip *chip)
> 
>   down_read(>ops_sem);
>   if (!chip->ops)
> - goto out_lock;
> + goto out_ops;
> 
>   mutex_lock(>tpm_mutex);
> + rc = tpm_chip_start(chip, 0);
> + if (rc)
> + goto out_lock;
> +
>   return 0;
>  out_lock:
> + mutex_unlock(>tpm_mutex);
> +out_ops:
>   up_read(>ops_sem);
>   put_device(>dev);
>   return rc;
> @@ -186,6 +180,7 @@ EXPORT_SYMBOL_GPL(tpm_try_get_ops);
>   */
>  void tpm_put_ops(struct tpm_chip *chip)  {
> + tpm_chip_stop(chip, 0);
>   mutex_unlock(>tpm_mutex);
>   up_read(>ops_sem);
>   put_device(>dev);
> @@ -563,7 +558,11 @@ int tpm_chip_register(struct tpm_chip *chip)  {
>   int rc;
> 
> + rc = tpm_chip_start(chip, 0);
> + if (rc)
> + return rc;
>   rc = tpm_auto_startup(chip);
> + tpm_chip_stop(chip, 0);
>   if (rc)
>   return rc;
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 2c79284ffd4e..21ac8da94d90 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -168,11 +168,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, u8
> *buf, size_t bufsiz,
>   memcpy(save, buf, save_size);
> 
>   for (;;) {
> - ret = tpm_chip_start(chip, flags);
> - if (ret)
> - return ret;
>   ret = tpm_try_transmit(chip, buf, bufsiz, flags);
> - tpm_chip_stop(chip, flags);
>   if (ret < 0)
>   break;
>   rc = be32_to_cpu(header->return_code); diff --git
> a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> c42a75710b70..f9d56dfd0d20 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -485,15 +485,6 @@ extern const struct file_operations tpm_fops;
> extern const struct file_operations tpmrm_fops;  extern struct idr
> dev_nums_idr;
> 
> -/**
> - * enum tpm_transmit_flags - flags for tpm_transmit()
> - *
> - * %TPM_TRANSMIT_NESTED: discard setup steps (power management,
> locality)
> - */
> -enum tpm_transmit_flags {
> - TPM_TRANSMIT_NESTED  = BIT(0),
> -};
> -
>  ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
>unsigned int flags);
>  ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf, diff -
> -git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index ced1dc91ba6f..d913715d30aa 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -60,7 +60,10 @@ int tpm2_init_space(struct tpm_space *space)  void
> tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space)  {
>   mutex_lock(>tpm_mutex);
> - tpm2_flush_sessions(chip, space);
> + if 

RE: [PATCH v9 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> 
> Call tpm_chip_start() and tpm_chip_stop() in
> 
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
> 
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
> (a command made up just for that driver).
> 
> The consequence of this is that this commit removes the remaining nested
> calls.
> 
> Signed-off-by: Jarkko Sakkinen 

This is still NACK from my side
Tomas

> ---
>  drivers/char/tpm/tpm-chip.c   | 25 -
>  drivers/char/tpm/tpm-interface.c  |  4 
>  drivers/char/tpm/tpm.h|  9 -
>  drivers/char/tpm/tpm2-space.c |  5 -
>  drivers/char/tpm/tpm_vtpm_proxy.c |  3 +--
>  5 files changed, 17 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index
> 65f1561eba81..7ad4d9045e4c 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -41,9 +41,6 @@ static int tpm_request_locality(struct tpm_chip *chip,
> unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->request_locality)
>   return 0;
> 
> @@ -59,9 +56,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return;
> -
>   if (!chip->ops->relinquish_locality)
>   return;
> 
> @@ -74,9 +68,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)
> 
>  static int tpm_cmd_ready(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->cmd_ready)
>   return 0;
> 
> @@ -85,9 +76,6 @@ static int tpm_cmd_ready(struct tpm_chip *chip,
> unsigned int flags)
> 
>  static int tpm_go_idle(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->go_idle)
>   return 0;
> 
> @@ -166,11 +154,17 @@ int tpm_try_get_ops(struct tpm_chip *chip)
> 
>   down_read(>ops_sem);
>   if (!chip->ops)
> - goto out_lock;
> + goto out_ops;
> 
>   mutex_lock(>tpm_mutex);
> + rc = tpm_chip_start(chip, 0);
> + if (rc)
> + goto out_lock;
> +
>   return 0;
>  out_lock:
> + mutex_unlock(>tpm_mutex);
> +out_ops:
>   up_read(>ops_sem);
>   put_device(>dev);
>   return rc;
> @@ -186,6 +180,7 @@ EXPORT_SYMBOL_GPL(tpm_try_get_ops);
>   */
>  void tpm_put_ops(struct tpm_chip *chip)  {
> + tpm_chip_stop(chip, 0);
>   mutex_unlock(>tpm_mutex);
>   up_read(>ops_sem);
>   put_device(>dev);
> @@ -563,7 +558,11 @@ int tpm_chip_register(struct tpm_chip *chip)  {
>   int rc;
> 
> + rc = tpm_chip_start(chip, 0);
> + if (rc)
> + return rc;
>   rc = tpm_auto_startup(chip);
> + tpm_chip_stop(chip, 0);
>   if (rc)
>   return rc;
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 2c79284ffd4e..21ac8da94d90 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -168,11 +168,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, u8
> *buf, size_t bufsiz,
>   memcpy(save, buf, save_size);
> 
>   for (;;) {
> - ret = tpm_chip_start(chip, flags);
> - if (ret)
> - return ret;
>   ret = tpm_try_transmit(chip, buf, bufsiz, flags);
> - tpm_chip_stop(chip, flags);
>   if (ret < 0)
>   break;
>   rc = be32_to_cpu(header->return_code); diff --git
> a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> c42a75710b70..f9d56dfd0d20 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -485,15 +485,6 @@ extern const struct file_operations tpm_fops;
> extern const struct file_operations tpmrm_fops;  extern struct idr
> dev_nums_idr;
> 
> -/**
> - * enum tpm_transmit_flags - flags for tpm_transmit()
> - *
> - * %TPM_TRANSMIT_NESTED: discard setup steps (power management,
> locality)
> - */
> -enum tpm_transmit_flags {
> - TPM_TRANSMIT_NESTED  = BIT(0),
> -};
> -
>  ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
>unsigned int flags);
>  ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf, diff -
> -git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index ced1dc91ba6f..d913715d30aa 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -60,7 +60,10 @@ int tpm2_init_space(struct tpm_space *space)  void
> tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space)  {
>   mutex_lock(>tpm_mutex);
> - tpm2_flush_sessions(chip, space);
> + if 

RE: [PATCH v6 00/17] Removed nested TPM operations

[Winkler, Tomas]

> 
> [was Detach TPM space code out of the tpm_transmit() flow but the scope
> expanded a bit.]

I believe you making this series artificially large we can merge the first 4 
patches and leave the rest for further discussion.

Thanks
Tomas

RE: [PATCH v6 00/17] Removed nested TPM operations

[Winkler, Tomas]

> 
> [was Detach TPM space code out of the tpm_transmit() flow but the scope
> expanded a bit.]

I believe you making this series artificially large we can merge the first 4 
patches and leave the rest for further discussion.

Thanks
Tomas

RE: [PATCH v5 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 13, 2018 13:12
> To: Winkler, Tomas 
> Cc: linux-integr...@vger.kernel.org; linux-security-mod...@vger.kernel.org;
> James Bottomley ; Struk,
> Tadeusz ; Stefan Berger
> ; Nayna Jain ; Peter
> Huewe ; Jason Gunthorpe ; Arnd
> Bergmann ; Greg Kroah-Hartman
> ; open list 
> Subject: Re: [PATCH v5 16/17] tpm: take TPM chip power gating out of
> tpm_transmit()
> 
> On Fri, Nov 09, 2018 at 09:37:48PM +, Winkler, Tomas wrote:
> > > On Thu, Nov 08, 2018 at 06:38:59PM +, Winkler, Tomas wrote:
> > > > > Call tpm_chip_start() and tpm_chip_stop() in
> > > > >
> > > > > * tpm_try_get_ops() and tpm_put_ops()
> > > > > * tpm_chip_register()
> > > > > * tpm2_del_space()
> > > > >
> > > > > And remove these calls from tpm_transmit(). The core reason for
> > > > > this change is that in tpm_vtpm_proxy a locality change requires
> > > > > a virtual TPM command (a command made up just for that driver).
> > > > >
> > > > I don't think you can do that,  locality has to be request for
> > > > each command, as  for example tboot can request higher locality any
> time.
> > >
> > > That could be a potential problem. How tboot intervention gets
> > > prevented without this patch?
> > As it was said, need to request locality and relinquish it for each
> > command, I believe thought this is not required for client platforms
> > only for servers.
> 
> And what I'm trying to under is why so.
> 
> If the intervention can happen at any time that would imply that even if you
> would request and relinquish locality for a single TPM command, the
> intervention could happen in the middle. That is why I'm asking why without
> this patch things are just fine.
Yes, w/o this constrain it would be okay to request locality only once, 
we can ask tboot ask again but at the time the requirement was that locality 
can be taken of at any point, 
I believe that the locality won't be granted till a single command is completed.

Anyhow still the power gating is wrong in this patch do not ignore that part.

Thanks
Tomas

RE: [PATCH v5 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 13, 2018 13:12
> To: Winkler, Tomas 
> Cc: linux-integr...@vger.kernel.org; linux-security-mod...@vger.kernel.org;
> James Bottomley ; Struk,
> Tadeusz ; Stefan Berger
> ; Nayna Jain ; Peter
> Huewe ; Jason Gunthorpe ; Arnd
> Bergmann ; Greg Kroah-Hartman
> ; open list 
> Subject: Re: [PATCH v5 16/17] tpm: take TPM chip power gating out of
> tpm_transmit()
> 
> On Fri, Nov 09, 2018 at 09:37:48PM +, Winkler, Tomas wrote:
> > > On Thu, Nov 08, 2018 at 06:38:59PM +, Winkler, Tomas wrote:
> > > > > Call tpm_chip_start() and tpm_chip_stop() in
> > > > >
> > > > > * tpm_try_get_ops() and tpm_put_ops()
> > > > > * tpm_chip_register()
> > > > > * tpm2_del_space()
> > > > >
> > > > > And remove these calls from tpm_transmit(). The core reason for
> > > > > this change is that in tpm_vtpm_proxy a locality change requires
> > > > > a virtual TPM command (a command made up just for that driver).
> > > > >
> > > > I don't think you can do that,  locality has to be request for
> > > > each command, as  for example tboot can request higher locality any
> time.
> > >
> > > That could be a potential problem. How tboot intervention gets
> > > prevented without this patch?
> > As it was said, need to request locality and relinquish it for each
> > command, I believe thought this is not required for client platforms
> > only for servers.
> 
> And what I'm trying to under is why so.
> 
> If the intervention can happen at any time that would imply that even if you
> would request and relinquish locality for a single TPM command, the
> intervention could happen in the middle. That is why I'm asking why without
> this patch things are just fine.
Yes, w/o this constrain it would be okay to request locality only once, 
we can ask tboot ask again but at the time the requirement was that locality 
can be taken of at any point, 
I believe that the locality won't be granted till a single command is completed.

Anyhow still the power gating is wrong in this patch do not ignore that part.

Thanks
Tomas

RE: [PATCH v5 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> 
> On Thu, Nov 08, 2018 at 06:38:59PM +, Winkler, Tomas wrote:
> > > Call tpm_chip_start() and tpm_chip_stop() in
> > >
> > > * tpm_try_get_ops() and tpm_put_ops()
> > > * tpm_chip_register()
> > > * tpm2_del_space()
> > >
> > > And remove these calls from tpm_transmit(). The core reason for this
> > > change is that in tpm_vtpm_proxy a locality change requires a
> > > virtual TPM command (a command made up just for that driver).
> > >
> > I don't think you can do that,  locality has to be request for each
> > command, as  for example tboot can request higher locality any time.
> 
> That could be a potential problem. How tboot intervention gets prevented
> without this patch?
As it was said, need to request locality and relinquish it for each command, I 
believe thought this is not required for client platforms only for servers. 
> 
> > Same for cmd_ready()/go_idle() powergatin, you will prevent the whole
> > platform entering power save state.
> 
> Why would you want that in a middle of using the TPM anyway?
If I'm reading this patch correctly you do cmd_ready when tpm is opened, it 
doesn't mean there is a real traffic, so why to keep it awake. 
Thanks
Tomas

RE: [PATCH v5 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> 
> On Thu, Nov 08, 2018 at 06:38:59PM +, Winkler, Tomas wrote:
> > > Call tpm_chip_start() and tpm_chip_stop() in
> > >
> > > * tpm_try_get_ops() and tpm_put_ops()
> > > * tpm_chip_register()
> > > * tpm2_del_space()
> > >
> > > And remove these calls from tpm_transmit(). The core reason for this
> > > change is that in tpm_vtpm_proxy a locality change requires a
> > > virtual TPM command (a command made up just for that driver).
> > >
> > I don't think you can do that,  locality has to be request for each
> > command, as  for example tboot can request higher locality any time.
> 
> That could be a potential problem. How tboot intervention gets prevented
> without this patch?
As it was said, need to request locality and relinquish it for each command, I 
believe thought this is not required for client platforms only for servers. 
> 
> > Same for cmd_ready()/go_idle() powergatin, you will prevent the whole
> > platform entering power save state.
> 
> Why would you want that in a middle of using the TPM anyway?
If I'm reading this patch correctly you do cmd_ready when tpm is opened, it 
doesn't mean there is a real traffic, so why to keep it awake. 
Thanks
Tomas

RE: [PATCH v5 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> Call tpm_chip_start() and tpm_chip_stop() in
> 
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
> 
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
> (a command made up just for that driver).
> 
I don't think you can do that,  locality has to be request for each command, as 
 for example tboot can request higher locality any time. 
Same for cmd_ready()/go_idle() powergatin, you will prevent the whole platform 
entering power save state.
Thanks
Tomas



> The consequence of this is that this commit removes the remaining nested
> calls.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  drivers/char/tpm/tpm-chip.c   | 19 ++-
>  drivers/char/tpm/tpm-interface.c  |  4 
>  drivers/char/tpm/tpm.h|  9 -
>  drivers/char/tpm/tpm2-space.c |  5 -
>  drivers/char/tpm/tpm_vtpm_proxy.c |  3 +--
>  5 files changed, 11 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index
> 65f1561eba81..87570182f75e 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -41,9 +41,6 @@ static int tpm_request_locality(struct tpm_chip *chip,
> unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->request_locality)
>   return 0;
> 
> @@ -59,9 +56,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return;
> -
>   if (!chip->ops->relinquish_locality)
>   return;
> 
> @@ -74,9 +68,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)
> 
>  static int tpm_cmd_ready(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->cmd_ready)
>   return 0;
> 
> @@ -85,9 +76,6 @@ static int tpm_cmd_ready(struct tpm_chip *chip,
> unsigned int flags)
> 
>  static int tpm_go_idle(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->go_idle)
>   return 0;
> 
> @@ -169,7 +157,7 @@ int tpm_try_get_ops(struct tpm_chip *chip)
>   goto out_lock;
> 
>   mutex_lock(>tpm_mutex);
> - return 0;
> + return tpm_chip_start(chip, 0);
>  out_lock:
>   up_read(>ops_sem);
>   put_device(>dev);
> @@ -186,6 +174,7 @@ EXPORT_SYMBOL_GPL(tpm_try_get_ops);
>   */
>  void tpm_put_ops(struct tpm_chip *chip)  {
> + tpm_chip_stop(chip, 0);
>   mutex_unlock(>tpm_mutex);
>   up_read(>ops_sem);
>   put_device(>dev);
> @@ -563,7 +552,11 @@ int tpm_chip_register(struct tpm_chip *chip)  {
>   int rc;
> 
> + rc = tpm_chip_start(chip, 0);
> + if (rc)
> + return rc;
>   rc = tpm_auto_startup(chip);
> + tpm_chip_stop(chip, 0);
>   if (rc)
>   return rc;
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 888c9923fca1..5c04c0d9aaba 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -168,11 +168,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, u8
> *buf, size_t bufsiz,
>   memcpy(save, buf, save_size);
> 
>   for (;;) {
> - ret = tpm_chip_start(chip, flags);
> - if (ret)
> - return ret;
>   ret = tpm_try_transmit(chip, buf, bufsiz, flags);
> - tpm_chip_stop(chip, flags);
> 
>   rc = be32_to_cpu(header->return_code);
>   if (rc != TPM2_RC_RETRY && rc != TPM2_RC_TESTING) diff --
> git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> c42a75710b70..f9d56dfd0d20 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -485,15 +485,6 @@ extern const struct file_operations tpm_fops;
> extern const struct file_operations tpmrm_fops;  extern struct idr
> dev_nums_idr;
> 
> -/**
> - * enum tpm_transmit_flags - flags for tpm_transmit()
> - *
> - * %TPM_TRANSMIT_NESTED: discard setup steps (power management,
> locality)
> - */
> -enum tpm_transmit_flags {
> - TPM_TRANSMIT_NESTED  = BIT(0),
> -};
> -
>  ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
>unsigned int flags);
>  ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf, diff -
> -git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index 341d4b90ba2f..8ed063b54040 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -60,7 +60,10 @@ int tpm2_init_space(struct tpm_space *space)  void
> tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space)  {
>   mutex_lock(>tpm_mutex);
> - 

RE: [PATCH v5 16/17] tpm: take TPM chip power gating out of tpm_transmit()

[Winkler, Tomas]

> Call tpm_chip_start() and tpm_chip_stop() in
> 
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
> 
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
> (a command made up just for that driver).
> 
I don't think you can do that,  locality has to be request for each command, as 
 for example tboot can request higher locality any time. 
Same for cmd_ready()/go_idle() powergatin, you will prevent the whole platform 
entering power save state.
Thanks
Tomas



> The consequence of this is that this commit removes the remaining nested
> calls.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  drivers/char/tpm/tpm-chip.c   | 19 ++-
>  drivers/char/tpm/tpm-interface.c  |  4 
>  drivers/char/tpm/tpm.h|  9 -
>  drivers/char/tpm/tpm2-space.c |  5 -
>  drivers/char/tpm/tpm_vtpm_proxy.c |  3 +--
>  5 files changed, 11 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index
> 65f1561eba81..87570182f75e 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -41,9 +41,6 @@ static int tpm_request_locality(struct tpm_chip *chip,
> unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->request_locality)
>   return 0;
> 
> @@ -59,9 +56,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)  {
>   int rc;
> 
> - if (flags & TPM_TRANSMIT_NESTED)
> - return;
> -
>   if (!chip->ops->relinquish_locality)
>   return;
> 
> @@ -74,9 +68,6 @@ static void tpm_relinquish_locality(struct tpm_chip
> *chip, unsigned int flags)
> 
>  static int tpm_cmd_ready(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->cmd_ready)
>   return 0;
> 
> @@ -85,9 +76,6 @@ static int tpm_cmd_ready(struct tpm_chip *chip,
> unsigned int flags)
> 
>  static int tpm_go_idle(struct tpm_chip *chip, unsigned int flags)  {
> - if (flags & TPM_TRANSMIT_NESTED)
> - return 0;
> -
>   if (!chip->ops->go_idle)
>   return 0;
> 
> @@ -169,7 +157,7 @@ int tpm_try_get_ops(struct tpm_chip *chip)
>   goto out_lock;
> 
>   mutex_lock(>tpm_mutex);
> - return 0;
> + return tpm_chip_start(chip, 0);
>  out_lock:
>   up_read(>ops_sem);
>   put_device(>dev);
> @@ -186,6 +174,7 @@ EXPORT_SYMBOL_GPL(tpm_try_get_ops);
>   */
>  void tpm_put_ops(struct tpm_chip *chip)  {
> + tpm_chip_stop(chip, 0);
>   mutex_unlock(>tpm_mutex);
>   up_read(>ops_sem);
>   put_device(>dev);
> @@ -563,7 +552,11 @@ int tpm_chip_register(struct tpm_chip *chip)  {
>   int rc;
> 
> + rc = tpm_chip_start(chip, 0);
> + if (rc)
> + return rc;
>   rc = tpm_auto_startup(chip);
> + tpm_chip_stop(chip, 0);
>   if (rc)
>   return rc;
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 888c9923fca1..5c04c0d9aaba 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -168,11 +168,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, u8
> *buf, size_t bufsiz,
>   memcpy(save, buf, save_size);
> 
>   for (;;) {
> - ret = tpm_chip_start(chip, flags);
> - if (ret)
> - return ret;
>   ret = tpm_try_transmit(chip, buf, bufsiz, flags);
> - tpm_chip_stop(chip, flags);
> 
>   rc = be32_to_cpu(header->return_code);
>   if (rc != TPM2_RC_RETRY && rc != TPM2_RC_TESTING) diff --
> git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> c42a75710b70..f9d56dfd0d20 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -485,15 +485,6 @@ extern const struct file_operations tpm_fops;
> extern const struct file_operations tpmrm_fops;  extern struct idr
> dev_nums_idr;
> 
> -/**
> - * enum tpm_transmit_flags - flags for tpm_transmit()
> - *
> - * %TPM_TRANSMIT_NESTED: discard setup steps (power management,
> locality)
> - */
> -enum tpm_transmit_flags {
> - TPM_TRANSMIT_NESTED  = BIT(0),
> -};
> -
>  ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
>unsigned int flags);
>  ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf, diff -
> -git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index 341d4b90ba2f..8ed063b54040 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -60,7 +60,10 @@ int tpm2_init_space(struct tpm_space *space)  void
> tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space)  {
>   mutex_lock(>tpm_mutex);
> - 

RE: [PATCH v5 09/17] tpm: move tpm_validate_commmand() to tpm2-space.c

[Winkler, Tomas]

> 
> Move tpm_validate_command() to tpm2-space.c and make it part of the
> tpm2_prepare_space() flow. Make cc resolution as part of the TPM space
> functionality in order to detach it from rest of the tpm_transmit() flow.
> 
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Stefan Berger 
> ---
>  drivers/char/tpm/tpm-interface.c | 72 +++-
>  drivers/char/tpm/tpm.h   |  9 ++--
>  drivers/char/tpm/tpm2-space.c| 54 +---
>  3 files changed, 68 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index f2280bf15339..a6ffd0960ae5 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -62,47 +62,6 @@ unsigned long tpm_calc_ordinal_duration(struct
> tpm_chip *chip, u32 ordinal)  }
> EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration);
> 
> -static int tpm_validate_command(struct tpm_chip *chip,
> -  struct tpm_space *space,
> -  const u8 *cmd,
> -  size_t len)
> -{
> - const struct tpm_header *header = (const void *)cmd;
> - int i;
> - u32 cc;
> - u32 attrs;
> - unsigned int nr_handles;
> -
> - if (len < TPM_HEADER_SIZE)
> - return -EINVAL;
> -
> - if (!space)
> - return 0;
> -
> - if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) {
> - cc = be32_to_cpu(header->ordinal);
> -
> - i = tpm2_find_cc(chip, cc);
> - if (i < 0) {
> - dev_dbg(>dev, "0x%04X is an invalid
> command\n",
> - cc);
> - return -EOPNOTSUPP;
> - }
> -
> - attrs = chip->cc_attrs_tbl[i];
> - nr_handles =
> - 4 * ((attrs >> TPM2_CC_ATTR_CHANDLES) &
> GENMASK(2, 0));
> - if (len < TPM_HEADER_SIZE + 4 * nr_handles)
> - goto err_len;
> - }
> -
> - return 0;
> -err_len:
> - dev_dbg(>dev,
> - "%s: insufficient command length %zu", __func__, len);
> - return -EINVAL;
> -}
> -
>  static int tpm_request_locality(struct tpm_chip *chip, unsigned int flags)  {
>   int rc;
> @@ -172,20 +131,8 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   u32 count, ordinal;
>   unsigned long stop;
> 
> - rc = tpm_validate_command(chip, space, buf, bufsiz);
> - if (rc == -EINVAL)
> - return rc;
> - /*
> -  * If the command is not implemented by the TPM, synthesize a
> -  * response with a TPM2_RC_COMMAND_CODE return for user-
> space.
> -  */
> - if (rc == -EOPNOTSUPP) {
> - header->length = cpu_to_be32(sizeof(*header));
> - header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
> - header->return_code =
> cpu_to_be32(TPM2_RC_COMMAND_CODE |
> -
> TSS2_RESMGR_TPM_RC_LAYER);
> - return sizeof(*header);
> - }
> + if (bufsiz < TPM_HEADER_SIZE)
> + return -EINVAL;
> 
>   if (bufsiz > TPM_BUFSIZE)
>   bufsiz = TPM_BUFSIZE;
> @@ -200,7 +147,18 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   return -E2BIG;
>   }
> 
> - rc = tpm2_prepare_space(chip, space, ordinal, buf);
> + rc = tpm2_prepare_space(chip, space, buf, bufsiz);
> + /*
> +  * If the command is not implemented by the TPM, synthesize a
> +  * response with a TPM2_RC_COMMAND_CODE return for user-
> space.
> +  */
> + if (rc == -EOPNOTSUPP) {
> + header->length = cpu_to_be32(sizeof(*header));
> + header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
> + header->return_code =
> cpu_to_be32(TPM2_RC_COMMAND_CODE |
> +
> TSS2_RESMGR_TPM_RC_LAYER);
> + return sizeof(*header);
> + }
>   if (rc)
>   return rc;
> 
> @@ -249,7 +207,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   if (rc)
>   tpm2_flush_space(chip);
>   else
> - rc = tpm2_commit_space(chip, space, ordinal, buf, );
> + rc = tpm2_commit_space(chip, space, buf, );
> 
>   return rc ? rc : len;
>  }
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> 92638ec6ec97..68d78ebba032 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -264,6 +264,7 @@ struct tpm_chip {
>  #endif /* CONFIG_ACPI */
> 
>   struct tpm_space work_space;
> + u32 last_cc;
>   u32 nr_commands;
>   u32 *cc_attrs_tbl;
> 
> @@ -577,10 +578,10 @@ int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
> int tpm2_init_space(struct tpm_space *space);  void tpm2_del_space(struct
> tpm_chip *chip, struct tpm_space *space);  void tpm2_flush_space(struct
> tpm_chip *chip); -int tpm2_prepare_space(struct tpm_chip *chip, struct
> tpm_space *space, u32 cc,
> -u8 *cmd);
> -int tpm2_commit_space(struct 

RE: [PATCH v5 09/17] tpm: move tpm_validate_commmand() to tpm2-space.c

[Winkler, Tomas]

> 
> Move tpm_validate_command() to tpm2-space.c and make it part of the
> tpm2_prepare_space() flow. Make cc resolution as part of the TPM space
> functionality in order to detach it from rest of the tpm_transmit() flow.
> 
> Signed-off-by: Jarkko Sakkinen 
> Reviewed-by: Stefan Berger 
> ---
>  drivers/char/tpm/tpm-interface.c | 72 +++-
>  drivers/char/tpm/tpm.h   |  9 ++--
>  drivers/char/tpm/tpm2-space.c| 54 +---
>  3 files changed, 68 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index f2280bf15339..a6ffd0960ae5 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -62,47 +62,6 @@ unsigned long tpm_calc_ordinal_duration(struct
> tpm_chip *chip, u32 ordinal)  }
> EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration);
> 
> -static int tpm_validate_command(struct tpm_chip *chip,
> -  struct tpm_space *space,
> -  const u8 *cmd,
> -  size_t len)
> -{
> - const struct tpm_header *header = (const void *)cmd;
> - int i;
> - u32 cc;
> - u32 attrs;
> - unsigned int nr_handles;
> -
> - if (len < TPM_HEADER_SIZE)
> - return -EINVAL;
> -
> - if (!space)
> - return 0;
> -
> - if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) {
> - cc = be32_to_cpu(header->ordinal);
> -
> - i = tpm2_find_cc(chip, cc);
> - if (i < 0) {
> - dev_dbg(>dev, "0x%04X is an invalid
> command\n",
> - cc);
> - return -EOPNOTSUPP;
> - }
> -
> - attrs = chip->cc_attrs_tbl[i];
> - nr_handles =
> - 4 * ((attrs >> TPM2_CC_ATTR_CHANDLES) &
> GENMASK(2, 0));
> - if (len < TPM_HEADER_SIZE + 4 * nr_handles)
> - goto err_len;
> - }
> -
> - return 0;
> -err_len:
> - dev_dbg(>dev,
> - "%s: insufficient command length %zu", __func__, len);
> - return -EINVAL;
> -}
> -
>  static int tpm_request_locality(struct tpm_chip *chip, unsigned int flags)  {
>   int rc;
> @@ -172,20 +131,8 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   u32 count, ordinal;
>   unsigned long stop;
> 
> - rc = tpm_validate_command(chip, space, buf, bufsiz);
> - if (rc == -EINVAL)
> - return rc;
> - /*
> -  * If the command is not implemented by the TPM, synthesize a
> -  * response with a TPM2_RC_COMMAND_CODE return for user-
> space.
> -  */
> - if (rc == -EOPNOTSUPP) {
> - header->length = cpu_to_be32(sizeof(*header));
> - header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
> - header->return_code =
> cpu_to_be32(TPM2_RC_COMMAND_CODE |
> -
> TSS2_RESMGR_TPM_RC_LAYER);
> - return sizeof(*header);
> - }
> + if (bufsiz < TPM_HEADER_SIZE)
> + return -EINVAL;
> 
>   if (bufsiz > TPM_BUFSIZE)
>   bufsiz = TPM_BUFSIZE;
> @@ -200,7 +147,18 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   return -E2BIG;
>   }
> 
> - rc = tpm2_prepare_space(chip, space, ordinal, buf);
> + rc = tpm2_prepare_space(chip, space, buf, bufsiz);
> + /*
> +  * If the command is not implemented by the TPM, synthesize a
> +  * response with a TPM2_RC_COMMAND_CODE return for user-
> space.
> +  */
> + if (rc == -EOPNOTSUPP) {
> + header->length = cpu_to_be32(sizeof(*header));
> + header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
> + header->return_code =
> cpu_to_be32(TPM2_RC_COMMAND_CODE |
> +
> TSS2_RESMGR_TPM_RC_LAYER);
> + return sizeof(*header);
> + }
>   if (rc)
>   return rc;
> 
> @@ -249,7 +207,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip
> *chip,
>   if (rc)
>   tpm2_flush_space(chip);
>   else
> - rc = tpm2_commit_space(chip, space, ordinal, buf, );
> + rc = tpm2_commit_space(chip, space, buf, );
> 
>   return rc ? rc : len;
>  }
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> 92638ec6ec97..68d78ebba032 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -264,6 +264,7 @@ struct tpm_chip {
>  #endif /* CONFIG_ACPI */
> 
>   struct tpm_space work_space;
> + u32 last_cc;
>   u32 nr_commands;
>   u32 *cc_attrs_tbl;
> 
> @@ -577,10 +578,10 @@ int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
> int tpm2_init_space(struct tpm_space *space);  void tpm2_del_space(struct
> tpm_chip *chip, struct tpm_space *space);  void tpm2_flush_space(struct
> tpm_chip *chip); -int tpm2_prepare_space(struct tpm_chip *chip, struct
> tpm_space *space, u32 cc,
> -u8 *cmd);
> -int tpm2_commit_space(struct 

RE: [PATCH 0/8] Detach TPM space code out of the tpm_transmit() flow

[Winkler, Tomas]

> Subject: [PATCH 0/8] Detach TPM space code out of the tpm_transmit() flow

You forgot to version your posts this should be V2 in the subject, right?
Thanks
Tomas

 
> Make the changes that are needed to detach TPM space code from
> tpm_transmit() flow so that we do no longer need nested tpm_transmit()
> calls.
> 
> v2:
> * Print tpm2_commit_space() error inside tpm2_commit_space()
> * Error code was not printed when recv() callback failed. It is
>   fixed in this version.
> * Added a patch that removes @space from tpm_transmit().
> * Fixed a regression in earlier series. Forgot to amend the change
>   from the staging area that renames NESTED to UNLOCKED in tpm2-space.c.
> 
> Jarkko Sakkinen (8):
>   tpm: use tpm_buf in tpm_transmit_cmd() as the IO parameter
>   tpm: print tpm2_commit_space() error inside tpm2_commit_space()
>   tpm: clean up tpm_try_transmit() error handling flow
>   tpm: access command header through struct in  tpm_try_transmit()
>   tpm: move tpm_validate_commmand() to tpm2-space.c
>   tpm: encapsulate tpm_dev_transmit()
>   tpm: move TPM space code out of tpm_transmit()
>   tpm: remove @space from tpm_transmit()
> 
>  drivers/char/tpm/tpm-dev-common.c |  50 ++-  drivers/char/tpm/tpm-
> interface.c  | 240 +++---
>  drivers/char/tpm/tpm-sysfs.c  |   5 +-
>  drivers/char/tpm/tpm.h|  16 +-
>  drivers/char/tpm/tpm1-cmd.c   |  28 +---
>  drivers/char/tpm/tpm2-cmd.c   |  39 ++---
>  drivers/char/tpm/tpm2-space.c |  77 +++---
>  drivers/char/tpm/tpm_vtpm_proxy.c |   3 +-
>  8 files changed, 220 insertions(+), 238 deletions(-)
> 
> --
> 2.19.1

RE: [PATCH 0/8] Detach TPM space code out of the tpm_transmit() flow

[Winkler, Tomas]

> Subject: [PATCH 0/8] Detach TPM space code out of the tpm_transmit() flow

You forgot to version your posts this should be V2 in the subject, right?
Thanks
Tomas

 
> Make the changes that are needed to detach TPM space code from
> tpm_transmit() flow so that we do no longer need nested tpm_transmit()
> calls.
> 
> v2:
> * Print tpm2_commit_space() error inside tpm2_commit_space()
> * Error code was not printed when recv() callback failed. It is
>   fixed in this version.
> * Added a patch that removes @space from tpm_transmit().
> * Fixed a regression in earlier series. Forgot to amend the change
>   from the staging area that renames NESTED to UNLOCKED in tpm2-space.c.
> 
> Jarkko Sakkinen (8):
>   tpm: use tpm_buf in tpm_transmit_cmd() as the IO parameter
>   tpm: print tpm2_commit_space() error inside tpm2_commit_space()
>   tpm: clean up tpm_try_transmit() error handling flow
>   tpm: access command header through struct in  tpm_try_transmit()
>   tpm: move tpm_validate_commmand() to tpm2-space.c
>   tpm: encapsulate tpm_dev_transmit()
>   tpm: move TPM space code out of tpm_transmit()
>   tpm: remove @space from tpm_transmit()
> 
>  drivers/char/tpm/tpm-dev-common.c |  50 ++-  drivers/char/tpm/tpm-
> interface.c  | 240 +++---
>  drivers/char/tpm/tpm-sysfs.c  |   5 +-
>  drivers/char/tpm/tpm.h|  16 +-
>  drivers/char/tpm/tpm1-cmd.c   |  28 +---
>  drivers/char/tpm/tpm2-cmd.c   |  39 ++---
>  drivers/char/tpm/tpm2-space.c |  77 +++---
>  drivers/char/tpm/tpm_vtpm_proxy.c |   3 +-
>  8 files changed, 220 insertions(+), 238 deletions(-)
> 
> --
> 2.19.1

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> 
> On Tue, 23 Oct 2018, Winkler, Tomas wrote:
> > To  the  out  label we jump after we are  done with locality and cmd
> > read() before we jump to locality 'locality'.  We will need to add
> > another variable to check If cmd_ready() was called or not in order to
> > get rid of the extran label, it's not internally tracked so far.
> 
> I think this is fine.
> 
> Reviewed-by: Jarkko Sakkinen 
> Tested-by: Jarkko Sakkinen 
> 
> I tested this by assigning rc error code instead of requesting locality in
> addition of testig unchanged code.
> 
Great
Thanks
Tomas 

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> 
> On Tue, 23 Oct 2018, Winkler, Tomas wrote:
> > To  the  out  label we jump after we are  done with locality and cmd
> > read() before we jump to locality 'locality'.  We will need to add
> > another variable to check If cmd_ready() was called or not in order to
> > get rid of the extran label, it's not internally tracked so far.
> 
> I think this is fine.
> 
> Reviewed-by: Jarkko Sakkinen 
> Tested-by: Jarkko Sakkinen 
> 
> I tested this by assigning rc error code instead of requesting locality in
> addition of testig unchanged code.
> 
Great
Thanks
Tomas 

RE: [PATCH v7 21/21] tpm: use u32 instead of int for PCR index

[Winkler, Tomas]

> 
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > The TPM specs defines PCR index as a positive number, and there is no
> > reason to use a signed number. It is also a possible security issue as
> > currently no functions check for a negative index, which may become a
> > large number when converted to u32.
> >
> > Adjust the API to use u32 instead of int in all PCR related functions.
> >
> > Signed-off-by: Tomas Winkler 
> > Reviewed-by: Jarkko Sakkinen 
> > Tested-by: Jarkko Sakkinen 
> > ---
> > V3: New in the series.
> > V4: Separate unrelated change to another patches.
> > V5: Fix the commit message.
> > V6: Rebased.
> > V7: Resend.
> >
> > drivers/char/tpm/tpm-interface.c|  6 +++---
> > drivers/char/tpm/tpm-sysfs.c|  2 +-
> > drivers/char/tpm/tpm.h  | 10 +-
> > drivers/char/tpm/tpm1-cmd.c |  6 +++---
> > drivers/char/tpm/tpm2-cmd.c |  5 ++---
> > include/linux/tpm.h | 11 +++
> > security/integrity/ima/ima_crypto.c |  5 +++--
> > 7 files changed, 24 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm-interface.c
> > b/drivers/char/tpm/tpm-interface.c
> > index acd647476ae1..d9439f9abe78 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -38,7 +38,7 @@
> >  * recently changed pcr on suspend, so force the flush
> >  * with an extend to the selected _unused_ non-volatile pcr.
> >  */
> > -static int tpm_suspend_pcr;
> > +static u32 tpm_suspend_pcr;
> > module_param_named(suspend_pcr, tpm_suspend_pcr, uint, 0644);
> > MODULE_PARM_DESC(suspend_pcr,
> >  "PCR to use for dummy writes to facilitate flush on
> suspend."); @@
> > -455,7 +455,7 @@ EXPORT_SYMBOL_GPL(tpm_is_tpm2);
> >  *
> >  * Return: same as with tpm_transmit_cmd()  */ -int
> > tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
> > +int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf)
> > {
> > int rc;
> >
> > @@ -485,7 +485,7 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read);
> >  *
> >  * Return: same as with tpm_transmit_cmd()  */ -int
> > tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)
> > +int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8
> > +*hash)
> > {
> > int rc;
> > struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
> > diff --git a/drivers/char/tpm/tpm-sysfs.c
> > b/drivers/char/tpm/tpm-sysfs.c index 96fc7433c57d..b88e08ec2c59 100644
> > --- a/drivers/char/tpm/tpm-sysfs.c
> > +++ b/drivers/char/tpm/tpm-sysfs.c
> > @@ -102,7 +102,7 @@ static ssize_t pcrs_show(struct device *dev, struct
> device_attribute *attr,
> > cap_t cap;
> > u8 digest[TPM_DIGEST_SIZE];
> > ssize_t rc;
> > -   int i, j, num_pcrs;
> > +   u32 i, j, num_pcrs;
> > char *str = buf;
> > struct tpm_chip *chip = to_tpm_chip(dev);
> >
> > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> > e0778d19da98..f27d1f38a93d 100644
> > --- a/drivers/char/tpm/tpm.h
> > +++ b/drivers/char/tpm/tpm.h
> > @@ -509,14 +509,14 @@ ssize_t tpm_transmit_cmd(struct tpm_chip
> *chip,
> > struct tpm_space *space, int tpm_get_timeouts(struct tpm_chip *); int
> > tpm_auto_startup(struct tpm_chip *chip);
> >
> > -int tpm1_pm_suspend(struct tpm_chip *chip, int tpm_suspend_pcr);
> > +int tpm1_pm_suspend(struct tpm_chip *chip, u32 tpm_suspend_pcr);
> > int tpm1_auto_startup(struct tpm_chip *chip); int
> > tpm1_do_selftest(struct tpm_chip *chip); int tpm1_get_timeouts(struct
> > tpm_chip *chip); unsigned long tpm1_calc_ordinal_duration(struct
> > tpm_chip *chip, u32 ordinal); -int tpm1_pcr_extend(struct tpm_chip
> > *chip, int pcr_idx, const u8 *hash,
> > +int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8
> > +*hash,
> > const char *log_msg);
> > -int tpm1_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
> > +int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
> > ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> > const char *desc, size_t min_cap_length); int
> > tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max); @@ -558,8
> > +558,8 @@ static inline u32 tpm2_rc_value(u32 rc) }
> >
> > int tpm2_get_timeouts(struct tpm_chip *chip); -int
> > tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf); -int
> > tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
> > +int tpm2_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
> > +int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, u32 count,
> > struct tpm2_digest *digests);
> > int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max); void
> > tpm2_flush_context_cmd(struct tpm_chip *chip, u32 handle, diff --git
> > a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c index
> > 6b04648f8184..6f306338953b 100644
> > --- a/drivers/char/tpm/tpm1-cmd.c
> > +++ b/drivers/char/tpm/tpm1-cmd.c
> > @@ -449,7 +449,7 @@ int 

RE: [PATCH v7 21/21] tpm: use u32 instead of int for PCR index

[Winkler, Tomas]

> 
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > The TPM specs defines PCR index as a positive number, and there is no
> > reason to use a signed number. It is also a possible security issue as
> > currently no functions check for a negative index, which may become a
> > large number when converted to u32.
> >
> > Adjust the API to use u32 instead of int in all PCR related functions.
> >
> > Signed-off-by: Tomas Winkler 
> > Reviewed-by: Jarkko Sakkinen 
> > Tested-by: Jarkko Sakkinen 
> > ---
> > V3: New in the series.
> > V4: Separate unrelated change to another patches.
> > V5: Fix the commit message.
> > V6: Rebased.
> > V7: Resend.
> >
> > drivers/char/tpm/tpm-interface.c|  6 +++---
> > drivers/char/tpm/tpm-sysfs.c|  2 +-
> > drivers/char/tpm/tpm.h  | 10 +-
> > drivers/char/tpm/tpm1-cmd.c |  6 +++---
> > drivers/char/tpm/tpm2-cmd.c |  5 ++---
> > include/linux/tpm.h | 11 +++
> > security/integrity/ima/ima_crypto.c |  5 +++--
> > 7 files changed, 24 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm-interface.c
> > b/drivers/char/tpm/tpm-interface.c
> > index acd647476ae1..d9439f9abe78 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -38,7 +38,7 @@
> >  * recently changed pcr on suspend, so force the flush
> >  * with an extend to the selected _unused_ non-volatile pcr.
> >  */
> > -static int tpm_suspend_pcr;
> > +static u32 tpm_suspend_pcr;
> > module_param_named(suspend_pcr, tpm_suspend_pcr, uint, 0644);
> > MODULE_PARM_DESC(suspend_pcr,
> >  "PCR to use for dummy writes to facilitate flush on
> suspend."); @@
> > -455,7 +455,7 @@ EXPORT_SYMBOL_GPL(tpm_is_tpm2);
> >  *
> >  * Return: same as with tpm_transmit_cmd()  */ -int
> > tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
> > +int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf)
> > {
> > int rc;
> >
> > @@ -485,7 +485,7 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read);
> >  *
> >  * Return: same as with tpm_transmit_cmd()  */ -int
> > tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)
> > +int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8
> > +*hash)
> > {
> > int rc;
> > struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
> > diff --git a/drivers/char/tpm/tpm-sysfs.c
> > b/drivers/char/tpm/tpm-sysfs.c index 96fc7433c57d..b88e08ec2c59 100644
> > --- a/drivers/char/tpm/tpm-sysfs.c
> > +++ b/drivers/char/tpm/tpm-sysfs.c
> > @@ -102,7 +102,7 @@ static ssize_t pcrs_show(struct device *dev, struct
> device_attribute *attr,
> > cap_t cap;
> > u8 digest[TPM_DIGEST_SIZE];
> > ssize_t rc;
> > -   int i, j, num_pcrs;
> > +   u32 i, j, num_pcrs;
> > char *str = buf;
> > struct tpm_chip *chip = to_tpm_chip(dev);
> >
> > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> > e0778d19da98..f27d1f38a93d 100644
> > --- a/drivers/char/tpm/tpm.h
> > +++ b/drivers/char/tpm/tpm.h
> > @@ -509,14 +509,14 @@ ssize_t tpm_transmit_cmd(struct tpm_chip
> *chip,
> > struct tpm_space *space, int tpm_get_timeouts(struct tpm_chip *); int
> > tpm_auto_startup(struct tpm_chip *chip);
> >
> > -int tpm1_pm_suspend(struct tpm_chip *chip, int tpm_suspend_pcr);
> > +int tpm1_pm_suspend(struct tpm_chip *chip, u32 tpm_suspend_pcr);
> > int tpm1_auto_startup(struct tpm_chip *chip); int
> > tpm1_do_selftest(struct tpm_chip *chip); int tpm1_get_timeouts(struct
> > tpm_chip *chip); unsigned long tpm1_calc_ordinal_duration(struct
> > tpm_chip *chip, u32 ordinal); -int tpm1_pcr_extend(struct tpm_chip
> > *chip, int pcr_idx, const u8 *hash,
> > +int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8
> > +*hash,
> > const char *log_msg);
> > -int tpm1_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
> > +int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
> > ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> > const char *desc, size_t min_cap_length); int
> > tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max); @@ -558,8
> > +558,8 @@ static inline u32 tpm2_rc_value(u32 rc) }
> >
> > int tpm2_get_timeouts(struct tpm_chip *chip); -int
> > tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf); -int
> > tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
> > +int tpm2_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
> > +int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, u32 count,
> > struct tpm2_digest *digests);
> > int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max); void
> > tpm2_flush_context_cmd(struct tpm_chip *chip, u32 handle, diff --git
> > a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c index
> > 6b04648f8184..6f306338953b 100644
> > --- a/drivers/char/tpm/tpm1-cmd.c
> > +++ b/drivers/char/tpm/tpm1-cmd.c
> > @@ -449,7 +449,7 @@ int 

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> 
> 
> On Sat, 20 Oct 2018, Winkler, Tomas wrote:
> 
> >>
> >> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >>>> -Original Message-
> >>>> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >>>> Sent: Thursday, October 18, 2018 03:15
> >>>> To: Winkler, Tomas 
> >>>> Cc: Jarkko Sakkinen ; Jason
> >>>> Gunthorpe ; Nayna Jain ;
> >>>> Usyskin, Alexander ; Struk, Tadeusz
> >>>> ; linux-integr...@vger.kernel.org;
> >>>> linux-security- mod...@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org; sta...@vger.kernel.org
> >>>> Subject: Re: [PATCH] tpm: tpm_try_transmit() refactor error flow.
> >>>>
bb> >>>> On Tue, 16 Oct 2018, Tomas Winkler wrote:
> >>>>> First, rename out_no_locality to out_locality for bailing out on
> >>>>> both
> >>>>> tpm_cmd_ready() and tpm_request_locality() failure.
> >>>>
> >>>> This is unnecessary change and technically it is not a rename: the
> >>>> commit message text and the code change do not match. Rename is
> >>>> just a rename (i.e. change a variable name foo to bar).
> >>>
> >>> I'm renaming the label because it doesn't match the code flow
> >>> anymore, I can change the commit message, but you please review the
> code.
> >>> Tomas
> >>
> >> The flow change is unnecessary and does not really have anything to
> >> do with the bug fix.
> >
> > What I see in the original code is that when
> > tpm_cmd_ready()  fails it's jumps to 'out' label and trying to do
> > tpm_go_idle() but instead it should just undoing the locality, so both
> > cmd_read and go idle had a wrong jump. I see both should  be fixed.
> >
> > Earlier version was better than this and would have been fine
> >> when taking account the remark from Jason.
> 
> So you are doing tpm_cmd_ready() change in order to prevent unnecessary
> call to tpm_go_idle() that was previously i.e. before when that function
> failed in jumped to out and called tpm_go_idle()?

> 
> This should be probably split into two commits if I understood right. You did
> not have this updated mentioned in a changelog (there was no changelog).

I'm not sure why to do it in two steps, this addresses the same issue.

> Have you checked that if these were separate commits they would have the
> same fixes line? Why not use the label name 'out' as the same label handles
> bot 'locality' and 'no_locality'?

To  the  out  label we jump after we are  done with locality and cmd read() 
before we jump to locality 'locality'.
We will need to add another variable to check If cmd_ready() was called or not 
in order to get rid of the extran label,
it's not internally tracked so far.
I'm not sure what is better, I prefer this short fix, as the transmit() has to 
be rewritten anyway at some point, the recursion what is there is not helthy. 

Thanks
Tomas

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> 
> 
> On Sat, 20 Oct 2018, Winkler, Tomas wrote:
> 
> >>
> >> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >>>> -Original Message-
> >>>> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >>>> Sent: Thursday, October 18, 2018 03:15
> >>>> To: Winkler, Tomas 
> >>>> Cc: Jarkko Sakkinen ; Jason
> >>>> Gunthorpe ; Nayna Jain ;
> >>>> Usyskin, Alexander ; Struk, Tadeusz
> >>>> ; linux-integr...@vger.kernel.org;
> >>>> linux-security- mod...@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org; sta...@vger.kernel.org
> >>>> Subject: Re: [PATCH] tpm: tpm_try_transmit() refactor error flow.
> >>>>
bb> >>>> On Tue, 16 Oct 2018, Tomas Winkler wrote:
> >>>>> First, rename out_no_locality to out_locality for bailing out on
> >>>>> both
> >>>>> tpm_cmd_ready() and tpm_request_locality() failure.
> >>>>
> >>>> This is unnecessary change and technically it is not a rename: the
> >>>> commit message text and the code change do not match. Rename is
> >>>> just a rename (i.e. change a variable name foo to bar).
> >>>
> >>> I'm renaming the label because it doesn't match the code flow
> >>> anymore, I can change the commit message, but you please review the
> code.
> >>> Tomas
> >>
> >> The flow change is unnecessary and does not really have anything to
> >> do with the bug fix.
> >
> > What I see in the original code is that when
> > tpm_cmd_ready()  fails it's jumps to 'out' label and trying to do
> > tpm_go_idle() but instead it should just undoing the locality, so both
> > cmd_read and go idle had a wrong jump. I see both should  be fixed.
> >
> > Earlier version was better than this and would have been fine
> >> when taking account the remark from Jason.
> 
> So you are doing tpm_cmd_ready() change in order to prevent unnecessary
> call to tpm_go_idle() that was previously i.e. before when that function
> failed in jumped to out and called tpm_go_idle()?

> 
> This should be probably split into two commits if I understood right. You did
> not have this updated mentioned in a changelog (there was no changelog).

I'm not sure why to do it in two steps, this addresses the same issue.

> Have you checked that if these were separate commits they would have the
> same fixes line? Why not use the label name 'out' as the same label handles
> bot 'locality' and 'no_locality'?

To  the  out  label we jump after we are  done with locality and cmd read() 
before we jump to locality 'locality'.
We will need to add another variable to check If cmd_ready() was called or not 
in order to get rid of the extran label,
it's not internally tracked so far.
I'm not sure what is better, I prefer this short fix, as the transmit() has to 
be rewritten anyway at some point, the recursion what is there is not helthy. 

Thanks
Tomas

RE: [PATCH v7 00/21] tpm: separate tpm 1.x and tpm 2.x commands

[Winkler, Tomas]

> 
> On Mon, 22 Oct 2018, Winkler, Tomas wrote:
> >> This is the list of patches (assuming that I didn't miss anything)
> >> that still need tested-by tags:
> >
> > Those are just code movements, we are running them form months on our
> > systems.
> 
> I'm not sure what point you are trying to make. You cannot give tested-by by
> yourself to yourself you know. By saying that you are just saying things. It 
> is
> not any form of peer testing.
No, you are exposed to that code base as well, after all you are working @intel.
> 
> >> - tpm: factor out tpm1_get_random into tpm1-cmd.c
> >> - tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
> >> - tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read()
> >>(the subsystem tag is wrong in this, just noticed, should be
> >> 'tpm:')
> > When have you established this requirement I missed that and it cannot
> > be deduced from the git history.
> 
> Which requirement?

The requirement that the  subsystem prefix should be 'tpm:' 


Thanks
Tomas

RE: [PATCH v7 00/21] tpm: separate tpm 1.x and tpm 2.x commands

[Winkler, Tomas]

> 
> On Mon, 22 Oct 2018, Winkler, Tomas wrote:
> >> This is the list of patches (assuming that I didn't miss anything)
> >> that still need tested-by tags:
> >
> > Those are just code movements, we are running them form months on our
> > systems.
> 
> I'm not sure what point you are trying to make. You cannot give tested-by by
> yourself to yourself you know. By saying that you are just saying things. It 
> is
> not any form of peer testing.
No, you are exposed to that code base as well, after all you are working @intel.
> 
> >> - tpm: factor out tpm1_get_random into tpm1-cmd.c
> >> - tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
> >> - tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read()
> >>(the subsystem tag is wrong in this, just noticed, should be
> >> 'tpm:')
> > When have you established this requirement I missed that and it cannot
> > be deduced from the git history.
> 
> Which requirement?

The requirement that the  subsystem prefix should be 'tpm:' 


Thanks
Tomas

RE: [PATCH v7 00/21] tpm: separate tpm 1.x and tpm 2.x commands

[Winkler, Tomas]

> 
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > This patch series provides initial separation of tpm 1.x and tpm 2.x
> > commands, in foresight that the tpm 1.x chips will eventually phase
> > out and can be compiled out for modern systems.
> > A new file is added tpm1-cmd.c that contains tpm 1.x specific commands.
> > In addition, tpm 1.x commands are now implemented using tpm_buf
> > structure and instead of tpm_cmd_t construct. The latter is now removed.
> >
> > Note: my tpm 1.x HW availability is limited hence some more testing is
> needed.
> >
> > This series also contains two trivial cleanups and addition of new
> > commands by TCG spec 1.36, now supported on new Intet's platforms.
> >
> > V6: 1. Dropping tpm: move pcr extend code to tpm2-cmd.c and rebasing
> code over that change
> >2. Trivial fixes in kdoc and header
> > V7: 1. Add backportable patch for nuvoton duration calculation
> >2. Rebase durations patches over it.
> >3. Fix notorious typo tmp->tpm
> >
> >
> > Tomas Winkler (21):
> >  tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x
> >  tpm2: add new tpm2 commands according to TCG 1.36
> >  tpm: sort objects in the Makefile
> >  tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c
> >  tpm: add tpm_calc_ordinal_duration() wrapper
> >  tpm: factor out tpm_get_timeouts()
> >  tpm: move tpm1_pcr_extend to tpm1-cmd.c
> >  tpm: move tpm_getcap to tpm1-cmd.c
> >  tpm: factor out tpm1_get_random into tpm1-cmd.c
> >  tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c
> >  tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
> >  tpm: factor out tpm_startup function
> >  tpm: add tpm_auto_startup() into tpm-interface.c
> >  tpm: tpm-interface.c drop unused macros
> >  tpm: tpm-space.c remove unneeded semicolon
> >  tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure
> >  tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure
> >  tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read()
> >  tpm1: reimplement SAVESTATE using tpm_buf
> >  tpm1: reimplement tpm1_continue_selftest() using tpm_buf
> >  tpm: use u32 instead of int for PCR index
> >
> > drivers/char/tpm/Makefile|  16 +-
> > drivers/char/tpm/st33zp24/st33zp24.c |   2 +-
> > drivers/char/tpm/tpm-chip.c  |  11 +-
> > drivers/char/tpm/tpm-interface.c | 817 
> > +++
> > drivers/char/tpm/tpm-sysfs.c |  52 +--
> > drivers/char/tpm/tpm.h   |  97 ++---
> > drivers/char/tpm/tpm1-cmd.c  | 781
> +
> > drivers/char/tpm/tpm2-cmd.c  | 301 +++--
> > drivers/char/tpm/tpm2-space.c|   2 +-
> > drivers/char/tpm/tpm_i2c_nuvoton.c   |  11 +-
> > drivers/char/tpm/tpm_tis_core.c  |  10 +-
> > include/linux/tpm.h  |  11 +-
> > security/integrity/ima/ima_crypto.c  |   5 +-
> > 13 files changed, 1082 insertions(+), 1034 deletions(-) create mode
> > 100644 drivers/char/tpm/tpm1-cmd.c
> >
> > --
> > 2.14.4
> >
> >
> 
> Starts to look reosonable:
> 
> https://patchwork.kernel.org/project/linux-integrity/list/?series=33257
> 
> This is the list of patches (assuming that I didn't miss anything) that still
> need tested-by tags:

Those are just code movements, we are running them form months on our systems.

> 
> - tpm: factor out tpm1_get_random into tpm1-cmd.c
> - tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
> - tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read()
>(the subsystem tag is wrong in this, just noticed, should be 'tpm:')
When have you established this requirement I missed that and it cannot be 
deduced from the git history.

> - tpm: use u32 instead of int for PCR index

The last one maybe need some more target testing.

Thanks
Tomas

RE: [PATCH v7 00/21] tpm: separate tpm 1.x and tpm 2.x commands

[Winkler, Tomas]

> 
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > This patch series provides initial separation of tpm 1.x and tpm 2.x
> > commands, in foresight that the tpm 1.x chips will eventually phase
> > out and can be compiled out for modern systems.
> > A new file is added tpm1-cmd.c that contains tpm 1.x specific commands.
> > In addition, tpm 1.x commands are now implemented using tpm_buf
> > structure and instead of tpm_cmd_t construct. The latter is now removed.
> >
> > Note: my tpm 1.x HW availability is limited hence some more testing is
> needed.
> >
> > This series also contains two trivial cleanups and addition of new
> > commands by TCG spec 1.36, now supported on new Intet's platforms.
> >
> > V6: 1. Dropping tpm: move pcr extend code to tpm2-cmd.c and rebasing
> code over that change
> >2. Trivial fixes in kdoc and header
> > V7: 1. Add backportable patch for nuvoton duration calculation
> >2. Rebase durations patches over it.
> >3. Fix notorious typo tmp->tpm
> >
> >
> > Tomas Winkler (21):
> >  tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x
> >  tpm2: add new tpm2 commands according to TCG 1.36
> >  tpm: sort objects in the Makefile
> >  tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c
> >  tpm: add tpm_calc_ordinal_duration() wrapper
> >  tpm: factor out tpm_get_timeouts()
> >  tpm: move tpm1_pcr_extend to tpm1-cmd.c
> >  tpm: move tpm_getcap to tpm1-cmd.c
> >  tpm: factor out tpm1_get_random into tpm1-cmd.c
> >  tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c
> >  tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
> >  tpm: factor out tpm_startup function
> >  tpm: add tpm_auto_startup() into tpm-interface.c
> >  tpm: tpm-interface.c drop unused macros
> >  tpm: tpm-space.c remove unneeded semicolon
> >  tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure
> >  tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure
> >  tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read()
> >  tpm1: reimplement SAVESTATE using tpm_buf
> >  tpm1: reimplement tpm1_continue_selftest() using tpm_buf
> >  tpm: use u32 instead of int for PCR index
> >
> > drivers/char/tpm/Makefile|  16 +-
> > drivers/char/tpm/st33zp24/st33zp24.c |   2 +-
> > drivers/char/tpm/tpm-chip.c  |  11 +-
> > drivers/char/tpm/tpm-interface.c | 817 
> > +++
> > drivers/char/tpm/tpm-sysfs.c |  52 +--
> > drivers/char/tpm/tpm.h   |  97 ++---
> > drivers/char/tpm/tpm1-cmd.c  | 781
> +
> > drivers/char/tpm/tpm2-cmd.c  | 301 +++--
> > drivers/char/tpm/tpm2-space.c|   2 +-
> > drivers/char/tpm/tpm_i2c_nuvoton.c   |  11 +-
> > drivers/char/tpm/tpm_tis_core.c  |  10 +-
> > include/linux/tpm.h  |  11 +-
> > security/integrity/ima/ima_crypto.c  |   5 +-
> > 13 files changed, 1082 insertions(+), 1034 deletions(-) create mode
> > 100644 drivers/char/tpm/tpm1-cmd.c
> >
> > --
> > 2.14.4
> >
> >
> 
> Starts to look reosonable:
> 
> https://patchwork.kernel.org/project/linux-integrity/list/?series=33257
> 
> This is the list of patches (assuming that I didn't miss anything) that still
> need tested-by tags:

Those are just code movements, we are running them form months on our systems.

> 
> - tpm: factor out tpm1_get_random into tpm1-cmd.c
> - tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
> - tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read()
>(the subsystem tag is wrong in this, just noticed, should be 'tpm:')
When have you established this requirement I missed that and it cannot be 
deduced from the git history.

> - tpm: use u32 instead of int for PCR index

The last one maybe need some more target testing.

Thanks
Tomas

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> 
> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >> -Original Message-
> >> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >> Sent: Thursday, October 18, 2018 03:15
> >> To: Winkler, Tomas 
> >> Cc: Jarkko Sakkinen ; Jason
> >> Gunthorpe ; Nayna Jain ;
> >> Usyskin, Alexander ; Struk, Tadeusz
> >> ; linux-integr...@vger.kernel.org;
> >> linux-security- mod...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> sta...@vger.kernel.org
> >> Subject: Re: [PATCH] tpm: tpm_try_transmit() refactor error flow.
> >>
> >> On Tue, 16 Oct 2018, Tomas Winkler wrote:
> >>> First, rename out_no_locality to out_locality for bailing out on
> >>> both
> >>> tpm_cmd_ready() and tpm_request_locality() failure.
> >>
> >> This is unnecessary change and technically it is not a rename: the
> >> commit message text and the code change do not match. Rename is just
> >> a rename (i.e. change a variable name foo to bar).
> >
> > I'm renaming the label because it doesn't match the code flow anymore,
> > I can change the commit message, but you please review the code.
> > Tomas
> 
> The flow change is unnecessary and does not really have anything to do with
> the bug fix. 

What I see in the original code is that when 
tpm_cmd_ready()  fails it's jumps to 'out' label and trying to do tpm_go_idle()
but instead it should just undoing the locality, so both cmd_read and go idle 
had a wrong 
jump. I see both should  be fixed.

Earlier version was better than this and would have been fine
> when taking account the remark from Jason.

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> 
> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >> -Original Message-
> >> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >> Sent: Thursday, October 18, 2018 03:15
> >> To: Winkler, Tomas 
> >> Cc: Jarkko Sakkinen ; Jason
> >> Gunthorpe ; Nayna Jain ;
> >> Usyskin, Alexander ; Struk, Tadeusz
> >> ; linux-integr...@vger.kernel.org;
> >> linux-security- mod...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> sta...@vger.kernel.org
> >> Subject: Re: [PATCH] tpm: tpm_try_transmit() refactor error flow.
> >>
> >> On Tue, 16 Oct 2018, Tomas Winkler wrote:
> >>> First, rename out_no_locality to out_locality for bailing out on
> >>> both
> >>> tpm_cmd_ready() and tpm_request_locality() failure.
> >>
> >> This is unnecessary change and technically it is not a rename: the
> >> commit message text and the code change do not match. Rename is just
> >> a rename (i.e. change a variable name foo to bar).
> >
> > I'm renaming the label because it doesn't match the code flow anymore,
> > I can change the commit message, but you please review the code.
> > Tomas
> 
> The flow change is unnecessary and does not really have anything to do with
> the bug fix. 

What I see in the original code is that when 
tpm_cmd_ready()  fails it's jumps to 'out' label and trying to do tpm_go_idle()
but instead it should just undoing the locality, so both cmd_read and go idle 
had a wrong 
jump. I see both should  be fixed.

Earlier version was better than this and would have been fine
> when taking account the remark from Jason.

Re: [PATCH] tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x

[Winkler, Tomas]

On Fri, 2018-10-19 at 10:14 +0530, Nayna Jain wrote:
> 
> On 10/17/2018 10:02 PM, Tomas Winkler wrote:
> > diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c 
> > b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > index caa86b19c76d..f74f451baf6a 100644
> > --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > @@ -369,6 +369,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 
> > *buf, size_t len)
> > struct device *dev = chip->dev.parent;
> > struct i2c_client *client = to_i2c_client(dev);
> > u32 ordinal;
> > +   unsigned long duration;
> > size_t count = 0;
> > int burst_count, bytes2write, retries, rc = -EIO;
> > 
> > @@ -455,10 +456,12 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 
> > *buf, size_t len)
> > return rc;
> > }
> > ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
> > -   rc = i2c_nuvoton_wait_for_data_avail(chip,
> > -tpm_calc_ordinal_duration(chip,
> > -  ordinal),
> > ->read_queue);
> > +   if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > +   duration = tpm2_calc_ordinal_duration(chip, ordinal);
> > +   else
> > +   duration = tpm_calc_ordinal_duration(chip, ordinal);
> > +
> > +   rc = i2c_nuvoton_wait_for_data_avail(chip, duration, >read_queue);
> > if (rc) {
> > dev_err(dev, "%s() timeout command duration\n", __func__);
> > i2c_nuvoton_ready(chip);
> 
> I only have Nuvoton TPM 2.0, tested for that.
> 
> Reviewed-by: Nayna Jain 
> Tested-by: Nayna Jain  (For TPM 2.0)

That's what we needed as TPM 1.2 should be unchanged.
Really appreciate the quick response. I will rebase the series on to of
this patch. 

Thanks
Tomas

Re: [PATCH] tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x

[Winkler, Tomas]

On Fri, 2018-10-19 at 10:14 +0530, Nayna Jain wrote:
> 
> On 10/17/2018 10:02 PM, Tomas Winkler wrote:
> > diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c 
> > b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > index caa86b19c76d..f74f451baf6a 100644
> > --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > @@ -369,6 +369,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 
> > *buf, size_t len)
> > struct device *dev = chip->dev.parent;
> > struct i2c_client *client = to_i2c_client(dev);
> > u32 ordinal;
> > +   unsigned long duration;
> > size_t count = 0;
> > int burst_count, bytes2write, retries, rc = -EIO;
> > 
> > @@ -455,10 +456,12 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 
> > *buf, size_t len)
> > return rc;
> > }
> > ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
> > -   rc = i2c_nuvoton_wait_for_data_avail(chip,
> > -tpm_calc_ordinal_duration(chip,
> > -  ordinal),
> > ->read_queue);
> > +   if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > +   duration = tpm2_calc_ordinal_duration(chip, ordinal);
> > +   else
> > +   duration = tpm_calc_ordinal_duration(chip, ordinal);
> > +
> > +   rc = i2c_nuvoton_wait_for_data_avail(chip, duration, >read_queue);
> > if (rc) {
> > dev_err(dev, "%s() timeout command duration\n", __func__);
> > i2c_nuvoton_ready(chip);
> 
> I only have Nuvoton TPM 2.0, tested for that.
> 
> Reviewed-by: Nayna Jain 
> Tested-by: Nayna Jain  (For TPM 2.0)

That's what we needed as TPM 1.2 should be unchanged.
Really appreciate the quick response. I will rebase the series on to of
this patch. 

Thanks
Tomas

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Thursday, October 18, 2018 03:15
> To: Winkler, Tomas 
> Cc: Jarkko Sakkinen ; Jason Gunthorpe
> ; Nayna Jain ; Usyskin,
> Alexander ; Struk, Tadeusz
> ; linux-integr...@vger.kernel.org; linux-security-
> mod...@vger.kernel.org; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] tpm: tpm_try_transmit() refactor error flow.
> 
> On Tue, 16 Oct 2018, Tomas Winkler wrote:
> > First, rename out_no_locality to out_locality for bailing out on both
> > tpm_cmd_ready() and tpm_request_locality() failure.
> 
> This is unnecessary change and technically it is not a rename: the commit
> message text and the code change do not match. Rename is just a rename
> (i.e. change a variable name foo to bar).

I'm renaming the label because it doesn't match the code flow anymore,
I can change the commit message, but you please review the code.
Tomas

RE: [PATCH] tpm: tpm_try_transmit() refactor error flow.

[Winkler, Tomas]

> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Thursday, October 18, 2018 03:15
> To: Winkler, Tomas 
> Cc: Jarkko Sakkinen ; Jason Gunthorpe
> ; Nayna Jain ; Usyskin,
> Alexander ; Struk, Tadeusz
> ; linux-integr...@vger.kernel.org; linux-security-
> mod...@vger.kernel.org; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] tpm: tpm_try_transmit() refactor error flow.
> 
> On Tue, 16 Oct 2018, Tomas Winkler wrote:
> > First, rename out_no_locality to out_locality for bailing out on both
> > tpm_cmd_ready() and tpm_request_locality() failure.
> 
> This is unnecessary change and technically it is not a rename: the commit
> message text and the code change do not match. Rename is just a rename
> (i.e. change a variable name foo to bar).

I'm renaming the label because it doesn't match the code flow anymore,
I can change the commit message, but you please review the code.
Tomas