Re: [PATCH] scsi: ufs: add missing declaration in ufshcd.h

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 1 warning about global functions without a declaration in
Baoyou> the scsi ufshcd driver when building with W=1:
Baoyou> drivers/scsi/ufs/ufshcd.c:1991:5: warning: no previous prototype
Baoyou> for 'ufshcd_query_descriptor_retry' [-Wmissing-prototypes]

Baoyou> in fact, this function is implemented in ufshcd.c and exported
Baoyou> but need to be declared in header file.

ufshcd_query_descriptor_retry doesn't appear to be used outside of
ufshcd.c.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: ufs: add missing declaration in ufshcd.h

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 1 warning about global functions without a declaration in
Baoyou> the scsi ufshcd driver when building with W=1:
Baoyou> drivers/scsi/ufs/ufshcd.c:1991:5: warning: no previous prototype
Baoyou> for 'ufshcd_query_descriptor_retry' [-Wmissing-prototypes]

Baoyou> in fact, this function is implemented in ufshcd.c and exported
Baoyou> but need to be declared in header file.

ufshcd_query_descriptor_retry doesn't appear to be used outside of
ufshcd.c.

-- 
Martin K. Petersen  Oracle Linux Engineering

[GIT PULL]: dmaengine fixes for 4.8-rc5

[Vinod Koul]

Hi Linus,

Here is the fixes PULL request for dmaengine. This time we have odd driver
fixes, nothing major.


The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.8-rc5

for you to fetch changes up to 32e80820de5d7eb778632af8f235727a32d3aeb2:

  dmaengine: img-mdc: fix a possible NULL dereference (2016-08-22 11:57:49 
+0530)


dmaengine fixes for 4.8-rc5

The fixes this time are all in drivers:
 o possible NULL dereference in img-mdc
 o correct device identity for free_irq in at_xdmac
 o missing of_node_put() in fsl probe
 o fix debug log and hotchain corner case for pxa-dma
 o fix checking hardware bits in isr in usb dmac


LABBE Corentin (1):
  dmaengine: img-mdc: fix a possible NULL dereference

Robert Jarzmik (2):
  dmaengine: pxa_dma: fix hotchain corner case
  dmaengine: pxa_dma: fix debug message

Wei Yongjun (2):
  dmaengine: fsl_raid: add missing of_node_put() in fsl_re_probe()
  dmaengine: at_xdmac: fix to pass correct device identity to free_irq()

Yoshihiro Shimoda (1):
  dmaengine: usb-dmac: check CHCR.DE bit in usb_dmac_isr_channel()

 drivers/dma/at_xdmac.c|  4 ++--
 drivers/dma/fsl_raid.c|  1 +
 drivers/dma/img-mdc-dma.c |  4 +---
 drivers/dma/pxa_dma.c | 11 +++
 drivers/dma/sh/usb-dmac.c | 19 +++
 5 files changed, 22 insertions(+), 17 deletions(-)

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature

[GIT PULL]: dmaengine fixes for 4.8-rc5

[Vinod Koul]

Hi Linus,

Here is the fixes PULL request for dmaengine. This time we have odd driver
fixes, nothing major.


The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.8-rc5

for you to fetch changes up to 32e80820de5d7eb778632af8f235727a32d3aeb2:

  dmaengine: img-mdc: fix a possible NULL dereference (2016-08-22 11:57:49 
+0530)


dmaengine fixes for 4.8-rc5

The fixes this time are all in drivers:
 o possible NULL dereference in img-mdc
 o correct device identity for free_irq in at_xdmac
 o missing of_node_put() in fsl probe
 o fix debug log and hotchain corner case for pxa-dma
 o fix checking hardware bits in isr in usb dmac


LABBE Corentin (1):
  dmaengine: img-mdc: fix a possible NULL dereference

Robert Jarzmik (2):
  dmaengine: pxa_dma: fix hotchain corner case
  dmaengine: pxa_dma: fix debug message

Wei Yongjun (2):
  dmaengine: fsl_raid: add missing of_node_put() in fsl_re_probe()
  dmaengine: at_xdmac: fix to pass correct device identity to free_irq()

Yoshihiro Shimoda (1):
  dmaengine: usb-dmac: check CHCR.DE bit in usb_dmac_isr_channel()

 drivers/dma/at_xdmac.c|  4 ++--
 drivers/dma/fsl_raid.c|  1 +
 drivers/dma/img-mdc-dma.c |  4 +---
 drivers/dma/pxa_dma.c | 11 +++
 drivers/dma/sh/usb-dmac.c | 19 +++
 5 files changed, 22 insertions(+), 17 deletions(-)

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature

Re: [PART2 PATCH v7 00/12] iommu/AMD: Introduce IOMMU AVIC support

[Paolo Bonzini]

On 29/08/2016 06:53, Suravee Suthikulpanit wrote:
> Hi Joerg, Radim
> 
> Any other concerns?

Joerg, if there's no other issues, could you apply the first 9 patches
to a branch based on 4.8-rc1 or similar, so that I can pull it into the
KVM tree?

Thanks,

Paolo

> Thanks,
> Suravee
> 
> On 8/24/16 01:52, Suravee Suthikulpanit wrote:
>> From: Suravee Suthikulpanit 
>>
>> CHANGES FROM V6
>> ===
>>
>> Per Radim:
>> * No longer expose struct amd_ir_data to SVM.
>> * Introduce struct amd_svm_iommu_ir (amd_ir_data wrapper).
>> * Fix logic to manage ir_list where we need to remove
>>   the posted interrupt from the previous ir_list before
>>   mapping it to a new vcpu. Tested running smp VM with:
>>   -  Using irqbalance
>>   -  No irqbalance (manually set /proc/irq/smp_affinity)
>>
>> Misc:
>> * 08/12: Only set ga_root_ptr in amd_ir_set_vcpu_affinity().
>> * 10/12: Fix bug in #define AVIC_GATAG_TO_VCPUID.
>>
>> GITHUB
>> ==
>> Latest git tree can be found at:
>> http://github.com/ssuthiku/linux.gitavic_part2_v7
>>
>> OVERVIEW
>> 
>> This patch set is the second part of the two-part patch series to
>> introduce
>> the new AMD Advance Virtual Interrupt Controller (AVIC) support.
>>
>> In addition to the SVM AVIC, AMD IOMMU also extends the AVIC capability
>> to allow I/O interrupts injection directly into the virtualized guest
>> local APIC without the need for hypervisor intervention.
>>
>> This patch series introduces a new hardware interrupt remapping (IR) mode
>> in AMD IOMMU driver, the Guest Virtual APIC (GA) mode. This is in
>> contrast
>> to the existing "legacy" mode. The IR mode can be specified with a new
>> kernel parameter:
>>
>> amd_iommu_guest_ir=[vapic (default) | legacy]
>>
>> When enabling GA mode, the AMD IOMMU driver will configure device
>> interrupt
>> remapping in GA mode when possible (i.e. SVM AVIC must be enabled, and if
>> the interrupt types are supported). Otherewise, the driver will fallback
>> to using the legacy IR mode.
>>
>> This patch series also introduces new interfaces between SVM and IOMMU
>> to allow:
>>   * SVM driver to communicate to IOMMU with updated vcpu scheduling
>> information.
>>   * IOMMU driver to notify SVM driver to schedule vcpu on to physical
>> core
>> handle IOMMU GALog entry.
>>
>> DOCUMENTATIONS
>> ==
>> More information about SVM AVIC can be found in the
>> AMD64 Architecture Programmer’s Manual Volume 2 - System Programming.
>>
>> http://support.amd.com/TechDocs/24593.pdf
>>
>> More information about IOMMU AVIC can be found int the
>> AMD I/O Virtualization Technology (IOMMU) Specification - Rev 2.62.
>>
>> http://support.amd.com/TechDocs/48882_IOMMU.pdf
>>
>> Any feedback and comments are very much appreciated.
>>
>> Thank you,
>> Suravee
>>
>> Suravee Suthikulpanit (12):
>>   iommu/amd: Detect and enable guest vAPIC support
>>   iommu/amd: Move and introduce new IRTE-related unions and structures
>>   iommu/amd: Introduce interrupt remapping ops structure
>>   iommu/amd: Add support for multiple IRTE formats
>>   iommu/amd: Detect and initialize guest vAPIC log
>>   iommu/amd: Adding GALOG interrupt handler
>>   iommu/amd: Introduce amd_iommu_update_ga()
>>   iommu/amd: Implements irq_set_vcpu_affinity() hook to setup vapic mode
>> for pass-through devices
>>   iommu/amd: Enable vAPIC interrupt remapping mode by default
>>   svm: Introduces AVIC per-VM ID
>>   svm: Introduce AMD IOMMU avic_ga_log_notifier
>>   svm: Implements update_pi_irte hook to setup posted interrupt
>>
>>  Documentation/kernel-parameters.txt |   9 +
>>  arch/x86/include/asm/kvm_host.h |   2 +
>>  arch/x86/kvm/svm.c  | 406 --
>>  drivers/iommu/amd_iommu.c   | 484
>> +++-
>>  drivers/iommu/amd_iommu_init.c  | 181 +-
>>  drivers/iommu/amd_iommu_proto.h |   1 +
>>  drivers/iommu/amd_iommu_types.h | 149 +++
>>  include/linux/amd-iommu.h   |  43 +++-
>>  8 files changed, 1188 insertions(+), 87 deletions(-)
>>

Re: [PART2 PATCH v7 00/12] iommu/AMD: Introduce IOMMU AVIC support

[Paolo Bonzini]

On 29/08/2016 06:53, Suravee Suthikulpanit wrote:
> Hi Joerg, Radim
> 
> Any other concerns?

Joerg, if there's no other issues, could you apply the first 9 patches
to a branch based on 4.8-rc1 or similar, so that I can pull it into the
KVM tree?

Thanks,

Paolo

> Thanks,
> Suravee
> 
> On 8/24/16 01:52, Suravee Suthikulpanit wrote:
>> From: Suravee Suthikulpanit 
>>
>> CHANGES FROM V6
>> ===
>>
>> Per Radim:
>> * No longer expose struct amd_ir_data to SVM.
>> * Introduce struct amd_svm_iommu_ir (amd_ir_data wrapper).
>> * Fix logic to manage ir_list where we need to remove
>>   the posted interrupt from the previous ir_list before
>>   mapping it to a new vcpu. Tested running smp VM with:
>>   -  Using irqbalance
>>   -  No irqbalance (manually set /proc/irq/smp_affinity)
>>
>> Misc:
>> * 08/12: Only set ga_root_ptr in amd_ir_set_vcpu_affinity().
>> * 10/12: Fix bug in #define AVIC_GATAG_TO_VCPUID.
>>
>> GITHUB
>> ==
>> Latest git tree can be found at:
>> http://github.com/ssuthiku/linux.gitavic_part2_v7
>>
>> OVERVIEW
>> 
>> This patch set is the second part of the two-part patch series to
>> introduce
>> the new AMD Advance Virtual Interrupt Controller (AVIC) support.
>>
>> In addition to the SVM AVIC, AMD IOMMU also extends the AVIC capability
>> to allow I/O interrupts injection directly into the virtualized guest
>> local APIC without the need for hypervisor intervention.
>>
>> This patch series introduces a new hardware interrupt remapping (IR) mode
>> in AMD IOMMU driver, the Guest Virtual APIC (GA) mode. This is in
>> contrast
>> to the existing "legacy" mode. The IR mode can be specified with a new
>> kernel parameter:
>>
>> amd_iommu_guest_ir=[vapic (default) | legacy]
>>
>> When enabling GA mode, the AMD IOMMU driver will configure device
>> interrupt
>> remapping in GA mode when possible (i.e. SVM AVIC must be enabled, and if
>> the interrupt types are supported). Otherewise, the driver will fallback
>> to using the legacy IR mode.
>>
>> This patch series also introduces new interfaces between SVM and IOMMU
>> to allow:
>>   * SVM driver to communicate to IOMMU with updated vcpu scheduling
>> information.
>>   * IOMMU driver to notify SVM driver to schedule vcpu on to physical
>> core
>> handle IOMMU GALog entry.
>>
>> DOCUMENTATIONS
>> ==
>> More information about SVM AVIC can be found in the
>> AMD64 Architecture Programmer’s Manual Volume 2 - System Programming.
>>
>> http://support.amd.com/TechDocs/24593.pdf
>>
>> More information about IOMMU AVIC can be found int the
>> AMD I/O Virtualization Technology (IOMMU) Specification - Rev 2.62.
>>
>> http://support.amd.com/TechDocs/48882_IOMMU.pdf
>>
>> Any feedback and comments are very much appreciated.
>>
>> Thank you,
>> Suravee
>>
>> Suravee Suthikulpanit (12):
>>   iommu/amd: Detect and enable guest vAPIC support
>>   iommu/amd: Move and introduce new IRTE-related unions and structures
>>   iommu/amd: Introduce interrupt remapping ops structure
>>   iommu/amd: Add support for multiple IRTE formats
>>   iommu/amd: Detect and initialize guest vAPIC log
>>   iommu/amd: Adding GALOG interrupt handler
>>   iommu/amd: Introduce amd_iommu_update_ga()
>>   iommu/amd: Implements irq_set_vcpu_affinity() hook to setup vapic mode
>> for pass-through devices
>>   iommu/amd: Enable vAPIC interrupt remapping mode by default
>>   svm: Introduces AVIC per-VM ID
>>   svm: Introduce AMD IOMMU avic_ga_log_notifier
>>   svm: Implements update_pi_irte hook to setup posted interrupt
>>
>>  Documentation/kernel-parameters.txt |   9 +
>>  arch/x86/include/asm/kvm_host.h |   2 +
>>  arch/x86/kvm/svm.c  | 406 --
>>  drivers/iommu/amd_iommu.c   | 484
>> +++-
>>  drivers/iommu/amd_iommu_init.c  | 181 +-
>>  drivers/iommu/amd_iommu_proto.h |   1 +
>>  drivers/iommu/amd_iommu_types.h | 149 +++
>>  include/linux/amd-iommu.h   |  43 +++-
>>  8 files changed, 1188 insertions(+), 87 deletions(-)
>>

Re: [PATCH] fix:pmcraid: mark symbols static where possible

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 4 warnings about global functions without a declaration
Baoyou> in the scsi pmcraid driver when building with W=1:
Baoyou> drivers/scsi/pmcraid.c:309:6: warning: no previous prototype for
Baoyou> 'pmcraid_init_cmdblk' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pmcraid.c:404:6: warning: no previous prototype for
Baoyou> 'pmcraid_return_cmd' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pmcraid.c:1713:6: warning: no previous prototype
Baoyou> for 'pmcraid_ioasc_logger' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pmcraid.c:3141:1: warning: no previous prototype
Baoyou> for 'pmcraid_init_ioadls' [-Wmissing-prototypes]

Baoyou> In fact, these functions are only used in the file in which it
Baoyou> is declared and don't need a declaration, but can be made
Baoyou> static.  so this patch marks it 'static'.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] fix:pmcraid: mark symbols static where possible

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 4 warnings about global functions without a declaration
Baoyou> in the scsi pmcraid driver when building with W=1:
Baoyou> drivers/scsi/pmcraid.c:309:6: warning: no previous prototype for
Baoyou> 'pmcraid_init_cmdblk' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pmcraid.c:404:6: warning: no previous prototype for
Baoyou> 'pmcraid_return_cmd' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pmcraid.c:1713:6: warning: no previous prototype
Baoyou> for 'pmcraid_ioasc_logger' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pmcraid.c:3141:1: warning: no previous prototype
Baoyou> for 'pmcraid_init_ioadls' [-Wmissing-prototypes]

Baoyou> In fact, these functions are only used in the file in which it
Baoyou> is declared and don't need a declaration, but can be made
Baoyou> static.  so this patch marks it 'static'.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>> 
>> Hi Felipe and Arnd,
>> 
>> It has been a while since the last response to this discussion, but we
>> haven't reached an agreement yet!  Can we get to a conclusion on if it
>> is valid to create child platform device for abstraction purpose?  If
>> yes, can this child device do DMA by itself?
>
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.

heh, that looks like an excuse to me :-)

This will always be a problem for e.g. MFD, for example. Are you saying
MFD child-devices shouldn't be allowed to do DMA? It becomes silly when
you read it that way, right?

> This used to be simpler back when we could configure the kernel for
> only one SoC platform at a time, and the platforms could provide their
> own overrides for the dma-mapping interfaces. These days, we rely on

right, so we have a very old regression that just took a complex driver
such as dwc3 to trigger ;-)

> firmware or bootloader to describe various aspects of how DMA is done,

there's no DMA description in DT. Every OF device gets the same 32-bit
DMA mask and that is, itself, wrong for several devices.

> so you can't assume that passing a device without an of_node pointer
> or ACPI data into those functions will do the right thing.

That's not the problem, however. We can very easily pass along
ACPI_COMPANION() to any platform_device we want, but that's not enough
because DMA-related bits are passed along with archdata; but archdata
isn't generic in any way. Some arches (like x86) _do_ use it for DMA,
but some don't.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>> 
>> Hi Felipe and Arnd,
>> 
>> It has been a while since the last response to this discussion, but we
>> haven't reached an agreement yet!  Can we get to a conclusion on if it
>> is valid to create child platform device for abstraction purpose?  If
>> yes, can this child device do DMA by itself?
>
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.

heh, that looks like an excuse to me :-)

This will always be a problem for e.g. MFD, for example. Are you saying
MFD child-devices shouldn't be allowed to do DMA? It becomes silly when
you read it that way, right?

> This used to be simpler back when we could configure the kernel for
> only one SoC platform at a time, and the platforms could provide their
> own overrides for the dma-mapping interfaces. These days, we rely on

right, so we have a very old regression that just took a complex driver
such as dwc3 to trigger ;-)

> firmware or bootloader to describe various aspects of how DMA is done,

there's no DMA description in DT. Every OF device gets the same 32-bit
DMA mask and that is, itself, wrong for several devices.

> so you can't assume that passing a device without an of_node pointer
> or ACPI data into those functions will do the right thing.

That's not the problem, however. We can very easily pass along
ACPI_COMPANION() to any platform_device we want, but that's not enough
because DMA-related bits are passed along with archdata; but archdata
isn't generic in any way. Some arches (like x86) _do_ use it for DMA,
but some don't.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/6] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

[Marc Zyngier]

Hi Matt,

On 02/09/16 10:59, Matt Redfearn wrote:
> The MIPS remote processor driver allows non-Linux firmware to take
> control of and execute on one of the systems VPEs. If that VPE is
> brought back under Linux, it is necessary to ensure that all GIC
> interrupts are routed and masked as Linux expects them, as the firmware
> can have done anything it likes with the GIC configuration (hopefully
> just for that VPEs local interrupt sources, but allow for shared
> external interrupts as well).
> 
> The configuration of shared and local CPU interrupts is maintained and
> updated every time a change is made. When a CPU is brought online, the
> saved configuration is restored.
> 
> These functions will also be useful for restoring GIC context after a
> suspend to RAM.
> 
> Signed-off-by: Matt Redfearn 
> ---
> 
>  drivers/irqchip/irq-mips-gic.c | 185 
> +++--
>  1 file changed, 178 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
> index 83f498393a7f..5ba1fe1468ce 100644
> --- a/drivers/irqchip/irq-mips-gic.c
> +++ b/drivers/irqchip/irq-mips-gic.c
> @@ -8,6 +8,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -56,6 +57,47 @@ static unsigned int timer_cpu_pin;
>  static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
>  DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
>  
> +#if defined(CONFIG_MIPS_RPROC)
> +#define CONTEXT_SAVING
> +#endif
> +
> +#ifdef CONTEXT_SAVING

This looks really cumbersome. Why not make everything depend on
CONFIG_MIPS_RPROC instead?

> +static struct {
> + unsigned mask:  GIC_NUM_LOCAL_INTRS;

nit/personal taste: can't you make this a normal type instead of a
bitfield? Considering that GIC_NUM_LOCAL_INTRS is hardcoded to 7, I'd
rather see a u8... or even an unsigned long if you have to use bitmap
operations on it.

> +} gic_local_state[NR_CPUS];

This looks like this really should be a percpu variable.

> +
> +#define gic_save_local_rmask(vpe, i) (gic_local_state[vpe].mask &= i)
> +#define gic_save_local_smask(vpe, i) (gic_local_state[vpe].mask |= i)
> +
> +static struct {
> + unsigned vpe:   8;
> + unsigned pin:   4;
> +
> + unsigned polarity:  1;
> + unsigned trigger:   1;
> + unsigned dual_edge: 1;
> + unsigned mask:  1;
> +} gic_shared_state[GIC_MAX_INTRS];
> +
> +#define gic_save_shared_vpe(i, v)gic_shared_state[i].vpe = v
> +#define gic_save_shared_pin(i, p)gic_shared_state[i].pin = p
> +#define gic_save_shared_polarity(i, p)   gic_shared_state[i].polarity = p
> +#define gic_save_shared_trigger(i, t)gic_shared_state[i].trigger = t
> +#define gic_save_shared_dual_edge(i, d)  gic_shared_state[i].dual_edge = 
> d
> +#define gic_save_shared_mask(i, m)   gic_shared_state[i].mask = m

Why don't you make these static functions? The compiler will inline them
nicely, and that will save you fixing them (they all miss proper
bracketing of arguments).

> +
> +#else
> +#define gic_save_local_rmask(vpe, i)
> +#define gic_save_local_smask(vpe, i)
> +
> +#define gic_save_shared_vpe(i, v)
> +#define gic_save_shared_pin(i, p)
> +#define gic_save_shared_polarity(i, p)
> +#define gic_save_shared_trigger(i, t)
> +#define gic_save_shared_dual_edge(i, d)
> +#define gic_save_shared_mask(i, m)

Please make those a "do { } while(0)" construct, so that the trailing
semi-colon is properly swallowed.

> +#endif /* CONTEXT_SAVING */
> +
>  static void __gic_irq_dispatch(void);
>  
>  static inline u32 gic_read32(unsigned int reg)
> @@ -105,52 +147,94 @@ static inline void gic_update_bits(unsigned int reg, 
> unsigned long mask,
>   gic_write(reg, regval);
>  }
>  
> -static inline void gic_reset_mask(unsigned int intr)
> +static inline void gic_write_reset_mask(unsigned int intr)
>  {
>   gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
> 1ul << GIC_INTR_BIT(intr));
>  }
>  
> -static inline void gic_set_mask(unsigned int intr)
> +static inline void gic_reset_mask(unsigned int intr)
> +{
> + gic_save_shared_mask(intr, 0);
> + gic_write_reset_mask(intr);
> +}
> +
> +static inline void gic_write_set_mask(unsigned int intr)
>  {
>   gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
> 1ul << GIC_INTR_BIT(intr));
>  }
>  
> -static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
> +static inline void gic_set_mask(unsigned int intr)
> +{
> + gic_save_shared_mask(intr, 1);
> + gic_write_set_mask(intr);
> +}
> +
> +static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
>  {
>   gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
>   GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
>   (unsigned long)pol << GIC_INTR_BIT(intr));
>  }
>  
> -static inline void 

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Russell King - ARM Linux]

On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> > 
> > Hi Felipe and Arnd,
> > 
> > It has been a while since the last response to this discussion, but we
> > haven't reached an agreement yet!  Can we get to a conclusion on if it
> > is valid to create child platform device for abstraction purpose?  If
> > yes, can this child device do DMA by itself?
> 
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.

That's absolutely right.  Consider the USB model - only the USB host
controller can perform DMA, not the USB devices themselves.  All DMA
mappings need to be mapped using the USB host controller device struct
not the USB device struct.

The same _should_ be true everywhere else: the struct device representing
the device performing DMA must be the one used to map the transfer.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 1/6] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

[Marc Zyngier]

Hi Matt,

On 02/09/16 10:59, Matt Redfearn wrote:
> The MIPS remote processor driver allows non-Linux firmware to take
> control of and execute on one of the systems VPEs. If that VPE is
> brought back under Linux, it is necessary to ensure that all GIC
> interrupts are routed and masked as Linux expects them, as the firmware
> can have done anything it likes with the GIC configuration (hopefully
> just for that VPEs local interrupt sources, but allow for shared
> external interrupts as well).
> 
> The configuration of shared and local CPU interrupts is maintained and
> updated every time a change is made. When a CPU is brought online, the
> saved configuration is restored.
> 
> These functions will also be useful for restoring GIC context after a
> suspend to RAM.
> 
> Signed-off-by: Matt Redfearn 
> ---
> 
>  drivers/irqchip/irq-mips-gic.c | 185 
> +++--
>  1 file changed, 178 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
> index 83f498393a7f..5ba1fe1468ce 100644
> --- a/drivers/irqchip/irq-mips-gic.c
> +++ b/drivers/irqchip/irq-mips-gic.c
> @@ -8,6 +8,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -56,6 +57,47 @@ static unsigned int timer_cpu_pin;
>  static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
>  DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
>  
> +#if defined(CONFIG_MIPS_RPROC)
> +#define CONTEXT_SAVING
> +#endif
> +
> +#ifdef CONTEXT_SAVING

This looks really cumbersome. Why not make everything depend on
CONFIG_MIPS_RPROC instead?

> +static struct {
> + unsigned mask:  GIC_NUM_LOCAL_INTRS;

nit/personal taste: can't you make this a normal type instead of a
bitfield? Considering that GIC_NUM_LOCAL_INTRS is hardcoded to 7, I'd
rather see a u8... or even an unsigned long if you have to use bitmap
operations on it.

> +} gic_local_state[NR_CPUS];

This looks like this really should be a percpu variable.

> +
> +#define gic_save_local_rmask(vpe, i) (gic_local_state[vpe].mask &= i)
> +#define gic_save_local_smask(vpe, i) (gic_local_state[vpe].mask |= i)
> +
> +static struct {
> + unsigned vpe:   8;
> + unsigned pin:   4;
> +
> + unsigned polarity:  1;
> + unsigned trigger:   1;
> + unsigned dual_edge: 1;
> + unsigned mask:  1;
> +} gic_shared_state[GIC_MAX_INTRS];
> +
> +#define gic_save_shared_vpe(i, v)gic_shared_state[i].vpe = v
> +#define gic_save_shared_pin(i, p)gic_shared_state[i].pin = p
> +#define gic_save_shared_polarity(i, p)   gic_shared_state[i].polarity = p
> +#define gic_save_shared_trigger(i, t)gic_shared_state[i].trigger = t
> +#define gic_save_shared_dual_edge(i, d)  gic_shared_state[i].dual_edge = 
> d
> +#define gic_save_shared_mask(i, m)   gic_shared_state[i].mask = m

Why don't you make these static functions? The compiler will inline them
nicely, and that will save you fixing them (they all miss proper
bracketing of arguments).

> +
> +#else
> +#define gic_save_local_rmask(vpe, i)
> +#define gic_save_local_smask(vpe, i)
> +
> +#define gic_save_shared_vpe(i, v)
> +#define gic_save_shared_pin(i, p)
> +#define gic_save_shared_polarity(i, p)
> +#define gic_save_shared_trigger(i, t)
> +#define gic_save_shared_dual_edge(i, d)
> +#define gic_save_shared_mask(i, m)

Please make those a "do { } while(0)" construct, so that the trailing
semi-colon is properly swallowed.

> +#endif /* CONTEXT_SAVING */
> +
>  static void __gic_irq_dispatch(void);
>  
>  static inline u32 gic_read32(unsigned int reg)
> @@ -105,52 +147,94 @@ static inline void gic_update_bits(unsigned int reg, 
> unsigned long mask,
>   gic_write(reg, regval);
>  }
>  
> -static inline void gic_reset_mask(unsigned int intr)
> +static inline void gic_write_reset_mask(unsigned int intr)
>  {
>   gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
> 1ul << GIC_INTR_BIT(intr));
>  }
>  
> -static inline void gic_set_mask(unsigned int intr)
> +static inline void gic_reset_mask(unsigned int intr)
> +{
> + gic_save_shared_mask(intr, 0);
> + gic_write_reset_mask(intr);
> +}
> +
> +static inline void gic_write_set_mask(unsigned int intr)
>  {
>   gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
> 1ul << GIC_INTR_BIT(intr));
>  }
>  
> -static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
> +static inline void gic_set_mask(unsigned int intr)
> +{
> + gic_save_shared_mask(intr, 1);
> + gic_write_set_mask(intr);
> +}
> +
> +static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
>  {
>   gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
>   GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
>   (unsigned long)pol << GIC_INTR_BIT(intr));
>  }
>  
> -static inline void gic_set_trigger(unsigned int intr, unsigned 

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Russell King - ARM Linux]

On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> > 
> > Hi Felipe and Arnd,
> > 
> > It has been a while since the last response to this discussion, but we
> > haven't reached an agreement yet!  Can we get to a conclusion on if it
> > is valid to create child platform device for abstraction purpose?  If
> > yes, can this child device do DMA by itself?
> 
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.

That's absolutely right.  Consider the USB model - only the USB host
controller can perform DMA, not the USB devices themselves.  All DMA
mappings need to be mapped using the USB host controller device struct
not the USB device struct.

The same _should_ be true everywhere else: the struct device representing
the device performing DMA must be the one used to map the transfer.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] arm64: dts: rockchip: Add pinctrl entry for 32k clock on rk3399

[Heiko Stübner]

Am Donnerstag, 1. September 2016, 16:53:22 schrieb Douglas Anderson:
> On some rk3399 boards GPIO0_A0 is hooked up to a 32 kHz clock.  This can
> be used as the source for various clocks in the system.
> 
> Add a pinmux so boards can get this pin properly configured.
> 
> Signed-off-by: Douglas Anderson 

applied to my dts64 branch for 4.9


Thanks
Heiko

Re: [PATCH] arm64: dts: rockchip: Add pinctrl entry for 32k clock on rk3399

[Heiko Stübner]

Am Donnerstag, 1. September 2016, 16:53:22 schrieb Douglas Anderson:
> On some rk3399 boards GPIO0_A0 is hooked up to a 32 kHz clock.  This can
> be used as the source for various clocks in the system.
> 
> Add a pinmux so boards can get this pin properly configured.
> 
> Signed-off-by: Douglas Anderson 

applied to my dts64 branch for 4.9


Thanks
Heiko

Re: [PATCH 12/18] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Bamvor Jian Zhang]

Hi, Yury

On 08/17/2016 07:46 PM, Yury Norov wrote:
> From: Andrew Pinski 
> 
[...]
> diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
> new file mode 100644
> index 000..10fc0ca
> --- /dev/null
> +++ b/arch/arm64/kernel/sys_ilp32.c
> @@ -0,0 +1,86 @@
> +/*
> + * AArch64- ILP32 specific system calls implementation
> + *
> + * Copyright (C) 2016 Cavium Inc.
> + * Author: Andrew Pinski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#define __SYSCALL_COMPAT
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Using aarch32 syscall handlerss where off_t is passed.
> + */
> +#define compat_sys_fadvise64_64  compat_sys_fadvise64_64_wrapper
> +#define compat_sys_fallocate compat_sys_fallocate_wrapper
> +#define compat_sys_fcntl64   sys_fcntl
> +#define compat_sys_ftruncate64   compat_sys_ftruncate64_wrapper
> +#define compat_sys_pread64   compat_sys_pread64_wrapper
> +#define compat_sys_pwrite64  compat_sys_pwrite64_wrapper
> +#define compat_sys_readahead compat_sys_readahead_wrapper
> +#define compat_sys_shmat sys_shmat
> +#define compat_sys_sync_file_range   compat_sys_sync_file_range2_wrapper
> +#define compat_sys_truncate64compat_sys_truncate64_wrapper
When we test sync_file_range with our own testcase, we found that the parameter
sequence is not correct for sync_file_range2 because glibc think kernel use
the sync_file_range. So, in this patch we force to sync_file_range2.

Is it make sense to you?

Regards

Bamvor

>From e730e4db23bca4dd0ff6bcca0bc4c04e5c13b5c7 Mon Sep 17 00:00:00 2001
From: Bamvor Jian Zhang 
Date: Sat, 27 Aug 2016 12:26:31 +0800
Subject: [PATCH] arm64:ilp32: force sync_file_range2

Define __ARCH_WANT_SYNC_FILE_RANGE2 in order to select correct
sync_file_range parameters sequence in glibc and kernel.

Tested-by: Jianguo Chen 
Signed-off-by: Bamvor Jian Zhang 
---
 arch/arm64/include/uapi/asm/unistd.h | 5 +
 arch/arm64/kernel/sys_ilp32.c| 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/unistd.h 
b/arch/arm64/include/uapi/asm/unistd.h
index 043d17a..78bea1d 100644
--- a/arch/arm64/include/uapi/asm/unistd.h
+++ b/arch/arm64/include/uapi/asm/unistd.h
@@ -16,4 +16,9 @@

 #define __ARCH_WANT_RENAMEAT

+/* We need to make sure it works for both userspace and kernel(sys_ilp32.c) */
+#if defined(__ILP32__) || defined(__SYSCALL_COMPAT)
+#define __ARCH_WANT_SYNC_FILE_RANGE2
+#endif
+
 #include 
diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
index 10fc0ca..13c9c9d 100644
--- a/arch/arm64/kernel/sys_ilp32.c
+++ b/arch/arm64/kernel/sys_ilp32.c
@@ -42,7 +42,7 @@
 #define compat_sys_pwrite64compat_sys_pwrite64_wrapper
 #define compat_sys_readahead   compat_sys_readahead_wrapper
 #define compat_sys_shmat   sys_shmat
-#define compat_sys_sync_file_range compat_sys_sync_file_range2_wrapper
+#define compat_sys_sync_file_range2compat_sys_sync_file_range2_wrapper
 #define compat_sys_truncate64  compat_sys_truncate64_wrapper
 #define sys_mmap2  compat_sys_mmap2_wrapper
 #define sys_ptrace compat_sys_ptrace
-- 
1.8.4.5

> +#define sys_mmap2compat_sys_mmap2_wrapper
> +#define sys_ptrace   compat_sys_ptrace
> +
> +/*
> + * Use non-compat syscall handlers where rlimit, stat and statfs
> + * structure pointers are passed, as their layout is identical to LP64.
> + */
> +#define compat_sys_fstatfs64 sys_fstatfs
> +#define compat_sys_statfs64  sys_statfs
> +#define sys_fstat64  sys_newfstat
> +#define sys_fstatat64sys_newfstatat
> +#define compat_sys_getrlimit sys_getrlimit
> +#define compat_sys_setrlimit sys_setrlimit
> +
> +asmlinkage long compat_sys_fadvise64_64_wrapper(void);
> +asmlinkage long compat_sys_fallocate_wrapper(void);
> +asmlinkage long compat_sys_ftruncate64_wrapper(void);
> +asmlinkage long compat_sys_mmap2_wrapper(void);
> +asmlinkage long compat_sys_pread64_wrapper(void);
> +asmlinkage long 

Re: [PATCH 12/18] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Bamvor Jian Zhang]

Hi, Yury

On 08/17/2016 07:46 PM, Yury Norov wrote:
> From: Andrew Pinski 
> 
[...]
> diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
> new file mode 100644
> index 000..10fc0ca
> --- /dev/null
> +++ b/arch/arm64/kernel/sys_ilp32.c
> @@ -0,0 +1,86 @@
> +/*
> + * AArch64- ILP32 specific system calls implementation
> + *
> + * Copyright (C) 2016 Cavium Inc.
> + * Author: Andrew Pinski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#define __SYSCALL_COMPAT
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Using aarch32 syscall handlerss where off_t is passed.
> + */
> +#define compat_sys_fadvise64_64  compat_sys_fadvise64_64_wrapper
> +#define compat_sys_fallocate compat_sys_fallocate_wrapper
> +#define compat_sys_fcntl64   sys_fcntl
> +#define compat_sys_ftruncate64   compat_sys_ftruncate64_wrapper
> +#define compat_sys_pread64   compat_sys_pread64_wrapper
> +#define compat_sys_pwrite64  compat_sys_pwrite64_wrapper
> +#define compat_sys_readahead compat_sys_readahead_wrapper
> +#define compat_sys_shmat sys_shmat
> +#define compat_sys_sync_file_range   compat_sys_sync_file_range2_wrapper
> +#define compat_sys_truncate64compat_sys_truncate64_wrapper
When we test sync_file_range with our own testcase, we found that the parameter
sequence is not correct for sync_file_range2 because glibc think kernel use
the sync_file_range. So, in this patch we force to sync_file_range2.

Is it make sense to you?

Regards

Bamvor

>From e730e4db23bca4dd0ff6bcca0bc4c04e5c13b5c7 Mon Sep 17 00:00:00 2001
From: Bamvor Jian Zhang 
Date: Sat, 27 Aug 2016 12:26:31 +0800
Subject: [PATCH] arm64:ilp32: force sync_file_range2

Define __ARCH_WANT_SYNC_FILE_RANGE2 in order to select correct
sync_file_range parameters sequence in glibc and kernel.

Tested-by: Jianguo Chen 
Signed-off-by: Bamvor Jian Zhang 
---
 arch/arm64/include/uapi/asm/unistd.h | 5 +
 arch/arm64/kernel/sys_ilp32.c| 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/unistd.h 
b/arch/arm64/include/uapi/asm/unistd.h
index 043d17a..78bea1d 100644
--- a/arch/arm64/include/uapi/asm/unistd.h
+++ b/arch/arm64/include/uapi/asm/unistd.h
@@ -16,4 +16,9 @@

 #define __ARCH_WANT_RENAMEAT

+/* We need to make sure it works for both userspace and kernel(sys_ilp32.c) */
+#if defined(__ILP32__) || defined(__SYSCALL_COMPAT)
+#define __ARCH_WANT_SYNC_FILE_RANGE2
+#endif
+
 #include 
diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
index 10fc0ca..13c9c9d 100644
--- a/arch/arm64/kernel/sys_ilp32.c
+++ b/arch/arm64/kernel/sys_ilp32.c
@@ -42,7 +42,7 @@
 #define compat_sys_pwrite64compat_sys_pwrite64_wrapper
 #define compat_sys_readahead   compat_sys_readahead_wrapper
 #define compat_sys_shmat   sys_shmat
-#define compat_sys_sync_file_range compat_sys_sync_file_range2_wrapper
+#define compat_sys_sync_file_range2compat_sys_sync_file_range2_wrapper
 #define compat_sys_truncate64  compat_sys_truncate64_wrapper
 #define sys_mmap2  compat_sys_mmap2_wrapper
 #define sys_ptrace compat_sys_ptrace
-- 
1.8.4.5

> +#define sys_mmap2compat_sys_mmap2_wrapper
> +#define sys_ptrace   compat_sys_ptrace
> +
> +/*
> + * Use non-compat syscall handlers where rlimit, stat and statfs
> + * structure pointers are passed, as their layout is identical to LP64.
> + */
> +#define compat_sys_fstatfs64 sys_fstatfs
> +#define compat_sys_statfs64  sys_statfs
> +#define sys_fstat64  sys_newfstat
> +#define sys_fstatat64sys_newfstatat
> +#define compat_sys_getrlimit sys_getrlimit
> +#define compat_sys_setrlimit sys_setrlimit
> +
> +asmlinkage long compat_sys_fadvise64_64_wrapper(void);
> +asmlinkage long compat_sys_fallocate_wrapper(void);
> +asmlinkage long compat_sys_ftruncate64_wrapper(void);
> +asmlinkage long compat_sys_mmap2_wrapper(void);
> +asmlinkage long compat_sys_pread64_wrapper(void);
> +asmlinkage long compat_sys_pwrite64_wrapper(void);
> +asmlinkage long compat_sys_readahead_wrapper(void);
> +asmlinkage long 

Re: [PATCH v11 3/4] tee: add OP-TEE driver

[Jens Wiklander]

On Thu, Sep 01, 2016 at 01:06:04PM -0500, Andrew F. Davis wrote:
> On 09/01/2016 04:22 AM, Jens Wiklander wrote:
> > On Wed, Aug 31, 2016 at 11:40:20AM -0500, Andrew F. Davis wrote:
> >> On 08/31/2016 08:50 AM, Jens Wiklander wrote:
> >>> On Tue, Aug 30, 2016 at 03:23:24PM -0500, Andrew F. Davis wrote:
>  On 08/22/2016 08:00 AM, Jens Wiklander wrote:
> > +static struct tee_shm_pool *
> > +optee_config_shm_ioremap(struct device *dev, optee_invoke_fn 
> > *invoke_fn,
> > +void __iomem **ioremaped_shm)
> > +{
> > +   struct arm_smccc_res res;
> > +   struct tee_shm_pool *pool;
> > +   unsigned long vaddr;
> > +   phys_addr_t paddr;
> > +   size_t size;
> > +   phys_addr_t begin;
> > +   phys_addr_t end;
> > +   void __iomem *va;
> > +   struct tee_shm_pool_mem_info priv_info;
> > +   struct tee_shm_pool_mem_info dmabuf_info;
> > +
> > +   invoke_fn(OPTEE_SMC_GET_SHM_CONFIG, 0, 0, 0, 0, 0, 0, 0, );
> > +   if (res.a0 != OPTEE_SMC_RETURN_OK) {
> > +   dev_info(dev, "shm service not available\n");
> > +   return ERR_PTR(-ENOENT);
> > +   }
> > +
> > +   if (res.a3 != OPTEE_SMC_SHM_CACHED) {
> > +   dev_err(dev, "only normal cached shared memory 
> > supported\n");
> > +   return ERR_PTR(-EINVAL);
> > +   }
> > +
> > +   begin = roundup(res.a1, PAGE_SIZE);
> > +   end = rounddown(res.a1 + res.a2, PAGE_SIZE);
> 
>  res.a1/2/3 is really hard to review and understand, would it work better
>  to use a union or cast for the output of invoke_fn based on the function
>  type?
> 
>  In the header that defines what the returned info from these calls means
>  add:
> 
>  struct OPTEE_SMC_GET_SHM_CONFIG_RESULT {
>   unsigned long status;
>   unsigned long start;
>   unsigned long size;
>   unsigned long settings;
>  };
> 
>  then:
> 
>  union something result;
> 
>  begin = roundup(result.ret.start, PAGE_SIZE);
>  end = rounddown(result.ret.start + result.ret.size, PAGE_SIZE);
> 
>  or similar with just casting to the better named struct type.
> >>>
> >>> optee_smc.h describes what's passed in the registers during an SMC I'd
> >>> rather not clutter it with structs that doesn't add any information
> >>> there. I'm not that happy with casting or using unions to alias struct
> >>> arm_smccc_res either. How about a simple wrapper function for this call
> >>> to deal with the details instead?
> >>>
> >>
> >> I think that would be a good idea anyway, for instance, someday if the
> >> interface changes slightly then you will be able to contain the
> >> compatibility fixes in the wrapper and not out here in the main driver.
> > 
> > That interface is supposed to be a stable ABI, incompatible changes in
> > the ABI should be discouraged. If there's an incompatible change it has
> > to be dealt with in the main driver.
> 
> Why? This driver is for "OPTEE" not "OPTEE v2.0.01.02", any minor ABI
> changes should be abstracted away as much as possible to keep the main
> driver logically simple, agnostic to any OPTEE version ABI quirks/handling.

Call me naive, but I don't expect any quirks. The ABI should only be
extended with new functions and old may be deprecated.

Take the function optee_config_shm_ioremap() as an example. That
function will not be used if OP-TEE doesn't use a specific shared memory
pool but instead allocate shared memory via vmalloc() or from user
space.

This kind of changes/extensions are expected, but that's probably things
the driver need to deal with directly since if change doesn't add
something significant it wouldn't be needed.

> 
> > A small wrapper function in a
> > standalone header file has no chance here as it probably involves using
> > information gathered while probing secure world.
> > 
> > What I meant was a small wrapper function just above 
> > optee_config_shm_ioremap() to deal with only this call.
> > 
> 
> This wouldn't do anything that a cast couldn't do. Why not put the
> wrapper function in the header as part of that OPTEE version's ABI
> definition?

Choosing between wrapper functions or structs in optee_smc.h I'd choose
structs. I'll add structs for the ABI functions where it helps, skipping
for instance the OPTEE_SMC_*UID and OPTEE_SMC_CALL_WITH_ARG functions.
Would that be OK?

Thanks,
Jens

Re: [PATCH 2/2] KVM: nVMX: make emulated nested preemption timer pinned

[Paolo Bonzini]

On 30/08/2016 10:14, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Commit 61abdbe0bc ("kvm: x86: make lapic hrtimer pinned") pins the emulated 
> lapic timer. This patch does the same for the emulated nested preemption 
> timer to avoid vmexit an unrelated vCPU and the latency of kicking IPI to 
> another vCPU.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Yunhong Jiang 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 5cede40..090a3f8 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -7013,7 +7013,7 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
>   vmx->nested.vmcs02_num = 0;
>  
>   hrtimer_init(>nested.preemption_timer, CLOCK_MONOTONIC,
> -  HRTIMER_MODE_REL);
> +  HRTIMER_MODE_REL_PINNED);
>   vmx->nested.preemption_timer.function = vmx_preemption_timer_fn;
>  
>   vmx->nested.vmxon = true;
> 

Queued for 4.9, thanks.

Paolo

Re: [PATCH v11 3/4] tee: add OP-TEE driver

[Jens Wiklander]

On Thu, Sep 01, 2016 at 01:06:04PM -0500, Andrew F. Davis wrote:
> On 09/01/2016 04:22 AM, Jens Wiklander wrote:
> > On Wed, Aug 31, 2016 at 11:40:20AM -0500, Andrew F. Davis wrote:
> >> On 08/31/2016 08:50 AM, Jens Wiklander wrote:
> >>> On Tue, Aug 30, 2016 at 03:23:24PM -0500, Andrew F. Davis wrote:
>  On 08/22/2016 08:00 AM, Jens Wiklander wrote:
> > +static struct tee_shm_pool *
> > +optee_config_shm_ioremap(struct device *dev, optee_invoke_fn 
> > *invoke_fn,
> > +void __iomem **ioremaped_shm)
> > +{
> > +   struct arm_smccc_res res;
> > +   struct tee_shm_pool *pool;
> > +   unsigned long vaddr;
> > +   phys_addr_t paddr;
> > +   size_t size;
> > +   phys_addr_t begin;
> > +   phys_addr_t end;
> > +   void __iomem *va;
> > +   struct tee_shm_pool_mem_info priv_info;
> > +   struct tee_shm_pool_mem_info dmabuf_info;
> > +
> > +   invoke_fn(OPTEE_SMC_GET_SHM_CONFIG, 0, 0, 0, 0, 0, 0, 0, );
> > +   if (res.a0 != OPTEE_SMC_RETURN_OK) {
> > +   dev_info(dev, "shm service not available\n");
> > +   return ERR_PTR(-ENOENT);
> > +   }
> > +
> > +   if (res.a3 != OPTEE_SMC_SHM_CACHED) {
> > +   dev_err(dev, "only normal cached shared memory 
> > supported\n");
> > +   return ERR_PTR(-EINVAL);
> > +   }
> > +
> > +   begin = roundup(res.a1, PAGE_SIZE);
> > +   end = rounddown(res.a1 + res.a2, PAGE_SIZE);
> 
>  res.a1/2/3 is really hard to review and understand, would it work better
>  to use a union or cast for the output of invoke_fn based on the function
>  type?
> 
>  In the header that defines what the returned info from these calls means
>  add:
> 
>  struct OPTEE_SMC_GET_SHM_CONFIG_RESULT {
>   unsigned long status;
>   unsigned long start;
>   unsigned long size;
>   unsigned long settings;
>  };
> 
>  then:
> 
>  union something result;
> 
>  begin = roundup(result.ret.start, PAGE_SIZE);
>  end = rounddown(result.ret.start + result.ret.size, PAGE_SIZE);
> 
>  or similar with just casting to the better named struct type.
> >>>
> >>> optee_smc.h describes what's passed in the registers during an SMC I'd
> >>> rather not clutter it with structs that doesn't add any information
> >>> there. I'm not that happy with casting or using unions to alias struct
> >>> arm_smccc_res either. How about a simple wrapper function for this call
> >>> to deal with the details instead?
> >>>
> >>
> >> I think that would be a good idea anyway, for instance, someday if the
> >> interface changes slightly then you will be able to contain the
> >> compatibility fixes in the wrapper and not out here in the main driver.
> > 
> > That interface is supposed to be a stable ABI, incompatible changes in
> > the ABI should be discouraged. If there's an incompatible change it has
> > to be dealt with in the main driver.
> 
> Why? This driver is for "OPTEE" not "OPTEE v2.0.01.02", any minor ABI
> changes should be abstracted away as much as possible to keep the main
> driver logically simple, agnostic to any OPTEE version ABI quirks/handling.

Call me naive, but I don't expect any quirks. The ABI should only be
extended with new functions and old may be deprecated.

Take the function optee_config_shm_ioremap() as an example. That
function will not be used if OP-TEE doesn't use a specific shared memory
pool but instead allocate shared memory via vmalloc() or from user
space.

This kind of changes/extensions are expected, but that's probably things
the driver need to deal with directly since if change doesn't add
something significant it wouldn't be needed.

> 
> > A small wrapper function in a
> > standalone header file has no chance here as it probably involves using
> > information gathered while probing secure world.
> > 
> > What I meant was a small wrapper function just above 
> > optee_config_shm_ioremap() to deal with only this call.
> > 
> 
> This wouldn't do anything that a cast couldn't do. Why not put the
> wrapper function in the header as part of that OPTEE version's ABI
> definition?

Choosing between wrapper functions or structs in optee_smc.h I'd choose
structs. I'll add structs for the ABI functions where it helps, skipping
for instance the OPTEE_SMC_*UID and OPTEE_SMC_CALL_WITH_ARG functions.
Would that be OK?

Thanks,
Jens

Re: [PATCH 2/2] KVM: nVMX: make emulated nested preemption timer pinned

[Paolo Bonzini]

On 30/08/2016 10:14, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Commit 61abdbe0bc ("kvm: x86: make lapic hrtimer pinned") pins the emulated 
> lapic timer. This patch does the same for the emulated nested preemption 
> timer to avoid vmexit an unrelated vCPU and the latency of kicking IPI to 
> another vCPU.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Yunhong Jiang 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/vmx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 5cede40..090a3f8 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -7013,7 +7013,7 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
>   vmx->nested.vmcs02_num = 0;
>  
>   hrtimer_init(>nested.preemption_timer, CLOCK_MONOTONIC,
> -  HRTIMER_MODE_REL);
> +  HRTIMER_MODE_REL_PINNED);
>   vmx->nested.preemption_timer.function = vmx_preemption_timer_fn;
>  
>   vmx->nested.vmxon = true;
> 

Queued for 4.9, thanks.

Paolo

Re: [tip:smp/hotplug 4/8] kernel/cpu.c:1252:3: error: unknown field 'startup' specified in initializer

[Sebastian Andrzej Siewior]

On 2016-09-02 17:42:33 [+0800], kbuild test robot wrote:
> compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
> 
> >> kernel/cpu.c:1252:3: error: unknown field 'startup' specified in 
> >> initializer
> >> kernel/cpu.c:1252:3: warning: missing braces around initializer
>kernel/cpu.c:1252:3: warning: (near initialization for 
> 'cpuhp_bp_states[0].')
> >> kernel/cpu.c:1253:3: error: unknown field 'teardown' specified in 
> >> initializer
>kernel/cpu.c:1425:3: error: unknown field 'startup' specified in 
> initializer
>kernel/cpu.c:1425:3: warning: missing braces around initializer
>kernel/cpu.c:1425:3: warning: (near initialization for 
> 'cpuhp_ap_states[121].')
>kernel/cpu.c:1426:3: error: unknown field 'teardown' specified in 
> initializer

This is a compiler issue. We have:
| struct cpuhp_step {
| const char  *name;
| union {
| int (*startup)(unsigned int cpu);
| int (*startup_multi)(unsigned int cpu,
|  void *node);
| };
…
| };
This unnamed union fields are valid as of ISO C11.
It seems that gcc 4.5 and earlier can't access ->startup. According to
[0] this is supported since gcc 4.6.

[0] https://gcc.gnu.org/wiki/C11Status

Sebastian

Re: [PATCH] relay: Use irq_work instead of plain timer for deferred wakeup

[kbuild test robot]

Hi Peter,

[auto build test WARNING on next-20160825]
[cannot apply to linus/master linux/master v4.8-rc4 v4.8-rc3 v4.8-rc2 v4.8-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/akash-goel-intel-com/relay-Use-irq_work-instead-of-plain-timer-for-deferred-wakeup/20160902-165512
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   lib/crc32.c:148: warning: No description found for parameter 'tab)[256]'
   lib/crc32.c:148: warning: Excess function parameter 'tab' description in 
'crc32_le_generic'
   lib/crc32.c:293: warning: No description found for parameter 'tab)[256]'
   lib/crc32.c:293: warning: Excess function parameter 'tab' description in 
'crc32_be_generic'
   lib/crc32.c:1: warning: no structured comments found
>> kernel/relay.c:336: warning: No description found for parameter 'work'
>> kernel/relay.c:336: warning: Excess function parameter 'data' description in 
>> 'wakeup_readers'
>> kernel/relay.c:336: warning: No description found for parameter 'work'
>> kernel/relay.c:336: warning: Excess function parameter 'data' description in 
>> 'wakeup_readers'

vim +/work +336 kernel/relay.c

b86ff981a Jens Axboe 2006-03-23  320  /* relay channel default callbacks */
b86ff981a Jens Axboe 2006-03-23  321  static struct rchan_callbacks 
default_channel_callbacks = {
b86ff981a Jens Axboe 2006-03-23  322.subbuf_start = 
subbuf_start_default_callback,
b86ff981a Jens Axboe 2006-03-23  323.buf_mapped = 
buf_mapped_default_callback,
b86ff981a Jens Axboe 2006-03-23  324.buf_unmapped = 
buf_unmapped_default_callback,
b86ff981a Jens Axboe 2006-03-23  325.create_buf_file = 
create_buf_file_default_callback,
b86ff981a Jens Axboe 2006-03-23  326.remove_buf_file = 
remove_buf_file_default_callback,
b86ff981a Jens Axboe 2006-03-23  327  };
b86ff981a Jens Axboe 2006-03-23  328  
b86ff981a Jens Axboe 2006-03-23  329  /**
b86ff981a Jens Axboe 2006-03-23  330   *wakeup_readers - wake up 
readers waiting on a channel
9a9136e27 Linus Torvalds 2007-05-09  331   *@data: contains the channel 
buffer
b86ff981a Jens Axboe 2006-03-23  332   *
60538b154 Peter Zijlstra 2016-09-02  333   *This is the function used to 
defer reader waking
b86ff981a Jens Axboe 2006-03-23  334   */
60538b154 Peter Zijlstra 2016-09-02  335  static void wakeup_readers(struct 
irq_work *work)
b86ff981a Jens Axboe 2006-03-23 @336  {
60538b154 Peter Zijlstra 2016-09-02  337struct rchan_buf *buf = 
container_of(work, struct rchan_buf, wakeup_work);
b86ff981a Jens Axboe 2006-03-23  338
wake_up_interruptible(>read_wait);
b86ff981a Jens Axboe 2006-03-23  339  }
b86ff981a Jens Axboe 2006-03-23  340  
b86ff981a Jens Axboe 2006-03-23  341  /**
b86ff981a Jens Axboe 2006-03-23  342   *__relay_reset - reset a channel 
buffer
b86ff981a Jens Axboe 2006-03-23  343   *@buf: the channel buffer
b86ff981a Jens Axboe 2006-03-23  344   *@init: 1 if this is a 
first-time initialization

:: The code at line 336 was first introduced by commit
:: b86ff981a8252d83d6a7719ae09f3a05307e3592 [PATCH] relay: migrate from 
relayfs to a generic relay API

:: TO: Jens Axboe <ax...@suse.de>
:: CC: Jens Axboe <ax...@suse.de>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/2] KVM: lapic: fix preemption timer backward when TSC backward

[Paolo Bonzini]

On 30/08/2016 10:14, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> TSC_OFFSET will be adjusted if discovers TSC backward during vCPU load. 
> The preemption timer which will leverage guest tsc to reprogram its 
> preemption timer value is also reprogrammed if vCPU is scheded in to 
> a different pCPU. However, current implementation reprogram preemption 
> timer before TSC_OFFSET is adjusted to the right value, this will result 
> in preemption timer also backward and fire prematurity.
> 
> This patch fix it by adjusting TSC_OFFSET before reprogramming preemption 
> timer if TSC backward.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Yunhong Jiang 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/x86.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 19f9f9e..699f872 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2743,16 +2743,16 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int 
> cpu)
>   if (tsc_delta < 0)
>   mark_tsc_unstable("KVM discovered backwards TSC");
>  
> - if (kvm_lapic_hv_timer_in_use(vcpu) &&
> - kvm_x86_ops->set_hv_timer(vcpu,
> - kvm_get_lapic_tscdeadline_msr(vcpu)))
> - kvm_lapic_switch_to_sw_timer(vcpu);
>   if (check_tsc_unstable()) {
>   u64 offset = kvm_compute_tsc_offset(vcpu,
>   vcpu->arch.last_guest_tsc);
>   kvm_x86_ops->write_tsc_offset(vcpu, offset);
>   vcpu->arch.tsc_catchup = 1;
>   }
> + if (kvm_lapic_hv_timer_in_use(vcpu) &&
> + kvm_x86_ops->set_hv_timer(vcpu,
> + kvm_get_lapic_tscdeadline_msr(vcpu)))
> + kvm_lapic_switch_to_sw_timer(vcpu);
>   /*
>* On a host with synchronized TSC, there is no need to update
>* kvmclock on vcpu->cpu migration
> 

Queued for 4.8, thanks.

Paolo

Re: [tip:smp/hotplug 4/8] kernel/cpu.c:1252:3: error: unknown field 'startup' specified in initializer

[Sebastian Andrzej Siewior]

On 2016-09-02 17:42:33 [+0800], kbuild test robot wrote:
> compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
> 
> >> kernel/cpu.c:1252:3: error: unknown field 'startup' specified in 
> >> initializer
> >> kernel/cpu.c:1252:3: warning: missing braces around initializer
>kernel/cpu.c:1252:3: warning: (near initialization for 
> 'cpuhp_bp_states[0].')
> >> kernel/cpu.c:1253:3: error: unknown field 'teardown' specified in 
> >> initializer
>kernel/cpu.c:1425:3: error: unknown field 'startup' specified in 
> initializer
>kernel/cpu.c:1425:3: warning: missing braces around initializer
>kernel/cpu.c:1425:3: warning: (near initialization for 
> 'cpuhp_ap_states[121].')
>kernel/cpu.c:1426:3: error: unknown field 'teardown' specified in 
> initializer

This is a compiler issue. We have:
| struct cpuhp_step {
| const char  *name;
| union {
| int (*startup)(unsigned int cpu);
| int (*startup_multi)(unsigned int cpu,
|  void *node);
| };
…
| };
This unnamed union fields are valid as of ISO C11.
It seems that gcc 4.5 and earlier can't access ->startup. According to
[0] this is supported since gcc 4.6.

[0] https://gcc.gnu.org/wiki/C11Status

Sebastian

Re: [PATCH] relay: Use irq_work instead of plain timer for deferred wakeup

[kbuild test robot]

Hi Peter,

[auto build test WARNING on next-20160825]
[cannot apply to linus/master linux/master v4.8-rc4 v4.8-rc3 v4.8-rc2 v4.8-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/akash-goel-intel-com/relay-Use-irq_work-instead-of-plain-timer-for-deferred-wakeup/20160902-165512
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   lib/crc32.c:148: warning: No description found for parameter 'tab)[256]'
   lib/crc32.c:148: warning: Excess function parameter 'tab' description in 
'crc32_le_generic'
   lib/crc32.c:293: warning: No description found for parameter 'tab)[256]'
   lib/crc32.c:293: warning: Excess function parameter 'tab' description in 
'crc32_be_generic'
   lib/crc32.c:1: warning: no structured comments found
>> kernel/relay.c:336: warning: No description found for parameter 'work'
>> kernel/relay.c:336: warning: Excess function parameter 'data' description in 
>> 'wakeup_readers'
>> kernel/relay.c:336: warning: No description found for parameter 'work'
>> kernel/relay.c:336: warning: Excess function parameter 'data' description in 
>> 'wakeup_readers'

vim +/work +336 kernel/relay.c

b86ff981a Jens Axboe 2006-03-23  320  /* relay channel default callbacks */
b86ff981a Jens Axboe 2006-03-23  321  static struct rchan_callbacks 
default_channel_callbacks = {
b86ff981a Jens Axboe 2006-03-23  322.subbuf_start = 
subbuf_start_default_callback,
b86ff981a Jens Axboe 2006-03-23  323.buf_mapped = 
buf_mapped_default_callback,
b86ff981a Jens Axboe 2006-03-23  324.buf_unmapped = 
buf_unmapped_default_callback,
b86ff981a Jens Axboe 2006-03-23  325.create_buf_file = 
create_buf_file_default_callback,
b86ff981a Jens Axboe 2006-03-23  326.remove_buf_file = 
remove_buf_file_default_callback,
b86ff981a Jens Axboe 2006-03-23  327  };
b86ff981a Jens Axboe 2006-03-23  328  
b86ff981a Jens Axboe 2006-03-23  329  /**
b86ff981a Jens Axboe 2006-03-23  330   *wakeup_readers - wake up 
readers waiting on a channel
9a9136e27 Linus Torvalds 2007-05-09  331   *@data: contains the channel 
buffer
b86ff981a Jens Axboe 2006-03-23  332   *
60538b154 Peter Zijlstra 2016-09-02  333   *This is the function used to 
defer reader waking
b86ff981a Jens Axboe 2006-03-23  334   */
60538b154 Peter Zijlstra 2016-09-02  335  static void wakeup_readers(struct 
irq_work *work)
b86ff981a Jens Axboe 2006-03-23 @336  {
60538b154 Peter Zijlstra 2016-09-02  337struct rchan_buf *buf = 
container_of(work, struct rchan_buf, wakeup_work);
b86ff981a Jens Axboe 2006-03-23  338
wake_up_interruptible(>read_wait);
b86ff981a Jens Axboe 2006-03-23  339  }
b86ff981a Jens Axboe 2006-03-23  340  
b86ff981a Jens Axboe 2006-03-23  341  /**
b86ff981a Jens Axboe 2006-03-23  342   *__relay_reset - reset a channel 
buffer
b86ff981a Jens Axboe 2006-03-23  343   *@buf: the channel buffer
b86ff981a Jens Axboe 2006-03-23  344   *@init: 1 if this is a 
first-time initialization

:: The code at line 336 was first introduced by commit
:: b86ff981a8252d83d6a7719ae09f3a05307e3592 [PATCH] relay: migrate from 
relayfs to a generic relay API

:: TO: Jens Axboe 
:: CC: Jens Axboe 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/2] KVM: lapic: fix preemption timer backward when TSC backward

[Paolo Bonzini]

On 30/08/2016 10:14, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> TSC_OFFSET will be adjusted if discovers TSC backward during vCPU load. 
> The preemption timer which will leverage guest tsc to reprogram its 
> preemption timer value is also reprogrammed if vCPU is scheded in to 
> a different pCPU. However, current implementation reprogram preemption 
> timer before TSC_OFFSET is adjusted to the right value, this will result 
> in preemption timer also backward and fire prematurity.
> 
> This patch fix it by adjusting TSC_OFFSET before reprogramming preemption 
> timer if TSC backward.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Yunhong Jiang 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/x86.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 19f9f9e..699f872 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2743,16 +2743,16 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int 
> cpu)
>   if (tsc_delta < 0)
>   mark_tsc_unstable("KVM discovered backwards TSC");
>  
> - if (kvm_lapic_hv_timer_in_use(vcpu) &&
> - kvm_x86_ops->set_hv_timer(vcpu,
> - kvm_get_lapic_tscdeadline_msr(vcpu)))
> - kvm_lapic_switch_to_sw_timer(vcpu);
>   if (check_tsc_unstable()) {
>   u64 offset = kvm_compute_tsc_offset(vcpu,
>   vcpu->arch.last_guest_tsc);
>   kvm_x86_ops->write_tsc_offset(vcpu, offset);
>   vcpu->arch.tsc_catchup = 1;
>   }
> + if (kvm_lapic_hv_timer_in_use(vcpu) &&
> + kvm_x86_ops->set_hv_timer(vcpu,
> + kvm_get_lapic_tscdeadline_msr(vcpu)))
> + kvm_lapic_switch_to_sw_timer(vcpu);
>   /*
>* On a host with synchronized TSC, there is no need to update
>* kvmclock on vcpu->cpu migration
> 

Queued for 4.8, thanks.

Paolo

Re: [PATCH] spi: qup: skip clk_disable_unprepare if the device is already runtime suspended

[Sudeep Holla]

On 02/09/16 10:38, Mark Brown wrote:

On Fri, Sep 02, 2016 at 09:42:04AM +0100, Sudeep Holla wrote:

On 01/09/16 21:29, Mark Brown wrote:

On Thu, Aug 25, 2016 at 01:33:28PM +0100, Sudeep Holla wrote:



CPU: 3 PID: 1593 Comm: bash Tainted: GW   4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [] lr : [] pstate: 6145



Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative then it's
usually better to pull out the relevant sections.



I removed most of the addresses and just retained the symbols(somehow
the last line with pc and lr was left unintentionally). While you may
have the above opinion, other maintainers may differ. In future, I will
try to add it as a note just to describe the issue.


Oh, *that's* why it looked so weird.  Removing the addresses doesn't
help here, the issue isn't that the addresses are confusing it's that
you had a tiny commit message dwarfed by the backtrace preamble then a
screenful of call stack which conveyed no meaningful information,
including not just the entire callback path for a suspend (which doesn't
tell us anything really, especially beyond the first frame) and going on
to show the entire call stack from the sysfs write you used to trigger
suspend which is even less relevant.

This gives us 30 lines or so of splat (more than a screenful) for five
lines of actual content with the important bit which describes what the
change is supposed to be doing buried at the bottom.  That's a really
bad signal to noise ratio.  What would've been better would be
explaining why the change you are making fixes the problem.



Agreed.

--
Regards,
Sudeep

Re: [PATCH] spi: qup: skip clk_disable_unprepare if the device is already runtime suspended

[Sudeep Holla]

On 02/09/16 10:38, Mark Brown wrote:

On Fri, Sep 02, 2016 at 09:42:04AM +0100, Sudeep Holla wrote:

On 01/09/16 21:29, Mark Brown wrote:

On Thu, Aug 25, 2016 at 01:33:28PM +0100, Sudeep Holla wrote:



CPU: 3 PID: 1593 Comm: bash Tainted: GW   4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [] lr : [] pstate: 6145



Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative then it's
usually better to pull out the relevant sections.



I removed most of the addresses and just retained the symbols(somehow
the last line with pc and lr was left unintentionally). While you may
have the above opinion, other maintainers may differ. In future, I will
try to add it as a note just to describe the issue.


Oh, *that's* why it looked so weird.  Removing the addresses doesn't
help here, the issue isn't that the addresses are confusing it's that
you had a tiny commit message dwarfed by the backtrace preamble then a
screenful of call stack which conveyed no meaningful information,
including not just the entire callback path for a suspend (which doesn't
tell us anything really, especially beyond the first frame) and going on
to show the entire call stack from the sysfs write you used to trigger
suspend which is even less relevant.

This gives us 30 lines or so of splat (more than a screenful) for five
lines of actual content with the important bit which describes what the
change is supposed to be doing buried at the bottom.  That's a really
bad signal to noise ratio.  What would've been better would be
explaining why the change you are making fixes the problem.



Agreed.

--
Regards,
Sudeep

Re: [Patch v4 01/12] microblaze: irqchip: Move intc driver to irqchip

[Michal Simek]

On 2.9.2016 12:06, Zubair Lutfullah Kakakhel wrote:
> Hi,
> 
> On 09/02/2016 07:25 AM, Michal Simek wrote:
>> On 1.9.2016 18:50, Zubair Lutfullah Kakakhel wrote:
>>> The Xilinx AXI Interrupt Controller IP block is used by the MIPS
>>> based xilfpga platform.
>>>
>>> Move the interrupt controller code out of arch/microblaze so that
>>> it can be used by everyone
>>>
>>> Signed-off-by: Zubair Lutfullah Kakakhel 
>>>
>>> ---
>>> V3 -> V4
>>> No change
>>>
>>> V2 -> V3
>>> No change here. Cleanup patches follow after this patch.
>>> Its debatable to cleanup before/after move. Decided to place cleanup
>>> after move to put history in new place.
>>>
>>> V1 -> V2
>>>
>>> Renamed irq-xilinx to irq-axi-intc
>>> Renamed CONFIG_XILINX_INTC to CONFIG_XILINX_AXI_INTC
>>
>>
>> I see that this was suggested by Jason Cooper but using axi name here is
>> not correct.
>> There is xps-intc name which is the name used on old OPB hardware
>> designs. It means this driver can be still used only on system which
>> uses it.
> 
> Wouldn't axi-intc be more suitable moving forwards?
> The IP block is now known as axi intc for 5 years as far as I can tell.
> 
> Searching "axi intc" online results in the right docs for current and
> future platforms.

yes but we still should support older platform and it is more then this.
This is soft-IP core and in future when there is new bus then IP will
just change bus interface, etc.

> 
> The binding is still xps-intc as that won't change. So older systems
> should still be able to find their way.

yes that's not a problem. But in general having bus name in name is not
a good way to go.

> 
>> Also there is another copy of this driver in the tree which was using
>> old ppc405 and ppc440 xilinx platforms.
>>
>> arch/powerpc/include/asm/xilinx_intc.h
>> arch/powerpc/sysdev/xilinx_intc.c
>>
>> These should be also removed by moving this driver to generic folder.
> 
> I didn't know about that drivers existence.
> 
> This patch series already touches microblaze, mips and irqchip.
> Both microblaze and mips platforms using this driver are little-endian.

MB is big ending too and as you see there is big endian support in the
driver already.

> 
> Adding a big-endian powerpc driver + platform to the mix is going to
> complicate
> the series further and make it super hard to synchronize various
> subsystems,
> test stuff, and then move the drivers without breakage.
> 
> I'd highly recommend letting this move happen. And then the powerpc
> driver can
> transition over time to this driver.

I have no problem with this but you should be aware about it.
PPC will remain to use big endiand PLB bus. It means it is not axi too.

Thanks,
Michal

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Arnd Bergmann]

On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> 
> Hi Felipe and Arnd,
> 
> It has been a while since the last response to this discussion, but we
> haven't reached an agreement yet!  Can we get to a conclusion on if it
> is valid to create child platform device for abstraction purpose?  If
> yes, can this child device do DMA by itself?

I'd say it's no problem for a driver to create child devices in order
to represent different aspects of a device, but you should not rely on
those devices working when used with the dma-mapping interfaces.

This used to be simpler back when we could configure the kernel for
only one SoC platform at a time, and the platforms could provide their
own overrides for the dma-mapping interfaces. These days, we rely on
firmware or bootloader to describe various aspects of how DMA is done,
so you can't assume that passing a device without an of_node pointer
or ACPI data into those functions will do the right thing.

Arnd

Re: [Patch v4 01/12] microblaze: irqchip: Move intc driver to irqchip

[Michal Simek]

On 2.9.2016 12:06, Zubair Lutfullah Kakakhel wrote:
> Hi,
> 
> On 09/02/2016 07:25 AM, Michal Simek wrote:
>> On 1.9.2016 18:50, Zubair Lutfullah Kakakhel wrote:
>>> The Xilinx AXI Interrupt Controller IP block is used by the MIPS
>>> based xilfpga platform.
>>>
>>> Move the interrupt controller code out of arch/microblaze so that
>>> it can be used by everyone
>>>
>>> Signed-off-by: Zubair Lutfullah Kakakhel 
>>>
>>> ---
>>> V3 -> V4
>>> No change
>>>
>>> V2 -> V3
>>> No change here. Cleanup patches follow after this patch.
>>> Its debatable to cleanup before/after move. Decided to place cleanup
>>> after move to put history in new place.
>>>
>>> V1 -> V2
>>>
>>> Renamed irq-xilinx to irq-axi-intc
>>> Renamed CONFIG_XILINX_INTC to CONFIG_XILINX_AXI_INTC
>>
>>
>> I see that this was suggested by Jason Cooper but using axi name here is
>> not correct.
>> There is xps-intc name which is the name used on old OPB hardware
>> designs. It means this driver can be still used only on system which
>> uses it.
> 
> Wouldn't axi-intc be more suitable moving forwards?
> The IP block is now known as axi intc for 5 years as far as I can tell.
> 
> Searching "axi intc" online results in the right docs for current and
> future platforms.

yes but we still should support older platform and it is more then this.
This is soft-IP core and in future when there is new bus then IP will
just change bus interface, etc.

> 
> The binding is still xps-intc as that won't change. So older systems
> should still be able to find their way.

yes that's not a problem. But in general having bus name in name is not
a good way to go.

> 
>> Also there is another copy of this driver in the tree which was using
>> old ppc405 and ppc440 xilinx platforms.
>>
>> arch/powerpc/include/asm/xilinx_intc.h
>> arch/powerpc/sysdev/xilinx_intc.c
>>
>> These should be also removed by moving this driver to generic folder.
> 
> I didn't know about that drivers existence.
> 
> This patch series already touches microblaze, mips and irqchip.
> Both microblaze and mips platforms using this driver are little-endian.

MB is big ending too and as you see there is big endian support in the
driver already.

> 
> Adding a big-endian powerpc driver + platform to the mix is going to
> complicate
> the series further and make it super hard to synchronize various
> subsystems,
> test stuff, and then move the drivers without breakage.
> 
> I'd highly recommend letting this move happen. And then the powerpc
> driver can
> transition over time to this driver.

I have no problem with this but you should be aware about it.
PPC will remain to use big endiand PLB bus. It means it is not axi too.

Thanks,
Michal

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Arnd Bergmann]

On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> 
> Hi Felipe and Arnd,
> 
> It has been a while since the last response to this discussion, but we
> haven't reached an agreement yet!  Can we get to a conclusion on if it
> is valid to create child platform device for abstraction purpose?  If
> yes, can this child device do DMA by itself?

I'd say it's no problem for a driver to create child devices in order
to represent different aspects of a device, but you should not rely on
those devices working when used with the dma-mapping interfaces.

This used to be simpler back when we could configure the kernel for
only one SoC platform at a time, and the platforms could provide their
own overrides for the dma-mapping interfaces. These days, we rely on
firmware or bootloader to describe various aspects of how DMA is done,
so you can't assume that passing a device without an of_node pointer
or ACPI data into those functions will do the right thing.

Arnd

Re: [PATCH 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Sekhar Nori]

+ Robert Nelson

On Friday 02 September 2016 02:36 PM, Nishanth Menon wrote:
> Latest update to the BeagleBoard-X15 platform (revision B1)[1] updates
> for allowing UHS SD cards to function with the split of supply to SD
> card from a dedicated LDO.
> 
> As a result of this, AM57xx BeagleBoard-X15 now uses gpio2_30 instead
> of gpio6_28 for HDMI because HDMI_LS_OE should now be switched from
> GPIO6_28(Y9) to GPIO2_30 (AG8) to avoid a 1.8V GPIO toggling a 3.3V
> SoC input when the SD card is in UHS 1.8V mode.
> 
> NOTE: For UHS mode to function, we need full fledged IODelay support
> in kernel to be functional. IODelay support is yet to be added.
> 
> Further, It does not make much sense to spin off a new board
> compatible flag since there is no real functional benefit for the
> same.
> 
> Note: Even though production version is supposed to be B1, there is
> over ~200 boards of previous version (A2)[2] out there which continue
> to get supported with the existing dts file and the production board
> is now supported as revb1
> 
> [1] 
> https://github.com/beagleboard/beagleboard-x15/blob/master/BEAGLEBOARD_X15_REV_B1.pdf
> [2] http://marc.info/?l=linux-arm-kernel=147273929820708=2
> 
> Signed-off-by: Nishanth Menon 
> ---
> 
> NOTE: even though I have used -C -M option with git-format-patch, the
> diff for x15.dts might look a little weird. we could alternatively
> split the patch into two by creating a common dtsi and then
> introducing revb1 -> but, at least for the moment, I felt it to be an
> overkill.
> 
> Also, please note that even though revb1 is the production platform,
> there are sufficient quantities of x15 A2s (pre-prod) in the wild
> currently to leave existing dts in sync with A2 and introduce b1 as a
> seperate dts (instead of the other way around).
> 
>  arch/arm/boot/dts/Makefile |   1 +
>  ...eagle-x15.dts => am57xx-beagle-x15-common.dtsi} |   8 +-
>  arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts  |  24 +
>  arch/arm/boot/dts/am57xx-beagle-x15.dts| 592 
> +

I understand that there are existing users of A2 boards and so we simply
cannot remove support for those boards (at least yet).

But given the small numbers of A2 boards, its also quite likely that we
will not have enough test coverage for those boards. Especially as years
pass and there are fewer and fewer people with access to working A2 boards.

Given that, aren't we increasing the chance of A2 breakage by creating a
common file - this essentially necessitates that any change to
am57xx-beagle-x15-common.dtsi is also tested on A2.

Instead, it seems to be easier for maintenance and safer overall if the
older version has a file of its own which can be kept alone.

Also, how about renaming the existing dts to am57xx-beagle-x15-reva2.dts
and let the production version be called am57xx-beagle-x15.dts? Surely
this will cause some inconvenience to A2 users. But there are few users
of those and it might be more intuitive for the majority users if the
file for production version is without a specific version string
attached. Just a thought though, not sure about it myself either.

Regards,
Sekhar

Re: [PATCH 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Sekhar Nori]

+ Robert Nelson

On Friday 02 September 2016 02:36 PM, Nishanth Menon wrote:
> Latest update to the BeagleBoard-X15 platform (revision B1)[1] updates
> for allowing UHS SD cards to function with the split of supply to SD
> card from a dedicated LDO.
> 
> As a result of this, AM57xx BeagleBoard-X15 now uses gpio2_30 instead
> of gpio6_28 for HDMI because HDMI_LS_OE should now be switched from
> GPIO6_28(Y9) to GPIO2_30 (AG8) to avoid a 1.8V GPIO toggling a 3.3V
> SoC input when the SD card is in UHS 1.8V mode.
> 
> NOTE: For UHS mode to function, we need full fledged IODelay support
> in kernel to be functional. IODelay support is yet to be added.
> 
> Further, It does not make much sense to spin off a new board
> compatible flag since there is no real functional benefit for the
> same.
> 
> Note: Even though production version is supposed to be B1, there is
> over ~200 boards of previous version (A2)[2] out there which continue
> to get supported with the existing dts file and the production board
> is now supported as revb1
> 
> [1] 
> https://github.com/beagleboard/beagleboard-x15/blob/master/BEAGLEBOARD_X15_REV_B1.pdf
> [2] http://marc.info/?l=linux-arm-kernel=147273929820708=2
> 
> Signed-off-by: Nishanth Menon 
> ---
> 
> NOTE: even though I have used -C -M option with git-format-patch, the
> diff for x15.dts might look a little weird. we could alternatively
> split the patch into two by creating a common dtsi and then
> introducing revb1 -> but, at least for the moment, I felt it to be an
> overkill.
> 
> Also, please note that even though revb1 is the production platform,
> there are sufficient quantities of x15 A2s (pre-prod) in the wild
> currently to leave existing dts in sync with A2 and introduce b1 as a
> seperate dts (instead of the other way around).
> 
>  arch/arm/boot/dts/Makefile |   1 +
>  ...eagle-x15.dts => am57xx-beagle-x15-common.dtsi} |   8 +-
>  arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts  |  24 +
>  arch/arm/boot/dts/am57xx-beagle-x15.dts| 592 
> +

I understand that there are existing users of A2 boards and so we simply
cannot remove support for those boards (at least yet).

But given the small numbers of A2 boards, its also quite likely that we
will not have enough test coverage for those boards. Especially as years
pass and there are fewer and fewer people with access to working A2 boards.

Given that, aren't we increasing the chance of A2 breakage by creating a
common file - this essentially necessitates that any change to
am57xx-beagle-x15-common.dtsi is also tested on A2.

Instead, it seems to be easier for maintenance and safer overall if the
older version has a file of its own which can be kept alone.

Also, how about renaming the existing dts to am57xx-beagle-x15-reva2.dts
and let the production version be called am57xx-beagle-x15.dts? Surely
this will cause some inconvenience to A2 users. But there are few users
of those and it might be more intuitive for the majority users if the
file for production version is without a specific version string
attached. Just a thought though, not sure about it myself either.

Regards,
Sekhar

Re: [PATCH 1/2] wd719x: Remove last declaration using DEFINE_PCI_DEVICE_TABLE

[Martin K. Petersen]

> "Joe" == Joe Perches  writes:

Joe> Convert it to the preferred const struct pci_device_id instead.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/2] wd719x: Remove last declaration using DEFINE_PCI_DEVICE_TABLE

[Martin K. Petersen]

> "Joe" == Joe Perches  writes:

Joe> Convert it to the preferred const struct pci_device_id instead.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/6] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

[Matt Redfearn]

On 02/09/16 10:59, Matt Redfearn wrote:

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. If that VPE is
brought back under Linux, it is necessary to ensure that all GIC
interrupts are routed and masked as Linux expects them, as the firmware
can have done anything it likes with the GIC configuration (hopefully
just for that VPEs local interrupt sources, but allow for shared
external interrupts as well).

The configuration of shared and local CPU interrupts is maintained and
updated every time a change is made. When a CPU is brought online, the
saved configuration is restored.

These functions will also be useful for restoring GIC context after a
suspend to RAM.

Signed-off-by: Matt Redfearn 
---

  drivers/irqchip/irq-mips-gic.c | 185 +++--
  1 file changed, 178 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 83f498393a7f..5ba1fe1468ce 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -8,6 +8,7 @@
   */
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -56,6 +57,47 @@ static unsigned int timer_cpu_pin;
  static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
  DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
  
+#if defined(CONFIG_MIPS_RPROC)


Spot the mistake - this should, of course, be CONFIG_MIPS_REMOTEPROC. 
I'll fix that in v2.


Matt


+#define CONTEXT_SAVING
+#endif
+
+#ifdef CONTEXT_SAVING
+static struct {
+   unsigned mask:  GIC_NUM_LOCAL_INTRS;
+} gic_local_state[NR_CPUS];
+
+#define gic_save_local_rmask(vpe, i)   (gic_local_state[vpe].mask &= i)
+#define gic_save_local_smask(vpe, i)   (gic_local_state[vpe].mask |= i)
+
+static struct {
+   unsigned vpe:   8;
+   unsigned pin:   4;
+
+   unsigned polarity:  1;
+   unsigned trigger:   1;
+   unsigned dual_edge: 1;
+   unsigned mask:  1;
+} gic_shared_state[GIC_MAX_INTRS];
+
+#define gic_save_shared_vpe(i, v)  gic_shared_state[i].vpe = v
+#define gic_save_shared_pin(i, p)  gic_shared_state[i].pin = p
+#define gic_save_shared_polarity(i, p) gic_shared_state[i].polarity = p
+#define gic_save_shared_trigger(i, t)  gic_shared_state[i].trigger = t
+#define gic_save_shared_dual_edge(i, d)gic_shared_state[i].dual_edge = 
d
+#define gic_save_shared_mask(i, m) gic_shared_state[i].mask = m
+
+#else
+#define gic_save_local_rmask(vpe, i)
+#define gic_save_local_smask(vpe, i)
+
+#define gic_save_shared_vpe(i, v)
+#define gic_save_shared_pin(i, p)
+#define gic_save_shared_polarity(i, p)
+#define gic_save_shared_trigger(i, t)
+#define gic_save_shared_dual_edge(i, d)
+#define gic_save_shared_mask(i, m)
+#endif /* CONTEXT_SAVING */
+
  static void __gic_irq_dispatch(void);
  
  static inline u32 gic_read32(unsigned int reg)

@@ -105,52 +147,94 @@ static inline void gic_update_bits(unsigned int reg, 
unsigned long mask,
gic_write(reg, regval);
  }
  
-static inline void gic_reset_mask(unsigned int intr)

+static inline void gic_write_reset_mask(unsigned int intr)
  {
gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_mask(unsigned int intr)

+static inline void gic_reset_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 0);
+   gic_write_reset_mask(intr);
+}
+
+static inline void gic_write_set_mask(unsigned int intr)
  {
gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_polarity(unsigned int intr, unsigned int pol)

+static inline void gic_set_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 1);
+   gic_write_set_mask(intr);
+}
+
+static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
  {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)pol << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_trigger(unsigned int intr, unsigned int trig)

+static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+{
+   gic_save_shared_polarity(intr, pol);
+   gic_write_polarity(intr, pol);
+}
+
+static inline void gic_write_trigger(unsigned int intr, unsigned int trig)
  {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_TRIGGER) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)trig << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_dual_edge(unsigned int intr, unsigned int dual)

+static inline void gic_set_trigger(unsigned int intr, unsigned int trig)
+{
+   gic_save_shared_trigger(intr, trig);
+   gic_write_trigger(intr, trig);
+}
+

Re: [PATCH 1/6] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

[Matt Redfearn]

On 02/09/16 10:59, Matt Redfearn wrote:

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. If that VPE is
brought back under Linux, it is necessary to ensure that all GIC
interrupts are routed and masked as Linux expects them, as the firmware
can have done anything it likes with the GIC configuration (hopefully
just for that VPEs local interrupt sources, but allow for shared
external interrupts as well).

The configuration of shared and local CPU interrupts is maintained and
updated every time a change is made. When a CPU is brought online, the
saved configuration is restored.

These functions will also be useful for restoring GIC context after a
suspend to RAM.

Signed-off-by: Matt Redfearn 
---

  drivers/irqchip/irq-mips-gic.c | 185 +++--
  1 file changed, 178 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 83f498393a7f..5ba1fe1468ce 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -8,6 +8,7 @@
   */
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -56,6 +57,47 @@ static unsigned int timer_cpu_pin;
  static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
  DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
  
+#if defined(CONFIG_MIPS_RPROC)


Spot the mistake - this should, of course, be CONFIG_MIPS_REMOTEPROC. 
I'll fix that in v2.


Matt


+#define CONTEXT_SAVING
+#endif
+
+#ifdef CONTEXT_SAVING
+static struct {
+   unsigned mask:  GIC_NUM_LOCAL_INTRS;
+} gic_local_state[NR_CPUS];
+
+#define gic_save_local_rmask(vpe, i)   (gic_local_state[vpe].mask &= i)
+#define gic_save_local_smask(vpe, i)   (gic_local_state[vpe].mask |= i)
+
+static struct {
+   unsigned vpe:   8;
+   unsigned pin:   4;
+
+   unsigned polarity:  1;
+   unsigned trigger:   1;
+   unsigned dual_edge: 1;
+   unsigned mask:  1;
+} gic_shared_state[GIC_MAX_INTRS];
+
+#define gic_save_shared_vpe(i, v)  gic_shared_state[i].vpe = v
+#define gic_save_shared_pin(i, p)  gic_shared_state[i].pin = p
+#define gic_save_shared_polarity(i, p) gic_shared_state[i].polarity = p
+#define gic_save_shared_trigger(i, t)  gic_shared_state[i].trigger = t
+#define gic_save_shared_dual_edge(i, d)gic_shared_state[i].dual_edge = 
d
+#define gic_save_shared_mask(i, m) gic_shared_state[i].mask = m
+
+#else
+#define gic_save_local_rmask(vpe, i)
+#define gic_save_local_smask(vpe, i)
+
+#define gic_save_shared_vpe(i, v)
+#define gic_save_shared_pin(i, p)
+#define gic_save_shared_polarity(i, p)
+#define gic_save_shared_trigger(i, t)
+#define gic_save_shared_dual_edge(i, d)
+#define gic_save_shared_mask(i, m)
+#endif /* CONTEXT_SAVING */
+
  static void __gic_irq_dispatch(void);
  
  static inline u32 gic_read32(unsigned int reg)

@@ -105,52 +147,94 @@ static inline void gic_update_bits(unsigned int reg, 
unsigned long mask,
gic_write(reg, regval);
  }
  
-static inline void gic_reset_mask(unsigned int intr)

+static inline void gic_write_reset_mask(unsigned int intr)
  {
gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_mask(unsigned int intr)

+static inline void gic_reset_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 0);
+   gic_write_reset_mask(intr);
+}
+
+static inline void gic_write_set_mask(unsigned int intr)
  {
gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_polarity(unsigned int intr, unsigned int pol)

+static inline void gic_set_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 1);
+   gic_write_set_mask(intr);
+}
+
+static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
  {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)pol << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_trigger(unsigned int intr, unsigned int trig)

+static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+{
+   gic_save_shared_polarity(intr, pol);
+   gic_write_polarity(intr, pol);
+}
+
+static inline void gic_write_trigger(unsigned int intr, unsigned int trig)
  {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_TRIGGER) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)trig << GIC_INTR_BIT(intr));
  }
  
-static inline void gic_set_dual_edge(unsigned int intr, unsigned int dual)

+static inline void gic_set_trigger(unsigned int intr, unsigned int trig)
+{
+   gic_save_shared_trigger(intr, trig);
+   gic_write_trigger(intr, trig);
+}
+
+static inline void 

Re: [PATCH] arm64: dts: hi6220: add sd-uhs- properties into dwmmc_1

[Wei Xu]

Hi Guodong,

On 31/08/2016 14:10, Guodong Xu wrote:
> With these properties added, sd cards inserted into hikey can work at UHS
> mode if they have such capability.
> 
> Note, this depends on HiKey UHS-SD support patch [1] to work properly.
> If you didn't add this patch, but added sd-uhs- properties into dwmmc_1,
> then sd cards cannot work. As of this post, patch [1] has been integrated
> into maintainer's next branch [2].
> 
> [1]: [V4] mmc: dw_mmc-k3: UHS-SD card for Hisilicon Hikey,
>  https://patchwork.kernel.org/patch/9262515/
> [2]: https://git.linaro.org/people/ulf.hansson/mmc.git next
>  commit a8a5b2909cfc ("mmc: dw_mmc: k3: UHS-SD card for Hisilicon Hikey")
> 
> cc: Ulf Hansson 
> cc: Jaehoon Chung 
> cc: Jinguojun 
> Signed-off-by: Guodong Xu 

Applied to the hisi-dt-4.9 branch.
Thanks!

Best Regards,
Wei

> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 63608e9..17839db 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -785,6 +785,9 @@
>   card-detect-delay = <200>;
>   hisilicon,peripheral-syscon = <_ctrl>;
>   cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
>   reg = <0x0 0xf723e000 0x0 0x1000>;
>   interrupts = <0x0 0x49 0x4>;
>   #address-cells = <0x1>;
> 

Re: [PATCH] arm64: dts: hi6220: add sd-uhs- properties into dwmmc_1

[Wei Xu]

Hi Guodong,

On 31/08/2016 14:10, Guodong Xu wrote:
> With these properties added, sd cards inserted into hikey can work at UHS
> mode if they have such capability.
> 
> Note, this depends on HiKey UHS-SD support patch [1] to work properly.
> If you didn't add this patch, but added sd-uhs- properties into dwmmc_1,
> then sd cards cannot work. As of this post, patch [1] has been integrated
> into maintainer's next branch [2].
> 
> [1]: [V4] mmc: dw_mmc-k3: UHS-SD card for Hisilicon Hikey,
>  https://patchwork.kernel.org/patch/9262515/
> [2]: https://git.linaro.org/people/ulf.hansson/mmc.git next
>  commit a8a5b2909cfc ("mmc: dw_mmc: k3: UHS-SD card for Hisilicon Hikey")
> 
> cc: Ulf Hansson 
> cc: Jaehoon Chung 
> cc: Jinguojun 
> Signed-off-by: Guodong Xu 

Applied to the hisi-dt-4.9 branch.
Thanks!

Best Regards,
Wei

> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 63608e9..17839db 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -785,6 +785,9 @@
>   card-detect-delay = <200>;
>   hisilicon,peripheral-syscon = <_ctrl>;
>   cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
>   reg = <0x0 0xf723e000 0x0 0x1000>;
>   interrupts = <0x0 0x49 0x4>;
>   #address-cells = <0x1>;
> 

Re: [PATCH] arm64/efi: efi_init error handling fix

[Will Deacon]

On Fri, Sep 02, 2016 at 06:18:39PM +0800, Xie Yisheng wrote:
> From: Yisheng Xie 
> 
> There's an early memmap leak in efi_init error path, fix it.
> 
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/firmware/efi/arm-init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Adding linux-efi, Ard and Matt. Please try to CC the relevant people in
future.

Will

> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index c49d50e..5080e40 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -243,8 +243,10 @@ void __init efi_init(void)
>"Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
> efi.memmap.desc_version);
>  
> - if (uefi_init() < 0)
> + if (uefi_init() < 0) {
> + early_memunmap(efi.memmap.map, params.mmap_size);
>   return;
> + }
>  
>   reserve_regions();
>   efi_memattr_init();
> -- 
> 1.7.12.4
> 

Re: [PATCH] arm64/efi: efi_init error handling fix

[Will Deacon]

On Fri, Sep 02, 2016 at 06:18:39PM +0800, Xie Yisheng wrote:
> From: Yisheng Xie 
> 
> There's an early memmap leak in efi_init error path, fix it.
> 
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/firmware/efi/arm-init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Adding linux-efi, Ard and Matt. Please try to CC the relevant people in
future.

Will

> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index c49d50e..5080e40 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -243,8 +243,10 @@ void __init efi_init(void)
>"Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
> efi.memmap.desc_version);
>  
> - if (uefi_init() < 0)
> + if (uefi_init() < 0) {
> + early_memunmap(efi.memmap.map, params.mmap_size);
>   return;
> + }
>  
>   reserve_regions();
>   efi_memattr_init();
> -- 
> 1.7.12.4
> 

Re: [PATCH 2/2] arm64: dts: rockchip: add eMMC's power domain support for rk3399

[Ulf Hansson]

On 1 September 2016 at 23:50, Doug Anderson  wrote:
> Hi,
>
> On Thu, Sep 1, 2016 at 6:45 AM, Ulf Hansson  wrote:
>> I was reading the discussion regarding this change and browsing the DT
>> documentation around this... Can you guys explain what really goes on
>> here, please.
>>
>> To me, it seems like you are managing one device's resources in one
>> separate genpd. One genpd per device. Is that correct?
>>
>> Perhaps each device actually has its own PM domain and thus it makes
>> sense to assign one genpd per device?
>
> I'm not as familiar with genpd as I should be, so hopefully this makes sense.
>
> ...in hardware there is a "pd_emmc" that is the power domain for just
> eMMC.  That will be referenced hooked up via device tree, like:
>
> power-domains = < RK3399_PD_EMMC>;

Yes, I noticed that and this is what puzzles me a bit.

>
> I believe that means that power will automatically be removed whenever
> the device is runtime suspended or suspended.

Well, it depends if the genpd has a subdomain or other devices in it
being runtime resumed.
The genpd will not power off unless all devices within it are runtime
enabled+suspended and that its subdomains are also powered off.

So, in case you only have one device and no subdomains, then your
statement is correct.

>
> If w're not supporting "autosuspend" and nobody is tweaking anything

I guess you mean runtime PM autosuspend? Then why don't you support this?

Wouldn't that allow you to avoid wasting power in runtime when the
device is idle?

> manually, then it's possible (I think) that runtime suspend happens at
> exactly the same time as suspend.  ...but my point was that it was

I am not sure I follow you here. You must not rely on that the device
always becomes runtime suspended during system suspend, as there are
no guarantees for this.

Instead that is something you need to take care of in the
subsystem/driver for the device, of course.

> cleaner to actually do it any restoring in the "runtime resume" hooks
> to match what genpd does.  This matches what you say: use runtime PM.

Yes!

Using genpd without deploying runtime PM for the devices doesn't make
much sense, at least to me.

>
> ...but it also sounds like it might not be terribly important to
> restore these values since they're a bit silly to begin with.  If
> that's true then I guess we don't need to do anything special here.
>
>
> Did that all make sense (it's entirely possible it didn't since
> somehow my brain still hasn't absorbed all runtime PM and genpd
> concepts)

No worries. I understand this might be a bit tricky, that's why I also
tries to help review related changes.

Kind regards
Uffe

Re: [PATCH 2/2] arm64: dts: rockchip: add eMMC's power domain support for rk3399

[Ulf Hansson]

On 1 September 2016 at 23:50, Doug Anderson  wrote:
> Hi,
>
> On Thu, Sep 1, 2016 at 6:45 AM, Ulf Hansson  wrote:
>> I was reading the discussion regarding this change and browsing the DT
>> documentation around this... Can you guys explain what really goes on
>> here, please.
>>
>> To me, it seems like you are managing one device's resources in one
>> separate genpd. One genpd per device. Is that correct?
>>
>> Perhaps each device actually has its own PM domain and thus it makes
>> sense to assign one genpd per device?
>
> I'm not as familiar with genpd as I should be, so hopefully this makes sense.
>
> ...in hardware there is a "pd_emmc" that is the power domain for just
> eMMC.  That will be referenced hooked up via device tree, like:
>
> power-domains = < RK3399_PD_EMMC>;

Yes, I noticed that and this is what puzzles me a bit.

>
> I believe that means that power will automatically be removed whenever
> the device is runtime suspended or suspended.

Well, it depends if the genpd has a subdomain or other devices in it
being runtime resumed.
The genpd will not power off unless all devices within it are runtime
enabled+suspended and that its subdomains are also powered off.

So, in case you only have one device and no subdomains, then your
statement is correct.

>
> If w're not supporting "autosuspend" and nobody is tweaking anything

I guess you mean runtime PM autosuspend? Then why don't you support this?

Wouldn't that allow you to avoid wasting power in runtime when the
device is idle?

> manually, then it's possible (I think) that runtime suspend happens at
> exactly the same time as suspend.  ...but my point was that it was

I am not sure I follow you here. You must not rely on that the device
always becomes runtime suspended during system suspend, as there are
no guarantees for this.

Instead that is something you need to take care of in the
subsystem/driver for the device, of course.

> cleaner to actually do it any restoring in the "runtime resume" hooks
> to match what genpd does.  This matches what you say: use runtime PM.

Yes!

Using genpd without deploying runtime PM for the devices doesn't make
much sense, at least to me.

>
> ...but it also sounds like it might not be terribly important to
> restore these values since they're a bit silly to begin with.  If
> that's true then I guess we don't need to do anything special here.
>
>
> Did that all make sense (it's entirely possible it didn't since
> somehow my brain still hasn't absorbed all runtime PM and genpd
> concepts)

No worries. I understand this might be a bit tricky, that's why I also
tries to help review related changes.

Kind regards
Uffe

[PATCH 1/3] staging: rtl8712: delete one space before if statement

[Louie Lu]

This patch fixed minor checkpatch warning:

WARNING: Statements should start on a tabstop

Signed-off-by: Louie Lu 
---
 drivers/staging/rtl8712/os_intfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/os_intfs.c 
b/drivers/staging/rtl8712/os_intfs.c
index b615fbf..cbe4de0 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -425,7 +425,7 @@ static int netdev_open(struct net_device *pnetdev)
else
netif_wake_queue(pnetdev);
 
-if (video_mode)
+   if (video_mode)
enable_video_mode(padapter, cbw40_enable);
/* start driver mlme relation timer */
start_drv_timers(padapter);
-- 
2.8.2

[PATCH 1/3] staging: rtl8712: delete one space before if statement

[Louie Lu]

This patch fixed minor checkpatch warning:

WARNING: Statements should start on a tabstop

Signed-off-by: Louie Lu 
---
 drivers/staging/rtl8712/os_intfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/os_intfs.c 
b/drivers/staging/rtl8712/os_intfs.c
index b615fbf..cbe4de0 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -425,7 +425,7 @@ static int netdev_open(struct net_device *pnetdev)
else
netif_wake_queue(pnetdev);
 
-if (video_mode)
+   if (video_mode)
enable_video_mode(padapter, cbw40_enable);
/* start driver mlme relation timer */
start_drv_timers(padapter);
-- 
2.8.2

[PATCH] arm64/efi: efi_init error handling fix

[Xie Yisheng]

From: Yisheng Xie 

There's an early memmap leak in efi_init error path, fix it.

Signed-off-by: Yisheng Xie 
---
 drivers/firmware/efi/arm-init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index c49d50e..5080e40 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -243,8 +243,10 @@ void __init efi_init(void)
 "Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
  efi.memmap.desc_version);
 
-   if (uefi_init() < 0)
+   if (uefi_init() < 0) {
+   early_memunmap(efi.memmap.map, params.mmap_size);
return;
+   }
 
reserve_regions();
efi_memattr_init();
-- 
1.7.12.4

[PATCH 2/3] staging: rtl8172: fixed comment style in rts871x_cmd.c

[Louie Lu]

Fixed comment style warning by checkpatch:

* Block comments use * on subsequent lines
* Block comments use a trailing */ on a separate line

Signed-off-by: Louie Lu 
---
 drivers/staging/rtl8712/rtl871x_cmd.c | 46 +++
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c 
b/drivers/staging/rtl8712/rtl871x_cmd.c
index 5838696..51b6959 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -51,9 +51,9 @@
 #include "mlme_osdep.h"
 
 /*
-Caller and the r8712_cmd_thread can protect cmd_q by spin_lock.
-No irqsave is necessary.
-*/
+ * Caller and the r8712_cmd_thread can protect cmd_q by spin_lock.
+ * No irqsave is necessary.
+ */
 
 static sint _init_cmd_priv(struct cmd_priv *pcmdpriv)
 {
@@ -110,14 +110,14 @@ static void _free_cmd_priv(struct cmd_priv *pcmdpriv)
 }
 
 /*
-Calling Context:
-
-_enqueue_cmd can only be called between kernel thread,
-since only spin_lock is used.
-
-ISR/Call-Back functions can't call this sub-function.
-
-*/
+ * Calling Context:
+ *
+ * _enqueue_cmd can only be called between kernel thread,
+ * since only spin_lock is used.
+ *
+ * ISR/Call-Back functions can't call this sub-function.
+ *
+ */
 
 static sint _enqueue_cmd(struct  __queue *queue, struct cmd_obj *obj)
 {
@@ -211,11 +211,11 @@ void r8712_free_cmd_obj(struct cmd_obj *pcmd)
 }
 
 /*
-r8712_sitesurvey_cmd(~)
-   ### NOTE: ()
-   MUST TAKE CARE THAT BEFORE CALLING THIS FUNC,
-YOU SHOULD HAVE LOCKED pmlmepriv->lock
-*/
+ * r8712_sitesurvey_cmd(~)
+ * ### NOTE: ()
+ * MUST TAKE CARE THAT BEFORE CALLING THIS FUNC,
+ * YOU SHOULD HAVE LOCKED pmlmepriv->lock
+ */
 u8 r8712_sitesurvey_cmd(struct _adapter *padapter,
struct ndis_802_11_ssid *pssid)
 {
@@ -491,8 +491,9 @@ u8 r8712_joinbss_cmd(struct _adapter  *padapter, struct 
wlan_network *pnetwork)
memcpy(>authenticator_ie[1],
>IEs[12], (256 - 1));
psecnetwork->IELength = 0;
-   /* If the driver wants to use the bssid to create the connection.
-* If not,  we copy the connecting AP's MAC address to it so that
+   /*
+* If the driver wants to use the bssid to create the connection.
+* If not, we copy the connecting AP's MAC address to it so that
 * the driver just has the bssid information for PMKIDList searching.
 */
if (!pmlmepriv->assoc_by_bssid)
@@ -519,7 +520,8 @@ u8 r8712_joinbss_cmd(struct _adapter  *padapter, struct 
wlan_network *pnetwork)
}
}
if (pregistrypriv->ht_enable) {
-   /* For WEP mode, we will use the bg mode to do the connection
+   /*
+* For WEP mode, we will use the bg mode to do the connection
 * to avoid some IOT issues, especially for Realtek 8192u
 * SoftAP.
 */
@@ -904,8 +906,10 @@ void r8712_createbss_cmd_callback(struct _adapter 
*padapter,
(r8712_get_wlan_bssid_ex_sz(pnetwork)));
if (pmlmepriv->fw_state & _FW_UNDER_LINKING)
pmlmepriv->fw_state ^= _FW_UNDER_LINKING;
-   /* we will set _FW_LINKED when there is one more sat to
-* join us (stassoc_event_callback) */
+   /*
+* we will set _FW_LINKED when there is one more sat to
+* join us (stassoc_event_callback)
+*/
}
 createbss_cmd_fail:
spin_unlock_irqrestore(>lock, irqL);
-- 
2.8.2

[PATCH] arm64/efi: efi_init error handling fix

[Xie Yisheng]

From: Yisheng Xie 

There's an early memmap leak in efi_init error path, fix it.

Signed-off-by: Yisheng Xie 
---
 drivers/firmware/efi/arm-init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index c49d50e..5080e40 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -243,8 +243,10 @@ void __init efi_init(void)
 "Unexpected EFI_MEMORY_DESCRIPTOR version %ld",
  efi.memmap.desc_version);
 
-   if (uefi_init() < 0)
+   if (uefi_init() < 0) {
+   early_memunmap(efi.memmap.map, params.mmap_size);
return;
+   }
 
reserve_regions();
efi_memattr_init();
-- 
1.7.12.4

[PATCH 2/3] staging: rtl8172: fixed comment style in rts871x_cmd.c

[Louie Lu]

Fixed comment style warning by checkpatch:

* Block comments use * on subsequent lines
* Block comments use a trailing */ on a separate line

Signed-off-by: Louie Lu 
---
 drivers/staging/rtl8712/rtl871x_cmd.c | 46 +++
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c 
b/drivers/staging/rtl8712/rtl871x_cmd.c
index 5838696..51b6959 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -51,9 +51,9 @@
 #include "mlme_osdep.h"
 
 /*
-Caller and the r8712_cmd_thread can protect cmd_q by spin_lock.
-No irqsave is necessary.
-*/
+ * Caller and the r8712_cmd_thread can protect cmd_q by spin_lock.
+ * No irqsave is necessary.
+ */
 
 static sint _init_cmd_priv(struct cmd_priv *pcmdpriv)
 {
@@ -110,14 +110,14 @@ static void _free_cmd_priv(struct cmd_priv *pcmdpriv)
 }
 
 /*
-Calling Context:
-
-_enqueue_cmd can only be called between kernel thread,
-since only spin_lock is used.
-
-ISR/Call-Back functions can't call this sub-function.
-
-*/
+ * Calling Context:
+ *
+ * _enqueue_cmd can only be called between kernel thread,
+ * since only spin_lock is used.
+ *
+ * ISR/Call-Back functions can't call this sub-function.
+ *
+ */
 
 static sint _enqueue_cmd(struct  __queue *queue, struct cmd_obj *obj)
 {
@@ -211,11 +211,11 @@ void r8712_free_cmd_obj(struct cmd_obj *pcmd)
 }
 
 /*
-r8712_sitesurvey_cmd(~)
-   ### NOTE: ()
-   MUST TAKE CARE THAT BEFORE CALLING THIS FUNC,
-YOU SHOULD HAVE LOCKED pmlmepriv->lock
-*/
+ * r8712_sitesurvey_cmd(~)
+ * ### NOTE: ()
+ * MUST TAKE CARE THAT BEFORE CALLING THIS FUNC,
+ * YOU SHOULD HAVE LOCKED pmlmepriv->lock
+ */
 u8 r8712_sitesurvey_cmd(struct _adapter *padapter,
struct ndis_802_11_ssid *pssid)
 {
@@ -491,8 +491,9 @@ u8 r8712_joinbss_cmd(struct _adapter  *padapter, struct 
wlan_network *pnetwork)
memcpy(>authenticator_ie[1],
>IEs[12], (256 - 1));
psecnetwork->IELength = 0;
-   /* If the driver wants to use the bssid to create the connection.
-* If not,  we copy the connecting AP's MAC address to it so that
+   /*
+* If the driver wants to use the bssid to create the connection.
+* If not, we copy the connecting AP's MAC address to it so that
 * the driver just has the bssid information for PMKIDList searching.
 */
if (!pmlmepriv->assoc_by_bssid)
@@ -519,7 +520,8 @@ u8 r8712_joinbss_cmd(struct _adapter  *padapter, struct 
wlan_network *pnetwork)
}
}
if (pregistrypriv->ht_enable) {
-   /* For WEP mode, we will use the bg mode to do the connection
+   /*
+* For WEP mode, we will use the bg mode to do the connection
 * to avoid some IOT issues, especially for Realtek 8192u
 * SoftAP.
 */
@@ -904,8 +906,10 @@ void r8712_createbss_cmd_callback(struct _adapter 
*padapter,
(r8712_get_wlan_bssid_ex_sz(pnetwork)));
if (pmlmepriv->fw_state & _FW_UNDER_LINKING)
pmlmepriv->fw_state ^= _FW_UNDER_LINKING;
-   /* we will set _FW_LINKED when there is one more sat to
-* join us (stassoc_event_callback) */
+   /*
+* we will set _FW_LINKED when there is one more sat to
+* join us (stassoc_event_callback)
+*/
}
 createbss_cmd_fail:
spin_unlock_irqrestore(>lock, irqL);
-- 
2.8.2

Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64

[Bamvor Jian Zhang]

Base on the off-list discussion, the community care about the
performance regression of aarch64 LP64 and aarch32 after ILP32
is merged.

Given that there is not big open issue in ILP32 in kernel part, I try
to address this concern. It is reasonable that we should run lots of
testsuite(such as LKP) to ensure there is no performance regression.
But I am not expert of this, I started from test the lmbench for
aarch64 LP64 and compare the differnce between ILP32 enabled and
without ILP32 patches.

The branch I used is ilp32-4.8 on [1], compare the result between
two commit "d3746f1 arm64:ilp32: add ARM64_ILP32 to Kconfig"(defconfig
with CONFIG_ARM64_ILP32) and "3054de8 fiz set_personality by Catalin"
(defconfig).

The result show there is no big difference. Most of the difference is
less than 5%. Only two differnce more than 10%:
1.  Context switching 2p/16K 13.16%(ILP32 is bigger than No_ILP32.
smaller is better)
2.  *Local* Communication bandwidths: TCP -10.77%.(ILP32 is smaller than
No_ILP32. bigger is better).


If it is make sense to community, I could continue to do more that.

Thanks

Bamvor

[1] https://github.com/norov/linux.git
[2] The full result: (ILP32 - No_ILP32)/No_ILP32

 L M B E N C H  3 . 0   S U M M A R Y
 
 (Alpha software, do not distribute)

Basic system parameters
--
Host OS Description  Mhz  tlb  cache  mem   scal
 pages line   par   load
   bytes
- - ---  - - -- 
buildroot Linux 4.8.0-r A64_ILP32_diff_No_ILP32 102432   128 0.23% 1

Processor, Processes - times in microseconds - smaller is better
--
Host OS  Mhz null null  open slct sig  sig  fork exec sh
 call  I/O stat clos TCP  inst hndl proc proc proc
- -           
buildroot Linux 4.8.0-r 0.00% 0.00% 0.00% -3.03% -0.42% -1.96% 0.00% -0.67% 
2.29% -6.34% 0.85%

Basic integer operations - times in nanoseconds - smaller is better
---
Host OS  intgr intgr  intgr  intgr  intgr
  bit   addmuldivmod
- - -- -- -- -- --
buildroot Linux 4.8.0-r 0.00%  0.00%  0.00%  0.00%  0.00%

Basic uint64 operations - times in nanoseconds - smaller is better
--
Host OS int64  int64  int64  int64  int64
 bitaddmuldivmod
- - -- -- -- -- --
buildroot Linux 4.8.0-r  0.00%0.00%  0.00%  0.00%

Basic float operations - times in nanoseconds - smaller is better
-
Host OS  float  float  float  float
 addmuldivbogo
- - -- -- -- --
buildroot Linux 4.8.0-r 0.00%  0.00%  0.04%  0.00%

Basic double operations - times in nanoseconds - smaller is better
--
Host OS  double double double double
 addmuldivbogo
- - --  -- -- --
buildroot Linux 4.8.0-r 0.00%  0.00%0.00%  0.00%

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
- - -- -- -- -- -- --- ---
buildroot Linux 4.8.0-r  -6.00%  13.16% -1.83% 3.80%  9.94%  -6.17%   2.72%

*Local* Communication latencies in microseconds - smaller is better
-
Host OS 2p/0K  Pipe AF UDP  RPC/   TCP  RPC/ TCP
ctxsw   UNIX UDP TCP conn
- - - -  - - - - 
buildroot Linux 4.8.0-r -6.00% -4.08% 1.95% -5.02%4.87% 0.00%


File & VM system latencies in microseconds - smaller is better
---
Host OS   0K File  10K File MmapProt   Page   100fd
Create Delete Create Delete Latency Fault  Fault  selct
- - -- -- -- -- --- - --- -
buildroot 

Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64

[Bamvor Jian Zhang]

Base on the off-list discussion, the community care about the
performance regression of aarch64 LP64 and aarch32 after ILP32
is merged.

Given that there is not big open issue in ILP32 in kernel part, I try
to address this concern. It is reasonable that we should run lots of
testsuite(such as LKP) to ensure there is no performance regression.
But I am not expert of this, I started from test the lmbench for
aarch64 LP64 and compare the differnce between ILP32 enabled and
without ILP32 patches.

The branch I used is ilp32-4.8 on [1], compare the result between
two commit "d3746f1 arm64:ilp32: add ARM64_ILP32 to Kconfig"(defconfig
with CONFIG_ARM64_ILP32) and "3054de8 fiz set_personality by Catalin"
(defconfig).

The result show there is no big difference. Most of the difference is
less than 5%. Only two differnce more than 10%:
1.  Context switching 2p/16K 13.16%(ILP32 is bigger than No_ILP32.
smaller is better)
2.  *Local* Communication bandwidths: TCP -10.77%.(ILP32 is smaller than
No_ILP32. bigger is better).


If it is make sense to community, I could continue to do more that.

Thanks

Bamvor

[1] https://github.com/norov/linux.git
[2] The full result: (ILP32 - No_ILP32)/No_ILP32

 L M B E N C H  3 . 0   S U M M A R Y
 
 (Alpha software, do not distribute)

Basic system parameters
--
Host OS Description  Mhz  tlb  cache  mem   scal
 pages line   par   load
   bytes
- - ---  - - -- 
buildroot Linux 4.8.0-r A64_ILP32_diff_No_ILP32 102432   128 0.23% 1

Processor, Processes - times in microseconds - smaller is better
--
Host OS  Mhz null null  open slct sig  sig  fork exec sh
 call  I/O stat clos TCP  inst hndl proc proc proc
- -           
buildroot Linux 4.8.0-r 0.00% 0.00% 0.00% -3.03% -0.42% -1.96% 0.00% -0.67% 
2.29% -6.34% 0.85%

Basic integer operations - times in nanoseconds - smaller is better
---
Host OS  intgr intgr  intgr  intgr  intgr
  bit   addmuldivmod
- - -- -- -- -- --
buildroot Linux 4.8.0-r 0.00%  0.00%  0.00%  0.00%  0.00%

Basic uint64 operations - times in nanoseconds - smaller is better
--
Host OS int64  int64  int64  int64  int64
 bitaddmuldivmod
- - -- -- -- -- --
buildroot Linux 4.8.0-r  0.00%0.00%  0.00%  0.00%

Basic float operations - times in nanoseconds - smaller is better
-
Host OS  float  float  float  float
 addmuldivbogo
- - -- -- -- --
buildroot Linux 4.8.0-r 0.00%  0.00%  0.04%  0.00%

Basic double operations - times in nanoseconds - smaller is better
--
Host OS  double double double double
 addmuldivbogo
- - --  -- -- --
buildroot Linux 4.8.0-r 0.00%  0.00%0.00%  0.00%

Context switching - times in microseconds - smaller is better
-
Host OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
 ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
- - -- -- -- -- -- --- ---
buildroot Linux 4.8.0-r  -6.00%  13.16% -1.83% 3.80%  9.94%  -6.17%   2.72%

*Local* Communication latencies in microseconds - smaller is better
-
Host OS 2p/0K  Pipe AF UDP  RPC/   TCP  RPC/ TCP
ctxsw   UNIX UDP TCP conn
- - - -  - - - - 
buildroot Linux 4.8.0-r -6.00% -4.08% 1.95% -5.02%4.87% 0.00%


File & VM system latencies in microseconds - smaller is better
---
Host OS   0K File  10K File MmapProt   Page   100fd
Create Delete Create Delete Latency Fault  Fault  selct
- - -- -- -- -- --- - --- -
buildroot 

Re: [PATCH 1/2] ARM: dts: am57xx-beagle-x15: Remove pinmux configurations

[Sekhar Nori]

On Friday 02 September 2016 02:35 PM, Nishanth Menon wrote:
> pinmuxing for DRA7x/AM57x family of processors need to be done in IO
> isolation as part of initial bootloader executed from SRAM. This is
> done as part of iodelay configuration sequence and is required due to
> the limitations introduced by erratum ID: i869[1] and elaborated in
> the Technical Reference Manual[2] 18.4.6.1.7 Isolation Requirements.
> 
> Only peripheral that is permitted for dynamic pin mux configuration is
> MMC. This is to accommodate the requirements for varied speeds (which

Actually its MMC and DCAN. DCAN because of i893 ("DCAN Initialization
Sequence"). But I can see you may have omitted reference to it since
DCAN is not really used on the x15.

Thanks,
Sekhar

Re: [PATCH 1/2] ARM: dts: am57xx-beagle-x15: Remove pinmux configurations

[Sekhar Nori]

On Friday 02 September 2016 02:35 PM, Nishanth Menon wrote:
> pinmuxing for DRA7x/AM57x family of processors need to be done in IO
> isolation as part of initial bootloader executed from SRAM. This is
> done as part of iodelay configuration sequence and is required due to
> the limitations introduced by erratum ID: i869[1] and elaborated in
> the Technical Reference Manual[2] 18.4.6.1.7 Isolation Requirements.
> 
> Only peripheral that is permitted for dynamic pin mux configuration is
> MMC. This is to accommodate the requirements for varied speeds (which

Actually its MMC and DCAN. DCAN because of i893 ("DCAN Initialization
Sequence"). But I can see you may have omitted reference to it since
DCAN is not really used on the x15.

Thanks,
Sekhar

Re: [PATCH 0/2] fusion: Remove deprecated create_singlethread_workqueue

[Martin K. Petersen]

> "Bhaktipriya" == Bhaktipriya Shridhar  writes:

Bhaktipriya> This patch set removes deprecated
Bhaktipriya> create_singlethread_workqueue instances from
Bhaktipriya> drivers/message

Applied to 4.9/scsi-queue.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH 3/3] staging: rtl8712: fixed comment style and space indent

[Louie Lu]

fixed comment style and space indent report from checkpatch:

* WARNING: Statements should start on a tabstop
* WARNING: Block comments use * on subsequent lines
* WARNING: suspect code indent for conditional statements (16, 32)

Signed-off-by: Louie Lu 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 37 ---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index e205adf..5c05f21 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -422,7 +422,8 @@ static int wpa_set_encryption(struct net_device *dev, 
struct ieee_param *param,
(u8)_FAIL)
ret = -EOPNOTSUPP;
} else {
-   /* don't update "psecuritypriv->PrivacyAlgrthm" and
+   /* 
+* don't update "psecuritypriv->PrivacyAlgrthm" and
 * "psecuritypriv->PrivacyKeyIndex=keyid", but can
 * r8712_set_key to fw/cam
 */
@@ -664,7 +665,7 @@ static int r8711_wx_set_freq(struct net_device *dev,
struct iw_freq *fwrq = >freq;
int rc = 0;
 
-/* If setting by frequency, convert to a channel */
+   /* If setting by frequency, convert to a channel */
if ((fwrq->e == 1) &&
  (fwrq->m >= (int) 2.412e8) &&
  (fwrq->m <= (int) 2.487e8)) {
@@ -827,7 +828,8 @@ static int r871x_wx_set_pmkid(struct net_device *dev,
for (j = 0; j < NUM_PMKID_CACHE; j++) {
if (!memcmp(psecuritypriv->PMKIDList[j].Bssid,
strIssueBssid, ETH_ALEN)) {
-   /* BSSID is matched, the same AP => Remove
+   /* 
+*BSSID is matched, the same AP => Remove
 * this PMKID information and reset it.
 */

eth_zero_addr(psecuritypriv->PMKIDList[j].Bssid);
@@ -870,11 +872,13 @@ static int r8711_wx_get_range(struct net_device *dev,
 
wrqu->data.length = sizeof(*range);
memset(range, 0, sizeof(*range));
-   /* Let's try to keep this struct in the same order as in
+   /* 
+* Let's try to keep this struct in the same order as in
 * linux/include/wireless.h
 */
 
-   /* TODO: See what values we can set, and remove the ones we can't
+   /* 
+* TODO: See what values we can set, and remove the ones we can't
 * set, or fill them with some default data.
 */
/* ~5 Mb/s real (802.11b) */
@@ -1714,7 +1718,8 @@ static int r871x_wx_set_auth(struct net_device *dev,
}
break;
case IW_AUTH_DROP_UNENCRYPTED:
-   /* HACK:
+   /* 
+* HACK:
 *
 * wpa_supplicant calls set_wpa_enabled when the driver
 * is loaded and unloaded, regardless of if WPA is being
@@ -1727,12 +1732,13 @@ static int r871x_wx_set_auth(struct net_device *dev,
 */
if (padapter->securitypriv.ndisencryptstatus ==
Ndis802_11Encryption1Enabled) {
-   /* it means init value, or using wep,
-* ndisencryptstatus =
-*  Ndis802_11Encryption1Enabled,
-* then it needn't reset it;
-*/
-   break;
+   /* 
+* it means init value, or using wep,
+* ndisencryptstatus =
+*  Ndis802_11Encryption1Enabled,
+* then it needn't reset it;
+*/
+   break;
}
 
if (paramval) {
@@ -1976,9 +1982,9 @@ static int r871x_get_ap_info(struct net_device *dev,
if (pdata->length >= 32) {
if (copy_from_user(data, pdata->pointer, 32))
return -EINVAL;
-data[32] = 0;
+   data[32] = 0;
} else {
-return -EINVAL;
+   return -EINVAL;
}
spin_lock_irqsave(&(pmlmepriv->scanned_queue.lock), irqL);
phead = >queue;
@@ -2107,7 +2113,8 @@ static int wpa_set_param(struct net_device *dev, u8 name, 
u32 value)
case IEEE_PARAM_TKIP_COUNTERMEASURES:
break;
case IEEE_PARAM_DROP_UNENCRYPTED:
-   /* HACK:
+   /* 
+* HACK:
 *
 * wpa_supplicant calls set_wpa_enabled when the driver
 * is loaded and unloaded, regardless of if WPA is 

Re: [PATCH 0/2] fusion: Remove deprecated create_singlethread_workqueue

[Martin K. Petersen]

> "Bhaktipriya" == Bhaktipriya Shridhar  writes:

Bhaktipriya> This patch set removes deprecated
Bhaktipriya> create_singlethread_workqueue instances from
Bhaktipriya> drivers/message

Applied to 4.9/scsi-queue.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH 3/3] staging: rtl8712: fixed comment style and space indent

[Louie Lu]

fixed comment style and space indent report from checkpatch:

* WARNING: Statements should start on a tabstop
* WARNING: Block comments use * on subsequent lines
* WARNING: suspect code indent for conditional statements (16, 32)

Signed-off-by: Louie Lu 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 37 ---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index e205adf..5c05f21 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -422,7 +422,8 @@ static int wpa_set_encryption(struct net_device *dev, 
struct ieee_param *param,
(u8)_FAIL)
ret = -EOPNOTSUPP;
} else {
-   /* don't update "psecuritypriv->PrivacyAlgrthm" and
+   /* 
+* don't update "psecuritypriv->PrivacyAlgrthm" and
 * "psecuritypriv->PrivacyKeyIndex=keyid", but can
 * r8712_set_key to fw/cam
 */
@@ -664,7 +665,7 @@ static int r8711_wx_set_freq(struct net_device *dev,
struct iw_freq *fwrq = >freq;
int rc = 0;
 
-/* If setting by frequency, convert to a channel */
+   /* If setting by frequency, convert to a channel */
if ((fwrq->e == 1) &&
  (fwrq->m >= (int) 2.412e8) &&
  (fwrq->m <= (int) 2.487e8)) {
@@ -827,7 +828,8 @@ static int r871x_wx_set_pmkid(struct net_device *dev,
for (j = 0; j < NUM_PMKID_CACHE; j++) {
if (!memcmp(psecuritypriv->PMKIDList[j].Bssid,
strIssueBssid, ETH_ALEN)) {
-   /* BSSID is matched, the same AP => Remove
+   /* 
+*BSSID is matched, the same AP => Remove
 * this PMKID information and reset it.
 */

eth_zero_addr(psecuritypriv->PMKIDList[j].Bssid);
@@ -870,11 +872,13 @@ static int r8711_wx_get_range(struct net_device *dev,
 
wrqu->data.length = sizeof(*range);
memset(range, 0, sizeof(*range));
-   /* Let's try to keep this struct in the same order as in
+   /* 
+* Let's try to keep this struct in the same order as in
 * linux/include/wireless.h
 */
 
-   /* TODO: See what values we can set, and remove the ones we can't
+   /* 
+* TODO: See what values we can set, and remove the ones we can't
 * set, or fill them with some default data.
 */
/* ~5 Mb/s real (802.11b) */
@@ -1714,7 +1718,8 @@ static int r871x_wx_set_auth(struct net_device *dev,
}
break;
case IW_AUTH_DROP_UNENCRYPTED:
-   /* HACK:
+   /* 
+* HACK:
 *
 * wpa_supplicant calls set_wpa_enabled when the driver
 * is loaded and unloaded, regardless of if WPA is being
@@ -1727,12 +1732,13 @@ static int r871x_wx_set_auth(struct net_device *dev,
 */
if (padapter->securitypriv.ndisencryptstatus ==
Ndis802_11Encryption1Enabled) {
-   /* it means init value, or using wep,
-* ndisencryptstatus =
-*  Ndis802_11Encryption1Enabled,
-* then it needn't reset it;
-*/
-   break;
+   /* 
+* it means init value, or using wep,
+* ndisencryptstatus =
+*  Ndis802_11Encryption1Enabled,
+* then it needn't reset it;
+*/
+   break;
}
 
if (paramval) {
@@ -1976,9 +1982,9 @@ static int r871x_get_ap_info(struct net_device *dev,
if (pdata->length >= 32) {
if (copy_from_user(data, pdata->pointer, 32))
return -EINVAL;
-data[32] = 0;
+   data[32] = 0;
} else {
-return -EINVAL;
+   return -EINVAL;
}
spin_lock_irqsave(&(pmlmepriv->scanned_queue.lock), irqL);
phead = >queue;
@@ -2107,7 +2113,8 @@ static int wpa_set_param(struct net_device *dev, u8 name, 
u32 value)
case IEEE_PARAM_TKIP_COUNTERMEASURES:
break;
case IEEE_PARAM_DROP_UNENCRYPTED:
-   /* HACK:
+   /* 
+* HACK:
 *
 * wpa_supplicant calls set_wpa_enabled when the driver
 * is loaded and unloaded, regardless of if WPA is being
-- 
2.8.2

[PATCH 0/3] staging: rtl8712: fixed indent and comment style in code

[Louie Lu]

This patchsets cleanup some warning report from checkpatch

Including:
  * space indent
  * bad comment style

Louie Lu (3):
  staging: rtl8712: delete one space before if statement
  staging: rtl8172: fixed comment style in rts871x_cmd.c
  staging: rtl8712: fixed comment style and space indent

 drivers/staging/rtl8712/os_intfs.c|  2 +-
 drivers/staging/rtl8712/rtl871x_cmd.c | 46 +++
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 37 -
 3 files changed, 48 insertions(+), 37 deletions(-)

-- 
2.8.2

[PATCH 0/3] staging: rtl8712: fixed indent and comment style in code

[Louie Lu]

This patchsets cleanup some warning report from checkpatch

Including:
  * space indent
  * bad comment style

Louie Lu (3):
  staging: rtl8712: delete one space before if statement
  staging: rtl8172: fixed comment style in rts871x_cmd.c
  staging: rtl8712: fixed comment style and space indent

 drivers/staging/rtl8712/os_intfs.c|  2 +-
 drivers/staging/rtl8712/rtl871x_cmd.c | 46 +++
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 37 -
 3 files changed, 48 insertions(+), 37 deletions(-)

-- 
2.8.2

Re: [PATCH] bfa: do not dereference port before it is null checked

[Martin K. Petersen]

> "Colin" == Colin King  writes:

Colin> port is deferenced before it is null sanity checked, hence we
Colin> potentially have a null pointer dereference bug. Instead,
Colin> initialise trl_enabled from port->fcs->bfa after we are sure port
Colin> is not null.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] bfa: do not dereference port before it is null checked

[Martin K. Petersen]

> "Colin" == Colin King  writes:

Colin> port is deferenced before it is null sanity checked, hence we
Colin> potentially have a null pointer dereference bug. Instead,
Colin> initialise trl_enabled from port->fcs->bfa after we are sure port
Colin> is not null.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: alloc_pages_exact() triggering memory fragmentation on nommu?

[Nikita Yushchenko]

> I'm having a guess that this can be caused by use of
> alloc_pages_exact() for NoMMU private anonymous mappings.
> 
> This routine causes "tail" of allocation to be returned back
> to allocator... and inserted at top of free list. Later, when
> whatever in the system makes a trivial order-0 allocation, these
> just-freed tails immediately get used (because free pages are
> inserted at end of free lists... and new pages are allocated
> from either beginning or end of free list, depending on 'cold'
> parameter).  At a glance, this should have a net effect of much
> increased probability of "tail" of large allocation get used
> as a small allocation, and thus inability to rebuild a large free
> block at time when large allocation is freed.
> 
> Is there any protection against this effect in the allocator
> of current kernels? (kernel of system in question is somewhat
> outdated)

Just a small followup to whoever may be interested.

The guess was correct.

In old 3.0.8 kernel running on system in question, do_mmap_private() in
mm/nommu.c did not yet use alloc_pages_exact() but instead had it's own
implementation of the same logic.  And there was a tunable
'nr_trim_pages' that could alter it. In particular setting that tunable
to 0 effectively disabled any freeing of tails.

We tried to set nr_trim_pages=0 and fragmentation issue went away.


Nikita

Re: alloc_pages_exact() triggering memory fragmentation on nommu?

[Nikita Yushchenko]

> I'm having a guess that this can be caused by use of
> alloc_pages_exact() for NoMMU private anonymous mappings.
> 
> This routine causes "tail" of allocation to be returned back
> to allocator... and inserted at top of free list. Later, when
> whatever in the system makes a trivial order-0 allocation, these
> just-freed tails immediately get used (because free pages are
> inserted at end of free lists... and new pages are allocated
> from either beginning or end of free list, depending on 'cold'
> parameter).  At a glance, this should have a net effect of much
> increased probability of "tail" of large allocation get used
> as a small allocation, and thus inability to rebuild a large free
> block at time when large allocation is freed.
> 
> Is there any protection against this effect in the allocator
> of current kernels? (kernel of system in question is somewhat
> outdated)

Just a small followup to whoever may be interested.

The guess was correct.

In old 3.0.8 kernel running on system in question, do_mmap_private() in
mm/nommu.c did not yet use alloc_pages_exact() but instead had it's own
implementation of the same logic.  And there was a tunable
'nr_trim_pages' that could alter it. In particular setting that tunable
to 0 effectively disabled any freeing of tails.

We tried to set nr_trim_pages=0 and fragmentation issue went away.


Nikita

Re: [PATCH] [SCSI] qla4xxx: mark symbols static where possible

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 1 warning when build kernel with W=1:
Baoyou> drivers/scsi/qla4xxx/ql4_nx.c:1846:10: warning: no previous
Baoyou> prototype for 'ql4_84xx_ipmdio_rd_reg' [-Wmissing-prototypes]

Baoyou> In fact, this function is only used in the file in which it is
Baoyou> declared and don't need a declaration, but can be made static.
Baoyou> so this patch marks this function with 'static'.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] [SCSI] qla4xxx: mark symbols static where possible

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 1 warning when build kernel with W=1:
Baoyou> drivers/scsi/qla4xxx/ql4_nx.c:1846:10: warning: no previous
Baoyou> prototype for 'ql4_84xx_ipmdio_rd_reg' [-Wmissing-prototypes]

Baoyou> In fact, this function is only used in the file in which it is
Baoyou> declared and don't need a declaration, but can be made static.
Baoyou> so this patch marks this function with 'static'.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver

[Mark Rutland]

On Thu, Sep 01, 2016 at 05:30:52PM +0100, Mark Rutland wrote:
> On Tue, Aug 30, 2016 at 01:01:33PM -0400, Neil Leeder wrote:
> > +static DEFINE_MUTEX(l2cache_pmu_mutex);
> 
> A mutex (which can sleep) is not safe for the hotplug state machine
> stuff. See recent patches to the arm_pmu code.
> 
> That's further subsumed by the multi-instance stuff, so this (and the
> list) will not be necessary shortly.

This has *just* landed in tip. See the smp/hotplug branch [1]. The
arm_pmu change [2] should serve as an example of what to do.

Thanks,
Mark.

[1] https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=smp/hotplug
[2] 
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=smp/hotplug=cc727977acb0fe05b7aa1f00cccb893530820895

Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver

[Mark Rutland]

On Thu, Sep 01, 2016 at 05:30:52PM +0100, Mark Rutland wrote:
> On Tue, Aug 30, 2016 at 01:01:33PM -0400, Neil Leeder wrote:
> > +static DEFINE_MUTEX(l2cache_pmu_mutex);
> 
> A mutex (which can sleep) is not safe for the hotplug state machine
> stuff. See recent patches to the arm_pmu code.
> 
> That's further subsumed by the multi-instance stuff, so this (and the
> list) will not be necessary shortly.

This has *just* landed in tip. See the smp/hotplug branch [1]. The
arm_pmu change [2] should serve as an example of what to do.

Thanks,
Mark.

[1] https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=smp/hotplug
[2] 
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=smp/hotplug=cc727977acb0fe05b7aa1f00cccb893530820895

Re: [Patch v4 01/12] microblaze: irqchip: Move intc driver to irqchip

[Zubair Lutfullah Kakakhel]

Hi,

On 09/02/2016 07:25 AM, Michal Simek wrote:

On 1.9.2016 18:50, Zubair Lutfullah Kakakhel wrote:

The Xilinx AXI Interrupt Controller IP block is used by the MIPS
based xilfpga platform.

Move the interrupt controller code out of arch/microblaze so that
it can be used by everyone

Signed-off-by: Zubair Lutfullah Kakakhel 

---
V3 -> V4
No change

V2 -> V3
No change here. Cleanup patches follow after this patch.
Its debatable to cleanup before/after move. Decided to place cleanup
after move to put history in new place.

V1 -> V2

Renamed irq-xilinx to irq-axi-intc
Renamed CONFIG_XILINX_INTC to CONFIG_XILINX_AXI_INTC



I see that this was suggested by Jason Cooper but using axi name here is
not correct.
There is xps-intc name which is the name used on old OPB hardware
designs. It means this driver can be still used only on system which
uses it.


Wouldn't axi-intc be more suitable moving forwards?
The IP block is now known as axi intc for 5 years as far as I can tell.

Searching "axi intc" online results in the right docs for current and
future platforms.

The binding is still xps-intc as that won't change. So older systems
should still be able to find their way.


Also there is another copy of this driver in the tree which was using
old ppc405 and ppc440 xilinx platforms.

arch/powerpc/include/asm/xilinx_intc.h
arch/powerpc/sysdev/xilinx_intc.c

These should be also removed by moving this driver to generic folder.


I didn't know about that drivers existence.

This patch series already touches microblaze, mips and irqchip.
Both microblaze and mips platforms using this driver are little-endian.

Adding a big-endian powerpc driver + platform to the mix is going to complicate
the series further and make it super hard to synchronize various subsystems,
test stuff, and then move the drivers without breakage.

I'd highly recommend letting this move happen. And then the powerpc driver can
transition over time to this driver.

Regards,
ZubairLK



Thanks,
Michal

Re: [Patch v4 01/12] microblaze: irqchip: Move intc driver to irqchip

[Zubair Lutfullah Kakakhel]

Hi,

On 09/02/2016 07:25 AM, Michal Simek wrote:

On 1.9.2016 18:50, Zubair Lutfullah Kakakhel wrote:

The Xilinx AXI Interrupt Controller IP block is used by the MIPS
based xilfpga platform.

Move the interrupt controller code out of arch/microblaze so that
it can be used by everyone

Signed-off-by: Zubair Lutfullah Kakakhel 

---
V3 -> V4
No change

V2 -> V3
No change here. Cleanup patches follow after this patch.
Its debatable to cleanup before/after move. Decided to place cleanup
after move to put history in new place.

V1 -> V2

Renamed irq-xilinx to irq-axi-intc
Renamed CONFIG_XILINX_INTC to CONFIG_XILINX_AXI_INTC



I see that this was suggested by Jason Cooper but using axi name here is
not correct.
There is xps-intc name which is the name used on old OPB hardware
designs. It means this driver can be still used only on system which
uses it.


Wouldn't axi-intc be more suitable moving forwards?
The IP block is now known as axi intc for 5 years as far as I can tell.

Searching "axi intc" online results in the right docs for current and
future platforms.

The binding is still xps-intc as that won't change. So older systems
should still be able to find their way.


Also there is another copy of this driver in the tree which was using
old ppc405 and ppc440 xilinx platforms.

arch/powerpc/include/asm/xilinx_intc.h
arch/powerpc/sysdev/xilinx_intc.c

These should be also removed by moving this driver to generic folder.


I didn't know about that drivers existence.

This patch series already touches microblaze, mips and irqchip.
Both microblaze and mips platforms using this driver are little-endian.

Adding a big-endian powerpc driver + platform to the mix is going to complicate
the series further and make it super hard to synchronize various subsystems,
test stuff, and then move the drivers without breakage.

I'd highly recommend letting this move happen. And then the powerpc driver can
transition over time to this driver.

Regards,
ZubairLK



Thanks,
Michal

Re: [PATCH 0/6] constify snd_pcm_ops structures

[Julia Lawall]

On Fri, 2 Sep 2016, Takashi Iwai wrote:

> On Fri, 02 Sep 2016 00:13:08 +0200,
> Julia Lawall wrote:
> >
> > Constify snd_pcm_ops structures.
>
> Applied all six patches now.  Thanks.

Thanks.  There are a bunch more for this type, for other directories.  I
will send them shortly.

julia

Re: [PATCH 0/6] constify snd_pcm_ops structures

[Julia Lawall]

On Fri, 2 Sep 2016, Takashi Iwai wrote:

> On Fri, 02 Sep 2016 00:13:08 +0200,
> Julia Lawall wrote:
> >
> > Constify snd_pcm_ops structures.
>
> Applied all six patches now.  Thanks.

Thanks.  There are a bunch more for this type, for other directories.  I
will send them shortly.

julia

Re: [PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes

[Suzuki K Poulose]

On 26/08/16 18:00, Catalin Marinas wrote:

On Fri, Aug 26, 2016 at 05:16:27PM +0100, Will Deacon wrote:

On Fri, Aug 26, 2016 at 02:08:01PM +0100, Suzuki K Poulose wrote:

On 26/08/16 14:04, Suzuki K Poulose wrote:



It might be worth looking to see if we can pass the ctr as an extra
parameter to the assembly routines that need it. Then you can access it
easily from C code, and if you pass it as 0 that could result in the asm
code reading it from the h/w register, removing the need for the _raw
stuff you add.


How often to we need to access a sanitised sysreg from assembly? AFAICT,
CTR_EL0 is the first. If we only need it to infer the minimum cache line
size, we could as well store the latter in a global variable and access
it directly. If we feel brave, we could patch a "mov \reg, #x"
instruction in the ?cache_line_size macros (starting with 32 by default,
though to make it less cumbersome we'd have to improve the run-time
patching code a bit).



With Ard's patches [1] to refactor the feature array, we can refer to named
CTR_EL0 feature register cleanly. I can rebase this series on top of that
if nobody has any objection.

[1] http://marc.info/?l=linux-arm-kernel=147263959504998=2


Suzuki

Re: [PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes

[Suzuki K Poulose]

On 26/08/16 18:00, Catalin Marinas wrote:

On Fri, Aug 26, 2016 at 05:16:27PM +0100, Will Deacon wrote:

On Fri, Aug 26, 2016 at 02:08:01PM +0100, Suzuki K Poulose wrote:

On 26/08/16 14:04, Suzuki K Poulose wrote:



It might be worth looking to see if we can pass the ctr as an extra
parameter to the assembly routines that need it. Then you can access it
easily from C code, and if you pass it as 0 that could result in the asm
code reading it from the h/w register, removing the need for the _raw
stuff you add.


How often to we need to access a sanitised sysreg from assembly? AFAICT,
CTR_EL0 is the first. If we only need it to infer the minimum cache line
size, we could as well store the latter in a global variable and access
it directly. If we feel brave, we could patch a "mov \reg, #x"
instruction in the ?cache_line_size macros (starting with 32 by default,
though to make it less cumbersome we'd have to improve the run-time
patching code a bit).



With Ard's patches [1] to refactor the feature array, we can refer to named
CTR_EL0 feature register cleanly. I can rebase this series on top of that
if nobody has any objection.

[1] http://marc.info/?l=linux-arm-kernel=147263959504998=2


Suzuki

Re: [PATCH 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Nishanth Menon]

On 09/02/2016 04:58 AM, Tomi Valkeinen wrote:

On 02/09/16 12:06, Nishanth Menon wrote:


diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
new file mode 100644
index ..da61dbba7768
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am57xx-beagle-x15-common.dtsi"
+
+/ {
+   model = "TI AM5728 BeagleBoard-X15 rev B1";
+};
+
+ {
+   gpios = < 10 GPIO_ACTIVE_HIGH>, /* gpio7_10, CT CP HPD */
+   < 30 GPIO_ACTIVE_HIGH>, /* gpio6_30, LS OE */


Wrong gpio in the comment.


Uggh.. thanks for catching that.. should have been gpio2_30

will repost a v2 if there are no further comments at the end of the day..


--
Regards,
Nishanth Menon

Re: [PATCH 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Nishanth Menon]

On 09/02/2016 04:58 AM, Tomi Valkeinen wrote:

On 02/09/16 12:06, Nishanth Menon wrote:


diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
new file mode 100644
index ..da61dbba7768
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am57xx-beagle-x15-common.dtsi"
+
+/ {
+   model = "TI AM5728 BeagleBoard-X15 rev B1";
+};
+
+ {
+   gpios = < 10 GPIO_ACTIVE_HIGH>, /* gpio7_10, CT CP HPD */
+   < 30 GPIO_ACTIVE_HIGH>, /* gpio6_30, LS OE */


Wrong gpio in the comment.


Uggh.. thanks for catching that.. should have been gpio2_30

will repost a v2 if there are no further comments at the end of the day..


--
Regards,
Nishanth Menon

[PATCH 2/6] MIPS: tlb-r4k: If there are wired entries, don't use TLBINVF

[Matt Redfearn]

When adding a wired entry to the TLB via add_wired_entry, the tlb is
flushed with local_flush_tlb_all, which on CPUs with TLBINV results in
the new wired entry being flushed again.

Behavior of the TLBINV instruction applies to all applicable TLB entries
and is unaffected by the setting of the Wired register. Therefore if
the TLB has any wired entries, fall back to iterating over the entries
rather than blasting them all using TLBINVF.

Signed-off-by: Matt Redfearn 
---

 arch/mips/mm/tlb-r4k.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index e8b335c16295..4953c1a8cdfd 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -67,8 +67,11 @@ void local_flush_tlb_all(void)
 
entry = read_c0_wired();
 
-   /* Blast 'em all away. */
-   if (cpu_has_tlbinv) {
+   /*
+* Blast 'em all away.
+* If there are any wired entries, fall back to iterating
+*/
+   if (cpu_has_tlbinv && !entry) {
if (current_cpu_data.tlbsizevtlb) {
write_c0_index(0);
mtc0_tlbw_hazard();
-- 
2.7.4

[PATCH 1/6] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

[Matt Redfearn]

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. If that VPE is
brought back under Linux, it is necessary to ensure that all GIC
interrupts are routed and masked as Linux expects them, as the firmware
can have done anything it likes with the GIC configuration (hopefully
just for that VPEs local interrupt sources, but allow for shared
external interrupts as well).

The configuration of shared and local CPU interrupts is maintained and
updated every time a change is made. When a CPU is brought online, the
saved configuration is restored.

These functions will also be useful for restoring GIC context after a
suspend to RAM.

Signed-off-by: Matt Redfearn 
---

 drivers/irqchip/irq-mips-gic.c | 185 +++--
 1 file changed, 178 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 83f498393a7f..5ba1fe1468ce 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,47 @@ static unsigned int timer_cpu_pin;
 static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
 DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
 
+#if defined(CONFIG_MIPS_RPROC)
+#define CONTEXT_SAVING
+#endif
+
+#ifdef CONTEXT_SAVING
+static struct {
+   unsigned mask:  GIC_NUM_LOCAL_INTRS;
+} gic_local_state[NR_CPUS];
+
+#define gic_save_local_rmask(vpe, i)   (gic_local_state[vpe].mask &= i)
+#define gic_save_local_smask(vpe, i)   (gic_local_state[vpe].mask |= i)
+
+static struct {
+   unsigned vpe:   8;
+   unsigned pin:   4;
+
+   unsigned polarity:  1;
+   unsigned trigger:   1;
+   unsigned dual_edge: 1;
+   unsigned mask:  1;
+} gic_shared_state[GIC_MAX_INTRS];
+
+#define gic_save_shared_vpe(i, v)  gic_shared_state[i].vpe = v
+#define gic_save_shared_pin(i, p)  gic_shared_state[i].pin = p
+#define gic_save_shared_polarity(i, p) gic_shared_state[i].polarity = p
+#define gic_save_shared_trigger(i, t)  gic_shared_state[i].trigger = t
+#define gic_save_shared_dual_edge(i, d)gic_shared_state[i].dual_edge = 
d
+#define gic_save_shared_mask(i, m) gic_shared_state[i].mask = m
+
+#else
+#define gic_save_local_rmask(vpe, i)
+#define gic_save_local_smask(vpe, i)
+
+#define gic_save_shared_vpe(i, v)
+#define gic_save_shared_pin(i, p)
+#define gic_save_shared_polarity(i, p)
+#define gic_save_shared_trigger(i, t)
+#define gic_save_shared_dual_edge(i, d)
+#define gic_save_shared_mask(i, m)
+#endif /* CONTEXT_SAVING */
+
 static void __gic_irq_dispatch(void);
 
 static inline u32 gic_read32(unsigned int reg)
@@ -105,52 +147,94 @@ static inline void gic_update_bits(unsigned int reg, 
unsigned long mask,
gic_write(reg, regval);
 }
 
-static inline void gic_reset_mask(unsigned int intr)
+static inline void gic_write_reset_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_mask(unsigned int intr)
+static inline void gic_reset_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 0);
+   gic_write_reset_mask(intr);
+}
+
+static inline void gic_write_set_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+static inline void gic_set_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 1);
+   gic_write_set_mask(intr);
+}
+
+static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)pol << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_trigger(unsigned int intr, unsigned int trig)
+static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+{
+   gic_save_shared_polarity(intr, pol);
+   gic_write_polarity(intr, pol);
+}
+
+static inline void gic_write_trigger(unsigned int intr, unsigned int trig)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_TRIGGER) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)trig << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_dual_edge(unsigned int intr, unsigned int dual)
+static inline void gic_set_trigger(unsigned int intr, unsigned int trig)
+{
+   gic_save_shared_trigger(intr, trig);
+   gic_write_trigger(intr, trig);
+}
+
+static inline void gic_write_dual_edge(unsigned int intr, unsigned int dual)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_DUAL) + GIC_INTR_OFS(intr),
   

[PATCH 2/6] MIPS: tlb-r4k: If there are wired entries, don't use TLBINVF

[Matt Redfearn]

When adding a wired entry to the TLB via add_wired_entry, the tlb is
flushed with local_flush_tlb_all, which on CPUs with TLBINV results in
the new wired entry being flushed again.

Behavior of the TLBINV instruction applies to all applicable TLB entries
and is unaffected by the setting of the Wired register. Therefore if
the TLB has any wired entries, fall back to iterating over the entries
rather than blasting them all using TLBINVF.

Signed-off-by: Matt Redfearn 
---

 arch/mips/mm/tlb-r4k.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index e8b335c16295..4953c1a8cdfd 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -67,8 +67,11 @@ void local_flush_tlb_all(void)
 
entry = read_c0_wired();
 
-   /* Blast 'em all away. */
-   if (cpu_has_tlbinv) {
+   /*
+* Blast 'em all away.
+* If there are any wired entries, fall back to iterating
+*/
+   if (cpu_has_tlbinv && !entry) {
if (current_cpu_data.tlbsizevtlb) {
write_c0_index(0);
mtc0_tlbw_hazard();
-- 
2.7.4

[PATCH 1/6] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

[Matt Redfearn]

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. If that VPE is
brought back under Linux, it is necessary to ensure that all GIC
interrupts are routed and masked as Linux expects them, as the firmware
can have done anything it likes with the GIC configuration (hopefully
just for that VPEs local interrupt sources, but allow for shared
external interrupts as well).

The configuration of shared and local CPU interrupts is maintained and
updated every time a change is made. When a CPU is brought online, the
saved configuration is restored.

These functions will also be useful for restoring GIC context after a
suspend to RAM.

Signed-off-by: Matt Redfearn 
---

 drivers/irqchip/irq-mips-gic.c | 185 +++--
 1 file changed, 178 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 83f498393a7f..5ba1fe1468ce 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,47 @@ static unsigned int timer_cpu_pin;
 static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller;
 DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS);
 
+#if defined(CONFIG_MIPS_RPROC)
+#define CONTEXT_SAVING
+#endif
+
+#ifdef CONTEXT_SAVING
+static struct {
+   unsigned mask:  GIC_NUM_LOCAL_INTRS;
+} gic_local_state[NR_CPUS];
+
+#define gic_save_local_rmask(vpe, i)   (gic_local_state[vpe].mask &= i)
+#define gic_save_local_smask(vpe, i)   (gic_local_state[vpe].mask |= i)
+
+static struct {
+   unsigned vpe:   8;
+   unsigned pin:   4;
+
+   unsigned polarity:  1;
+   unsigned trigger:   1;
+   unsigned dual_edge: 1;
+   unsigned mask:  1;
+} gic_shared_state[GIC_MAX_INTRS];
+
+#define gic_save_shared_vpe(i, v)  gic_shared_state[i].vpe = v
+#define gic_save_shared_pin(i, p)  gic_shared_state[i].pin = p
+#define gic_save_shared_polarity(i, p) gic_shared_state[i].polarity = p
+#define gic_save_shared_trigger(i, t)  gic_shared_state[i].trigger = t
+#define gic_save_shared_dual_edge(i, d)gic_shared_state[i].dual_edge = 
d
+#define gic_save_shared_mask(i, m) gic_shared_state[i].mask = m
+
+#else
+#define gic_save_local_rmask(vpe, i)
+#define gic_save_local_smask(vpe, i)
+
+#define gic_save_shared_vpe(i, v)
+#define gic_save_shared_pin(i, p)
+#define gic_save_shared_polarity(i, p)
+#define gic_save_shared_trigger(i, t)
+#define gic_save_shared_dual_edge(i, d)
+#define gic_save_shared_mask(i, m)
+#endif /* CONTEXT_SAVING */
+
 static void __gic_irq_dispatch(void);
 
 static inline u32 gic_read32(unsigned int reg)
@@ -105,52 +147,94 @@ static inline void gic_update_bits(unsigned int reg, 
unsigned long mask,
gic_write(reg, regval);
 }
 
-static inline void gic_reset_mask(unsigned int intr)
+static inline void gic_write_reset_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_RMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_mask(unsigned int intr)
+static inline void gic_reset_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 0);
+   gic_write_reset_mask(intr);
+}
+
+static inline void gic_write_set_mask(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_SMASK) + GIC_INTR_OFS(intr),
  1ul << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+static inline void gic_set_mask(unsigned int intr)
+{
+   gic_save_shared_mask(intr, 1);
+   gic_write_set_mask(intr);
+}
+
+static inline void gic_write_polarity(unsigned int intr, unsigned int pol)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_POLARITY) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)pol << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_trigger(unsigned int intr, unsigned int trig)
+static inline void gic_set_polarity(unsigned int intr, unsigned int pol)
+{
+   gic_save_shared_polarity(intr, pol);
+   gic_write_polarity(intr, pol);
+}
+
+static inline void gic_write_trigger(unsigned int intr, unsigned int trig)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_TRIGGER) +
GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
(unsigned long)trig << GIC_INTR_BIT(intr));
 }
 
-static inline void gic_set_dual_edge(unsigned int intr, unsigned int dual)
+static inline void gic_set_trigger(unsigned int intr, unsigned int trig)
+{
+   gic_save_shared_trigger(intr, trig);
+   gic_write_trigger(intr, trig);
+}
+
+static inline void gic_write_dual_edge(unsigned int intr, unsigned int dual)
 {
gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_DUAL) + GIC_INTR_OFS(intr),
1ul << 

[PATCH 5/6] remoteproc/MIPS: Add a remoteproc driver for MIPS

[Matt Redfearn]

Add a remoteproc driver to steal, load the firmware, and boot an offline
MIPS core, turning it into a coprocessor.

This driver provides a sysfs to allow arbitrary firmware to be loaded
onto a core, which may expose virtio devices. Coprocessor firmware must
abide by the UHI coprocessor boot protocol.

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 

---

 Documentation/ABI/testing/sysfs-class-mips-rproc |  24 +
 drivers/remoteproc/Kconfig   |  11 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/mips_remoteproc.c | 651 +++
 4 files changed, 687 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-mips-rproc
 create mode 100644 drivers/remoteproc/mips_remoteproc.c

diff --git a/Documentation/ABI/testing/sysfs-class-mips-rproc 
b/Documentation/ABI/testing/sysfs-class-mips-rproc
new file mode 100644
index ..c09d02a755e4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-mips-rproc
@@ -0,0 +1,24 @@
+What:  /sys/class/mips-rproc/rproc#/firmware
+Date:  August 2015
+Contact:   Lisa Parratt 
+Description:   MIPS VPE remoteproc start
+
+   This node only exists when a VPE is considered offline by Linux. Writes
+   to this file will start firmware running on a VPE.
+
+   If the VPE is idle, specifying a name will cause a remoteproc instance
+   to be allocated, which will cause the core to be stolen, the firmware
+   image to be loaded, and the remoteproc instance to be started.
+   Otherwise, the operation will fail.
+
+What:  /sys/class/mips-rproc/rproc#/stop
+Date:  August 2015
+Contact:   Lisa Parratt 
+Description:   MIPS VPE remoteproc stop
+
+   This node only exists when a VPE is considered offline by Linux. Writes
+   to this file will stop firmware running on a VPE.
+
+   If the VPE is running a remote proc instance, the instance will be
+   stopped, the core returned, and the instance freed.
+   Otherwise, the operation will fail.
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a925f..05db52e0e668 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,15 @@ config ST_REMOTEPROC
  processor framework.
  This can be either built-in or a loadable module.
 
+config MIPS_REMOTEPROC
+   tristate "MIPS remoteproc support"
+   depends on MIPS_CPS && HAS_DMA
+   select CMA
+   select REMOTEPROC
+   select MIPS_STEAL
+   help
+ Say y here to support using offline cores/VPEs as remote processors
+ via the remote processor framework.
+ If unsure say N.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758bd15c..de19cd320f3a 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)+= 
da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
 obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
+obj-$(CONFIG_MIPS_REMOTEPROC)  += mips_remoteproc.o
diff --git a/drivers/remoteproc/mips_remoteproc.c 
b/drivers/remoteproc/mips_remoteproc.c
new file mode 100644
index ..944ad66280b4
--- /dev/null
+++ b/drivers/remoteproc/mips_remoteproc.c
@@ -0,0 +1,651 @@
+/*
+ * MIPS Remote Processor driver
+ *
+ * Copyright (C) 2016 Imagination Technologies
+ * Lisa Parratt 
+ * Matt Redfearn 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+struct mips_rproc {
+   struct rproc*rproc;
+   char*firmware;
+   struct task_struct  *tsk;
+   struct device   dev;
+   unsigned intcpu;
+   int ipi_linux;
+   int ipi_remote;
+};
+
+static struct rproc *mips_rprocs[NR_CPUS];
+
+#define to_mips_rproc(d) container_of(d, struct mips_rproc, dev)
+
+
+/* Compute the largest page mask a physical address can be mapped with */
+static unsigned long mips_rproc_largest_pm(unsigned long pa,
+  unsigned long maxmask)
+{
+   unsigned long mask;
+   /* Find address bits limiting alignment */
+   unsigned long shift = ffs(pa);
+
+   /* Obey MIPS restrictions on page sizes */
+   if 

[PATCH 4/6] MIPS: CPS: Add VP(E) stealing

[Matt Redfearn]

From: Lisa Parratt 

VP(E) stealing provides a mechanism for removing an offline Virtual
Processor from the Linux kernel such that it is available to run bare
metal code.
Once the CPU has been offlined from Linux, the CPU can be given a task
to run via mips_cps_steal_cpu_and_execute(). The CPU is removed from the
cpu_present mask and is set up to execute from address entry_fn. Stack
space is assigned via the tsk task_struct so that C initialisation code
may be used.
To return the CPU back to Linux control, mips_cps_halt_and_return_cpu
will arrange to halt the CPU and return it to the cpu_present mask. It
is then available to be brought online again via CPU hotplug.

This mechanism is used by the MIPS remote processor driver to allow
CPUs within the system to execute bare metal code, not under control of
the kernel.

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 
---

 arch/mips/Kconfig   |   7 ++
 arch/mips/include/asm/smp-cps.h |   8 ++
 arch/mips/include/asm/smp.h |   1 +
 arch/mips/kernel/smp-cps.c  | 162 ++--
 arch/mips/kernel/smp.c  |  12 +++
 5 files changed, 183 insertions(+), 7 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..2094cbcea0d4 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2341,6 +2341,13 @@ config MIPS_CPS
  no external assistance. It is safe to enable this when hardware
  support is unavailable.
 
+config MIPS_STEAL
+   bool "VPE stealing"
+   depends on HOTPLUG_CPU && MIPS_CPS
+   help
+ Select this is you wish to be able to run bare metal code on offline
+ VPEs.
+
 config MIPS_CPS_PM
depends on MIPS_CPS
select MIPS_CPC
diff --git a/arch/mips/include/asm/smp-cps.h b/arch/mips/include/asm/smp-cps.h
index 2ae1f61a4a95..4f6cd5b14185 100644
--- a/arch/mips/include/asm/smp-cps.h
+++ b/arch/mips/include/asm/smp-cps.h
@@ -34,6 +34,14 @@ extern void mips_cps_boot_vpes(struct core_boot_config *cfg, 
unsigned vpe);
 extern void mips_cps_pm_save(void);
 extern void mips_cps_pm_restore(void);
 
+#ifdef CONFIG_MIPS_STEAL
+
+extern int mips_cps_steal_cpu_and_execute(unsigned int cpu, void *entry_fn,
+ struct task_struct *tsk);
+extern int mips_cps_halt_and_return_cpu(unsigned int cpu);
+
+#endif /* CONFIG_MIPS_STEAL */
+
 #ifdef CONFIG_MIPS_CPS
 
 extern bool mips_cps_smp_in_use(void);
diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp.h
index 060f23ff1817..3c62a1958af5 100644
--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -117,4 +117,5 @@ static inline void arch_send_call_function_ipi_mask(const 
struct cpumask *mask)
 extern void (*dump_ipi_function_ptr)(void *);
 void dump_send_ipi(void (*dump_ipi_callback)(void *));
 #endif
+
 #endif /* __ASM_SMP_H */
diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index e9d9fc6c754c..bcb9b62816b1 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -8,6 +8,7 @@
  * option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,31 @@ static int __init setup_nothreads(char *s)
 }
 early_param("nothreads", setup_nothreads);
 
+#ifdef CONFIG_MIPS_STEAL
+struct cpumask cpu_stolen_mask;
+
+static inline bool cpu_stolen(int cpu)
+{
+   return cpumask_test_cpu(cpu, _stolen_mask);
+}
+
+static inline void set_cpu_stolen(int cpu, bool state)
+{
+   if (state)
+   cpumask_set_cpu(cpu, _stolen_mask);
+   else
+   cpumask_clear_cpu(cpu, _stolen_mask);
+}
+#else
+static inline bool cpu_stolen(int cpu)
+{
+   return false;
+}
+
+static inline void set_cpu_stolen(int cpu, bool state) { }
+
+#endif /* CONFIG_MIPS_STEAL */
+
 static unsigned core_vpe_count(unsigned core)
 {
unsigned cfg;
@@ -109,6 +135,10 @@ static void __init cps_smp_setup(void)
write_gcr_bev_base(core_entry);
}
 
+#ifdef CONFIG_MIPS_STEAL
+   cpumask_clear(_stolen_mask);
+#endif /* CONFIG_MIPS_STEAL */
+
 #ifdef CONFIG_MIPS_MT_FPAFF
/* If we have an FPU, enroll ourselves in the FPU-full mask */
if (cpu_has_fpu)
@@ -287,7 +317,7 @@ static void remote_vpe_boot(void *dummy)
mips_cps_boot_vpes(core_cfg, cpu_vpe_id(_cpu_data));
 }
 
-static void cps_boot_secondary(int cpu, struct task_struct *idle)
+static void cps_start_secondary(int cpu, void *entry_fn, struct task_struct 
*tsk)
 {
unsigned core = cpu_data[cpu].core;
unsigned vpe_id = cpu_vpe_id(_data[cpu]);
@@ -297,9 +327,9 @@ static void cps_boot_secondary(int cpu, struct task_struct 
*idle)
unsigned int remote;
int err;
 
-   vpe_cfg->pc = (unsigned long)_bootstrap;
-   vpe_cfg->sp = __KSTK_TOS(idle);
-   vpe_cfg->gp = (unsigned long)task_thread_info(idle);
+   vpe_cfg->pc = (unsigned long)entry_fn;
+  

[PATCH 0/6] MIPS: Remote processor driver

[Matt Redfearn]

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. The CPU must be
offlined from Linux first. A sysfs interface is created which allows
firmware to be loaded and changed at runtime. A full description is
available at [1]. An example firmware that can be used with this driver
is available at [2].

This is useful to allow running bare metal code, or an RTOS, on one or
more CPUs while allowing Linux to continue running on those remaining.

The remote processor framework allows for firmwares to provide any
virtio device for communication between the firmware running on the
remote VPE and Linux. For example [2] demonstrates a simple firmware
which provides a virtual serial port. Any string sent to the port is
case inverted and returned.

This is conceptually similar to the VPE loader functionality, but is
more standard as it fits into the remoteproc subsystem.

The first patches in this series lay the groundwork for the driver
before it is added. The last series deprecates the VPE loader.

This functionality is supported on:
- MIPS32r2 devices implementing the MIPS MT ASE for multithreading, such
  as interAptiv.
- MIPS32r6 devices implementing VPs, such as I6400.

Limitations:
- The remoteproc core supports only 32bit ELFs. Therefore it is only
  possible to run 32bit firmware on the remote processor. Also, for
  virtio communication, pointers are passed from the kernel to firmware.
  There can be no mismatch in pointer sizes between the kernel and
  firmware, so this limits the host kernel to 32bit as well.

The functionality has been tested on the Ci40 board which has a 2 core 2
thread interAptiv.

This series is based on v4.8-rc4.

Depends on some patches from James Hogan's recent "MIPS: General EVA fixes &
cleanups" series:
MIPS: traps: 64bit kernels should read CP0_EBase 64bit
MIPS: traps: Convert ebase to KSeg0
MIPS: traps: Ensure full EBase is written

Without these patches, if firmware modifies ebase to allow handling
exceptions / interrupts, then when the VPE is returned to Linux the
kernel exception handlers won't be reinstated properly.

[1] 
http://wiki.prplfoundation.org/w/images/d/df/MIPS_OS_Remote_Processor_Driver_Whitepaper_1.0.9.pdf
[2] https://github.com/MIPS/mips-rproc-example



Lisa Parratt (1):
  MIPS: CPS: Add VP(E) stealing

Matt Redfearn (5):
  irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC
  MIPS: tlb-r4k: If there are wired entries, don't use TLBINVF
  MIPS: smp.c: Introduce mechanism for freeing and allocating IPIs
  remoteproc/MIPS: Add a remoteproc driver for MIPS
  MIPS: Deprecate VPE Loader

 Documentation/ABI/testing/sysfs-class-mips-rproc |  24 +
 arch/mips/Kconfig|  12 +-
 arch/mips/include/asm/smp-cps.h  |   8 +
 arch/mips/include/asm/smp.h  |  15 +
 arch/mips/kernel/smp-cps.c   | 162 +-
 arch/mips/kernel/smp.c   |  73 ++-
 arch/mips/mm/tlb-r4k.c   |   7 +-
 drivers/irqchip/irq-mips-gic.c   | 185 ++-
 drivers/remoteproc/Kconfig   |  11 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/mips_remoteproc.c | 651 +++
 11 files changed, 1124 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-mips-rproc
 create mode 100644 drivers/remoteproc/mips_remoteproc.c

-- 
2.7.4

[PATCH 5/6] remoteproc/MIPS: Add a remoteproc driver for MIPS

[Matt Redfearn]

Add a remoteproc driver to steal, load the firmware, and boot an offline
MIPS core, turning it into a coprocessor.

This driver provides a sysfs to allow arbitrary firmware to be loaded
onto a core, which may expose virtio devices. Coprocessor firmware must
abide by the UHI coprocessor boot protocol.

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 

---

 Documentation/ABI/testing/sysfs-class-mips-rproc |  24 +
 drivers/remoteproc/Kconfig   |  11 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/mips_remoteproc.c | 651 +++
 4 files changed, 687 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-mips-rproc
 create mode 100644 drivers/remoteproc/mips_remoteproc.c

diff --git a/Documentation/ABI/testing/sysfs-class-mips-rproc 
b/Documentation/ABI/testing/sysfs-class-mips-rproc
new file mode 100644
index ..c09d02a755e4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-mips-rproc
@@ -0,0 +1,24 @@
+What:  /sys/class/mips-rproc/rproc#/firmware
+Date:  August 2015
+Contact:   Lisa Parratt 
+Description:   MIPS VPE remoteproc start
+
+   This node only exists when a VPE is considered offline by Linux. Writes
+   to this file will start firmware running on a VPE.
+
+   If the VPE is idle, specifying a name will cause a remoteproc instance
+   to be allocated, which will cause the core to be stolen, the firmware
+   image to be loaded, and the remoteproc instance to be started.
+   Otherwise, the operation will fail.
+
+What:  /sys/class/mips-rproc/rproc#/stop
+Date:  August 2015
+Contact:   Lisa Parratt 
+Description:   MIPS VPE remoteproc stop
+
+   This node only exists when a VPE is considered offline by Linux. Writes
+   to this file will stop firmware running on a VPE.
+
+   If the VPE is running a remote proc instance, the instance will be
+   stopped, the core returned, and the instance freed.
+   Otherwise, the operation will fail.
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a925f..05db52e0e668 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,15 @@ config ST_REMOTEPROC
  processor framework.
  This can be either built-in or a loadable module.
 
+config MIPS_REMOTEPROC
+   tristate "MIPS remoteproc support"
+   depends on MIPS_CPS && HAS_DMA
+   select CMA
+   select REMOTEPROC
+   select MIPS_STEAL
+   help
+ Say y here to support using offline cores/VPEs as remote processors
+ via the remote processor framework.
+ If unsure say N.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758bd15c..de19cd320f3a 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)+= 
da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
 obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
+obj-$(CONFIG_MIPS_REMOTEPROC)  += mips_remoteproc.o
diff --git a/drivers/remoteproc/mips_remoteproc.c 
b/drivers/remoteproc/mips_remoteproc.c
new file mode 100644
index ..944ad66280b4
--- /dev/null
+++ b/drivers/remoteproc/mips_remoteproc.c
@@ -0,0 +1,651 @@
+/*
+ * MIPS Remote Processor driver
+ *
+ * Copyright (C) 2016 Imagination Technologies
+ * Lisa Parratt 
+ * Matt Redfearn 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+struct mips_rproc {
+   struct rproc*rproc;
+   char*firmware;
+   struct task_struct  *tsk;
+   struct device   dev;
+   unsigned intcpu;
+   int ipi_linux;
+   int ipi_remote;
+};
+
+static struct rproc *mips_rprocs[NR_CPUS];
+
+#define to_mips_rproc(d) container_of(d, struct mips_rproc, dev)
+
+
+/* Compute the largest page mask a physical address can be mapped with */
+static unsigned long mips_rproc_largest_pm(unsigned long pa,
+  unsigned long maxmask)
+{
+   unsigned long mask;
+   /* Find address bits limiting alignment */
+   unsigned long shift = ffs(pa);
+
+   /* Obey MIPS restrictions on page sizes */
+   if (pa) {
+   if (shift & 1)
+   shift -= 2;
+   else
+   shift--;
+   }
+   mask 

[PATCH 4/6] MIPS: CPS: Add VP(E) stealing

[Matt Redfearn]

From: Lisa Parratt 

VP(E) stealing provides a mechanism for removing an offline Virtual
Processor from the Linux kernel such that it is available to run bare
metal code.
Once the CPU has been offlined from Linux, the CPU can be given a task
to run via mips_cps_steal_cpu_and_execute(). The CPU is removed from the
cpu_present mask and is set up to execute from address entry_fn. Stack
space is assigned via the tsk task_struct so that C initialisation code
may be used.
To return the CPU back to Linux control, mips_cps_halt_and_return_cpu
will arrange to halt the CPU and return it to the cpu_present mask. It
is then available to be brought online again via CPU hotplug.

This mechanism is used by the MIPS remote processor driver to allow
CPUs within the system to execute bare metal code, not under control of
the kernel.

Signed-off-by: Lisa Parratt 
Signed-off-by: Matt Redfearn 
---

 arch/mips/Kconfig   |   7 ++
 arch/mips/include/asm/smp-cps.h |   8 ++
 arch/mips/include/asm/smp.h |   1 +
 arch/mips/kernel/smp-cps.c  | 162 ++--
 arch/mips/kernel/smp.c  |  12 +++
 5 files changed, 183 insertions(+), 7 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..2094cbcea0d4 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2341,6 +2341,13 @@ config MIPS_CPS
  no external assistance. It is safe to enable this when hardware
  support is unavailable.
 
+config MIPS_STEAL
+   bool "VPE stealing"
+   depends on HOTPLUG_CPU && MIPS_CPS
+   help
+ Select this is you wish to be able to run bare metal code on offline
+ VPEs.
+
 config MIPS_CPS_PM
depends on MIPS_CPS
select MIPS_CPC
diff --git a/arch/mips/include/asm/smp-cps.h b/arch/mips/include/asm/smp-cps.h
index 2ae1f61a4a95..4f6cd5b14185 100644
--- a/arch/mips/include/asm/smp-cps.h
+++ b/arch/mips/include/asm/smp-cps.h
@@ -34,6 +34,14 @@ extern void mips_cps_boot_vpes(struct core_boot_config *cfg, 
unsigned vpe);
 extern void mips_cps_pm_save(void);
 extern void mips_cps_pm_restore(void);
 
+#ifdef CONFIG_MIPS_STEAL
+
+extern int mips_cps_steal_cpu_and_execute(unsigned int cpu, void *entry_fn,
+ struct task_struct *tsk);
+extern int mips_cps_halt_and_return_cpu(unsigned int cpu);
+
+#endif /* CONFIG_MIPS_STEAL */
+
 #ifdef CONFIG_MIPS_CPS
 
 extern bool mips_cps_smp_in_use(void);
diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp.h
index 060f23ff1817..3c62a1958af5 100644
--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -117,4 +117,5 @@ static inline void arch_send_call_function_ipi_mask(const 
struct cpumask *mask)
 extern void (*dump_ipi_function_ptr)(void *);
 void dump_send_ipi(void (*dump_ipi_callback)(void *));
 #endif
+
 #endif /* __ASM_SMP_H */
diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index e9d9fc6c754c..bcb9b62816b1 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -8,6 +8,7 @@
  * option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,31 @@ static int __init setup_nothreads(char *s)
 }
 early_param("nothreads", setup_nothreads);
 
+#ifdef CONFIG_MIPS_STEAL
+struct cpumask cpu_stolen_mask;
+
+static inline bool cpu_stolen(int cpu)
+{
+   return cpumask_test_cpu(cpu, _stolen_mask);
+}
+
+static inline void set_cpu_stolen(int cpu, bool state)
+{
+   if (state)
+   cpumask_set_cpu(cpu, _stolen_mask);
+   else
+   cpumask_clear_cpu(cpu, _stolen_mask);
+}
+#else
+static inline bool cpu_stolen(int cpu)
+{
+   return false;
+}
+
+static inline void set_cpu_stolen(int cpu, bool state) { }
+
+#endif /* CONFIG_MIPS_STEAL */
+
 static unsigned core_vpe_count(unsigned core)
 {
unsigned cfg;
@@ -109,6 +135,10 @@ static void __init cps_smp_setup(void)
write_gcr_bev_base(core_entry);
}
 
+#ifdef CONFIG_MIPS_STEAL
+   cpumask_clear(_stolen_mask);
+#endif /* CONFIG_MIPS_STEAL */
+
 #ifdef CONFIG_MIPS_MT_FPAFF
/* If we have an FPU, enroll ourselves in the FPU-full mask */
if (cpu_has_fpu)
@@ -287,7 +317,7 @@ static void remote_vpe_boot(void *dummy)
mips_cps_boot_vpes(core_cfg, cpu_vpe_id(_cpu_data));
 }
 
-static void cps_boot_secondary(int cpu, struct task_struct *idle)
+static void cps_start_secondary(int cpu, void *entry_fn, struct task_struct 
*tsk)
 {
unsigned core = cpu_data[cpu].core;
unsigned vpe_id = cpu_vpe_id(_data[cpu]);
@@ -297,9 +327,9 @@ static void cps_boot_secondary(int cpu, struct task_struct 
*idle)
unsigned int remote;
int err;
 
-   vpe_cfg->pc = (unsigned long)_bootstrap;
-   vpe_cfg->sp = __KSTK_TOS(idle);
-   vpe_cfg->gp = (unsigned long)task_thread_info(idle);
+   vpe_cfg->pc = (unsigned long)entry_fn;
+   vpe_cfg->sp = __KSTK_TOS(tsk);
+   vpe_cfg->gp = (unsigned 

[PATCH 0/6] MIPS: Remote processor driver

[Matt Redfearn]

The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. The CPU must be
offlined from Linux first. A sysfs interface is created which allows
firmware to be loaded and changed at runtime. A full description is
available at [1]. An example firmware that can be used with this driver
is available at [2].

This is useful to allow running bare metal code, or an RTOS, on one or
more CPUs while allowing Linux to continue running on those remaining.

The remote processor framework allows for firmwares to provide any
virtio device for communication between the firmware running on the
remote VPE and Linux. For example [2] demonstrates a simple firmware
which provides a virtual serial port. Any string sent to the port is
case inverted and returned.

This is conceptually similar to the VPE loader functionality, but is
more standard as it fits into the remoteproc subsystem.

The first patches in this series lay the groundwork for the driver
before it is added. The last series deprecates the VPE loader.

This functionality is supported on:
- MIPS32r2 devices implementing the MIPS MT ASE for multithreading, such
  as interAptiv.
- MIPS32r6 devices implementing VPs, such as I6400.

Limitations:
- The remoteproc core supports only 32bit ELFs. Therefore it is only
  possible to run 32bit firmware on the remote processor. Also, for
  virtio communication, pointers are passed from the kernel to firmware.
  There can be no mismatch in pointer sizes between the kernel and
  firmware, so this limits the host kernel to 32bit as well.

The functionality has been tested on the Ci40 board which has a 2 core 2
thread interAptiv.

This series is based on v4.8-rc4.

Depends on some patches from James Hogan's recent "MIPS: General EVA fixes &
cleanups" series:
MIPS: traps: 64bit kernels should read CP0_EBase 64bit
MIPS: traps: Convert ebase to KSeg0
MIPS: traps: Ensure full EBase is written

Without these patches, if firmware modifies ebase to allow handling
exceptions / interrupts, then when the VPE is returned to Linux the
kernel exception handlers won't be reinstated properly.

[1] 
http://wiki.prplfoundation.org/w/images/d/df/MIPS_OS_Remote_Processor_Driver_Whitepaper_1.0.9.pdf
[2] https://github.com/MIPS/mips-rproc-example



Lisa Parratt (1):
  MIPS: CPS: Add VP(E) stealing

Matt Redfearn (5):
  irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC
  MIPS: tlb-r4k: If there are wired entries, don't use TLBINVF
  MIPS: smp.c: Introduce mechanism for freeing and allocating IPIs
  remoteproc/MIPS: Add a remoteproc driver for MIPS
  MIPS: Deprecate VPE Loader

 Documentation/ABI/testing/sysfs-class-mips-rproc |  24 +
 arch/mips/Kconfig|  12 +-
 arch/mips/include/asm/smp-cps.h  |   8 +
 arch/mips/include/asm/smp.h  |  15 +
 arch/mips/kernel/smp-cps.c   | 162 +-
 arch/mips/kernel/smp.c   |  73 ++-
 arch/mips/mm/tlb-r4k.c   |   7 +-
 drivers/irqchip/irq-mips-gic.c   | 185 ++-
 drivers/remoteproc/Kconfig   |  11 +
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/mips_remoteproc.c | 651 +++
 11 files changed, 1124 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-mips-rproc
 create mode 100644 drivers/remoteproc/mips_remoteproc.c

-- 
2.7.4

[PATCH 6/6] MIPS: Deprecate VPE Loader

[Matt Redfearn]

The MIPS remote processor driver (CONFIG_MIPS_RPROC) provides a more
standard mechanism for using one or more VPs as coprocessors running
separate firmware.

Here we deprecate this mechanism before it is removed.

Signed-off-by: Matt Redfearn 
---

 arch/mips/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2094cbcea0d4..071fc4585265 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2263,7 +2263,7 @@ comment "MIPS R2-to-R6 emulator is only available for UP 
kernels"
depends on SMP && CPU_MIPSR6
 
 config MIPS_VPE_LOADER
-   bool "VPE loader support."
+   bool "VPE loader support. (DEPRECATED)"
depends on SYS_SUPPORTS_MULTITHREADING && MODULES
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
@@ -2272,6 +2272,9 @@ config MIPS_VPE_LOADER
  Includes a loader for loading an elf relocatable object
  onto another VPE and running it.
 
+ Unless you have a specific need, you should use CONFIG_MIPS_RPROC
+  instead of this.
+
 config MIPS_VPE_LOADER_CMP
bool
default "y"
-- 
2.7.4

[PATCH 6/6] MIPS: Deprecate VPE Loader

[Matt Redfearn]

The MIPS remote processor driver (CONFIG_MIPS_RPROC) provides a more
standard mechanism for using one or more VPs as coprocessors running
separate firmware.

Here we deprecate this mechanism before it is removed.

Signed-off-by: Matt Redfearn 
---

 arch/mips/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2094cbcea0d4..071fc4585265 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2263,7 +2263,7 @@ comment "MIPS R2-to-R6 emulator is only available for UP 
kernels"
depends on SMP && CPU_MIPSR6
 
 config MIPS_VPE_LOADER
-   bool "VPE loader support."
+   bool "VPE loader support. (DEPRECATED)"
depends on SYS_SUPPORTS_MULTITHREADING && MODULES
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
@@ -2272,6 +2272,9 @@ config MIPS_VPE_LOADER
  Includes a loader for loading an elf relocatable object
  onto another VPE and running it.
 
+ Unless you have a specific need, you should use CONFIG_MIPS_RPROC
+  instead of this.
+
 config MIPS_VPE_LOADER_CMP
bool
default "y"
-- 
2.7.4

[PATCH 3/6] MIPS: smp.c: Introduce mechanism for freeing and allocating IPIs

[Matt Redfearn]

For the MIPS remote processor implementation, we need additional IPIs to
talk to the remote processor. Since MIPS GIC reserves exactly the right
number of IPI IRQs required by Linux for the number of VPs in the
system, this is not possible without releasing some recources.

This commit introduces mips_smp_ipi_allocate() which allocates IPIs to a
given cpumask. It is called as normal with the cpu_possible_mask at
bootup to initialise IPIs to all CPUs. mips_smp_ipi_free() may then be
used to free IPIs to a subset of those CPUs so that their hardware
resources can be reused.

Signed-off-by: Matt Redfearn 
---

 arch/mips/include/asm/smp.h | 14 +++
 arch/mips/kernel/smp.c  | 61 +++--
 2 files changed, 67 insertions(+), 8 deletions(-)

diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp.h
index 8bc6c70a4030..060f23ff1817 100644
--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -85,6 +85,20 @@ static inline void __cpu_die(unsigned int cpu)
 extern void play_dead(void);
 #endif
 
+/*
+ * This function will set up the necessary IPIs for Linux to communicate
+ * with the CPUs in mask.
+ * Return 0 on success.
+ */
+int mips_smp_ipi_allocate(const struct cpumask *mask);
+
+/*
+ * This function will free up IPIs allocated with mips_smp_ipi_allocate to the
+ * CPUs in mask, which must be a subset of the IPIs that have been configured.
+ * Return 0 on success.
+ */
+int mips_smp_ipi_free(const struct cpumask *mask);
+
 static inline void arch_send_call_function_single_ipi(int cpu)
 {
extern struct plat_smp_ops *mp_ops; /* private */
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index f95f094f36e4..afa06c2bb019 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -229,7 +229,7 @@ static struct irqaction irq_call = {
.name   = "IPI call"
 };
 
-static __init void smp_ipi_init_one(unsigned int virq,
+static void smp_ipi_init_one(unsigned int virq,
struct irqaction *action)
 {
int ret;
@@ -239,9 +239,11 @@ static __init void smp_ipi_init_one(unsigned int virq,
BUG_ON(ret);
 }
 
-static int __init mips_smp_ipi_init(void)
+static unsigned int call_virq, sched_virq;
+
+int mips_smp_ipi_allocate(const struct cpumask *mask)
 {
-   unsigned int call_virq, sched_virq;
+   int virq;
struct irq_domain *ipidomain;
struct device_node *node;
 
@@ -268,16 +270,20 @@ static int __init mips_smp_ipi_init(void)
if (!ipidomain)
return 0;
 
-   call_virq = irq_reserve_ipi(ipidomain, cpu_possible_mask);
-   BUG_ON(!call_virq);
+   virq = irq_reserve_ipi(ipidomain, mask);
+   BUG_ON(!virq);
+   if (!call_virq)
+   call_virq = virq;
 
-   sched_virq = irq_reserve_ipi(ipidomain, cpu_possible_mask);
-   BUG_ON(!sched_virq);
+   virq = irq_reserve_ipi(ipidomain, mask);
+   BUG_ON(!virq);
+   if (!sched_virq)
+   sched_virq = virq;
 
if (irq_domain_is_ipi_per_cpu(ipidomain)) {
int cpu;
 
-   for_each_cpu(cpu, cpu_possible_mask) {
+   for_each_cpu(cpu, mask) {
smp_ipi_init_one(call_virq + cpu, _call);
smp_ipi_init_one(sched_virq + cpu, _resched);
}
@@ -286,6 +292,45 @@ static int __init mips_smp_ipi_init(void)
smp_ipi_init_one(sched_virq, _resched);
}
 
+   return 0;
+}
+
+int mips_smp_ipi_free(const struct cpumask *mask)
+{
+   struct irq_domain *ipidomain;
+   struct device_node *node;
+
+   node = of_irq_find_parent(of_root);
+   ipidomain = irq_find_matching_host(node, DOMAIN_BUS_IPI);
+
+   /*
+* Some platforms have half DT setup. So if we found irq node but
+* didn't find an ipidomain, try to search for one that is not in the
+* DT.
+*/
+   if (node && !ipidomain)
+   ipidomain = irq_find_matching_host(NULL, DOMAIN_BUS_IPI);
+
+   BUG_ON(!ipidomain);
+
+   if (irq_domain_is_ipi_per_cpu(ipidomain)) {
+   int cpu;
+
+   for_each_cpu(cpu, mask) {
+   remove_irq(call_virq + cpu, _call);
+   remove_irq(sched_virq + cpu, _resched);
+   }
+   }
+   irq_destroy_ipi(call_virq, mask);
+   irq_destroy_ipi(sched_virq, mask);
+   return 0;
+}
+
+
+static int __init mips_smp_ipi_init(void)
+{
+   mips_smp_ipi_allocate(cpu_possible_mask);
+
call_desc = irq_to_desc(call_virq);
sched_desc = irq_to_desc(sched_virq);
 
-- 
2.7.4

[PATCH 3/6] MIPS: smp.c: Introduce mechanism for freeing and allocating IPIs

[Matt Redfearn]

For the MIPS remote processor implementation, we need additional IPIs to
talk to the remote processor. Since MIPS GIC reserves exactly the right
number of IPI IRQs required by Linux for the number of VPs in the
system, this is not possible without releasing some recources.

This commit introduces mips_smp_ipi_allocate() which allocates IPIs to a
given cpumask. It is called as normal with the cpu_possible_mask at
bootup to initialise IPIs to all CPUs. mips_smp_ipi_free() may then be
used to free IPIs to a subset of those CPUs so that their hardware
resources can be reused.

Signed-off-by: Matt Redfearn 
---

 arch/mips/include/asm/smp.h | 14 +++
 arch/mips/kernel/smp.c  | 61 +++--
 2 files changed, 67 insertions(+), 8 deletions(-)

diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp.h
index 8bc6c70a4030..060f23ff1817 100644
--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -85,6 +85,20 @@ static inline void __cpu_die(unsigned int cpu)
 extern void play_dead(void);
 #endif
 
+/*
+ * This function will set up the necessary IPIs for Linux to communicate
+ * with the CPUs in mask.
+ * Return 0 on success.
+ */
+int mips_smp_ipi_allocate(const struct cpumask *mask);
+
+/*
+ * This function will free up IPIs allocated with mips_smp_ipi_allocate to the
+ * CPUs in mask, which must be a subset of the IPIs that have been configured.
+ * Return 0 on success.
+ */
+int mips_smp_ipi_free(const struct cpumask *mask);
+
 static inline void arch_send_call_function_single_ipi(int cpu)
 {
extern struct plat_smp_ops *mp_ops; /* private */
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index f95f094f36e4..afa06c2bb019 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -229,7 +229,7 @@ static struct irqaction irq_call = {
.name   = "IPI call"
 };
 
-static __init void smp_ipi_init_one(unsigned int virq,
+static void smp_ipi_init_one(unsigned int virq,
struct irqaction *action)
 {
int ret;
@@ -239,9 +239,11 @@ static __init void smp_ipi_init_one(unsigned int virq,
BUG_ON(ret);
 }
 
-static int __init mips_smp_ipi_init(void)
+static unsigned int call_virq, sched_virq;
+
+int mips_smp_ipi_allocate(const struct cpumask *mask)
 {
-   unsigned int call_virq, sched_virq;
+   int virq;
struct irq_domain *ipidomain;
struct device_node *node;
 
@@ -268,16 +270,20 @@ static int __init mips_smp_ipi_init(void)
if (!ipidomain)
return 0;
 
-   call_virq = irq_reserve_ipi(ipidomain, cpu_possible_mask);
-   BUG_ON(!call_virq);
+   virq = irq_reserve_ipi(ipidomain, mask);
+   BUG_ON(!virq);
+   if (!call_virq)
+   call_virq = virq;
 
-   sched_virq = irq_reserve_ipi(ipidomain, cpu_possible_mask);
-   BUG_ON(!sched_virq);
+   virq = irq_reserve_ipi(ipidomain, mask);
+   BUG_ON(!virq);
+   if (!sched_virq)
+   sched_virq = virq;
 
if (irq_domain_is_ipi_per_cpu(ipidomain)) {
int cpu;
 
-   for_each_cpu(cpu, cpu_possible_mask) {
+   for_each_cpu(cpu, mask) {
smp_ipi_init_one(call_virq + cpu, _call);
smp_ipi_init_one(sched_virq + cpu, _resched);
}
@@ -286,6 +292,45 @@ static int __init mips_smp_ipi_init(void)
smp_ipi_init_one(sched_virq, _resched);
}
 
+   return 0;
+}
+
+int mips_smp_ipi_free(const struct cpumask *mask)
+{
+   struct irq_domain *ipidomain;
+   struct device_node *node;
+
+   node = of_irq_find_parent(of_root);
+   ipidomain = irq_find_matching_host(node, DOMAIN_BUS_IPI);
+
+   /*
+* Some platforms have half DT setup. So if we found irq node but
+* didn't find an ipidomain, try to search for one that is not in the
+* DT.
+*/
+   if (node && !ipidomain)
+   ipidomain = irq_find_matching_host(NULL, DOMAIN_BUS_IPI);
+
+   BUG_ON(!ipidomain);
+
+   if (irq_domain_is_ipi_per_cpu(ipidomain)) {
+   int cpu;
+
+   for_each_cpu(cpu, mask) {
+   remove_irq(call_virq + cpu, _call);
+   remove_irq(sched_virq + cpu, _resched);
+   }
+   }
+   irq_destroy_ipi(call_virq, mask);
+   irq_destroy_ipi(sched_virq, mask);
+   return 0;
+}
+
+
+static int __init mips_smp_ipi_init(void)
+{
+   mips_smp_ipi_allocate(cpu_possible_mask);
+
call_desc = irq_to_desc(call_virq);
sched_desc = irq_to_desc(sched_virq);
 
-- 
2.7.4

Re: [PATCH 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Tomi Valkeinen]

On 02/09/16 12:06, Nishanth Menon wrote:

> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
> new file mode 100644
> index ..da61dbba7768
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2014-2016 Texas Instruments Incorporated - 
> http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am57xx-beagle-x15-common.dtsi"
> +
> +/ {
> + model = "TI AM5728 BeagleBoard-X15 rev B1";
> +};
> +
> + {
> + gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, CT CP HPD */
> + < 30 GPIO_ACTIVE_HIGH>,   /* gpio6_30, LS OE */

Wrong gpio in the comment.

 Tomi



signature.asc
Description: OpenPGP digital signature

Dear Friend.

[Mr. Hassan Alwan Ali]

Dear Friend,

I know that this mail will come to you as a surprise since we have not
known or met before now, but please, I would like you to treat it like
blood brother affair and with the urgency and secrecy it requires. I
am Mr. Hassan Alwan Ali, an Audit staff of (C.B.N) Central Bank of
Nigeria.


An investor (name with-held) died without naming any next of kin to
his fund he deposited in my bank. The amount is $10.5M (Ten Million
Five hundred Thousand Dollars) and banking regulation/legislation in
Nigeria demands that I should notify the fiscal authorities after
three years.

The above set of facts underscores my reason to seek your permission
to have you stand in as the next of kin to the deceased.

This fund will be approved and released in your favour as the next of
kin if only you will adhere to my instruction and cooperate with me in
one accord.

I have all the legal and banking details of the deceased client that
will facilitate our putting you forward as the claimant/beneficiary of
the funds and ultimately transfer of the $10.5M plus interest to any
bank account nominated by you.

I am prepared to compensate you with a 35% share of the total funds
for your efforts. The final details will be given upon receipt an
affirmation of your desire to participate.

Please contact me immediately on (  hassan_alwanal...@yahoo.com  ) if
you are interest in my proposal to enable me not to start scouting for
another foreign partner.

Thanks,
Mr. Hassan Alwan Ali.

Dear Friend.

[Mr. Hassan Alwan Ali]

Dear Friend,

I know that this mail will come to you as a surprise since we have not
known or met before now, but please, I would like you to treat it like
blood brother affair and with the urgency and secrecy it requires. I
am Mr. Hassan Alwan Ali, an Audit staff of (C.B.N) Central Bank of
Nigeria.


An investor (name with-held) died without naming any next of kin to
his fund he deposited in my bank. The amount is $10.5M (Ten Million
Five hundred Thousand Dollars) and banking regulation/legislation in
Nigeria demands that I should notify the fiscal authorities after
three years.

The above set of facts underscores my reason to seek your permission
to have you stand in as the next of kin to the deceased.

This fund will be approved and released in your favour as the next of
kin if only you will adhere to my instruction and cooperate with me in
one accord.

I have all the legal and banking details of the deceased client that
will facilitate our putting you forward as the claimant/beneficiary of
the funds and ultimately transfer of the $10.5M plus interest to any
bank account nominated by you.

I am prepared to compensate you with a 35% share of the total funds
for your efforts. The final details will be given upon receipt an
affirmation of your desire to participate.

Please contact me immediately on (  hassan_alwanal...@yahoo.com  ) if
you are interest in my proposal to enable me not to start scouting for
another foreign partner.

Thanks,
Mr. Hassan Alwan Ali.

Re: [PATCH 2/2] ARM: dts: am57xx-beagle-x15: Add support for rev B1

[Tomi Valkeinen]

On 02/09/16 12:06, Nishanth Menon wrote:

> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
> new file mode 100644
> index ..da61dbba7768
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2014-2016 Texas Instruments Incorporated - 
> http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am57xx-beagle-x15-common.dtsi"
> +
> +/ {
> + model = "TI AM5728 BeagleBoard-X15 rev B1";
> +};
> +
> + {
> + gpios = < 10 GPIO_ACTIVE_HIGH>,   /* gpio7_10, CT CP HPD */
> + < 30 GPIO_ACTIVE_HIGH>,   /* gpio6_30, LS OE */

Wrong gpio in the comment.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] sched: fix incorrect PELT values on SMT

[Morten Rasmussen]

On Wed, Aug 31, 2016 at 03:07:20PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 19, 2016 at 04:30:39PM +0100, Morten Rasmussen wrote:
> > I can't convince myself whether this is the right thing to do. SMT is a
> > bit 'special' and it depends on how you model SMT capacity.
> > 
> > I'm no SMT expert, but the way I understand the current SMT capacity
> > model is that capacity_orig represents the capacity of the SMT-thread
> > when all its thread-siblings are busy.
> 
> Correct. Has a weird side effect if you have >2 siblings and unplug some
> but not symmetric. Rather uncommon case though.
> 
> > The true capacity of an
> > SMT-thread where all thread-siblings are idle is actually 1024, but we
> > don't model this (it would be nightmare to track when the capacity
> > should change). 
> 
> Right, so we have some dynamics in the capacity, but doing things like
> that (and the power7 asymmetric SMT) requires changing the capacity of
> other CPUs, which gets to be real interesting real quick.
> 
> The current dynamics are limited to CPU local things, like having RT
> tasks eat time.
> 
> > The capacity of a core with two or more SMT-threads is
> > chosen to be 1024 + smt_gain, where smt_gain is supposed represent the
> 
>   (1024 * smt_gain) >> 10

Looking at the code it seems that we just use smt_gain as the core
capacity, so the SMT capacity is simply sd->smt_gain/sd->span_weight,
where sd->smt_gain is initialized to 1178 by default. But it really
doesn't matter ;-)

> > additional throughput we gain for the additional SMT-threads. The reason
> > why we don't have 1024 per thread is that we would prefer to have only
> > one task per core if possible.
> 
> Not really, it stems from the fact that 1024 used (and still might in
> some places) represent 1 (nice-0) task (at 100% utilization).
> 
> And if you have SMT you really don't want to stick 2 tasks on if you can
> do differently. Simply because 2 threads on a core do not get the same
> throughput (in general) as 2 cores do.

Agreed, that is what I failed to communicate above.

> Now, these days SD_PREFER_SIBLING might actually be the main force that
> gets us 1 task per core if possible. We no longer use the capacity stuff
> to compute how many tasks we can run (with exception of
> update_numa_stats it seems).

Okay. I think the load_above_capacity stuff still does that and we tried
to get rid of that a while back. If we can rely on SD_PREFER_SIBLING
alone, it would certainly make things simpler.

> > With util_avg scaling to 1024 a core (capacity = 2*589) would be nearly
> > 'full' with just one always-running task. If we change util_avg to max
> > out at 589, it would take two always-running tasks for the combined
> > utilization to match the core capacity. So we may loose some bias
> > towards spreading for SMT systems.
> 
> Right, so this is always going to be a bit weird, as util numbers shrink
> under load. Therefore they too shrink when you saturate a core with SMT
> threads.

Shouldn't utilization increase, not shrink, if you saturate more SMT
threads? The effective throughput of each SMT thread should reduce when
more threads are saturated so the utilization should go up since
utilization is time-based?

> > AFAICT, group_is_overloaded() and group_has_capacity() would both be
> > affected by this patch.
> > 
> > Interestingly, Vincent recently proposed to set the SMT-thread capacity
> > to 1024 which would affectively make all the current SMT code redundant.
> > It would make things a lot simpler, but I'm not sure if we can get away
> > with it. It would need discussion at least.
> > 
> > Opinions?
> 
> Time I go stare at SMT again I suppose.. :-)

I'm afraid so.

Re: [PATCH] sched: fix incorrect PELT values on SMT

[Morten Rasmussen]

On Wed, Aug 31, 2016 at 03:07:20PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 19, 2016 at 04:30:39PM +0100, Morten Rasmussen wrote:
> > I can't convince myself whether this is the right thing to do. SMT is a
> > bit 'special' and it depends on how you model SMT capacity.
> > 
> > I'm no SMT expert, but the way I understand the current SMT capacity
> > model is that capacity_orig represents the capacity of the SMT-thread
> > when all its thread-siblings are busy.
> 
> Correct. Has a weird side effect if you have >2 siblings and unplug some
> but not symmetric. Rather uncommon case though.
> 
> > The true capacity of an
> > SMT-thread where all thread-siblings are idle is actually 1024, but we
> > don't model this (it would be nightmare to track when the capacity
> > should change). 
> 
> Right, so we have some dynamics in the capacity, but doing things like
> that (and the power7 asymmetric SMT) requires changing the capacity of
> other CPUs, which gets to be real interesting real quick.
> 
> The current dynamics are limited to CPU local things, like having RT
> tasks eat time.
> 
> > The capacity of a core with two or more SMT-threads is
> > chosen to be 1024 + smt_gain, where smt_gain is supposed represent the
> 
>   (1024 * smt_gain) >> 10

Looking at the code it seems that we just use smt_gain as the core
capacity, so the SMT capacity is simply sd->smt_gain/sd->span_weight,
where sd->smt_gain is initialized to 1178 by default. But it really
doesn't matter ;-)

> > additional throughput we gain for the additional SMT-threads. The reason
> > why we don't have 1024 per thread is that we would prefer to have only
> > one task per core if possible.
> 
> Not really, it stems from the fact that 1024 used (and still might in
> some places) represent 1 (nice-0) task (at 100% utilization).
> 
> And if you have SMT you really don't want to stick 2 tasks on if you can
> do differently. Simply because 2 threads on a core do not get the same
> throughput (in general) as 2 cores do.

Agreed, that is what I failed to communicate above.

> Now, these days SD_PREFER_SIBLING might actually be the main force that
> gets us 1 task per core if possible. We no longer use the capacity stuff
> to compute how many tasks we can run (with exception of
> update_numa_stats it seems).

Okay. I think the load_above_capacity stuff still does that and we tried
to get rid of that a while back. If we can rely on SD_PREFER_SIBLING
alone, it would certainly make things simpler.

> > With util_avg scaling to 1024 a core (capacity = 2*589) would be nearly
> > 'full' with just one always-running task. If we change util_avg to max
> > out at 589, it would take two always-running tasks for the combined
> > utilization to match the core capacity. So we may loose some bias
> > towards spreading for SMT systems.
> 
> Right, so this is always going to be a bit weird, as util numbers shrink
> under load. Therefore they too shrink when you saturate a core with SMT
> threads.

Shouldn't utilization increase, not shrink, if you saturate more SMT
threads? The effective throughput of each SMT thread should reduce when
more threads are saturated so the utilization should go up since
utilization is time-based?

> > AFAICT, group_is_overloaded() and group_has_capacity() would both be
> > affected by this patch.
> > 
> > Interestingly, Vincent recently proposed to set the SMT-thread capacity
> > to 1024 which would affectively make all the current SMT code redundant.
> > It would make things a lot simpler, but I'm not sure if we can get away
> > with it. It would need discussion at least.
> > 
> > Opinions?
> 
> Time I go stare at SMT again I suppose.. :-)

I'm afraid so.

[PATCH] drm/amd/powerplay: return false instead of -EINVAL

[Andrew Shadura]

Returning -EINVAL from a bool-returning function
phm_check_smc_update_required_for_display_configuration has an unexpected
effect of returning true, which is probably not what was intended.
Replace -EINVAL by false.

The only place this function is called from is
psm_adjust_power_state_dynamic in
drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:

if (!equal || 
phm_check_smc_update_required_for_display_configuration(hwmgr)) {
phm_apply_state_adjust_rules(hwmgr, requested, pcurrent);
phm_set_power_state(hwmgr, >hardware, 
>hardware);
hwmgr->current_ps = requested;
}

It seems to expect a boolean value here.

This issue has been found using the following Coccinelle semantic patch
written by Peter Senna Tschudin:

@@
identifier f;
constant C;
typedef bool;
@@
bool f (...){
<+...
* return -C;
...+>
}


Signed-off-by: Andrew Shadura 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
index 789f98a..82038b08 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
@@ -306,7 +306,7 @@ bool 
phm_check_smc_update_required_for_display_configuration(struct pp_hwmgr *hw
PHM_FUNC_CHECK(hwmgr);
 
if 
(hwmgr->hwmgr_func->check_smc_update_required_for_display_configuration == NULL)
-   return -EINVAL;
+   return false;
 
return 
hwmgr->hwmgr_func->check_smc_update_required_for_display_configuration(hwmgr);
 }
-- 
2.7.4

Re: [PATCH 0/6] constify snd_pcm_ops structures

[Takashi Iwai]

On Fri, 02 Sep 2016 00:13:08 +0200,
Julia Lawall wrote:
> 
> Constify snd_pcm_ops structures.

Applied all six patches now.  Thanks.


Takashi