Re: [RFC PATCH 0/3] Expose gpu counters via perf pmu driver

[Ingo Molnar]

* Robert Bragg  wrote:

> [...]
> 
> I'd be interested to hear whether is sounds reasonable to 
> others for us to expose gpu device metrics via a perf pmu and 
> whether adding the PERF_PMU_CAP_IS_DEVICE flag as in my 
> following patch could be acceptable.

I think it's perfectly reasonable, it's one of the interesting 
kernel features I hoped for years would be implemented for perf.

> [...]
> 
> In addition I also explicitly black list numerous attributes 
> and PERF_SAMPLE_ flags that I don't think make sense for a 
> device pmu. This could be handled in the pmu driver but it 
> seemed better to do in events/core, avoiding duplication in 
> case we later have multiple device pmus.

Btw., if the GPU is able to dump (part of) its current execution 
status, you could in theory even do instruction profiling and 
in-GPU profiling (symbol resolution, maybe even annotation, etc.) 
with close to standard perf tooling - which I think is currently 
mostly the domain of proprietary tools.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/5] perf/sdt: Add support to perf record to trace SDT events

[Srikar Dronamraju]

* Masami Hiramatsu  [2014-10-22 18:41:58]:

> (2014/10/22 17:20), Hemant Kumar wrote:
> >>> From "file_sdt_ent" we will find out the file name.
> >>> Convert this sdt note into a perf event and then write this into 
> >>> uprobe_events
> >>> file to be able to record the event.
> >>> Then, corresponding entries are added to uprobe_events file for
> >>> the SDT events.
> >>> After recording is done, these events are silently deleted from 
> >>> uprobe_events
> >>> file. The uprobe_events file is present in debugfs/tracing directory.
> >>>
> >>> To support the addition and deletion of SDT events to/from uprobe_events
> >>> file, a record_sdt struct is maintained which has the event data.
> >> OK, I have some comments on this.
> >>
> >>> An example usage:
> >>>
> >>> # ./perf record -e %user_app:fun_start -aR /home/user_app
> >> At first, I'd like to add SDT support for adding probes too, like below;
> >>
> >> ./perf probe -a '%user_app:fun_start $vars'
> >
> > But I think, previously we discussed that we won't be having "perf
> > probe" for SDT events.
> > We list them and probe/trace them using "perf record" directly.
>
> Right, sorry for confusing you. I meant that I'd like to support SDT on both 
> of
> perf-record and perf-probe :)
> And even if we'll hide sdt related events via perf, users can access it via 
> ftrace.
> So, I doubt that we can completely hide them, in that case, honesty is the 
> best way;)
>

I am somehow not able to figure out how perf probe comes into the
current workflow.

I think the current design was
1. perf sdt-cache --add  (only once per file)
2. perf record -e 

So what is the additional thing that perf probe does or Is it going to
replace any of the above steps?

--
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] adv7604: Add DT parsing support

[Jean-Michel Hautbois]

Hi Laurent,

Thank you for reviewing,

2014-10-23 1:53 GMT+02:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Wednesday 22 October 2014 17:34:21 Jean-Michel Hautbois wrote:
>> This patch adds support for DT parsing of ADV7604 as well as ADV7611.
>> It needs to be improved in order to get ports parsing too.
>
> Let's improve it then :-) The DT bindings as proposed by this patch are
> incomplete, that's just asking for trouble.
>
> How would you model the adv7604 ports ?

I am opened to suggestions :).
But it has to remain as simple as possible, ideally allowing for
giving names to the ports.
As done today, it works, ports are parsed but are all the same...

>> Signed-off-by: Jean-Michel Hautbois 
>> ---
>>  Documentation/devicetree/bindings/media/i2c/adv7604.txt | 1 +
>>  drivers/media/i2c/adv7604.c | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
>> c27cede..5c8b3e6 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> @@ -10,6 +10,7 @@ Required Properties:
>>
>>- compatible: Must contain one of the following
>>  - "adi,adv7611" for the ADV7611
>> +- "adi,adv7604" for the ADV7604
>
> Please switch the two lines to keep them alphabetically sorted.
>>
>>- reg: I2C slave address
>>
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index 47795ff..421035f 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -2677,6 +2677,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
>>
>>  static struct of_device_id adv7604_of_id[] __maybe_unused = {
>>   { .compatible = "adi,adv7611", .data = _chip_info[ADV7611] },
>> + { .compatible = "adi,adv7604", .data = _chip_info[ADV7604] },
>
> Same comment here.

Done on my side, but will wait for your suggestions, in order to add
ports parsing ;-).

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: x86: Enable Intel AVX-512 for guest

[Chao Peng]

On Wed, Oct 22, 2014 at 12:17:33PM +0200, Paolo Bonzini wrote:
> On 10/22/2014 11:35 AM, Chao Peng wrote:
> > Expose Intel AVX-512 feature bits to guest. Also add checks for
> > xcr0 AVX512 related bits according to spec:
> > http://download-software.intel.com/sites/default/files/managed/71/2e/319433-017.pdf
> > 
> > Signed-off-by: Chao Peng 
> 
> The patch looks good, but you also have to patch QEMU in order to
> save/restore the values of the registers.  IIRC the manual already
> details where the registers are in the XSAVE area, so it should be easy
> to get them in and out.  You can look at the MPX patches for an example.
> 
> In the meanwhile, kernel bits are
> 
> Reviewed-by: Paolo Bonzini 
> 
> Paolo

Thanks Paolo.

QEMU side patch is already sent out to QEMU list in the other thread.
Also accessible from url:
http://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg02681.html

Chao
> 
> > ---
> >  arch/x86/include/asm/xsave.h |1 +
> >  arch/x86/kvm/cpuid.c |3 ++-
> >  arch/x86/kvm/x86.c   |6 ++
> >  arch/x86/kvm/x86.h   |3 ++-
> >  4 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xsave.h b/arch/x86/include/asm/xsave.h
> > index 7e7a79a..5fa9770 100644
> > --- a/arch/x86/include/asm/xsave.h
> > +++ b/arch/x86/include/asm/xsave.h
> > @@ -16,6 +16,7 @@
> >  #define XSTATE_Hi16_ZMM0x80
> >  
> >  #define XSTATE_FPSSE   (XSTATE_FP | XSTATE_SSE)
> > +#define XSTATE_AVX512  (XSTATE_OPMASK | XSTATE_ZMM_Hi256 | 
> > XSTATE_Hi16_ZMM)
> >  /* Bit 63 of XCR0 is reserved for future expansion */
> >  #define XSTATE_EXTEND_MASK (~(XSTATE_FPSSE | (1ULL << 63)))
> >  
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index 976e3a5..20d8321 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -317,7 +317,8 @@ static inline int __do_cpuid_ent(struct 
> > kvm_cpuid_entry2 *entry, u32 function,
> > const u32 kvm_supported_word9_x86_features =
> > F(FSGSBASE) | F(BMI1) | F(HLE) | F(AVX2) | F(SMEP) |
> > F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | f_mpx | F(RDSEED) |
> > -   F(ADX) | F(SMAP);
> > +   F(ADX) | F(SMAP) | F(AVX512F) | F(AVX512PF) | F(AVX512ER) |
> > +   F(AVX512CD);
> >  
> > /* all calls to cpuid_count() should be made on the same cpu */
> > get_cpu();
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 5430e4b..3d77b88 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -651,6 +651,12 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, 
> > u64 xcr)
> > if ((!(xcr0 & XSTATE_BNDREGS)) != (!(xcr0 & XSTATE_BNDCSR)))
> > return 1;
> >  
> > +   if (xcr0 & XSTATE_AVX512) {
> > +   if (!(xcr0 & XSTATE_YMM))
> > +   return 1;
> > +   if ((xcr0 & XSTATE_AVX512) != XSTATE_AVX512)
> > +   return 1;
> > +   }
> > kvm_put_guest_xcr0(vcpu);
> > vcpu->arch.xcr0 = xcr0;
> >  
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index 7cb9c45..cc1d61a 100644
> > --- a/arch/x86/kvm/x86.h
> > +++ b/arch/x86/kvm/x86.h
> > @@ -162,7 +162,8 @@ int kvm_write_guest_virt_system(struct x86_emulate_ctxt 
> > *ctxt,
> >  bool kvm_mtrr_valid(struct kvm_vcpu *vcpu, u32 msr, u64 data);
> >  
> >  #define KVM_SUPPORTED_XCR0 (XSTATE_FP | XSTATE_SSE | XSTATE_YMM \
> > -   | XSTATE_BNDREGS | XSTATE_BNDCSR)
> > +   | XSTATE_BNDREGS | XSTATE_BNDCSR \
> > +   | XSTATE_AVX512)
> >  extern u64 host_xcr0;
> >  
> >  extern u64 kvm_supported_xcr0(void);
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/27] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Bjorn Helgaas]

On Wed, Oct 15, 2014 at 11:06:48AM +0800, Yijing Wang wrote:
> Now there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm,
> that's a better solution than overriding lots of existing weak arch 
> functionsin. 
> This series use MSI chip framework to refactor MSI code across all platforms 
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code, 
> so tests in the related platforms are warmly welcomed!
> 
> And you may access it at:
> https://github.com/YijingWang/msi-chip-v3.git master
> 
> v2->v3:
> 1. For patch "x86/xen/MSI: Eliminate...", introduce a new global flag 
> "pci_msi_ignore_mask"
> to control the msi mask instead of replacing the irqchip->mask with nop 
> function,
> the latter method has problem pointed out by Konrad Rzeszutek Wilk.
> 2. Save msi chip in arch pci sysdata instead of associating msi chip to pci 
> bus.
> Because pci devices under same host share the same msi chip, so I think 
> associate
> msi chip to pci host/pci sysdata is better than to bother every pci 
> bus/devices.
> A better solution suggested by Liviu is to rip out pci_host_bridge from 
> pci_create_root_bus(), 
> then we can save some pci host common attributes like domain_nr, msi_chip, 
> resources,
> into the generic pci_host_bridge. Because this changes to pci host bridge is 
> also 
> a large series, so I think we should go step by step, I will try to post it 
> in another
> series later.
> 4. Clean up arm pcibios_add_bus() and pcibios_remove_bus() which were used to 
> associate
> msi chip to pci bus.
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (27):

This is a lot of stuff, and it's not all related, so putting it all
together in one series makes it hard for me to deal with it.

>   MSI: Remove the redundant irq_set_chip_data()

This doesn't seem related to eliminating weak functions.

>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()

These two seem to go together.

>   arm/MSI: Save MSI chip in pci_sys_data
>   PCI: tegra: Save msi chip in pci_sys_data
>   PCI: designware: Save msi chip in pci_sys_data
>   PCI: rcar: Save msi chip in pci_sys_data
>   PCI: mvebu: Save msi chip in pci_sys_data
>   arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus()
>   PCI/MSI: Remove useless bus->msi assignment

These seem to go together (it'd be nice if they were all capitalized the
same).

I don't like the "msi_chip" name because the "chip" part doesn't convey
much information, other than telling us that apparently some sort of
semiconductor integrated circuit is involved.  I sort of assumed that
much :)

Something like "msi_controller" would be more descriptive since we're
talking about an interrupt controller that accepts writes from a device and
turns them into CPU interrupts, e.g., a LAPIC.

>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   Mips/MSI: Save msi chip in pci sysdata
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/include/asm/mach/pci.h |   10 +-
>  arch/arm/include/asm/pci.h  |9 ++
>  arch/arm/kernel/bios32.c|   19 +---
>  arch/arm/mach-iop13xx/include/mach/pci.h|4 +
>  arch/arm/mach-iop13xx/iq81340mc.c   |3 +
>  arch/arm/mach-iop13xx/iq81340sc.c   |5 +-
>  arch/arm/mach-iop13xx/msi.c |   11 ++-
>  arch/ia64/include/asm/pci.h

Re: [PATCH v3 10/27] PCI/MSI: Remove useless bus->msi assignment

[Bjorn Helgaas]

On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote:
> Now msi chip is saved in pci_sys_data in arm,
> we could clean the bus->msi assignment in
> pci core.
> 
> Signed-off-by: Yijing Wang 
> CC: Thierry Reding 
> CC: Thomas Petazzoni 
> ---
>  drivers/pci/probe.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index efa48dc..98bf4c3 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -682,7 +682,6 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus 
> *parent,
>  
>   child->parent = parent;
>   child->ops = parent->ops;
> - child->msi = parent->msi;

This needs an explanation of why ARM was the only arch to depend on this.

>   child->sysdata = parent->sysdata;
>   child->bus_flags = parent->bus_flags;
>  
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 09/27] arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus()

[Bjorn Helgaas]

On Wed, Oct 15, 2014 at 11:06:57AM +0800, Yijing Wang wrote:
> MSI chip will be saved in pci_sys_data, now we can
> clean up pcibios_add_bus() and pcibios_remove_bus()
> in arm, and use pci_find_msi_chip() to get msi chip
> in core MSI code.
> 
> Signed-off-by: Yijing Wang 
> ---
>  arch/arm/include/asm/mach/pci.h |4 
>  arch/arm/kernel/bios32.c|   16 
>  drivers/pci/msi.c   |   11 +++
>  3 files changed, 3 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 59b0d87..230b2c9 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -39,8 +39,6 @@ struct hw_pci {
> resource_size_t start,
> resource_size_t size,
> resource_size_t align);
> - void(*add_bus)(struct pci_bus *bus);
> - void(*remove_bus)(struct pci_bus *bus);
>  };
>  
>  /*
> @@ -71,8 +69,6 @@ struct pci_sys_data {
> resource_size_t start,
> resource_size_t size,
> resource_size_t align);
> - void(*add_bus)(struct pci_bus *bus);
> - void(*remove_bus)(struct pci_bus *bus);
>   void*private_data;  /* platform controller private data 
> */
>  };
>  
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index a19038d..b1b872e 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -360,20 +360,6 @@ void pcibios_fixup_bus(struct pci_bus *bus)
>  }
>  EXPORT_SYMBOL(pcibios_fixup_bus);
>  
> -void pcibios_add_bus(struct pci_bus *bus)
> -{
> - struct pci_sys_data *sys = bus->sysdata;
> - if (sys->add_bus)
> - sys->add_bus(bus);
> -}
> -
> -void pcibios_remove_bus(struct pci_bus *bus)
> -{
> - struct pci_sys_data *sys = bus->sysdata;
> - if (sys->remove_bus)
> - sys->remove_bus(bus);
> -}
> -
>  /*
>   * Swizzle the device pin each time we cross a bridge.  If a platform does
>   * not provide a swizzle function, we perform the standard PCI swizzling.
> @@ -478,8 +464,6 @@ static void pcibios_init_hw(struct device *parent, struct 
> hw_pci *hw,
>   sys->swizzle = hw->swizzle;
>   sys->map_irq = hw->map_irq;
>   sys->align_resource = hw->align_resource;
> - sys->add_bus = hw->add_bus;
> - sys->remove_bus = hw->remove_bus;
>   INIT_LIST_HEAD(>resources);
>  
>   if (hw->private_data)

What do the core changes below have to do with the ARM changes above?
They should be a separate patch unless they can't be separated.

> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index f11108c..56e54ad 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -32,12 +32,10 @@ int pci_msi_ignore_mask;
>  
>  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> - struct msi_chip *chip = dev->bus->msi;
> + struct msi_chip *chip;
>   int err;
>  
> - if (!chip)
> - chip = pci_msi_chip(dev->bus);
> -
> + chip = pci_msi_chip(dev->bus);
>   if (!chip || !chip->setup_irq)
>   return -EINVAL;
>  
> @@ -51,10 +49,7 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct 
> msi_desc *desc)
>  void __weak arch_teardown_msi_irq(unsigned int irq)
>  {
>   struct msi_desc *entry = irq_get_msi_desc(irq);
> - struct msi_chip *chip = entry->dev->bus->msi;
> -
> - if (!chip)
> - chip = pci_msi_chip(entry->dev->bus);
> + struct msi_chip *chip = pci_msi_chip(entry->dev->bus);
>  
>   if (!chip || !chip->teardown_irq)
>   return;
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 04/27] arm/MSI: Save MSI chip in pci_sys_data

[Bjorn Helgaas]

On Wed, Oct 15, 2014 at 11:06:52AM +0800, Yijing Wang wrote:
> Saving msi chip in pci_sys_data can make pci bus and
> devices don't need to know msi chip detail, it also
> make pci enumeration code be decoupled from msi chip.
> In fact, all pci devices under the same pci hostbridge
> share same msi chip. So msi chip should be seen as one
> of resources or attributes to be initialized in pci host
> bridge driver. Currently, pci hostbridge drivers create
> pci_host_bridge in pci_create_root_bus(), and pass arch
> specific pci sysdata to core pci scan functions. So pci
> arch sysdata is good place to save msi chip.
> 
> Signed-off-by: Yijing Wang 
> ---
>  arch/arm/include/asm/mach/pci.h |6 ++
>  arch/arm/include/asm/pci.h  |9 +
>  arch/arm/kernel/bios32.c|3 +++
>  drivers/pci/msi.c   |6 ++
>  include/linux/pci.h |9 +
>  5 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 7fc4278..59b0d87 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -22,6 +22,9 @@ struct hw_pci {
>  #ifdef CONFIG_PCI_DOMAINS
>   int domain;
>  #endif
> +#ifdef CONFIG_PCI_MSI
> + struct msi_chip *msi_chip;
> +#endif
>   struct pci_ops  *ops;
>   int nr_controllers;
>   void**private_data;
> @@ -47,6 +50,9 @@ struct pci_sys_data {
>  #ifdef CONFIG_PCI_DOMAINS
>   int domain;
>  #endif
> +#ifdef CONFIG_PCI_MSI
> + struct msi_chip *msi_chip;
> +#endif
>   struct list_head node;
>   int busnr;  /* primary bus number   
> */
>   u64 mem_offset; /* bus->cpu memory mapping offset   
> */
> diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
> index 7e95d85..b562c09 100644
> --- a/arch/arm/include/asm/pci.h
> +++ b/arch/arm/include/asm/pci.h
> @@ -31,6 +31,15 @@ static inline int pci_proc_domain(struct pci_bus *bus)
>  }
>  #endif /* CONFIG_PCI_DOMAINS */
>  
> +#ifdef CONFIG_PCI_MSI
> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
> +{
> + struct pci_sys_data *root = bus->sysdata;
> +
> + return root->msi_chip;
> +}
> +#endif
> +
>  /*
>   * The PCI address space does equal the physical memory address space.
>   * The networking and block device layers use this boolean for bounce
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 17a26c1..a19038d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -471,6 +471,9 @@ static void pcibios_init_hw(struct device *parent, struct 
> hw_pci *hw,
>  #ifdef CONFIG_PCI_DOMAINS
>   sys->domain  = hw->domain;
>  #endif
> +#ifdef CONFIG_PCI_MSI
> + sys->msi_chip = hw->msi_chip;
> +#endif
>   sys->busnr   = busnr;
>   sys->swizzle = hw->swizzle;
>   sys->map_irq = hw->map_irq;
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 22e413c..f11108c 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -35,6 +35,9 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct 
> msi_desc *desc)
>   struct msi_chip *chip = dev->bus->msi;
>   int err;
>  
> + if (!chip)
> + chip = pci_msi_chip(dev->bus);
> +
>   if (!chip || !chip->setup_irq)
>   return -EINVAL;
>  
> @@ -50,6 +53,9 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
>   struct msi_desc *entry = irq_get_msi_desc(irq);
>   struct msi_chip *chip = entry->dev->bus->msi;
>  
> + if (!chip)
> + chip = pci_msi_chip(entry->dev->bus);
> +
>   if (!chip || !chip->teardown_irq)
>   return;
>  
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 9cd2721..7a48b40 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1433,6 +1433,15 @@ static inline int pci_get_new_domain_nr(void) { return 
> -ENOSYS; }
>  
>  #include 
>  
> +/* Just avoid compile error, will be clean up later */
> +#ifdef CONFIG_PCI_MSI
> +
> +#ifndef pci_msi_chip
> +#define pci_msi_chip(bus)NULL
> +#endif
> +#endif

I don't like the mixture of ARM changes and PCI core changes in the same
patch.  Can you split this into a core patch that does something like this:

  struct msi_chip * __weak pcibios_msi_controller(struct pci_bus *bus)
  {
return NULL;
  }

  struct msi_chip *pci_msi_controller(struct pci_bus *bus)
  {
msi_chip *controller = bus->msi;

if (controller)
  return controller;
return pcibios_msi_controller(bus);
  }

followed by an ARM patch that puts the msi_chip pointer in struct hw_pci
and implements pcibios_msi_controller()?

I know you're trying to *remove* weak functions, and this adds one, but
this section of the series is more about getting rid of the ARM
pcibios_add_bus() because all it was used for was setting the bus->msi

Re: [PATCH v3 5/5] perf/sdt: Add support to perf record to trace SDT events

[Hemant Kumar]

On 10/22/2014 03:11 PM, Masami Hiramatsu wrote:

(2014/10/22 17:20), Hemant Kumar wrote:

 From "file_sdt_ent" we will find out the file name.
Convert this sdt note into a perf event and then write this into uprobe_events
file to be able to record the event.
Then, corresponding entries are added to uprobe_events file for
the SDT events.
After recording is done, these events are silently deleted from uprobe_events
file. The uprobe_events file is present in debugfs/tracing directory.

To support the addition and deletion of SDT events to/from uprobe_events
file, a record_sdt struct is maintained which has the event data.

OK, I have some comments on this.


An example usage:

# ./perf record -e %user_app:fun_start -aR /home/user_app

At first, I'd like to add SDT support for adding probes too, like below;

./perf probe -a '%user_app:fun_start $vars'

But I think, previously we discussed that we won't be having "perf
probe" for SDT events.
We list them and probe/trace them using "perf record" directly.

Right, sorry for confusing you. I meant that I'd like to support SDT on both of
perf-record and perf-probe :)


I plan to do this and add this subsequently but will it be okay if we go 
with the current

implementation for the time being?

What do you think?


And even if we'll hide sdt related events via perf, users can access it via 
ftrace.
So, I doubt that we can completely hide them, in that case, honesty is the best 
way;)

Thank you,




--
Thanks,
Hemant Kumar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Possible wireless issue introduced in next-20140930

[Mike Galbraith]

On Thu, 2014-10-23 at 01:17 -0200, Murilo Opsfelder Araujo wrote: 
> Hello, everyone.
> 
> With next-20140930 my laptop does not work, i.e. after I enter my login 
> and password in KDM, the entire system becomes unresponsive and I need 
> to reset it in order to reboot (it does not even show the KDE splash 
> screen).
> 
> It was working pretty fine with next-20140926.
> 
> I've also tested with next-20141022 and v3.18-rc1 and no luck.
> 
> git bisect pointed me to the commit below [1].  My wireless card is a 
> RTL8191SEvA [2].

Mine is RTL8191SEvB.

I was going to bisect RTL8191SE regression when I got a chance, but you
beat me to it.

> commit 38506ecefab911785d5e1aa5889f6eeb462e0954
> Author: Larry Finger 
> Date:   Mon Sep 22 09:39:19 2014 -0500
> 
>  rtlwifi: rtl_pci: Start modification for new drivers

Did you confirm that bisection result, ie revert it at HEAD of whichever
tree you bisected?

The revert (master) removed some warnings on the way to kaboom here, but
the drivers is still toxic.  My log follows in case it's the same thing.
I can't go hunting atm, maybe during the weekend if the problem hasn't
evaporate by then.

Master:
[   28.028817] cfg80211: Calling CRDA to update world regulatory domain
[   28.102230] cfg80211: World regulatory domain updated:
[   28.103799] cfg80211:  DFS Master region: unset
[   28.103838] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   28.107012] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm), (N/A)
[   28.108663] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (300 mBi, 
2000 mBm), (N/A)
[   28.110251] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm), (N/A)
[   28.111837] cfg80211:   (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm), (N/A)
[   28.113422] cfg80211:   (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm), (N/A)
[   29.577727] rtl8192se :08:00.0: enabling device ( -> 0003)
[   29.618681] rtl8192se: FW Power Save off (module option)
[   29.620355] rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE
[   29.620355] Loading firmware rtlwifi/rtl8192sefw.bin
[   29.648444] [ cut here ]
[   29.650012] WARNING: CPU: 1 PID: 59 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x68/0x80()
[   29.651602] sysfs: cannot create duplicate filename 
'/devices/pci:00/:00:1c.5/:08:00.0/ieee80211/phy0'
[   29.653278] Modules linked in: rtl8192se(+) rtl_pci rtlwifi mac80211 
cfg80211 btusb bluetooth coretemp iTCO_wdt iTCO_vendor_support serio_raw 
microcode toshiba_acpi sparse_keymap snd_hda_codec_hdmi snd_hda_codec_conexant 
rfkill snd_hda_codec_generic pcspkr uvcvideo videobuf2_core v4l2_common 
videodev videobuf2_vmalloc videobuf2_memops joydev i2c_i801 wmi lpc_ich 
mfd_core acpi_cpufreq toshiba_haps snd_hda_intel snd_hda_controller 
snd_hda_codec snd_hwdep toshiba_bluetooth snd_pcm snd_seq snd_timer 
snd_seq_device snd battery ac soundcore sg autofs4 i915 drm_kms_helper drm 
i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac 
scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
[   29.655223] CPU: 1 PID: 59 Comm: kworker/1:4 Not tainted 3.18.0-master #48
[   29.655225] Hardware name: TOSHIBA 
/, BIOS V1.70   
 09/29/2009
[   29.655231] Workqueue: events request_firmware_work_func
[   29.655235]  0009 8800379bba98 8158f1d4 
c5c5
[   29.655238]  8800379bbae8 8800379bbad8 8104c801 
3664
[   29.655241]  880037b0c000 880136392dc0 8800371feeb0 
88013b027098
[   29.655242] Call Trace:
[   29.655248]  [] dump_stack+0x46/0x58
[   29.655253]  [] warn_slowpath_common+0x81/0xa0
[   29.655256]  [] warn_slowpath_fmt+0x46/0x50
[   29.655261]  [] ? kernfs_path+0x48/0x60
[   29.655263]  [] sysfs_warn_dup+0x68/0x80
[   29.655266]  [] sysfs_create_dir_ns+0x8e/0xa0
[   29.655270]  [] kobject_add_internal+0xc9/0x400
[   29.655273]  [] kobject_add+0x60/0xb0
[   29.655276]  [] ? mutex_lock+0x16/0x37
[   29.655281]  [] device_add+0x104/0x600
[   29.655285]  [] ? lazy_max_pages+0x1e/0x30
[   29.655312]  [] wiphy_register+0x3fd/0x710 [cfg80211]
[   29.655315]  [] ? __vunmap+0xc2/0x110
[   29.655346]  [] ? ieee80211_register_hw+0x1ec/0x9a0 
[mac80211]
[   29.655361]  [] ieee80211_register_hw+0x368/0x9a0 
[mac80211]
[   29.655369]  [] rtl92se_fw_cb+0xab/0x1d0 [rtl8192se]
[   29.655373]  [] request_firmware_work_func+0x30/0x60
[   29.655378]  [] process_one_work+0x14d/0x3d0
[   29.655381]  [] worker_thread+0x121/0x480
[   29.655384]  [] ? process_one_work+0x3d0/0x3d0
[   29.655387]  [] kthread+0xc9/0xe0
[   29.655390]  [] ? __kthread_parkme+0x80/0x80
[   29.655394]  [] ret_from_fork+0x7c/0xb0
[   29.655397]  [] ? __kthread_parkme+0x80/0x80
[   29.655399] ---[ end trace 3935ea42665e29bc ]---
[   29.6

Re: [PATCH 00/14] net: dsa: Fixes and enhancements

[Guenter Roeck]

On 10/22/2014 09:45 PM, Florian Fainelli wrote:

2014-10-22 21:03 GMT-07:00 Guenter Roeck :

Patch 01/14 addresses an annoying and unhelpful log message.

Patches 02/14 and 03/14 are minor enhancements, adding support for
known switch revisions.

Patches 04/14 and 05/14 add support for MV88E6352 and MV88E6176.

Patch 06/14 adds support for hardware monitoring, specifically for
reporting the chip temperature, to the dsa subsystem.

Patches 07/14 and 08/14 implement hardware monitoring for MV88E6352,
MV88E6176, MV88E6123, MV88E6161, and MV88E6165.

Patch 09/14 adds support for EEPROM access to the DSA subsystem.

Patch 10/14 implements EEPROM access for MV88E6352 and MV88E6176.

Patch 11/14 adds support for reading switch registers to the DSA
subsystem.

Patches 12/14 amd 13/14 implement support for reading switch registers
to the drivers for MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.

Patch 14/14 adds support for reading additional RMON registers to the drivers
for  MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.

The series resides and was tested on top of v3.18-rc1 in a system
with MV88E6352. Testing in systems with 88E6131, 88E6060 and MV88E6165
was done earlier (I don't have access to those systems right now).
The series applies cleanly to net-next as of today (10/22).


Besides the two nitpicking comments, this looks really good to me, thanks!


Thanks a lot for the quick review!

I'll wait a couple of days for additional feedback before I resubmit.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/14] net: dsa: Add support for reading switch registers with ethtool

[Guenter Roeck]

On 10/22/2014 09:40 PM, Florian Fainelli wrote:

2014-10-22 21:03 GMT-07:00 Guenter Roeck :

Add support for reading switch registers with 'ethtool -d'.

Signed-off-by: Guenter Roeck 
---


[snip]



+static int dsa_slave_get_regs_len(struct net_device *dev)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   if (ds->drv->get_regs_len != NULL)
+   return ds->drv->get_regs_len(ds, p->port);


Most of the checks in this file are just:

if (ds->drv->callback)
  return ds->drv->callback(...)


Hi Florian,

To be fair, that wasn't the case when I wrote the code ;-).
No problem, I'll do the same.


+
+   return -EOPNOTSUPP;
+}
+
+static void
+dsa_slave_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *_p)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   ds->drv->get_regs(ds, p->port, regs, _p);


We need to check that the driver does implement this callback here as well.



Obviously, and embarrassing ;-).

Thanks a lot for the review!
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 05/27] PCI: tegra: Save msi chip in pci_sys_data

[Bjorn Helgaas]

On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
> Save msi chip in pci_sys_data instead of assign
> msi chip to every pci bus in .add_bus().
> 
> Signed-off-by: Yijing Wang 
> ---
>  drivers/pci/host/pci-tegra.c |   13 +++--
>  1 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index 3d43874..5af0525 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev 
> *pdev, u8 slot, u8 pin)
>   return irq;
>  }
>  
> -static void tegra_pcie_add_bus(struct pci_bus *bus)
> -{
> - if (IS_ENABLED(CONFIG_PCI_MSI)) {
> - struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
> -
> - bus->msi = >msi.chip;
> - }
> -}
> -
>  static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
>  {
>   struct tegra_pcie *pcie = sys_to_pcie(sys);
> @@ -1881,11 +1872,13 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
>  
>   memset(, 0, sizeof(hw));
>  
> +#ifdef CONFIG_PCI_MSI
> + hw.msi_chip = >msi.chip;
> +#endif

Why did you use "#ifdef CONFIG_PCI_MSI" instead of the
"IS_ENABLED(CONFIG_PCI_MSI)" used previously?

It's true that CONFIG_PCI_MSI will never be a tristate symbol, so we don't
really *need* the extra smarts of IS_ENABLED(), but I'm fairly sympathetic
to James' argument [1] that we should just use IS_ENABLED() all the time
because it's simpler overall.

If you want to change the #ifdef to IS_ENABLED(), that should be a separate
patch from your msi_chip change, and we can debate the merits of that by
itself.

[1] http://lkml.iu.edu//hypermail/linux/kernel/1204.3/00081.html

>   hw.nr_controllers = 1;
>   hw.private_data = (void **)
>   hw.setup = tegra_pcie_setup;
>   hw.map_irq = tegra_pcie_map_irq;
> - hw.add_bus = tegra_pcie_add_bus;
>   hw.scan = tegra_pcie_scan_bus;
>   hw.ops = _pcie_ops;
>  
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] thermal-soc changes

[Zhang Rui]

On 二, 2014-10-21 at 09:49 -0400, Eduardo Valentin wrote:
> Hello Rui,
> 
> Here are a couple of changes that are in my tree. They include:
> - a few code refactoring improving the Exynos code base;
> - new feature on the Exynos code base (TRIMINFO and TRIMRELOAD);
> - a documentation of RCAR thermal; and
> - a fix in the of-thermal, regarding the proper usage of of APIs.
> 
what's their target?
please send me separate pull requests for different targets.

thanks,
rui
> They are based on your next branch.
> 
> BR,
> 
> Eduardo Valentin
> 
> The following changes since commit 6ceaf58abe25e86292152005c51169796bad3407:
> 
>   Merge branch 'int340x-thermal' of .git into next (2014-10-17 14:30:58 +0800)
> 
> are available in the git repository at:
> 
> 
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git 
> next
> 
> for you to fetch changes up to df67e40f51398fef8dd705dfe4e287ad9b10ba4b:
> 
>   thermal: fix multiple disbalanced device node counters (2014-10-21 08:05:50 
> -0400)
> 
> 
> Bartlomiej Zolnierkiewicz (9):
>   thermal: exynos: remove unused struct exynos_tmu_registers entries
>   thermal: exynos: remove dead code for HW_MODE calibration
>   thermal: exynos: remove redundant pdata checks from 
> exynos_tmu_initialize()
>   thermal: exynos: remove redundant threshold_code checks from 
> exynos_tmu_initialize()
>   thermal: exynos: simplify temp_to_code() and code_to_temp()
>   thermal: exynos: cache non_hw_trigger_levels in pdata
>   thermal: exynos: remove redundant pdata checks from exynos_tmu_control()
>   thermal: exynos: remove identical values from exynos*_tmu_registers 
> structures
>   thermal: samsung: Exynos5260 and Exynos5420 should not use TRIM_RELOAD 
> flag
> 
> Chanwoo Choi (2):
>   thermal: exynos: Add support for many TRIMINFO_CTRL registers
>   thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
> 
> Geert Uytterhoeven (1):
>   thermal: rcar: Add binding docs for new R-Car Gen2 SoCs
> 
> Vladimir Zapolskiy (1):
>   thermal: fix multiple disbalanced device node counters
> 
>  .../devicetree/bindings/thermal/rcar-thermal.txt   |   5 +-
>  drivers/thermal/of-thermal.c   |  40 --
>  drivers/thermal/samsung/exynos_thermal_common.h|   2 +-
>  drivers/thermal/samsung/exynos_tmu.c   | 141 
> ++---
>  drivers/thermal/samsung/exynos_tmu.h   |  81 ++--
>  drivers/thermal/samsung/exynos_tmu_data.c  |  83 
>  drivers/thermal/samsung/exynos_tmu_data.h  |  39 +-
>  7 files changed, 111 insertions(+), 280 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 3/4] gpiolib: add irq_not_threaded flag to gpio_chip

[Alexandre Courbot]

On Mon, Oct 20, 2014 at 7:19 PM, Octavian Purdila
 wrote:
> On Mon, Oct 20, 2014 at 8:08 AM, Alexandre Courbot  wrote:
>>
>> On Wed, Oct 15, 2014 at 11:48 PM, Octavian Purdila
>>  wrote:
>> > Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set
>> > operation but do not need a threaded irq handler.
>>
>> Sorry if you already explained this (I have been a little bit late
>> with the GPIO reviews recently), but does this optimization bring a
>> significant benefit that justifies adding another field in struct
>> gpio_chip? If so it would be nice to have it in the commit message. If
>> not, do we need this at all?
>
> Hi Alexandre,
>
> In the case DLN2 USB GPIO adapter the GPIO interrupt is generated in
> the completion routine of a receive URB, which means that we are in
> interrupt context. If a threaded irq is used, we would have to
> schedule work instead of running to interrupt handler directly which
> is unnecessary and adds latency.
>
> BTW, AFAIC Linus W already merged this patch in his next tree, I am
> keeping it in this series because it was not pulled in the mfd-next
> tree.

You're right, it's all good then. Thanks for the explanation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] selftests/kcmp: Don't include kernel headers

[Michael Ellerman]

The kcmp test mucks with the include path to bring in the kernel
headers, and x86 headers too for reasons that are not clear.

Now that kcmp.h is exported none of that should be necessary.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/kcmp/Makefile | 4 
 1 file changed, 4 deletions(-)

diff --git a/tools/testing/selftests/kcmp/Makefile 
b/tools/testing/selftests/kcmp/Makefile
index 8aabd82db9e4..4f00c0524501 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -8,11 +8,7 @@ ifeq ($(ARCH),x86_64)
ARCH := x86
CFLAGS := -DCONFIG_X86_64 -D__x86_64__
 endif
-
-CFLAGS += -I../../../../arch/x86/include/generated/
-CFLAGS += -I../../../../include/
 CFLAGS += -I../../../../usr/include/
-CFLAGS += -I../../../../arch/x86/include/
 
 all:
 ifeq ($(ARCH),x86)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] selftests/kcmp: Always try to build the test

[Michael Ellerman]

Don't prevent the test building on non-x86. Just try and build it and
let the chips fall where they may.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/kcmp/Makefile | 14 --
 1 file changed, 14 deletions(-)

diff --git a/tools/testing/selftests/kcmp/Makefile 
b/tools/testing/selftests/kcmp/Makefile
index 4f00c0524501..cda9cc4004c9 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -1,21 +1,7 @@
-uname_M := $(shell uname -m 2>/dev/null || echo not)
-ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
-ifeq ($(ARCH),i386)
-ARCH := x86
-   CFLAGS := -DCONFIG_X86_32 -D__i386__
-endif
-ifeq ($(ARCH),x86_64)
-   ARCH := x86
-   CFLAGS := -DCONFIG_X86_64 -D__x86_64__
-endif
 CFLAGS += -I../../../../usr/include/
 
 all:
-ifeq ($(ARCH),x86)
gcc $(CFLAGS) kcmp_test.c -o kcmp_test
-else
-   echo "Not an x86 target, can't build kcmp selftest"
-endif
 
 run_tests: all
@./kcmp_test || echo "kcmp_test: [FAIL]"
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] kcmp: Move kcmp.h into uapi

[Michael Ellerman]

kcmp.h appears to be part of the API, it's documented in kcmp(2), and
the selftests/kcmp code uses it. So move it to uapi so it's actually
exported.

Signed-off-by: Michael Ellerman 
---
 include/linux/kcmp.h  | 13 +
 include/uapi/linux/Kbuild |  1 +
 include/uapi/linux/kcmp.h | 17 +
 3 files changed, 19 insertions(+), 12 deletions(-)
 create mode 100644 include/uapi/linux/kcmp.h

diff --git a/include/linux/kcmp.h b/include/linux/kcmp.h
index 2dcd1b3aafc8..9dfb23e1771b 100644
--- a/include/linux/kcmp.h
+++ b/include/linux/kcmp.h
@@ -1,17 +1,6 @@
 #ifndef _LINUX_KCMP_H
 #define _LINUX_KCMP_H
 
-/* Comparison type */
-enum kcmp_type {
-   KCMP_FILE,
-   KCMP_VM,
-   KCMP_FILES,
-   KCMP_FS,
-   KCMP_SIGHAND,
-   KCMP_IO,
-   KCMP_SYSVSEM,
-
-   KCMP_TYPES,
-};
+#include 
 
 #endif /* _LINUX_KCMP_H */
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index b70237e8bc37..1cf50d682dbf 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -209,6 +209,7 @@ header-y += ivtvfb.h
 header-y += ixjuser.h
 header-y += jffs2.h
 header-y += joystick.h
+header-y += kcmp.h
 header-y += kd.h
 header-y += kdev_t.h
 header-y += kernel-page-flags.h
diff --git a/include/uapi/linux/kcmp.h b/include/uapi/linux/kcmp.h
new file mode 100644
index ..84df14b37360
--- /dev/null
+++ b/include/uapi/linux/kcmp.h
@@ -0,0 +1,17 @@
+#ifndef _UAPI_LINUX_KCMP_H
+#define _UAPI_LINUX_KCMP_H
+
+/* Comparison type */
+enum kcmp_type {
+   KCMP_FILE,
+   KCMP_VM,
+   KCMP_FILES,
+   KCMP_FS,
+   KCMP_SIGHAND,
+   KCMP_IO,
+   KCMP_SYSVSEM,
+
+   KCMP_TYPES,
+};
+
+#endif /* _UAPI_LINUX_KCMP_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring

[Guenter Roeck]

On 10/22/2014 09:37 PM, Florian Fainelli wrote:

2014-10-22 21:03 GMT-07:00 Guenter Roeck :

Some Marvell switches provide chip temperature data.
Add support for reporting it to the dsa infrastructure.

Signed-off-by: Guenter Roeck 
---

[snip]


+/* hwmon support /
+
+#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))


IS_ENABLED(CONFIG_HWMON)?



Hi Florian,

unfortunately, that won't work; I had it initially and got a nice error message
from Fengguang's build test bot.

Problem is that hwmon can be built as module and the dsa subsystem can be built
into the kernel. In that case, hwmon functionality in the driver must be 
disabled.
The above condition covers that case. The nouveau graphics driver has the same
problem and uses the same conditional to solve it.

An alternative would be to select HWMON in the NET_DSA Kconfig entry; the
Broadcom Tigon3 driver does that. I just don't know if that is a good idea.
I am open to suggestions.


+
+static ssize_t temp1_input_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dsa_switch *ds = dev_get_drvdata(dev);
+   int temp, ret;
+
+   ret = ds->drv->get_temp(ds, );
+   if (ret < 0)
+   return ret;
+
+   return sprintf(buf, "%d\n", temp * 1000);
+}
+static DEVICE_ATTR_RO(temp1_input);


You probably want the number of temperature sensors to come from the
switch driver, and support arbitrary number of temperature sensors?


In that case we would need the number of sensors, pass a sensor index,
and create a dynamic number of attributes. The code would get much more
complex without real benefit unless there is such a chip - and if there is,
we can still change the code at that time. I would prefer to keep it simple
for now.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] perf tools: Add support for exclusive option

[Masami Hiramatsu]

(2014/10/23 0:15), Namhyung Kim wrote:
> Some options cannot be used at the same time.  To handle such options
> add a new PARSE_OPT_EXCLUSIVE flag and show error message if more than
> one of them is used.

Looks useful for me :)

Reviewed-by: Masami Hiramatsu 

I just have a comment below;

> @@ -360,19 +378,21 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
>   }
>  
>   if (arg[1] != '-') {
> - ctx->opt = arg + 1;
> + ctx->opt = ++arg;
>   if (internal_help && *ctx->opt == 'h')
>   return usage_with_options_internal(usagestr, 
> options, 0);
>   switch (parse_short_opt(ctx, options)) {
>   case -1:
> - return parse_options_usage(usagestr, options, 
> arg + 1, 1);
> + return parse_options_usage(usagestr, options, 
> arg, 1);
>   case -2:
>   goto unknown;
> + case -3:
> + goto exclusive;

BTW, it may be a time to define return error codes.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] perf probe: Use PARSE_OPT_EXCLUSIVE flag

[Masami Hiramatsu]

Hi Namhyng,


(2014/10/23 0:15), Namhyung Kim wrote:
> The perf probe has some exclusive options.  Use new PARSE_OPT_EXCLUSIVE
> flag to simplify the code and show more compact usage.
> 
>   $ perf probe -l -a foo
> Error: switch `a' cannot be used with switch `l'
> 
>usage: perf probe [] 'PROBEDEF' ['PROBEDEF' ...]
>   or: perf probe [] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
>   or: perf probe [] --del '[GROUP:]EVENT' ...
>   or: perf probe --list
>   or: perf probe [] --line 'LINEDESC'
>   or: perf probe [] --vars 'PROBEPOINT'
> 
>   -a, --add <[EVENT=]FUNC[@SRC][+OFF|%return|:RL|;PT]|SRC:AL|SRC;PT 
> [[NAME=]ARG ...]>
> probe point definition, where
>   GROUP:  Group name (optional)
>   EVENT:  Event name
>   FUNC:   Function name
>   OFF:Offset from function entry (in byte)
>   %return:Put the probe at function return
>   SRC:Source code path
>   RL: Relative line number from function entry.
>   AL: Absolute line number in file.
>   PT: Lazy expression of line code.
>   ARG:Probe argument (local variable name or
>   kprobe-tracer argument format.)
> 
>   -l, --listlist up current probe events
> 

Thanks! this looks very good to me:)

Acked-by: Masami Hiramatsu 

> Cc: Masami Hiramatsu 
> Cc: Hemant Kumar 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/builtin-probe.c | 54 
> --
>  1 file changed, 9 insertions(+), 45 deletions(-)
> 
> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
> index 04412b4770a2..23d6e7f03cf1 100644
> --- a/tools/perf/builtin-probe.c
> +++ b/tools/perf/builtin-probe.c
> @@ -312,7 +312,7 @@ __cmd_probe(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>  #endif
>   NULL
>  };
> - const struct option options[] = {
> + struct option options[] = {
>   OPT_INCR('v', "verbose", ,
>   "be more verbose (show parsed arguments, etc)"),
>   OPT_BOOLEAN('l', "list", _events,
> @@ -382,6 +382,14 @@ __cmd_probe(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   };
>   int ret;
>  
> + set_option_flag(options, 'a', "add", PARSE_OPT_EXCLUSIVE);
> + set_option_flag(options, 'd', "del", PARSE_OPT_EXCLUSIVE);
> + set_option_flag(options, 'l', "list", PARSE_OPT_EXCLUSIVE);
> +#ifdef HAVE_DWARF_SUPPORT
> + set_option_flag(options, 'L', "line", PARSE_OPT_EXCLUSIVE);
> + set_option_flag(options, 'V', "vars", PARSE_OPT_EXCLUSIVE);
> +#endif
> +
>   argc = parse_options(argc, argv, options, probe_usage,
>PARSE_OPT_STOP_AT_NON_OPTION);
>   if (argc > 0) {
> @@ -409,22 +417,6 @@ __cmd_probe(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
>  
>   if (params.list_events) {
> - if (params.mod_events) {
> - pr_err("  Error: Don't use --list with --add/--del.\n");
> - usage_with_options(probe_usage, options);
> - }
> - if (params.show_lines) {
> - pr_err("  Error: Don't use --list with --line.\n");
> - usage_with_options(probe_usage, options);
> - }
> - if (params.show_vars) {
> - pr_err(" Error: Don't use --list with --vars.\n");
> - usage_with_options(probe_usage, options);
> - }
> - if (params.show_funcs) {
> - pr_err("  Error: Don't use --list with --funcs.\n");
> - usage_with_options(probe_usage, options);
> - }
>   if (params.uprobes) {
>   pr_warning("  Error: Don't use --list with --exec.\n");
>   usage_with_options(probe_usage, options);
> @@ -435,19 +427,6 @@ __cmd_probe(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   return ret;
>   }
>   if (params.show_funcs) {
> - if (params.nevents != 0 || params.dellist) {
> - pr_err("  Error: Don't use --funcs with"
> -" --add/--del.\n");
> - usage_with_options(probe_usage, options);
> - }
> - if (params.show_lines) {
> - pr_err("  Error: Don't use --funcs with --line.\n");
> - usage_with_options(probe_usage, options);
> - }
> - if (params.show_vars) {
> - pr_err("  Error: Don't use --funcs with --vars.\n");
> - usage_with_options(probe_usage, options);
> - }
>   if (!params.filter)
>   params.filter = 

Re: [PATCH 00/14] net: dsa: Fixes and enhancements

[Florian Fainelli]

2014-10-22 21:03 GMT-07:00 Guenter Roeck :
> Patch 01/14 addresses an annoying and unhelpful log message.
>
> Patches 02/14 and 03/14 are minor enhancements, adding support for
> known switch revisions.
>
> Patches 04/14 and 05/14 add support for MV88E6352 and MV88E6176.
>
> Patch 06/14 adds support for hardware monitoring, specifically for
> reporting the chip temperature, to the dsa subsystem.
>
> Patches 07/14 and 08/14 implement hardware monitoring for MV88E6352,
> MV88E6176, MV88E6123, MV88E6161, and MV88E6165.
>
> Patch 09/14 adds support for EEPROM access to the DSA subsystem.
>
> Patch 10/14 implements EEPROM access for MV88E6352 and MV88E6176.
>
> Patch 11/14 adds support for reading switch registers to the DSA
> subsystem.
>
> Patches 12/14 amd 13/14 implement support for reading switch registers
> to the drivers for MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.
>
> Patch 14/14 adds support for reading additional RMON registers to the drivers
> for  MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.
>
> The series resides and was tested on top of v3.18-rc1 in a system
> with MV88E6352. Testing in systems with 88E6131, 88E6060 and MV88E6165
> was done earlier (I don't have access to those systems right now).
> The series applies cleanly to net-next as of today (10/22).

Besides the two nitpicking comments, this looks really good to me, thanks!

>
> 
> Guenter Roeck (14):
>   net: dsa: Don't set skb->protocol on outgoing tagged packets
>   net: dsa: Report known silicon revisions for Marvell 88E6060
>   net: dsa: Report known silicon revisions for Marvell 88E6131
>   net: dsa: Add support for Marvell 88E6352
>   net: dsa/mv88e6352: Add support for MV88E6176
>   net: dsa: Add support for hardware monitoring
>   net: dsa/mv88e6352: Report chip temperature
>   net: dsa/mv88e6123_61_65: Report chip temperature
>   net: dsa: Add support for switch EEPROM access
>   net: dsa/mv88e6352: Implement EEPROM access functions
>   net: dsa: Add support for reading switch registers with ethtool
>   net: dsa/mv88e6123_61_65: Add support for reading switch registers
>   net: dsa/mv88e6352: Add support for reading switch registers
>   net: dsa: Provide additional RMON statistics
>
>  MAINTAINERS   |   5 +
>  drivers/net/dsa/Kconfig   |   9 +
>  drivers/net/dsa/Makefile  |   3 +
>  drivers/net/dsa/mv88e6060.c   |   5 +-
>  drivers/net/dsa/mv88e6123_61_65.c |  68 +++-
>  drivers/net/dsa/mv88e6131.c   |  12 +-
>  drivers/net/dsa/mv88e6352.c   | 789 
> ++
>  drivers/net/dsa/mv88e6xxx.c   |  53 ++-
>  drivers/net/dsa/mv88e6xxx.h   |  15 +
>  include/net/dsa.h |  20 +
>  net/dsa/dsa.c | 111 ++
>  net/dsa/slave.c   |  60 +++
>  net/dsa/tag_dsa.c |   2 -
>  net/dsa/tag_edsa.c|   2 -
>  net/dsa/tag_trailer.c |   2 -
>  15 files changed, 1138 insertions(+), 18 deletions(-)
>  create mode 100644 drivers/net/dsa/mv88e6352.c



-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 02/27] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()

[Yijing Wang]

On 2014/10/23 12:25, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
>> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
>> introduced two __weak arch functions arch_msix_mask_irq() and
>> arch_msi_mask_irq() to work around a bug when running xen in x86.
>> These two functions made msi code more complex. This patch reverts
>> the commit and introduces a global flag to control msi mask action to
>> avoid the bug. The patch is also preparation for using MSI chip framework
>> instead of weak arch MSI functions in all platforms. Keep 
>> default_msi_mask_irq()
>> and default_msix_mask_irq() in linux/msi.h to make s390 MSI code compile
>> happy, they will be removed in the later patch.
> 
> This patch is basically a revert of 0e4ccb1505a9 intermingled with the
> addition of the new pci_msi_ignore_mask technique.
> 
> Can you please split this into two patches:
> 
>   - Add the pci_msi_ignore_mask stuff (alongside the existing way)
>   - Revert 0e4ccb1505a9
> 
> I think that will make it easier to see what's going on.

OK, I will do it, thanks.

Thanks!
Yijing.

> 
>> Signed-off-by: Yijing Wang 
>> CC: David Vrabel 
>> CC: Konrad Rzeszutek Wilk 
>> ---
>> Hi David and Konrad,
>>I dropped the Acked-by and tested-by, because this version has a
>> lot changes compared to last. So, I guess you may want to check it again.
>> ---
>>  arch/x86/include/asm/x86_init.h |3 ---
>>  arch/x86/kernel/x86_init.c  |   10 --
>>  arch/x86/pci/xen.c  |   14 ++
>>  drivers/pci/msi.c   |   29 -
>>  include/linux/msi.h |8 ++--
>>  5 files changed, 20 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/x86_init.h 
>> b/arch/x86/include/asm/x86_init.h
>> index e45e4da..f58a9c7 100644
>> --- a/arch/x86/include/asm/x86_init.h
>> +++ b/arch/x86/include/asm/x86_init.h
>> @@ -172,7 +172,6 @@ struct x86_platform_ops {
>>  
>>  struct pci_dev;
>>  struct msi_msg;
>> -struct msi_desc;
>>  
>>  struct x86_msi_ops {
>>  int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
>> @@ -183,8 +182,6 @@ struct x86_msi_ops {
>>  void (*teardown_msi_irqs)(struct pci_dev *dev);
>>  void (*restore_msi_irqs)(struct pci_dev *dev);
>>  int  (*setup_hpet_msi)(unsigned int irq, unsigned int id);
>> -u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
>> -u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
>>  };
>>  
>>  struct IO_APIC_route_entry;
>> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
>> index e48b674..234b072 100644
>> --- a/arch/x86/kernel/x86_init.c
>> +++ b/arch/x86/kernel/x86_init.c
>> @@ -116,8 +116,6 @@ struct x86_msi_ops x86_msi = {
>>  .teardown_msi_irqs  = default_teardown_msi_irqs,
>>  .restore_msi_irqs   = default_restore_msi_irqs,
>>  .setup_hpet_msi = default_setup_hpet_msi,
>> -.msi_mask_irq   = default_msi_mask_irq,
>> -.msix_mask_irq  = default_msix_mask_irq,
>>  };
>>  
>>  /* MSI arch specific hooks */
>> @@ -140,14 +138,6 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
>>  {
>>  x86_msi.restore_msi_irqs(dev);
>>  }
>> -u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>> -{
>> -return x86_msi.msi_mask_irq(desc, mask, flag);
>> -}
>> -u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
>> -{
>> -return x86_msi.msix_mask_irq(desc, flag);
>> -}
>>  #endif
>>  
>>  struct x86_io_apic_ops x86_io_apic_ops = {
>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>> index 093f5f4..e5b8b78 100644
>> --- a/arch/x86/pci/xen.c
>> +++ b/arch/x86/pci/xen.c
>> @@ -394,14 +394,6 @@ static void xen_teardown_msi_irq(unsigned int irq)
>>  {
>>  xen_destroy_irq(irq);
>>  }
>> -static u32 xen_nop_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>> -{
>> -return 0;
>> -}
>> -static u32 xen_nop_msix_mask_irq(struct msi_desc *desc, u32 flag)
>> -{
>> -return 0;
>> -}
>>  #endif
>>  
>>  int __init pci_xen_init(void)
>> @@ -425,8 +417,7 @@ int __init pci_xen_init(void)
>>  x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
>>  x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>>  x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
>> -x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>> -x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +pci_msi_ignore_mask = 1;
>>  #endif
>>  return 0;
>>  }
>> @@ -506,8 +497,7 @@ int __init pci_xen_initial_domain(void)
>>  x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
>>  x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>>  x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
>> -x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
>> -x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
>> +pci_msi_ignore_mask = 1;
>>  #endif
>>  xen_setup_acpi_sci();
>>  __acpi_register_gsi = acpi_register_gsi_xen;
>> diff --git 

Re: [PATCH 11/14] net: dsa: Add support for reading switch registers with ethtool

[Florian Fainelli]

2014-10-22 21:03 GMT-07:00 Guenter Roeck :
> Add support for reading switch registers with 'ethtool -d'.
>
> Signed-off-by: Guenter Roeck 
> ---

[snip]

>
> +static int dsa_slave_get_regs_len(struct net_device *dev)
> +{
> +   struct dsa_slave_priv *p = netdev_priv(dev);
> +   struct dsa_switch *ds = p->parent;
> +
> +   if (ds->drv->get_regs_len != NULL)
> +   return ds->drv->get_regs_len(ds, p->port);

Most of the checks in this file are just:

if (ds->drv->callback)
 return ds->drv->callback(...)

> +
> +   return -EOPNOTSUPP;
> +}
> +
> +static void
> +dsa_slave_get_regs(struct net_device *dev, struct ethtool_regs *regs, void 
> *_p)
> +{
> +   struct dsa_slave_priv *p = netdev_priv(dev);
> +   struct dsa_switch *ds = p->parent;
> +
> +   ds->drv->get_regs(ds, p->port, regs, _p);

We need to check that the driver does implement this callback here as well.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring

[Florian Fainelli]

2014-10-22 21:03 GMT-07:00 Guenter Roeck :
> Some Marvell switches provide chip temperature data.
> Add support for reporting it to the dsa infrastructure.
>
> Signed-off-by: Guenter Roeck 
> ---
[snip]

> +/* hwmon support 
> /
> +
> +#if defined(CONFIG_HWMON) || (defined(MODULE) && 
> defined(CONFIG_HWMON_MODULE))

IS_ENABLED(CONFIG_HWMON)?

> +
> +static ssize_t temp1_input_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> +   struct dsa_switch *ds = dev_get_drvdata(dev);
> +   int temp, ret;
> +
> +   ret = ds->drv->get_temp(ds, );
> +   if (ret < 0)
> +   return ret;
> +
> +   return sprintf(buf, "%d\n", temp * 1000);
> +}
> +static DEVICE_ATTR_RO(temp1_input);

You probably want the number of temperature sensors to come from the
switch driver, and support arbitrary number of temperature sensors?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] pm: add FSM configuration for deep sleep

[Chenhui Zhao]

For some Freescale's SoCs which support deep sleep, such as T1040,
LS1021, software will start a Finite State Machine (FSM) to control
the hardware precedure to enter deep sleep and return from it.

This patch configures parameters of the FSM preparing for deep sleep.

Signed-off-by: Chenhui Zhao 
---
Changes for v2:
 * use iowrite32be()

 drivers/platform/Kconfig |1 +
 drivers/platform/Makefile|1 +
 drivers/platform/fsl/Kconfig |   10 ++
 drivers/platform/fsl/Makefile|5 +
 drivers/platform/fsl/sleep_fsm.c |  269 ++
 drivers/platform/fsl/sleep_fsm.h |  106 +++
 6 files changed, 392 insertions(+), 0 deletions(-)
 create mode 100644 drivers/platform/fsl/Kconfig
 create mode 100644 drivers/platform/fsl/Makefile
 create mode 100644 drivers/platform/fsl/sleep_fsm.c
 create mode 100644 drivers/platform/fsl/sleep_fsm.h

diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index 69616ae..54ada25 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -5,3 +5,4 @@ if GOLDFISH
 source "drivers/platform/goldfish/Kconfig"
 endif
 
+source "drivers/platform/fsl/Kconfig"
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index 8a44a4c..d0cce95 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_X86)  += x86/
 obj-$(CONFIG_OLPC) += olpc/
 obj-$(CONFIG_GOLDFISH) += goldfish/
+obj-$(CONFIG_FSL_SOC)  += fsl/
diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig
new file mode 100644
index 000..72ed053
--- /dev/null
+++ b/drivers/platform/fsl/Kconfig
@@ -0,0 +1,10 @@
+#
+# Freescale Specific Power Management Drivers
+#
+
+config FSL_SLEEP_FSM
+   bool
+   help
+ This driver configures a hardware FSM (Finite State Machine) for deep 
sleep.
+ The FSM is used to finish clean-ups at the last stage of system 
entering deep
+ sleep, and also wakes up system when a wake up event happens.
diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile
new file mode 100644
index 000..d99ca0e
--- /dev/null
+++ b/drivers/platform/fsl/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for linux/drivers/platform/fsl
+# Freescale Specific Power Management Drivers
+#
+obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o
diff --git a/drivers/platform/fsl/sleep_fsm.c b/drivers/platform/fsl/sleep_fsm.c
new file mode 100644
index 000..32616ad
--- /dev/null
+++ b/drivers/platform/fsl/sleep_fsm.c
@@ -0,0 +1,269 @@
+/*
+ * Freescale deep sleep FSM (finite-state machine) configuration
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * 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 "sleep_fsm.h"
+/*
+ * These values are from chip's reference manual. For example,
+ * the values for T1040 can be found in "8.4.3.8 Programming
+ * supporting deep sleep mode" of Chapter 8 "Run Control and
+ * Power Management (RCPM)".
+ * The default value can be applied to T104x, LS1021.
+ */
+struct fsm_reg_vals epu_default_val[] = {
+   /* EPGCR (Event Processor Global Control Register) */
+   {EPGCR, 0},
+   /* EPECR (Event Processor Event Control Registers) */
+   {EPECR0 + EPECR_STRIDE * 0, 0},
+   {EPECR0 + EPECR_STRIDE * 1, 0},
+   {EPECR0 + EPECR_STRIDE * 2, 0xF0004004},
+   {EPECR0 + EPECR_STRIDE * 3, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 4, 0x2084},
+   {EPECR0 + EPECR_STRIDE * 5, 0x0804},
+   {EPECR0 + EPECR_STRIDE * 6, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 7, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 8, 0x6084},
+   {EPECR0 + EPECR_STRIDE * 9, 0x0884},
+   {EPECR0 + EPECR_STRIDE * 10, 0x4284},
+   {EPECR0 + EPECR_STRIDE * 11, 0x9084},
+   {EPECR0 + EPECR_STRIDE * 12, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 13, 0x0884},
+   {EPECR0 + EPECR_STRIDE * 14, 0x0284},
+   {EPECR0 + EPECR_STRIDE * 15, 0x0004},
+   /*
+* EPEVTCR (Event Processor EVT Pin Control Registers)
+* SCU8 triger EVT2, and SCU11 triger EVT9
+*/
+   {EPEVTCR0 + EPEVTCR_STRIDE * 0, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 1, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 2, 0x8001},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 3, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 4, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 5, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 6, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 7, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 8, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 9, 0xB001},
+   /* EPCMPR (Event Processor Counter Compare Registers) */
+   {EPCMPR0 + EPCMPR_STRIDE * 0, 0},
+   

Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory

[Aneesh Kumar K.V]

Andrew Morton  writes:

> On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V" 
>  wrote:
>
>> Update generic gup implementation with powerpc specific details.
>> On powerpc at pmd level we can have hugepte, normal pmd pointer
>> or a pointer to the hugepage directory.
>> 
>> ...
>>
>> --- a/arch/arm/include/asm/pgtable.h
>> +++ b/arch/arm/include/asm/pgtable.h
>> @@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
>>  /* to find an entry in a kernel page-table-directory */
>>  #define pgd_offset_k(addr)  pgd_offset(_mm, addr)
>>  
>> +#define pgd_huge(pgd)   (0)
>> +
>>  #define pmd_none(pmd)   (!pmd_val(pmd))
>>  #define pmd_present(pmd)(pmd_val(pmd))
>>  
>> diff --git a/arch/arm64/include/asm/pgtable.h 
>> b/arch/arm64/include/asm/pgtable.h
>> index cefd3e825612..ed8f42497ac4 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t 
>> newprot)
>>  extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
>>  extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
>>  
>> +#define pgd_huge(pgd)   (0)
>> +
>
> So only arm, arm64 and powerpc implement CONFIG_HAVE_GENERIC_RCU_GUP
> and only powerpc impements pgd_huge().
>
> Could we get a bit of documentation in place for pgd_huge() so that
> people who aren't familiar with powerpc can understand what's going
> on?

Will update

>
>>  /*
>>   * Encode and decode a swap entry:
>>   *  bits 0-1:   present (must be zero)
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 02d11ee7f19d..f97732412cb4 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1219,6 +1219,32 @@ long get_user_pages(struct task_struct *tsk, struct 
>> mm_struct *mm,
>>  struct vm_area_struct **vmas);
>>  int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>>  struct page **pages);
>> +
>> +#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
>> +#ifndef is_hugepd
>
> And is_hugepd is a bit of a mystery.  Let's get some description in
> place for this as well?  Why it exists, what its role is.  Also,
> specifically which arch header file is responsible for defining it.
>
> It takes a hugepd_t argument, but hugepd_t is defined later in this
> header file.  This is weird because any preceding implementation of
> is_hugepd() can't actually be implemented because it hasn't seen the
> hugepd_t definition yet!  So any is_hugepd() implementation is forced
> to be a simple macro which punts to a C function which *has* seen the
> hugepd_t definition.  What a twisty maze.

arch can definitely do

#defne is_hugepd is_hugepd
typedef struct { unsigned long pd; } hugepd_t;
static inline int is_hugepd(hugepd_t hpd)
{

}

I wanted to make sure arch can have their own definition of hugepd_t . 

>
> It all seems messy, confusing and poorly documented.  Can we clean this
> up?
>
>> +/*
>> + * Some architectures support hugepage directory format that is
>> + * required to support different hugetlbfs sizes.
>> + */
>> +typedef struct { unsigned long pd; } hugepd_t;
>> +#define is_hugepd(hugepd) (0)
>> +#define __hugepd(x) ((hugepd_t) { (x) })
>
> What's this.

macro that is used to convert value to type hugepd_t. We use that style
already for __pte() etc.

>
>> +static inline int gup_hugepd(hugepd_t hugepd, unsigned long addr,
>> + unsigned pdshift, unsigned long end,
>> + int write, struct page **pages, int *nr)
>> +{
>> +return 0;
>> +}
>> +#else
>> +extern int gup_hugepd(hugepd_t hugepd, unsigned long addr,
>> +  unsigned pdshift, unsigned long end,
>> +  int write, struct page **pages, int *nr);
>> +#endif
>> +extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
>> +unsigned long sz, unsigned long end, int write,
>> +struct page **pages, int *nr);
>> +#endif

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 02/27] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()

[Bjorn Helgaas]

On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> introduced two __weak arch functions arch_msix_mask_irq() and
> arch_msi_mask_irq() to work around a bug when running xen in x86.
> These two functions made msi code more complex. This patch reverts
> the commit and introduces a global flag to control msi mask action to
> avoid the bug. The patch is also preparation for using MSI chip framework
> instead of weak arch MSI functions in all platforms. Keep 
> default_msi_mask_irq()
> and default_msix_mask_irq() in linux/msi.h to make s390 MSI code compile
> happy, they will be removed in the later patch.

This patch is basically a revert of 0e4ccb1505a9 intermingled with the
addition of the new pci_msi_ignore_mask technique.

Can you please split this into two patches:

  - Add the pci_msi_ignore_mask stuff (alongside the existing way)
  - Revert 0e4ccb1505a9

I think that will make it easier to see what's going on.

> Signed-off-by: Yijing Wang 
> CC: David Vrabel 
> CC: Konrad Rzeszutek Wilk 
> ---
> Hi David and Konrad,
>I dropped the Acked-by and tested-by, because this version has a
> lot changes compared to last. So, I guess you may want to check it again.
> ---
>  arch/x86/include/asm/x86_init.h |3 ---
>  arch/x86/kernel/x86_init.c  |   10 --
>  arch/x86/pci/xen.c  |   14 ++
>  drivers/pci/msi.c   |   29 -
>  include/linux/msi.h |8 ++--
>  5 files changed, 20 insertions(+), 44 deletions(-)
> 
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index e45e4da..f58a9c7 100644
> --- a/arch/x86/include/asm/x86_init.h
> +++ b/arch/x86/include/asm/x86_init.h
> @@ -172,7 +172,6 @@ struct x86_platform_ops {
>  
>  struct pci_dev;
>  struct msi_msg;
> -struct msi_desc;
>  
>  struct x86_msi_ops {
>   int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
> @@ -183,8 +182,6 @@ struct x86_msi_ops {
>   void (*teardown_msi_irqs)(struct pci_dev *dev);
>   void (*restore_msi_irqs)(struct pci_dev *dev);
>   int  (*setup_hpet_msi)(unsigned int irq, unsigned int id);
> - u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
> - u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
>  };
>  
>  struct IO_APIC_route_entry;
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index e48b674..234b072 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -116,8 +116,6 @@ struct x86_msi_ops x86_msi = {
>   .teardown_msi_irqs  = default_teardown_msi_irqs,
>   .restore_msi_irqs   = default_restore_msi_irqs,
>   .setup_hpet_msi = default_setup_hpet_msi,
> - .msi_mask_irq   = default_msi_mask_irq,
> - .msix_mask_irq  = default_msix_mask_irq,
>  };
>  
>  /* MSI arch specific hooks */
> @@ -140,14 +138,6 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
>  {
>   x86_msi.restore_msi_irqs(dev);
>  }
> -u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> -{
> - return x86_msi.msi_mask_irq(desc, mask, flag);
> -}
> -u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
> -{
> - return x86_msi.msix_mask_irq(desc, flag);
> -}
>  #endif
>  
>  struct x86_io_apic_ops x86_io_apic_ops = {
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 093f5f4..e5b8b78 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -394,14 +394,6 @@ static void xen_teardown_msi_irq(unsigned int irq)
>  {
>   xen_destroy_irq(irq);
>  }
> -static u32 xen_nop_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
> -{
> - return 0;
> -}
> -static u32 xen_nop_msix_mask_irq(struct msi_desc *desc, u32 flag)
> -{
> - return 0;
> -}
>  #endif
>  
>  int __init pci_xen_init(void)
> @@ -425,8 +417,7 @@ int __init pci_xen_init(void)
>   x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
>   x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>   x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
> - x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> - x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> + pci_msi_ignore_mask = 1;
>  #endif
>   return 0;
>  }
> @@ -506,8 +497,7 @@ int __init pci_xen_initial_domain(void)
>   x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
>   x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
>   x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
> - x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
> - x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
> + pci_msi_ignore_mask = 1;
>  #endif
>   xen_setup_acpi_sci();
>   __acpi_register_gsi = acpi_register_gsi_xen;
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index ecb92a5..22e413c 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -23,6 +23,7 @@
>  #include "pci.h"
>  
>  static int pci_msi_enable = 

linux-next: Tree for Oct 23

[Stephen Rothwell]

Hi all,

Changes since 20141022:

The sound-asoc tree still had its build failure so I used the version from
next-20141020.

The akpm-current tree gained a conflict against the pm tree.

Non-merge commits (relative to Linus' tree): 969
 1089 files changed, 21364 insertions(+), 36533 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 225 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (c3351dfabf5c Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (178c3dfe853a ARM: fix some printk formats)
Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat 
arch/m68k/mm/hwtest.c)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/for-linus (e89dafb5ca50 powerpc: Only do dynamic DMA 
zone limits on platforms that need it)
Merging sparc/master (61ed53deb1c6 Merge tag 'ntb-3.18' of 
git://github.com/jonmason/ntb)
Merging net/master (942396b01989 hyperv: Fix the total_data_buflen in send path)
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (dde1c652d7b1 ALSA: pcm: Fix false lockdep 
warnings)
Merging pci-current/for-linus (f10e3cd690b8 Merge branch 
'remove-weak-function-declarations' into for-linus)
Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in 
brcmf_count_20mhz_channels())
Merging driver-core.current/driver-core-linus (f114040e3ea6 Linux 3.18-rc1)
Merging tty.current/tty-linus (f114040e3ea6 Linux 3.18-rc1)
Merging usb.current/usb-linus (f114040e3ea6 Linux 3.18-rc1)
Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when 
multiple TRBs are started)
Merging usb-serial-fixes/usb-linus (dc477ad386fb USB: kobil_sct: Remove unused 
transfer buffer allocs)
Merging staging.current/staging-linus (54d5c5cd0fb2 staging: rtl8723au: Fix 
alignment of mac_addr for ether_addr_copy() usage)
Merging char-misc.current/char-misc-linus (f114040e3ea6 Linux 3.18-rc1)
Merging input-current/for-linus (4dfb15cd5aaa Input: xpad - add Thrustmaster as 
Xbox 360 controller vendor)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned 
input data in generic sha256 and sha512.)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL 
dereference in selftest removal code)
Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to 
remove the device)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (ce6a144a0d01 selftests/memfd: Run test on all 
architectures)
Merging drm-intel-fixes/for-linux-next-fixes (03a3780b0c82 drm/i915: Fix 
GMBUSFREQ o

[PATCH v2 2/2] arm: pm: add deep sleep support for LS1

[Chenhui Zhao]

LS1 supports deep sleep feature that can switch off most parts of
the SoC when it is in deep sleep state.

The DDR controller will also be powered off in deep sleep. Therefore,
copy the last stage code to enter deep sleep to SRAM and run it
with disabling MMU and caches.

Signed-off-by: Chenhui Zhao 
---
Changes for v2:
 * use identity mapping to smooth the process of disabling MMU
 * change the value of registers

 arch/arm/mach-imx/Kconfig |1 +
 arch/arm/mach-imx/Makefile|1 +
 arch/arm/mach-imx/pm-ls1.c|  341 +
 arch/arm/mach-imx/sleep-ls1.S |  132 
 4 files changed, 475 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-imx/pm-ls1.c
 create mode 100644 arch/arm/mach-imx/sleep-ls1.S

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index b85534c..716bb1b 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -866,6 +866,7 @@ config SOC_LS1021A
select HAVE_SMP
select ARCH_LAYERSCAPE
select ZONE_DMA if ARM_LPAE
+   select FSL_SLEEP_FSM if PM
 
help
  This enable support for Freescale Layerscape LS1021A  processor.
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 41b8044..9931528 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o mach-imx6sl.o
 
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
+obj-$(CONFIG_SOC_LS1021A) += pm-ls1.o sleep-ls1.o
 endif
 
 # i.MX5 based machines
diff --git a/arch/arm/mach-imx/pm-ls1.c b/arch/arm/mach-imx/pm-ls1.c
new file mode 100644
index 000..8fd7aee
--- /dev/null
+++ b/arch/arm/mach-imx/pm-ls1.c
@@ -0,0 +1,341 @@
+/*
+ * Support deep sleep feature for LS1
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * 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 "common.h"
+
+#define FSL_SLEEP  0x1
+#define FSL_DEEP_SLEEP 0x2
+
+#define DCSR_EPU_EPSMCR15  0x278
+#define DCSR_EPU_EPECR00x300
+#define DCSR_RCPM_CG1CR0   0x31c
+#define DCSR_RCPM_CSTTACR0 0xb00
+
+#define CCSR_SCFG_DPSLPCR  0
+#define CCSR_SCFG_DPSLPCR_VAL  0x1
+#define CCSR_SCFG_SPARECR2 0x504
+#define CCSR_SCFG_SPARECR3 0x508
+
+#define CCSR_DCFG_CRSTSR   0x400
+#define CCSR_DCFG_CRSTSR_VAL   0x0008
+
+#define CCSR_RCPM_POWMGTCSR0x130
+#define CCSR_RCPM_POWMGTCSR_LPM20_REQ  0x0010
+#define CCSR_RCPM_POWMGTCSR_LPM20_ST   0x0200
+#define CCSR_RCPM_POWMGTCSR_P_LPM20_ST 0x0100
+#define CCSR_RCPM_CLPCL10SETR  0x1c4
+#define CCSR_RCPM_CLPCL10SETR_C0   0x1
+
+#define OCRAM_BASE 0x1000
+#define OCRAM_SIZE 0x1 /* 64K */
+/* use the last page of SRAM */
+#define SRAM_CODE_BASE_PHY (OCRAM_BASE + OCRAM_SIZE - PAGE_SIZE)
+
+struct ls1_pm_baseaddr {
+   void __iomem *epu;
+   void __iomem *dcsr_rcpm1;
+   void __iomem *dcsr_rcpm2;
+   void __iomem *rcpm;
+   void __iomem *scfg;
+   void __iomem *dcfg;
+   void __iomem *fpga;
+   void __iomem *sram;
+};
+
+/* 128 bytes buffer for restoring data broke by DDR training initialization */
+#define DDR_BUF_SIZE   128
+static u8 ddr_buff[DDR_BUF_SIZE] __aligned(64);
+static struct ls1_pm_baseaddr ls1_pm_base;
+/* supported sleep modes by the present platform */
+static unsigned int sleep_modes;
+
+extern void ls1_do_deepsleep(unsigned long addr);
+extern void ls1_start_fsm(void);
+extern void ls1_deepsleep_resume(void);
+extern void ls1021a_set_secondary_entry(void);
+extern int ls1_sram_code_size;
+extern void fsl_epu_setup_default(void __iomem *epu_base);
+
+static void ls1_pm_iomap(void)
+{
+   struct device_node *np;
+   void *base;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcsr-epu");
+   base = of_iomap(np, 0);
+   BUG_ON(!base);
+   ls1_pm_base.epu = base;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcsr-rcpm");
+   base = of_iomap(np, 0);
+   BUG_ON(!base);
+   ls1_pm_base.dcsr_rcpm1 = base;
+   base = of_iomap(np, 1);
+   BUG_ON(!base);
+   ls1_pm_base.dcsr_rcpm2 = base;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-scfg");
+   base = of_iomap(np, 0);
+   BUG_ON(!base);
+   ls1_pm_base.scfg = base;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcfg");
+   base = of_iomap(np, 0);
+   BUG_ON(!base);
+   ls1_pm_base.dcfg = base;
+
+   np = of_find_compatible_node(NULL, NULL, "fsl,ls1021aqds-fpga");
+   base = of_iomap(np, 

[PATCH 06/14] net: dsa: Add support for hardware monitoring

[Guenter Roeck]

Some Marvell switches provide chip temperature data.
Add support for reporting it to the dsa infrastructure.

Signed-off-by: Guenter Roeck 
---
 include/net/dsa.h |   6 +++
 net/dsa/dsa.c | 111 ++
 2 files changed, 117 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index b765592..d8b3057 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -242,6 +242,12 @@ struct dsa_switch_driver {
   struct ethtool_eee *e);
int (*get_eee)(struct dsa_switch *ds, int port,
   struct ethtool_eee *e);
+
+   /* Hardware monitoring */
+   int (*get_temp)(struct dsa_switch *ds, int *temp);
+   int (*get_temp_limit)(struct dsa_switch *ds, int *temp);
+   int (*set_temp_limit)(struct dsa_switch *ds, int temp);
+   int (*get_temp_alarm)(struct dsa_switch *ds, bool *alarm);
 };
 
 void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 22f34cf..6567c8e 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -9,6 +9,8 @@
  * (at your option) any later version.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "dsa_priv.h"
 
 char dsa_driver_version[] = "0.1";
@@ -71,6 +74,104 @@ dsa_switch_probe(struct device *host_dev, int sw_addr, char 
**_name)
return ret;
 }
 
+/* hwmon support /
+
+#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
+
+static ssize_t temp1_input_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dsa_switch *ds = dev_get_drvdata(dev);
+   int temp, ret;
+
+   ret = ds->drv->get_temp(ds, );
+   if (ret < 0)
+   return ret;
+
+   return sprintf(buf, "%d\n", temp * 1000);
+}
+static DEVICE_ATTR_RO(temp1_input);
+
+static ssize_t temp1_max_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct dsa_switch *ds = dev_get_drvdata(dev);
+   int temp, ret;
+
+   ret = ds->drv->get_temp_limit(ds, );
+   if (ret < 0)
+   return ret;
+
+   return sprintf(buf, "%d\n", temp * 1000);
+}
+
+static ssize_t temp1_max_store(struct device *dev,
+  struct device_attribute *attr, const char *buf,
+  size_t count)
+{
+   struct dsa_switch *ds = dev_get_drvdata(dev);
+   int temp, ret;
+
+   ret = kstrtoint(buf, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = ds->drv->set_temp_limit(ds, DIV_ROUND_CLOSEST(temp, 1000));
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+static DEVICE_ATTR(temp1_max, S_IRUGO, temp1_max_show, temp1_max_store);
+
+static ssize_t temp1_max_alarm_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dsa_switch *ds = dev_get_drvdata(dev);
+   bool alarm;
+   int ret;
+
+   ret = ds->drv->get_temp_alarm(ds, );
+   if (ret < 0)
+   return ret;
+
+   return sprintf(buf, "%d\n", alarm);
+}
+static DEVICE_ATTR_RO(temp1_max_alarm);
+
+static struct attribute *dsa_hwmon_attrs[] = {
+   _attr_temp1_input.attr, /* 0 */
+   _attr_temp1_max.attr,   /* 1 */
+   _attr_temp1_max_alarm.attr, /* 2 */
+   NULL
+};
+
+static umode_t dsa_hwmon_attrs_visible(struct kobject *kobj,
+  struct attribute *attr, int index)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct dsa_switch *ds = dev_get_drvdata(dev);
+   struct dsa_switch_driver *drv = ds->drv;
+   umode_t mode = attr->mode;
+
+   if (index == 1) {
+   if (!drv->get_temp_limit)
+   mode = 0;
+   else if (drv->set_temp_limit)
+   mode |= S_IWUSR;
+   } else if (index == 2 && !drv->get_temp_alarm) {
+   mode = 0;
+   }
+   return mode;
+}
+
+static const struct attribute_group dsa_hwmon_group = {
+   .attrs = dsa_hwmon_attrs,
+   .is_visible = dsa_hwmon_attrs_visible,
+};
+__ATTRIBUTE_GROUPS(dsa_hwmon);
+
+#endif /* CONFIG_HWMON */
 
 /* basic switch operations **/
 static struct dsa_switch *
@@ -225,6 +326,16 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
ds->ports[i] = slave_dev;
}
 
+#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
+   /* If the switch provides a temperature sensor,
+* register with hardware monitoring subsystem.
+* Treat registration error as non-fatal and ignore it.
+*/
+   if (drv->get_temp)
+   

[PATCH 03/14] net: dsa: Report known silicon revisions for Marvell 88E6131

[Guenter Roeck]

Report known silicon revisions when probing Marvell 88E6131 switches.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6131.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index 244c735..1230f52 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -21,6 +21,7 @@
 #define ID_60850x04a0
 #define ID_60950x0950
 #define ID_61310x1060
+#define ID_6131_B2 0x1066
 
 static char *mv88e6131_probe(struct device *host_dev, int sw_addr)
 {
@@ -32,12 +33,15 @@ static char *mv88e6131_probe(struct device *host_dev, int 
sw_addr)
 
ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
if (ret >= 0) {
-   ret &= 0xfff0;
-   if (ret == ID_6085)
+   int ret_masked = ret & 0xfff0;
+
+   if (ret_masked == ID_6085)
return "Marvell 88E6085";
-   if (ret == ID_6095)
+   if (ret_masked == ID_6095)
return "Marvell 88E6095/88E6095F";
-   if (ret == ID_6131)
+   if (ret == ID_6131_B2)
+   return "Marvell 88E6131 (B2)";
+   if (ret_masked == ID_6131)
return "Marvell 88E6131";
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/14] net: dsa/mv88e6123_61_65: Report chip temperature

[Guenter Roeck]

MV88E6123 and compatible chips support reading the chip temperature
from PHY register 6:26.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6123_61_65.c | 63 +--
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123_61_65.c 
b/drivers/net/dsa/mv88e6123_61_65.c
index a332c53..17dc60e 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -291,6 +291,51 @@ static int mv88e6123_61_65_setup_port(struct dsa_switch 
*ds, int p)
return 0;
 }
 
+static int  mv88e6123_61_65_get_temp(struct dsa_switch *ds, int *temp)
+{
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+   int ret;
+   int val;
+
+   *temp = 0;
+
+   mutex_lock(>phy_mutex);
+
+   ret = mv88e6xxx_phy_write(ds, 0x0, 0x16, 0x6);
+   if (ret < 0)
+   goto error;
+
+   /* Enable temperature sensor */
+   ret = mv88e6xxx_phy_read(ds, 0x0, 0x1a);
+   if (ret < 0)
+   goto error;
+
+   ret = mv88e6xxx_phy_write(ds, 0x0, 0x1a, ret | (1 << 5));
+   if (ret < 0)
+   goto error;
+
+   /* Wait for temperature to stabilize */
+   usleep_range(1, 12000);
+
+   val = mv88e6xxx_phy_read(ds, 0x0, 0x1a);
+   if (val < 0) {
+   ret = val;
+   goto error;
+   }
+
+   /* Disable temperature sensor */
+   ret = mv88e6xxx_phy_write(ds, 0x0, 0x1a, ret & ~(1 << 5));
+   if (ret < 0)
+   goto error;
+
+   *temp = ((val & 0x1f) - 5) * 5;
+
+error:
+   mv88e6xxx_phy_write(ds, 0x0, 0x16, 0x0);
+   mutex_unlock(>phy_mutex);
+   return ret;
+}
+
 static int mv88e6123_61_65_setup(struct dsa_switch *ds)
 {
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -299,6 +344,7 @@ static int mv88e6123_61_65_setup(struct dsa_switch *ds)
 
mutex_init(>smi_mutex);
mutex_init(>stats_mutex);
+   mutex_init(>phy_mutex);
 
ret = mv88e6123_61_65_switch_reset(ds);
if (ret < 0)
@@ -329,16 +375,28 @@ static int mv88e6123_61_65_port_to_phy_addr(int port)
 static int
 mv88e6123_61_65_phy_read(struct dsa_switch *ds, int port, int regnum)
 {
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int addr = mv88e6123_61_65_port_to_phy_addr(port);
-   return mv88e6xxx_phy_read(ds, addr, regnum);
+   int ret;
+
+   mutex_lock(>phy_mutex);
+   ret = mv88e6xxx_phy_read(ds, addr, regnum);
+   mutex_unlock(>phy_mutex);
+   return ret;
 }
 
 static int
 mv88e6123_61_65_phy_write(struct dsa_switch *ds,
  int port, int regnum, u16 val)
 {
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int addr = mv88e6123_61_65_port_to_phy_addr(port);
-   return mv88e6xxx_phy_write(ds, addr, regnum, val);
+   int ret;
+
+   mutex_lock(>phy_mutex);
+   ret = mv88e6xxx_phy_write(ds, addr, regnum, val);
+   mutex_unlock(>phy_mutex);
+   return ret;
 }
 
 static struct mv88e6xxx_hw_stat mv88e6123_61_65_hw_stats[] = {
@@ -406,6 +464,7 @@ struct dsa_switch_driver mv88e6123_61_65_switch_driver = {
.get_strings= mv88e6123_61_65_get_strings,
.get_ethtool_stats  = mv88e6123_61_65_get_ethtool_stats,
.get_sset_count = mv88e6123_61_65_get_sset_count,
+   .get_temp   = mv88e6123_61_65_get_temp,
 };
 
 MODULE_ALIAS("platform:mv88e6123");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/cirrus: bind also to qemu-xen-traditional

[Dave Airlie]

No idea why I kept missing this, I've applied it to -fixes now.

Dave.

On 22 October 2014 18:14, Olaf Hering  wrote:
> Ping?
>
> On Tue, Aug 26, Olaf Hering wrote:
>
>> Ping?
>>
>> On Thu, Jun 12, Olaf Hering wrote:
>>
>> > Ping?
>> >
>> > On Fri, Apr 11, Olaf Hering wrote:
>> >
>> > > qemu as used by xend/xm toolstack uses a different subvendor id.
>> > > Bind the drm driver also to this emulated card.
>> > >
>> > > Signed-off-by: Olaf Hering 
>> > > ---
>> > >  drivers/gpu/drm/cirrus/cirrus_drv.c | 2 ++
>> > >  1 file changed, 2 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
>> > > b/drivers/gpu/drm/cirrus/cirrus_drv.c
>> > > index 953fc8a..848 100644
>> > > --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
>> > > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
>> > > @@ -31,6 +31,8 @@ static struct drm_driver driver;
>> > >  static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
>> > >   { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
>> > > 0, 0 },
>> > > + { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, PCI_VENDOR_ID_XEN,
>> > > +   0x0001, 0, 0, 0 },
>> > >   {0,}
>> > >  };
>> > >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/14] net: dsa: Report known silicon revisions for Marvell 88E6060

[Guenter Roeck]

Report known silicon revisions when probing Marvell 88E6060 switches.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6060.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index 05b0ca3..c29aebe 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -69,8 +69,11 @@ static char *mv88e6060_probe(struct device *host_dev, int 
sw_addr)
 
ret = mdiobus_read(bus, sw_addr + REG_PORT(0), 0x03);
if (ret >= 0) {
-   ret &= 0xfff0;
if (ret == 0x0600)
+   return "Marvell 88E6060 (A0)";
+   if (ret == 0x0601 || ret == 0x0602)
+   return "Marvell 88E6060 (B0)";
+   if ((ret & 0xfff0) == 0x0600)
return "Marvell 88E6060";
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/14] net: dsa/mv88e6352: Report chip temperature

[Guenter Roeck]

MV88E6352 supports reading the chip temperature from two PHY registers,
6:26 and 6:27. Report it using the more accurate register 6:27.
Also report temperature limit and alarm.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6352.c | 96 +
 1 file changed, 96 insertions(+)

diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index f17364f..aff6695 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -63,6 +63,41 @@ static int __mv88e6352_phy_write(struct dsa_switch *ds, int 
addr, int regnum,
return mv88e6352_phy_wait(ds);
 }
 
+static int mv88e6352_phy_page_read(struct dsa_switch *ds,
+  int port, int page, int reg)
+{
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+   int ret;
+
+   mutex_lock(>phy_mutex);
+   ret = __mv88e6352_phy_write(ds, port, 0x16, page);
+   if (ret < 0)
+   goto error;
+   ret = __mv88e6352_phy_read(ds, port, reg);
+error:
+   __mv88e6352_phy_write(ds, port, 0x16, 0x0);
+   mutex_unlock(>phy_mutex);
+   return ret;
+}
+
+static int mv88e6352_phy_page_write(struct dsa_switch *ds,
+   int port, int page, int reg, int val)
+{
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+   int ret;
+
+   mutex_lock(>phy_mutex);
+   ret = __mv88e6352_phy_write(ds, port, 0x16, page);
+   if (ret < 0)
+   goto error;
+
+   ret = __mv88e6352_phy_write(ds, port, reg, val);
+error:
+   __mv88e6352_phy_write(ds, port, 0x16, 0x0);
+   mutex_unlock(>phy_mutex);
+   return ret;
+}
+
 static char *mv88e6352_probe(struct device *host_dev, int sw_addr)
 {
struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
@@ -325,6 +360,63 @@ static int mv88e6352_setup_port(struct dsa_switch *ds, int 
p)
return 0;
 }
 
+static int mv88e6352_get_temp(struct dsa_switch *ds, int *temp)
+{
+   int ret;
+
+   *temp = 0;
+
+   ret = mv88e6352_phy_page_read(ds, 0, 6, 27);
+   if (ret < 0)
+   return ret;
+
+   *temp = (ret & 0xff) - 25;
+
+   return 0;
+}
+
+static int mv88e6352_get_temp_limit(struct dsa_switch *ds, int *temp)
+{
+   int ret;
+
+   *temp = 0;
+
+   ret = mv88e6352_phy_page_read(ds, 0, 6, 26);
+   if (ret < 0)
+   return ret;
+
+   *temp = (((ret >> 8) & 0x1f) * 5) - 25;
+
+   return 0;
+}
+
+static int mv88e6352_set_temp_limit(struct dsa_switch *ds, int temp)
+{
+   int ret;
+
+   ret = mv88e6352_phy_page_read(ds, 0, 6, 26);
+   if (ret < 0)
+   return ret;
+   temp = clamp_val(DIV_ROUND_CLOSEST(temp, 5) + 5, 0, 0x1f);
+   return mv88e6352_phy_page_write(ds, 0, 6, 26,
+   (ret & 0xe0ff) | (temp << 8));
+}
+
+static int mv88e6352_get_temp_alarm(struct dsa_switch *ds, bool *alarm)
+{
+   int ret;
+
+   *alarm = false;
+
+   ret = mv88e6352_phy_page_read(ds, 0, 6, 26);
+   if (ret < 0)
+   return ret;
+
+   *alarm = !!(ret & 0x40);
+
+   return 0;
+}
+
 static int mv88e6352_setup(struct dsa_switch *ds)
 {
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -461,6 +553,10 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.get_strings= mv88e6352_get_strings,
.get_ethtool_stats  = mv88e6352_get_ethtool_stats,
.get_sset_count = mv88e6352_get_sset_count,
+   .get_temp   = mv88e6352_get_temp,
+   .get_temp_limit = mv88e6352_get_temp_limit,
+   .set_temp_limit = mv88e6352_set_temp_limit,
+   .get_temp_alarm = mv88e6352_get_temp_alarm,
 };
 
 MODULE_ALIAS("platform:mv88e6352");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/14] net: dsa: Add support for switch EEPROM access

[Guenter Roeck]

On some chips it is possible to access the switch eeprom.
Add infrastructure support for it.

Signed-off-by: Guenter Roeck 
---
 include/net/dsa.h |  7 +++
 net/dsa/slave.c   | 38 ++
 2 files changed, 45 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index d8b3057..73146b7 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -248,6 +248,13 @@ struct dsa_switch_driver {
int (*get_temp_limit)(struct dsa_switch *ds, int *temp);
int (*set_temp_limit)(struct dsa_switch *ds, int temp);
int (*get_temp_alarm)(struct dsa_switch *ds, bool *alarm);
+
+   /* EEPROM access */
+   int (*get_eeprom_len)(struct dsa_switch *ds);
+   int (*get_eeprom)(struct dsa_switch *ds,
+ struct ethtool_eeprom *eeprom, u8 *data);
+   int (*set_eeprom)(struct dsa_switch *ds,
+ struct ethtool_eeprom *eeprom, u8 *data);
 };
 
 void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 6d18174..a54ee43 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -271,6 +271,41 @@ static u32 dsa_slave_get_link(struct net_device *dev)
return -EOPNOTSUPP;
 }
 
+static int dsa_slave_get_eeprom_len(struct net_device *dev)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   if (ds->drv->get_eeprom_len != NULL)
+   return ds->drv->get_eeprom_len(ds);
+
+   return 0;
+}
+
+static int dsa_slave_get_eeprom(struct net_device *dev,
+   struct ethtool_eeprom *eeprom, u8 *data)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   if (ds->drv->get_eeprom != NULL)
+   return ds->drv->get_eeprom(ds, eeprom, data);
+
+   return -EOPNOTSUPP;
+}
+
+static int dsa_slave_set_eeprom(struct net_device *dev,
+   struct ethtool_eeprom *eeprom, u8 *data)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   if (ds->drv->set_eeprom != NULL)
+   return ds->drv->set_eeprom(ds, eeprom, data);
+
+   return -EOPNOTSUPP;
+}
+
 static void dsa_slave_get_strings(struct net_device *dev,
  uint32_t stringset, uint8_t *data)
 {
@@ -387,6 +422,9 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
.get_drvinfo= dsa_slave_get_drvinfo,
.nway_reset = dsa_slave_nway_reset,
.get_link   = dsa_slave_get_link,
+   .get_eeprom_len = dsa_slave_get_eeprom_len,
+   .get_eeprom = dsa_slave_get_eeprom,
+   .set_eeprom = dsa_slave_set_eeprom,
.get_strings= dsa_slave_get_strings,
.get_ethtool_stats  = dsa_slave_get_ethtool_stats,
.get_sset_count = dsa_slave_get_sset_count,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/14] net: dsa: Fixes and enhancements

[Guenter Roeck]

Patch 01/14 addresses an annoying and unhelpful log message.

Patches 02/14 and 03/14 are minor enhancements, adding support for
known switch revisions.

Patches 04/14 and 05/14 add support for MV88E6352 and MV88E6176.

Patch 06/14 adds support for hardware monitoring, specifically for
reporting the chip temperature, to the dsa subsystem.

Patches 07/14 and 08/14 implement hardware monitoring for MV88E6352,
MV88E6176, MV88E6123, MV88E6161, and MV88E6165.

Patch 09/14 adds support for EEPROM access to the DSA subsystem.

Patch 10/14 implements EEPROM access for MV88E6352 and MV88E6176.

Patch 11/14 adds support for reading switch registers to the DSA
subsystem.

Patches 12/14 amd 13/14 implement support for reading switch registers
to the drivers for MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.

Patch 14/14 adds support for reading additional RMON registers to the drivers
for  MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.

The series resides and was tested on top of v3.18-rc1 in a system
with MV88E6352. Testing in systems with 88E6131, 88E6060 and MV88E6165
was done earlier (I don't have access to those systems right now).
The series applies cleanly to net-next as of today (10/22).


Guenter Roeck (14):
  net: dsa: Don't set skb->protocol on outgoing tagged packets
  net: dsa: Report known silicon revisions for Marvell 88E6060
  net: dsa: Report known silicon revisions for Marvell 88E6131
  net: dsa: Add support for Marvell 88E6352
  net: dsa/mv88e6352: Add support for MV88E6176
  net: dsa: Add support for hardware monitoring
  net: dsa/mv88e6352: Report chip temperature
  net: dsa/mv88e6123_61_65: Report chip temperature
  net: dsa: Add support for switch EEPROM access
  net: dsa/mv88e6352: Implement EEPROM access functions
  net: dsa: Add support for reading switch registers with ethtool
  net: dsa/mv88e6123_61_65: Add support for reading switch registers
  net: dsa/mv88e6352: Add support for reading switch registers
  net: dsa: Provide additional RMON statistics

 MAINTAINERS   |   5 +
 drivers/net/dsa/Kconfig   |   9 +
 drivers/net/dsa/Makefile  |   3 +
 drivers/net/dsa/mv88e6060.c   |   5 +-
 drivers/net/dsa/mv88e6123_61_65.c |  68 +++-
 drivers/net/dsa/mv88e6131.c   |  12 +-
 drivers/net/dsa/mv88e6352.c   | 789 ++
 drivers/net/dsa/mv88e6xxx.c   |  53 ++-
 drivers/net/dsa/mv88e6xxx.h   |  15 +
 include/net/dsa.h |  20 +
 net/dsa/dsa.c | 111 ++
 net/dsa/slave.c   |  60 +++
 net/dsa/tag_dsa.c |   2 -
 net/dsa/tag_edsa.c|   2 -
 net/dsa/tag_trailer.c |   2 -
 15 files changed, 1138 insertions(+), 18 deletions(-)
 create mode 100644 drivers/net/dsa/mv88e6352.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/14] net: dsa: Don't set skb->protocol on outgoing tagged packets

[Guenter Roeck]

Setting skb->protocol to a private protocol type may result in warning
messages such as
e1000e :00:19.0 em1: checksum_partial proto=dada!

This happens if the L3 protocol is IP or IPv6 and skb->ip_summed is set
to CHECKSUM_PARTIAL. Looking through the code, it appears that changing
skb->protocol for transmitted packets is not necessary and may actually
be harmful. Drop it.

Signed-off-by: Guenter Roeck 
---
 net/dsa/tag_dsa.c | 2 --
 net/dsa/tag_edsa.c| 2 --
 net/dsa/tag_trailer.c | 2 --
 3 files changed, 6 deletions(-)

diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
index ce90c8b..2dab270 100644
--- a/net/dsa/tag_dsa.c
+++ b/net/dsa/tag_dsa.c
@@ -63,8 +63,6 @@ static netdev_tx_t dsa_xmit(struct sk_buff *skb, struct 
net_device *dev)
dsa_header[3] = 0x00;
}
 
-   skb->protocol = htons(ETH_P_DSA);
-
skb->dev = p->parent->dst->master_netdev;
dev_queue_xmit(skb);
 
diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
index 94fcce7..9aeda59 100644
--- a/net/dsa/tag_edsa.c
+++ b/net/dsa/tag_edsa.c
@@ -76,8 +76,6 @@ static netdev_tx_t edsa_xmit(struct sk_buff *skb, struct 
net_device *dev)
edsa_header[7] = 0x00;
}
 
-   skb->protocol = htons(ETH_P_EDSA);
-
skb->dev = p->parent->dst->master_netdev;
dev_queue_xmit(skb);
 
diff --git a/net/dsa/tag_trailer.c b/net/dsa/tag_trailer.c
index 115fdca..e268f9d 100644
--- a/net/dsa/tag_trailer.c
+++ b/net/dsa/tag_trailer.c
@@ -57,8 +57,6 @@ static netdev_tx_t trailer_xmit(struct sk_buff *skb, struct 
net_device *dev)
trailer[2] = 0x10;
trailer[3] = 0x00;
 
-   nskb->protocol = htons(ETH_P_TRAILER);
-
nskb->dev = p->parent->dst->master_netdev;
dev_queue_xmit(nskb);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 11/14] net: dsa: Add support for reading switch registers with ethtool

[Guenter Roeck]

Add support for reading switch registers with 'ethtool -d'.

Signed-off-by: Guenter Roeck 
---
 include/net/dsa.h |  7 +++
 net/dsa/slave.c   | 22 ++
 2 files changed, 29 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 73146b7..edc5e71 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -255,6 +255,13 @@ struct dsa_switch_driver {
  struct ethtool_eeprom *eeprom, u8 *data);
int (*set_eeprom)(struct dsa_switch *ds,
  struct ethtool_eeprom *eeprom, u8 *data);
+
+   /*
+* Register access.
+*/
+   int (*get_regs_len)(struct dsa_switch *ds, int port);
+   void(*get_regs)(struct dsa_switch *ds, int port,
+   struct ethtool_regs *regs, void *p);
 };
 
 void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index a54ee43..e988d07 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -249,6 +249,26 @@ static void dsa_slave_get_drvinfo(struct net_device *dev,
strlcpy(drvinfo->bus_info, "platform", sizeof(drvinfo->bus_info));
 }
 
+static int dsa_slave_get_regs_len(struct net_device *dev)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   if (ds->drv->get_regs_len != NULL)
+   return ds->drv->get_regs_len(ds, p->port);
+
+   return -EOPNOTSUPP;
+}
+
+static void
+dsa_slave_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *_p)
+{
+   struct dsa_slave_priv *p = netdev_priv(dev);
+   struct dsa_switch *ds = p->parent;
+
+   ds->drv->get_regs(ds, p->port, regs, _p);
+}
+
 static int dsa_slave_nway_reset(struct net_device *dev)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
@@ -420,6 +440,8 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
.get_settings   = dsa_slave_get_settings,
.set_settings   = dsa_slave_set_settings,
.get_drvinfo= dsa_slave_get_drvinfo,
+   .get_regs_len   = dsa_slave_get_regs_len,
+   .get_regs   = dsa_slave_get_regs,
.nway_reset = dsa_slave_nway_reset,
.get_link   = dsa_slave_get_link,
.get_eeprom_len = dsa_slave_get_eeprom_len,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lib: show_mem: This patch adds cma reserved infromation

[Vishnu Pratap Singh]

This patch adds cma reserved information which is currently
shown as a part of total reserved only. This patch is
continuation of our previos cma patches related to this.
https://lkml.org/lkml/2014/10/20/64
https://lkml.org/lkml/2014/10/22/383

Signed-off-by: Vishnu Pratap Singh 
---
 lib/show_mem.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/show_mem.c b/lib/show_mem.c
index 0922579..a0e50d7 100644
--- a/lib/show_mem.c
+++ b/lib/show_mem.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_CMA
+#include 
+#endif
 
 void show_mem(unsigned int filter)
 {
@@ -38,7 +41,12 @@ void show_mem(unsigned int filter)
 
printk("%lu pages RAM\n", total);
printk("%lu pages HighMem/MovableOnly\n", highmem);
+#ifdef CONFIG_CMA
+   printk("%lu pages reserved\n", (reserved - totalcma_pages));
+   printk("%lu pages cma reserved\n", totalcma_pages);
+#else
printk("%lu pages reserved\n", reserved);
+#endif
 #ifdef CONFIG_QUICKLIST
printk("%lu pages in pagetable cache\n",
quicklist_total_size());
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/14] net: dsa: Add support for Marvell 88E6352

[Guenter Roeck]

Marvell 88E6352 is mostly compatible to MV88E6123/61/65,
but requires indirect phy access. Also, its configuration
registers are a bit different.

Signed-off-by: Guenter Roeck 
---
 MAINTAINERS |   5 +
 drivers/net/dsa/Kconfig |   8 +
 drivers/net/dsa/Makefile|   3 +
 drivers/net/dsa/mv88e6352.c | 464 
 drivers/net/dsa/mv88e6xxx.c |   3 +
 drivers/net/dsa/mv88e6xxx.h |   7 +
 6 files changed, 490 insertions(+)
 create mode 100644 drivers/net/dsa/mv88e6352.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a20df9b..e48a05b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5845,6 +5845,11 @@ M:   Russell King 
 S: Maintained
 F: drivers/gpu/drm/armada/
 
+MARVELL 88E6352 DSA support
+M: Guenter Roeck 
+S: Maintained
+F: drivers/net/dsa/mv88e6352.c
+
 MARVELL GIGABIT ETHERNET DRIVERS (skge/sky2)
 M: Mirko Lindner 
 M: Stephen Hemminger 
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 9234d80..0987c33 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -45,6 +45,14 @@ config NET_DSA_MV88E6171
  This enables support for the Marvell 88E6171 ethernet switch
  chip.
 
+config NET_DSA_MV88E6352
+   tristate "Marvell 88E6352 ethernet switch chip support"
+   select NET_DSA
+   select NET_DSA_MV88E6XXX
+   select NET_DSA_TAG_EDSA
+   ---help---
+ This enables support for the Marvell 88E6352 ethernet switch chip.
+
 config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
depends on HAS_IOMEM
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 23a90de..e2d51c4 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -7,6 +7,9 @@ endif
 ifdef CONFIG_NET_DSA_MV88E6131
 mv88e6xxx_drv-y += mv88e6131.o
 endif
+ifdef CONFIG_NET_DSA_MV88E6352
+mv88e6xxx_drv-y += mv88e6352.o
+endif
 ifdef CONFIG_NET_DSA_MV88E6171
 mv88e6xxx_drv-y += mv88e6171.o
 endif
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
new file mode 100644
index 000..43a5826
--- /dev/null
+++ b/drivers/net/dsa/mv88e6352.c
@@ -0,0 +1,464 @@
+/*
+ * net/dsa/mv88e6352.c - Marvell 88e6352 switch chip support
+ *
+ * Copyright (c) 2014 Guenter Roeck
+ *
+ * Derived from mv88e6123_61_65.c
+ * Copyright (c) 2008-2009 Marvell Semiconductor
+ *
+ * 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 "mv88e6xxx.h"
+
+static int mv88e6352_phy_wait(struct dsa_switch *ds)
+{
+   unsigned long timeout = jiffies + HZ / 10;
+
+   while (time_before(jiffies, timeout)) {
+   int ret;
+
+   ret = REG_READ(REG_GLOBAL2, 0x18);
+   if (ret < 0)
+   return ret;
+
+   if (!(ret & 0x8000))
+   return 0;
+
+   usleep_range(1000, 2000);
+   }
+   return -ETIMEDOUT;
+}
+
+static int __mv88e6352_phy_read(struct dsa_switch *ds, int addr, int regnum)
+{
+   int ret;
+
+   REG_WRITE(REG_GLOBAL2, 0x18, 0x9800 | (addr << 5) | regnum);
+
+   ret = mv88e6352_phy_wait(ds);
+   if (ret < 0)
+   return ret;
+
+   return REG_READ(REG_GLOBAL2, 0x19);
+}
+
+static int __mv88e6352_phy_write(struct dsa_switch *ds, int addr, int regnum,
+u16 val)
+{
+   REG_WRITE(REG_GLOBAL2, 0x19, val);
+   REG_WRITE(REG_GLOBAL2, 0x18, 0x9400 | (addr << 5) | regnum);
+
+   return mv88e6352_phy_wait(ds);
+}
+
+static char *mv88e6352_probe(struct device *host_dev, int sw_addr)
+{
+   struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
+   int ret;
+
+   if (bus == NULL)
+   return NULL;
+
+   ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
+   if (ret >= 0) {
+   if (ret == 0x3521)
+   return "Marvell 88E6352 (A0)";
+   if (ret == 0x3522)
+   return "Marvell 88E6352 (A1)";
+   if ((ret & 0xfff0) == 0x3520)
+   return "Marvell 88E6352";
+   }
+
+   return NULL;
+}
+
+static int mv88e6352_switch_reset(struct dsa_switch *ds)
+{
+   unsigned long timeout;
+   int ret;
+   int i;
+
+   /* Set all ports to the disabled state. */
+   for (i = 0; i < 7; i++) {
+   ret = REG_READ(REG_PORT(i), 0x04);
+   REG_WRITE(REG_PORT(i), 0x04, ret & 0xfffc);
+   }
+
+   /* Wait for transmit queues to drain. */
+   usleep_range(2000, 4000);
+
+   /* Reset the switch. Keep PPU active (bit 14, undocumented).
+* The PPU needs to be active to support indirect phy register

[PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM access functions

[Guenter Roeck]

MV88E6352 supports read and write access to its configuration eeprom.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6352.c | 228 +++-
 drivers/net/dsa/mv88e6xxx.h |   5 +
 2 files changed, 230 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index aff6695..9dddcba 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -22,18 +22,18 @@
 #include 
 #include "mv88e6xxx.h"
 
-static int mv88e6352_phy_wait(struct dsa_switch *ds)
+static int mv88e6352_wait(struct dsa_switch *ds, int reg, u16 mask)
 {
unsigned long timeout = jiffies + HZ / 10;
 
while (time_before(jiffies, timeout)) {
int ret;
 
-   ret = REG_READ(REG_GLOBAL2, 0x18);
+   ret = REG_READ(REG_GLOBAL2, reg);
if (ret < 0)
return ret;
 
-   if (!(ret & 0x8000))
+   if (!(ret & mask))
return 0;
 
usleep_range(1000, 2000);
@@ -41,6 +41,21 @@ static int mv88e6352_phy_wait(struct dsa_switch *ds)
return -ETIMEDOUT;
 }
 
+static inline int mv88e6352_phy_wait(struct dsa_switch *ds)
+{
+   return mv88e6352_wait(ds, 0x18, 0x8000);
+}
+
+static inline int mv88e6352_eeprom_load_wait(struct dsa_switch *ds)
+{
+   return mv88e6352_wait(ds, 0x14, 0x0800);
+}
+
+static inline int mv88e6352_eeprom_busy_wait(struct dsa_switch *ds)
+{
+   return mv88e6352_wait(ds, 0x14, 0x8000);
+}
+
 static int __mv88e6352_phy_read(struct dsa_switch *ds, int addr, int regnum)
 {
int ret;
@@ -426,6 +441,7 @@ static int mv88e6352_setup(struct dsa_switch *ds)
mutex_init(>smi_mutex);
mutex_init(>stats_mutex);
mutex_init(>phy_mutex);
+   mutex_init(>eeprom_mutex);
 
ps->id = REG_READ(REG_PORT(0), 0x03) & 0xfff0;
 
@@ -522,6 +538,209 @@ static struct mv88e6xxx_hw_stat mv88e6352_hw_stats[] = {
{ "hist_1024_max_bytes", 4, 0x0d, },
 };
 
+static int mv88e6352_get_eeprom_len(struct dsa_switch *ds)
+{
+   return 0x200;
+}
+
+static int mv88e6352_read_eeprom_word(struct dsa_switch *ds, int addr)
+{
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+   int ret;
+
+   mutex_lock(>eeprom_mutex);
+
+   ret = mv88e6xxx_reg_write(ds, REG_GLOBAL2, 0x14,
+ 0xc000 | (addr & 0xff));
+   if (ret < 0)
+   goto error;
+
+   ret = mv88e6352_eeprom_busy_wait(ds);
+   if (ret < 0)
+   goto error;
+
+   ret = mv88e6xxx_reg_read(ds, REG_GLOBAL2, 0x15);
+error:
+   mutex_unlock(>eeprom_mutex);
+   return ret;
+}
+
+static int mv88e6352_get_eeprom(struct dsa_switch *ds,
+   struct ethtool_eeprom *eeprom, u8 *data)
+{
+   int offset;
+   int len;
+   int ret;
+
+   offset = eeprom->offset;
+   len = eeprom->len;
+   eeprom->len = 0;
+
+   eeprom->magic = 0xc3ec4951;
+
+   ret = mv88e6352_eeprom_load_wait(ds);
+   if (ret < 0)
+   return ret;
+
+   if (offset & 1) {
+   int word;
+
+   word = mv88e6352_read_eeprom_word(ds, offset >> 1);
+   if (word < 0)
+   return word;
+
+   *data++ = (word >> 8) & 0xff;
+
+   offset++;
+   len--;
+   eeprom->len++;
+   }
+
+   while (len >= 2) {
+   int word;
+
+   word = mv88e6352_read_eeprom_word(ds, offset >> 1);
+   if (word < 0)
+   return word;
+
+   *data++ = word & 0xff;
+   *data++ = (word >> 8) & 0xff;
+
+   offset += 2;
+   len -= 2;
+   eeprom->len += 2;
+   }
+
+   if (len) {
+   int word;
+
+   word = mv88e6352_read_eeprom_word(ds, offset >> 1);
+   if (word < 0)
+   return word;
+
+   *data++ = word & 0xff;
+
+   offset++;
+   len--;
+   eeprom->len++;
+   }
+
+   return 0;
+}
+
+static int mv88e6352_eeprom_is_readonly(struct dsa_switch *ds)
+{
+   int ret;
+
+   ret = mv88e6xxx_reg_read(ds, REG_GLOBAL2, 0x14);
+   if (ret < 0)
+   return ret;
+
+   if (!(ret & 0x0400))
+   return -EROFS;
+
+   return 0;
+}
+
+static int mv88e6352_write_eeprom_word(struct dsa_switch *ds, int addr,
+  u16 data)
+{
+   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+   int ret;
+
+   mutex_lock(>eeprom_mutex);
+
+   ret = mv88e6xxx_reg_write(ds, REG_GLOBAL2, 0x15, data);
+   if (ret < 0)
+   goto error;
+
+   ret = mv88e6xxx_reg_write(ds, REG_GLOBAL2, 0x14,
+ 0xb000 | (addr & 0xff));
+   if (ret < 0)
+   goto error;
+
+   ret = 

[PATCH 05/14] net: dsa/mv88e6352: Add support for MV88E6176

[Guenter Roeck]

MV88E6176 is mostly compatible to MV88E6352 and is documented
in the same functional specification. Add support for it.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/Kconfig | 5 +++--
 drivers/net/dsa/mv88e6352.c | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 0987c33..2d1a55e 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -46,12 +46,13 @@ config NET_DSA_MV88E6171
  chip.
 
 config NET_DSA_MV88E6352
-   tristate "Marvell 88E6352 ethernet switch chip support"
+   tristate "Marvell 88E6176/88E6352 ethernet switch chip support"
select NET_DSA
select NET_DSA_MV88E6XXX
select NET_DSA_TAG_EDSA
---help---
- This enables support for the Marvell 88E6352 ethernet switch chip.
+ This enables support for the Marvell 88E6176 and 88E6352 ethernet
+ switch chips.
 
 config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 43a5826..f17364f 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -73,6 +73,8 @@ static char *mv88e6352_probe(struct device *host_dev, int 
sw_addr)
 
ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
if (ret >= 0) {
+   if ((ret & 0xfff0) == 0x1760)
+   return "Marvell 88E6176";
if (ret == 0x3521)
return "Marvell 88E6352 (A0)";
if (ret == 0x3522)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 6/7] sched: cfs: cpu frequency scaling based on task placement

[Preeti U Murthy]

Hi Mike,

On 10/22/2014 11:37 AM, Mike Turquette wrote:
> {en,de}queue_task_fair are updated to track which cpus will have changed
> utilization values as function of task queueing. The affected cpus are
> passed on to arch_eval_cpu_freq for further machine-specific processing
> based on a selectable policy.
> 
> arch_scale_cpu_freq is called from run_rebalance_domains as a way to
> kick off the scaling process (via wake_up_process), so as to prevent
> re-entering the {en,de}queue code.
> 
> All of the call sites in this patch are up for discussion. Does it make
> sense to track which cpus have updated statistics in enqueue_fair_task?
> I chose this because I wanted to gather statistics for all cpus affected
> in the event CONFIG_FAIR_GROUP_SCHED is enabled. As agreed at LPC14 the

Can you explain how pstate selection can get affected by the presence of
task groups? We are after all concerned with the cpu load. So when we
enqueue/dequeue a task, we update the cpu load and pass it on for cpu
pstate scaling. How does this change if we have task groups?
I know that this issue was brought up during LPC, but I have yet not
managed to gain clarity here.

> next version of this patch will focus on the simpler case of not using
> scheduler cgroups, which should remove a good chunk of this code,
> including the cpumask stuff.
> 
> Also discussed at LPC14 is that fact that load_balance is a very
> interesting place to do this as frequency can be considered in concert
> with task placement. Please put forth any ideas on a sensible way to do
> this.
> 
> Is run_rebalance_domains a logical place to change cpu frequency? What
> other call sites make sense?
> 
> Even for platforms that can target a cpu frequency without sleeping
> (x86, some ARM platforms with PM microcontrollers) it is currently
> necessary to always kick the frequency target work out into a kthread.
> This is because of the rw_sem usage in the cpufreq core which might
> sleep. Replacing that lock type is probably a good idea.
> 
> Not-signed-off-by: Mike Turquette 
> ---
>  kernel/sched/fair.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 1af6f6d..3619f63 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3999,6 +3999,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
> int flags)
>  {
>   struct cfs_rq *cfs_rq;
>   struct sched_entity *se = >se;
> + struct cpumask update_cpus;
> +
> + cpumask_clear(_cpus);
> 
>   for_each_sched_entity(se) {
>   if (se->on_rq)
> @@ -4028,12 +4031,27 @@ enqueue_task_fair(struct rq *rq, struct task_struct 
> *p, int flags)
> 
>   update_cfs_shares(cfs_rq);
>   update_entity_load_avg(se, 1);
> + /* track cpus that need to be re-evaluated */
> + cpumask_set_cpu(cpu_of(rq_of(cfs_rq)), _cpus);

All the cfs_rqs that you iterate through here will belong to the same
rq/cpu right?

Regards
Preeti U Murthy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 12/14] net: dsa/mv88e6123_61_65: Add support for reading switch registers

[Guenter Roeck]

The infrastructure can now report switch registers to ethtool.
Add support for it to the mv88e6123_61_65 driver.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6123_61_65.c |  2 ++
 drivers/net/dsa/mv88e6xxx.c   | 24 
 drivers/net/dsa/mv88e6xxx.h   |  3 +++
 3 files changed, 29 insertions(+)

diff --git a/drivers/net/dsa/mv88e6123_61_65.c 
b/drivers/net/dsa/mv88e6123_61_65.c
index 17dc60e..a3aeba4 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -465,6 +465,8 @@ struct dsa_switch_driver mv88e6123_61_65_switch_driver = {
.get_ethtool_stats  = mv88e6123_61_65_get_ethtool_stats,
.get_sset_count = mv88e6123_61_65_get_sset_count,
.get_temp   = mv88e6123_61_65_get_temp,
+   .get_regs_len   = mv88e6xxx_get_regs_len,
+   .get_regs   = mv88e6xxx_get_regs,
 };
 
 MODULE_ALIAS("platform:mv88e6123");
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 8e1090b..c071fde 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -499,6 +499,30 @@ void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds,
mutex_unlock(>stats_mutex);
 }
 
+int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port)
+{
+   return 32 * sizeof(u16);
+}
+
+void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
+   struct ethtool_regs *regs, void *_p)
+{
+   u16 *p = _p;
+   int i;
+
+   regs->version = 0;
+
+   memset(p, 0xff, 32 * sizeof(u16));
+
+   for (i = 0; i < 32; i++) {
+   int ret;
+
+   ret = mv88e6xxx_reg_read(ds, REG_PORT(port), i);
+   if (ret >= 0)
+   p[i] = ret;
+   }
+}
+
 static int __init mv88e6xxx_init(void)
 {
 #if IS_ENABLED(CONFIG_NET_DSA_MV88E6131)
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index d4d53ae..8c75702 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -78,6 +78,9 @@ void mv88e6xxx_get_strings(struct dsa_switch *ds,
 void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds,
 int nr_stats, struct mv88e6xxx_hw_stat *stats,
 int port, uint64_t *data);
+int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port);
+void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
+   struct ethtool_regs *regs, void *_p);
 
 extern struct dsa_switch_driver mv88e6131_switch_driver;
 extern struct dsa_switch_driver mv88e6123_61_65_switch_driver;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 14/14] net: dsa: Provide additional RMON statistics

[Guenter Roeck]

Display sw_in_discards, sw_in_filtered, and sw_out_filtered for chips
supported by mv88e6123_61_65 and mv88e6352 drivers.

The variables are provided in port registers, not the normal status registers.
Mark by adding 0x100 to the register offset and add special handling code
to mv88e6xxx_get_ethtool_stats.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6123_61_65.c |  3 +++
 drivers/net/dsa/mv88e6352.c   |  3 +++
 drivers/net/dsa/mv88e6xxx.c   | 26 +-
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123_61_65.c 
b/drivers/net/dsa/mv88e6123_61_65.c
index a3aeba4..18c026f 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -430,6 +430,9 @@ static struct mv88e6xxx_hw_stat mv88e6123_61_65_hw_stats[] 
= {
{ "hist_256_511bytes", 4, 0x0b, },
{ "hist_512_1023bytes", 4, 0x0c, },
{ "hist_1024_max_bytes", 4, 0x0d, },
+   { "sw_in_discards", 4, 0x110, },
+   { "sw_in_filtered", 2, 0x112, },
+   { "sw_out_filtered", 2, 0x113, },
 };
 
 static void
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 2f31e28..85dabd9 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -536,6 +536,9 @@ static struct mv88e6xxx_hw_stat mv88e6352_hw_stats[] = {
{ "hist_256_511bytes", 4, 0x0b, },
{ "hist_512_1023bytes", 4, 0x0c, },
{ "hist_1024_max_bytes", 4, 0x0d, },
+   { "sw_in_discards", 4, 0x110, },
+   { "sw_in_filtered", 2, 0x112, },
+   { "sw_out_filtered", 2, 0x113, },
 };
 
 static int mv88e6352_get_eeprom_len(struct dsa_switch *ds)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index c071fde..da558d8 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -485,17 +485,33 @@ void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds,
for (i = 0; i < nr_stats; i++) {
struct mv88e6xxx_hw_stat *s = stats + i;
u32 low;
-   u32 high;
-
+   u32 high = 0;
+
+   if (s->reg >= 0x100) {
+   int ret;
+
+   ret = mv88e6xxx_reg_read(ds, REG_PORT(port),
+s->reg - 0x100);
+   if (ret < 0)
+   goto error;
+   low = ret;
+   if (s->sizeof_stat == 4) {
+   ret = mv88e6xxx_reg_read(ds, REG_PORT(port),
+s->reg - 0x100 + 1);
+   if (ret < 0)
+   goto error;
+   high = ret;
+   }
+   data[i] = (((u64)high) << 16) | low;
+   continue;
+   }
mv88e6xxx_stats_read(ds, s->reg, );
if (s->sizeof_stat == 8)
mv88e6xxx_stats_read(ds, s->reg + 1, );
-   else
-   high = 0;
 
data[i] = (((u64)high) << 32) | low;
}
-
+error:
mutex_unlock(>stats_mutex);
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 13/14] net: dsa/mv88e6352: Add support for reading switch registers

[Guenter Roeck]

Report switch register values to ethtool.

Signed-off-by: Guenter Roeck 
---
 drivers/net/dsa/mv88e6352.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 9dddcba..2f31e28 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -779,6 +779,8 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.get_eeprom_len = mv88e6352_get_eeprom_len,
.get_eeprom = mv88e6352_get_eeprom,
.set_eeprom = mv88e6352_set_eeprom,
+   .get_regs_len   = mv88e6xxx_get_regs_len,
+   .get_regs   = mv88e6xxx_get_regs,
 };
 
 MODULE_ALIAS("platform:mv88e6352");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i386/audit: stop scribbling on the stack frame

[Eric Paris]

git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
It was writing over %esp/pt_regs semi-randomly on i686  with the expected
"system can't boot" results.  As noted in:

https://bugs.freedesktop.org/show_bug.cgi?id=85277

This patch stops fscking with pt_regs.  Instead it sets up the registers
for the call to __audit_syscall_entry in the most obvious conceivable
way.  It then does just a tiny tiny touch of magic.  We need to get what
started in PT_EDX into 0(%esp) and PT_ESI into 4(%esp).  This is as easy
as a pair of pushes.

After the call to __audit_syscall_entry all we need to do is get that
now useless junk off the stack (pair of pops) and reload %eax with the
original syscall so other stuff can keep going about it's business.

Signed-off-by: Eric Paris 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-au...@redhat.com
---
 arch/x86/kernel/entry_32.S | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index f9e3fab..fb01d22 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -447,15 +447,14 @@ sysenter_exit:
 sysenter_audit:
testl $(_TIF_WORK_SYSCALL_ENTRY & ~_TIF_SYSCALL_AUDIT),TI_flags(%ebp)
jnz syscall_trace_entry
-   addl $4,%esp
-   CFI_ADJUST_CFA_OFFSET -4
-   movl %esi,4(%esp)   /* 5th arg: 4th syscall arg */
-   movl %edx,(%esp)/* 4th arg: 3rd syscall arg */
-   /* %ecx already in %ecx3rd arg: 2nd syscall arg */
-   movl %ebx,%edx  /* 2nd arg: 1st syscall arg */
-   /* %eax already in %eax1st arg: syscall number */
+   /* movl PT_EAX(%esp), %eax  already set, syscall number: 1st arg to 
audit */
+   movl PT_EBX(%esp), %edx /* ebx/a0: 2nd arg to audit */
+   /* movl PT_ECX(%esp), %ecx  already set, a1: 3nd arg to audit */
+   pushl_cfi PT_ESI(%esp)  /* a3: 5th arg */
+   pushl_cfi PT_EDX+4(%esp)/* a2: 4th arg */
call __audit_syscall_entry
-   pushl_cfi %ebx
+   popl_cfi %ecx /* get that remapped edx off the stack */
+   popl_cfi %ecx /* get that remapped esi off the stack */
movl PT_EAX(%esp),%eax  /* reload syscall number */
jmp sysenter_do_call
 
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/3] dma: imx-sdma: correct the printk format

[Robin Gong]

Correct the printk format for 'size_t', 'dma_address_t', etc.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 5424d9a..377bb18 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1041,7 +1041,7 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
return NULL;
 
if (len >= NUM_BD * SDMA_BD_MAX_CNT) {
-   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%d > 
%d\n",
+   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%zu > 
%d\n",
channel, len, NUM_BD * SDMA_BD_MAX_CNT);
goto err_out;
}
@@ -1050,8 +1050,8 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
 
sdmac->buf_tail = 0;
 
-   dev_dbg(sdma->dev, "memcpy: %x->%x, len=%d, channel=%d.\n",
-   dma_src, dma_dst, len, channel);
+   dev_dbg(sdma->dev, "memcpy: %pad->%pad, len=%zu, channel=%d.\n",
+   _src, _dst, len, channel);
 
sdmac->direction = DMA_MEM_TO_MEM;
 
@@ -1104,7 +1104,7 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
param &= ~BD_CONT;
}
 
-   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
+   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%u %s%s\n",
i, count, bd->buffer_addr,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
@@ -1220,8 +1220,8 @@ static struct dma_async_tx_descriptor *sdma_prep_sg(
param &= ~BD_CONT;
}
 
-   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
-   i, count, sg_src->dma_address,
+   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%pad %s%s\n",
+   i, count, _src->dma_address,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
 
@@ -1291,7 +1291,7 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
}
 
if (period_len > SDMA_BD_MAX_CNT) {
-   dev_err(sdma->dev, "SDMA channel %d: maximum period size 
exceeded: %d > %d\n",
+   dev_err(sdma->dev, "SDMA channel %d: maximum period size 
exceeded: %zu > %d\n",
channel, period_len, SDMA_BD_MAX_CNT);
goto err_out;
}
@@ -1315,8 +1315,8 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
if (i + 1 == num_periods)
param |= BD_WRAP;
 
-   dev_dbg(sdma->dev, "entry %d: count: %d dma: %#llx %s%s\n",
-   i, period_len, (u64)dma_addr,
+   dev_dbg(sdma->dev, "entry %d: count: %d dma: %pad %s%s\n",
+   i, period_len, _addr,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/3] dma: imx-sdma: add support for sdma memory copy

[Robin Gong]

Add device_prep_dma_memcpy and device_prep_dma_sg common interfaces
for imx-sdma driver to support memory copy in two ways: continuous
memory buffers or scatter lists.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 188 ++---
 1 file changed, 164 insertions(+), 24 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f7626e3..5424d9a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -229,6 +229,7 @@ struct sdma_context_data {
 } __attribute__ ((packed));
 
 #define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
+#define SDMA_BD_MAX_CNT0xfffc /* align with 4 bytes */
 
 struct sdma_engine;
 
@@ -261,6 +262,7 @@ struct sdma_channel {
unsigned intpc_from_device, pc_to_device;
unsigned long   flags;
dma_addr_t  per_address;
+   unsigned intpc_to_pc;
unsigned long   event_mask[2];
unsigned long   watermark_level;
u32 shp_addr, per_addr;
@@ -701,6 +703,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
+   sdmac->pc_to_pc = 0;
 
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
@@ -775,6 +778,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
+   sdmac->pc_to_pc = emi_2_emi;
 }
 
 static int sdma_load_context(struct sdma_channel *sdmac)
@@ -787,11 +791,12 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
 
-   if (sdmac->direction == DMA_DEV_TO_MEM) {
+   if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
-   } else {
+   else if (sdmac->direction == DMA_MEM_TO_MEM)
+   load_address = sdmac->pc_to_pc;
+   else
load_address = sdmac->pc_to_device;
-   }
 
if (load_address < 0)
return load_address;
@@ -1021,16 +1026,118 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
clk_disable(sdma->clk_ahb);
 }
 
-static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
-   struct dma_chan *chan, struct scatterlist *sgl,
-   unsigned int sg_len, enum dma_transfer_direction direction,
-   unsigned long flags, void *context)
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+   struct dma_chan *chan, dma_addr_t dma_dst,
+   dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+   struct sdma_channel *sdmac = to_sdma_chan(chan);
+   struct sdma_engine *sdma = sdmac->sdma;
+   int channel = sdmac->channel;
+   size_t count;
+   int i = 0, param, ret;
+   struct sdma_buffer_descriptor *bd;
+
+   if (!chan || !len || sdmac->status == DMA_IN_PROGRESS)
+   return NULL;
+
+   if (len >= NUM_BD * SDMA_BD_MAX_CNT) {
+   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%d > 
%d\n",
+   channel, len, NUM_BD * SDMA_BD_MAX_CNT);
+   goto err_out;
+   }
+
+   sdmac->status = DMA_IN_PROGRESS;
+
+   sdmac->buf_tail = 0;
+
+   dev_dbg(sdma->dev, "memcpy: %x->%x, len=%d, channel=%d.\n",
+   dma_src, dma_dst, len, channel);
+
+   sdmac->direction = DMA_MEM_TO_MEM;
+
+   ret = sdma_load_context(sdmac);
+   if (ret)
+   goto err_out;
+
+   sdmac->chn_count = 0;
+
+   do {
+   count = min_t(size_t, len, SDMA_BD_MAX_CNT);
+   bd = >bd[i];
+   bd->buffer_addr = dma_src;
+   bd->ext_buffer_addr = dma_dst;
+   bd->mode.count = count;
+
+   if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES) {
+   ret =  -EINVAL;
+   goto err_out;
+   }
+
+   switch (sdmac->word_size) {
+   case DMA_SLAVE_BUSWIDTH_4_BYTES:
+   bd->mode.command = 0;
+   if ((count | dma_dst | dma_src) & 3)
+   return NULL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_2_BYTES:
+   bd->mode.command = 2;
+   if ((count | dma_dst | dma_src) & 1)
+   return NULL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_1_BYTE:
+   bd->mode.command = 1;
+   break;
+   default:
+   return NULL;
+   }
+
+   dma_src += count;
+   dma_dst += count;
+   len -= count;
+   i++;
+
+   param = BD_DONE | BD_EXTD | BD_CONT;
+

[PATCH v5 3/3] dma: imx-sdma: reorg code to make code clean

[Robin Gong]

Code reorg for transfer prepare and bus width check to make code
cleaner.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 127 +++--
 1 file changed, 60 insertions(+), 67 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 377bb18..f2dee57 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1026,6 +1026,52 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
clk_disable(sdma->clk_ahb);
 }
 
+static int sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction)
+{
+   int ret = 0;
+
+   sdmac->status = DMA_IN_PROGRESS;
+   sdmac->buf_tail = 0;
+   sdmac->flags = 0;
+   sdmac->direction = direction;
+
+   ret = sdma_load_context(sdmac);
+   if (ret)
+   return ret;
+
+   sdmac->chn_count = 0;
+
+   return ret;
+}
+
+static int check_bd_buswidth(struct sdma_buffer_descriptor *bd,
+struct sdma_channel *sdmac, int count,
+dma_addr_t dma_dst, dma_addr_t dma_src)
+{
+   int ret = 0;
+
+   switch (sdmac->word_size) {
+   case DMA_SLAVE_BUSWIDTH_4_BYTES:
+   bd->mode.command = 0;
+   if ((count | dma_dst | dma_src) & 3)
+   ret = -EINVAL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_2_BYTES:
+   bd->mode.command = 2;
+   if ((count | dma_dst | dma_src) & 1)
+   ret = -EINVAL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_1_BYTE:
+bd->mode.command = 1;
+break;
+   default:
+return -EINVAL;
+   }
+
+   return ret;
+}
+
 static struct dma_async_tx_descriptor *sdma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dma_dst,
dma_addr_t dma_src, size_t len, unsigned long flags)
@@ -1034,7 +1080,7 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
size_t count;
-   int i = 0, param, ret;
+   int i = 0, param;
struct sdma_buffer_descriptor *bd;
 
if (!chan || !len || sdmac->status == DMA_IN_PROGRESS)
@@ -1046,21 +1092,12 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
goto err_out;
}
 
-   sdmac->status = DMA_IN_PROGRESS;
-
-   sdmac->buf_tail = 0;
-
dev_dbg(sdma->dev, "memcpy: %pad->%pad, len=%zu, channel=%d.\n",
_src, _dst, len, channel);
 
-   sdmac->direction = DMA_MEM_TO_MEM;
-
-   ret = sdma_load_context(sdmac);
-   if (ret)
+   if (sdma_transfer_init(sdmac, DMA_MEM_TO_MEM))
goto err_out;
 
-   sdmac->chn_count = 0;
-
do {
count = min_t(size_t, len, SDMA_BD_MAX_CNT);
bd = >bd[i];
@@ -1068,28 +1105,8 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
bd->ext_buffer_addr = dma_dst;
bd->mode.count = count;
 
-   if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES) {
-   ret =  -EINVAL;
+   if (check_bd_buswidth(bd, sdmac, count, dma_dst, dma_src))
goto err_out;
-   }
-
-   switch (sdmac->word_size) {
-   case DMA_SLAVE_BUSWIDTH_4_BYTES:
-   bd->mode.command = 0;
-   if ((count | dma_dst | dma_src) & 3)
-   return NULL;
-   break;
-   case DMA_SLAVE_BUSWIDTH_2_BYTES:
-   bd->mode.command = 2;
-   if ((count | dma_dst | dma_src) & 1)
-   return NULL;
-   break;
-   case DMA_SLAVE_BUSWIDTH_1_BYTE:
-   bd->mode.command = 1;
-   break;
-   default:
-   return NULL;
-   }
 
dma_src += count;
dma_dst += count;
@@ -1141,21 +1158,10 @@ static struct dma_async_tx_descriptor *sdma_prep_sg(
 
if (sdmac->status == DMA_IN_PROGRESS)
return NULL;
-   sdmac->status = DMA_IN_PROGRESS;
-
-   sdmac->flags = 0;
-
-   sdmac->buf_tail = 0;
 
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
src_nents, channel);
 
-   sdmac->direction = direction;
-
-   ret = sdma_load_context(sdmac);
-   if (ret)
-   goto err_out;
-
if (src_nents > NUM_BD) {
dev_err(sdma->dev, "SDMA channel %d: maximum number of sg 
exceeded: %d > %d\n",
channel, src_nents, NUM_BD);
@@ -1163,7 +1169,9 @@ static struct dma_async_tx_descriptor *sdma_prep_sg(
goto err_out;
}
 
-   sdmac->chn_count = 

[PATCH v5 1/3] dma: imx-sdma: add support for sdma memory copy

[Robin Gong]

Add device_prep_dma_memcpy and device_prep_dma_sg common interfaces
for imx-sdma driver to support memory copy in two ways: continuous
memory buffers or scatter lists.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 188 ++---
 1 file changed, 164 insertions(+), 24 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f7626e3..5424d9a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -229,6 +229,7 @@ struct sdma_context_data {
 } __attribute__ ((packed));
 
 #define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
+#define SDMA_BD_MAX_CNT0xfffc /* align with 4 bytes */
 
 struct sdma_engine;
 
@@ -261,6 +262,7 @@ struct sdma_channel {
unsigned intpc_from_device, pc_to_device;
unsigned long   flags;
dma_addr_t  per_address;
+   unsigned intpc_to_pc;
unsigned long   event_mask[2];
unsigned long   watermark_level;
u32 shp_addr, per_addr;
@@ -701,6 +703,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
+   sdmac->pc_to_pc = 0;
 
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
@@ -775,6 +778,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
+   sdmac->pc_to_pc = emi_2_emi;
 }
 
 static int sdma_load_context(struct sdma_channel *sdmac)
@@ -787,11 +791,12 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
 
-   if (sdmac->direction == DMA_DEV_TO_MEM) {
+   if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
-   } else {
+   else if (sdmac->direction == DMA_MEM_TO_MEM)
+   load_address = sdmac->pc_to_pc;
+   else
load_address = sdmac->pc_to_device;
-   }
 
if (load_address < 0)
return load_address;
@@ -1021,16 +1026,118 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
clk_disable(sdma->clk_ahb);
 }
 
-static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
-   struct dma_chan *chan, struct scatterlist *sgl,
-   unsigned int sg_len, enum dma_transfer_direction direction,
-   unsigned long flags, void *context)
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+   struct dma_chan *chan, dma_addr_t dma_dst,
+   dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+   struct sdma_channel *sdmac = to_sdma_chan(chan);
+   struct sdma_engine *sdma = sdmac->sdma;
+   int channel = sdmac->channel;
+   size_t count;
+   int i = 0, param, ret;
+   struct sdma_buffer_descriptor *bd;
+
+   if (!chan || !len || sdmac->status == DMA_IN_PROGRESS)
+   return NULL;
+
+   if (len >= NUM_BD * SDMA_BD_MAX_CNT) {
+   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%d > 
%d\n",
+   channel, len, NUM_BD * SDMA_BD_MAX_CNT);
+   goto err_out;
+   }
+
+   sdmac->status = DMA_IN_PROGRESS;
+
+   sdmac->buf_tail = 0;
+
+   dev_dbg(sdma->dev, "memcpy: %x->%x, len=%d, channel=%d.\n",
+   dma_src, dma_dst, len, channel);
+
+   sdmac->direction = DMA_MEM_TO_MEM;
+
+   ret = sdma_load_context(sdmac);
+   if (ret)
+   goto err_out;
+
+   sdmac->chn_count = 0;
+
+   do {
+   count = min_t(size_t, len, SDMA_BD_MAX_CNT);
+   bd = >bd[i];
+   bd->buffer_addr = dma_src;
+   bd->ext_buffer_addr = dma_dst;
+   bd->mode.count = count;
+
+   if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES) {
+   ret =  -EINVAL;
+   goto err_out;
+   }
+
+   switch (sdmac->word_size) {
+   case DMA_SLAVE_BUSWIDTH_4_BYTES:
+   bd->mode.command = 0;
+   if ((count | dma_dst | dma_src) & 3)
+   return NULL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_2_BYTES:
+   bd->mode.command = 2;
+   if ((count | dma_dst | dma_src) & 1)
+   return NULL;
+   break;
+   case DMA_SLAVE_BUSWIDTH_1_BYTE:
+   bd->mode.command = 1;
+   break;
+   default:
+   return NULL;
+   }
+
+   dma_src += count;
+   dma_dst += count;
+   len -= count;
+   i++;
+
+   param = BD_DONE | BD_EXTD | BD_CONT;
+

[PATCH v4 2/3] dma: imx-sdma: correct print format

[Robin Gong]

correct print format for 'size_t', 'dma_address_t',etc.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc4a0df..7e8aa2d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1041,7 +1041,7 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
return NULL;
 
if (len >= NUM_BD * SDMA_BD_MAX_CNT) {
-   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%d > %d\n"
+   dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%zu > 
%d\n"
, channel, len, NUM_BD * SDMA_BD_MAX_CNT);
goto err_out;
}
@@ -1050,8 +1050,8 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
 
sdmac->buf_tail = 0;
 
-   dev_dbg(sdma->dev, "memcpy: %x->%x, len=%d, channel=%d.\n",
-   dma_src, dma_dst, len, channel);
+   dev_dbg(sdma->dev, "memcpy: %pad->%pad, len=%zu, channel=%d.\n",
+   _src, _dst, len, channel);
 
sdmac->direction = DMA_MEM_TO_MEM;
 
@@ -1104,7 +1104,7 @@ static struct dma_async_tx_descriptor *sdma_prep_memcpy(
param &= ~BD_CONT;
}
 
-   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
+   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%u %s%s\n",
i, count, bd->buffer_addr,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
@@ -1220,8 +1220,8 @@ static struct dma_async_tx_descriptor *sdma_prep_sg(
param &= ~BD_CONT;
}
 
-   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
-   i, count, sg_src->dma_address,
+   dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%pad %s%s\n",
+   i, count, _src->dma_address,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
 
@@ -1291,7 +1291,7 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
}
 
if (period_len > SDMA_BD_MAX_CNT) {
-   dev_err(sdma->dev, "SDMA channel %d: maximum period size 
exceeded: %d > %d\n",
+   dev_err(sdma->dev, "SDMA channel %d: maximum period size 
exceeded: %zu > %d\n",
channel, period_len, SDMA_BD_MAX_CNT);
goto err_out;
}
@@ -1315,8 +1315,8 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
if (i + 1 == num_periods)
param |= BD_WRAP;
 
-   dev_dbg(sdma->dev, "entry %d: count: %d dma: %#llx %s%s\n",
-   i, period_len, (u64)dma_addr,
+   dev_dbg(sdma->dev, "entry %d: count: %d dma: %pad %s%s\n",
+   i, period_len, _addr,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/3] dma: imx-sdma: add support for sdma memory copy

[Robin Gong]

Add memory copy interface to sdma driver, the patch set is based on
v3:
http://www.spinics.net/lists/dmaengine/msg00850.html.

change from v4:
1.address comments from Andy Shevchenko.
change from v3:
1.split two patches from v3 patch for Vinod's comments.

change from v2:
1.remove redundant check for bus width.

change from v1:
1. correct some printk format, such as %pad for dma_addr_t
2. split duplicated code in prep_dma_memcpy and prep_dma_sg to make code clean


Robin Gong (3):
  dma: imx-sdma: add support for sdma memory copy
  dma: imx-sdma: correct print format
  dma: imx-sdma: reorg code to make code clean

 drivers/dma/imx-sdma.c | 247 +
 1 file changed, 190 insertions(+), 57 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/3] dma: imx-sdma: add support for sdma memory copy

[Robin Gong]

Add memory copy interface to sdma driver, the patch set is based on
v3:
http://www.spinics.net/lists/dmaengine/msg00850.html.

change from v4:
1.address comments from Andy Shevchenko.
change from v3:
1.split two patches from v3 patch for Vinod's comments.

change from v2:
1.remove redundant check for bus width.

change from v1:
1. correct some printk format, such as %pad for dma_addr_t
2. split duplicated code in prep_dma_memcpy and prep_dma_sg to make code clean


Robin Gong (3):
  dma: imx-sdma: add support for sdma memory copy
  dma: imx-sdma: correct print format
  dma: imx-sdma: reorg code to make code clean

 drivers/dma/imx-sdma.c | 247 +
 1 file changed, 190 insertions(+), 57 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] Staging: iio: adc: fix line over 80 characters

[Joe Perches]

On Thu, 2014-10-23 at 01:47 +0200, Hartmut Knaack wrote:
> Sudip Mukherjee schrieb am 22.10.2014 06:21:
> > On Tue, Oct 21, 2014 at 05:56:47PM -0500, Brian Vandre wrote:
> >> This fixes the 2 checkpatch.pl warnings:
> >> WARNING: line over 80 characters
> >>
> > please check your patch with --strict option of checkpatch.pl , and you 
> > will get :
> > "Alignment should match open parenthesis" .
> > 
> Good point, but what solution would you propose?

> >> diff --git a/drivers/staging/iio/adc/mxs-lradc.c 
> >> b/drivers/staging/iio/adc/mxs-lradc.c

> >> @@ -455,7 +455,8 @@ static void mxs_lradc_setup_ts_channel(struct 
> >> mxs_lradc *lradc, unsigned ch)
> >> * SoC's delay unit and start the conversion later
> >> * and automatically.
> >> */
> >> -  mxs_lradc_reg_wrt(lradc, LRADC_DELAY_TRIGGER(0) | /* don't trigger ADC 
> >> */
> >> +  mxs_lradc_reg_wrt(lradc,
> >> +  LRADC_DELAY_TRIGGER(0) | /* don't trigger ADC */
> >>LRADC_DELAY_TRIGGER_DELAYS(1 << 3) | /* trigger DELAY unit#3 */
> >>LRADC_DELAY_KICK |
> >>LRADC_DELAY_DELAY(lradc->settling_delay),

Maybe something like:

mxs_lradc_reg_wrt(lradc,
  LRADC_DELAY_TRIGGER(0) |
/* don't trigger ADC */
  LRADC_DELAY_TRIGGER_DELAYS(1 << 3) |
/* trigger DELAY unit#3 */
  LRADC_DELAY_KICK |
  LRADC_DELAY_DELAY(lradc->settling_delay),


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Possible wireless issue introduced in next-20140930

[Murilo Opsfelder Araujo]

Hello, everyone.

With next-20140930 my laptop does not work, i.e. after I enter my login 
and password in KDM, the entire system becomes unresponsive and I need 
to reset it in order to reboot (it does not even show the KDE splash 
screen).


It was working pretty fine with next-20140926.

I've also tested with next-20141022 and v3.18-rc1 and no luck.

git bisect pointed me to the commit below [1].  My wireless card is a 
RTL8191SEvA [2].


I need your help to troubleshoot this.

Thanks in advance.

[1]
commit 38506ecefab911785d5e1aa5889f6eeb462e0954
Author: Larry Finger 
Date:   Mon Sep 22 09:39:19 2014 -0500

rtlwifi: rtl_pci: Start modification for new drivers

Future patches will move the drivers for RTL8192EE and RTL8821AE
from staging to the regular wireless tree. Here, the necessary features
are added to the PCI driver. Other files are touched due to changes
in the various data structs.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 

[2]
$ lspci -vvv
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvA 
Wireless LAN Controller (rev 10)

Subsystem: Hewlett-Packard Company Device 1467
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 3000 [size=256]
Region 1: Memory at d340 (32-bit, non-prefetchable) [size=16K]
Capabilities: 
Kernel driver in use: rtl8192se

--
Murilo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESUBMIT PATCH v4 1/8] mfd: Add support for Skyworks SKY81452 driver

[Gyungoh Yoo]

On Tue, Oct 21, 2014 at 01:30:01PM +0100, Lee Jones wrote:
> On Mon, 13 Oct 2014, Gyungoh Yoo wrote:
> 
> > Signed-off-by: Gyungoh Yoo 
> > ---
> > Changes v4:
> > Removed MODULE_VERSION()
> > Modified license to GPLv2
> > 
> > Changes v3:
> > Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
> > Assigned mfd_cell.of_compatible for binding device node
> > Modified error messages
> > 
> > Changes v2:
> > Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
> > Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
> > Added message for exception or errors
> > 
> >  drivers/mfd/Kconfig  |  12 +
> >  drivers/mfd/Makefile |   1 +
> >  drivers/mfd/sky81452.c   | 110 
> > +++
> >  include/linux/mfd/sky81452.h |  32 +
> >  4 files changed, 155 insertions(+)
> >  create mode 100644 drivers/mfd/sky81452.c
> >  create mode 100644 include/linux/mfd/sky81452.h
> 
> [...]
> 
> > +++ b/include/linux/mfd/sky81452.h
> > @@ -0,0 +1,32 @@
> > +/*
> > + * sky81452.h  SKY81452 MFD driver
> > + *
> > + * Copyright 2014 Skyworks Solutions Inc.
> > + * Author : Gyungoh Yoo 
> > + *
> > + * 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, or (at your option) any
> > + * later version.
> > + *
> > + * 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 .
> > + */
> > +
> > +#ifndef _SKY81452_H
> > +#define _SKY81452_H
> > +
> > +#include 
> 
> Shouldn't this live in linux/platform_data?

I will change the location to linux/platform_data and resubmit it.
Thank you your review.

> 
> > +#include 
> > +
> > +struct sky81452_platform_data {
> > +   struct sky81452_bl_platform_data *bl_pdata;
> > +   struct regulator_init_data *regulator_init_data;
> > +};
> > +
> > +#endif
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESUBMIT PATCH v4 7/8] regulator: sky81452: Add compatible string for device binding

[Gyungoh Yoo]

On Wed, Oct 22, 2014 at 11:27:23AM +0100, Mark Brown wrote:
> On Mon, Oct 20, 2014 at 03:10:24PM +0900, Gyungoh Yoo wrote:
> > On Fri, Oct 17, 2014 at 04:26:05PM +0200, Mark Brown wrote:
> 
> > > The thing I'm seeing is that the binding for your device with the
> > > subnode looks very much like the device trees of devices with multiple
> > > regulators.  The fact that you only have one regulator is a bit
> > > difference but not that much.  It seems like drivers should fit into one
> > > of two patterns: either the regulator is described in the root node for
> > > the device for single purpose devices or there should be a collection of
> > > regulators like is supported with this helper API.  Having a collection
> > > with only one node doesn't seem to be a problem in any way.
> 
> > Thank you for your kind comments.
> > My understanding is getting better.
> 
> > For my clear understanding:
> > I think the original designed which I wanted to design is similar
> > with arizona-ldo1.c
> > It seems that this is 1st pattern your explained above.
> > Can I ask what is different between arizona-ldo1.c and
> > this sky81452-regulator.c?
> > I think both are designed under root node.
> 
> Were that code being written today I'd probably be asking for it to use
> a regulators subnode to be consistent with everything else, it's a
> slightly older driver and sometimes we've not spotted the patterns when
> they're added, once we get to the point of adding the helpers as we have
> now things are definitely getting baked in.

I see. Thank you.

So, what do you think about DT like below?

sky81452@2c {
compatible = "skyworks,sky81452";
reg = <0x2c>;

backlight {
compatible = "skyworks,sky81452-backlight";
name = "pwm-backlight";
enable = <0x3F>;
ignore-pwm;
};

regulator {
compatible = "skyworks,sky81452-regulator";

lout@0 {
regulator-name = "LOUT";
regulator-min-microvolt = <450>;
regulator-max-microvolt = <800>;
};
};
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the akpm-current tree with the pm tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
include/linux/oom.h, kernel/power/process.c and mm/oom_kill.c between
commit 5695be142e20 ("OOM, PM: OOM killed task shouldn't escape PM
suspend") from the pm tree and commit e039ae202d34 ("OOM, PM: OOM
killed task cannot escape PM suspend") from the akpm-current tree.

I fixed it up (the pm tree version seems to be newer, so I used that)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH 1/2] Add pgcollapse stat counter to task_struct

[Alex Thorlton]

Pretty self explanatory.  Just adding one of the same counters that I used to
gather data for the other patches.

Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

---
 include/linux/sched.h | 3 +++
 mm/huge_memory.c  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..9b87d9a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1661,6 +1661,9 @@ struct task_struct {
unsigned intsequential_io;
unsigned intsequential_io_avg;
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   unsigned int pgcollapse_pages_collapsed;
+#endif
 };
 
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 74c78aa..ca8a813 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2531,6 +2531,7 @@ static void collapse_huge_page(struct mm_struct *mm,
 
*hpage = NULL;
 
+mm->owner->pgcollapse_pages_collapsed++;
khugepaged_pages_collapsed++;
 out_up_write:
up_write(>mmap_sem);
-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] Add /proc files to expose per-mm pgcollapse stats

[Alex Thorlton]

Just add a proc file to expose the stat counter I added.

Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

---
 fs/proc/base.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 772efa4..7517bf4 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2466,6 +2466,16 @@ static const struct file_operations 
proc_projid_map_operations = {
 };
 #endif /* CONFIG_USER_NS */
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+int proc_pgcollapse_show(struct seq_file *m, struct pid_namespace *ns,
+struct pid *pid, struct task_struct *tsk)
+{
+   seq_printf(m, "pages_collapsed: %u\n", tsk->pgcollapse_pages_collapsed);
+
+   return 0;
+}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+
 static int proc_pid_personality(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
 {
@@ -2576,6 +2586,9 @@ static const struct pid_entry tgid_base_stuff[] = {
 #ifdef CONFIG_CHECKPOINT_RESTORE
REG("timers", S_IRUGO, proc_timers_operations),
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   ONE("pgcollapse", S_IRUGO, proc_pgcollapse_show),
+#endif
 };
 
 static int proc_tgid_base_readdir(struct file *file, struct dir_context *ctx)
@@ -2914,6 +2927,9 @@ static const struct pid_entry tid_base_stuff[] = {
REG("gid_map",S_IRUGO|S_IWUSR, proc_gid_map_operations),
REG("projid_map", S_IRUGO|S_IWUSR, proc_projid_map_operations),
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   ONE("pgcollapse", S_IRUGO, proc_pgcollapse_show),
+#endif
 };
 
 static int proc_tid_base_readdir(struct file *file, struct dir_context *ctx)
-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHSET 0/5] perf tools: option parsing improvement

[Hemant Kumar]

Hi Namhyung,
On 10/22/2014 08:45 PM, Namhyung Kim wrote:

Hello,

This patchset tries to enhance option parser a bit.  Patch 1-3 are to
reuse existing perf record options for other commands like perf kvm
stat record.  Patch 4-5 are to support exclusive options that cannot
be used at the same time.  The perf probe has such options and upcoming
sdt-cache command also.


Thank you for working on this.

[SNIP]

--
Thanks,
Hemant Kumar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 02/20] perf: Add AUX area to ring buffer for raw data streams

[Frederic Weisbecker]

On Wed, Oct 22, 2014 at 02:35:47PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 13, 2014 at 04:45:30PM +0300, Alexander Shishkin wrote:
> > +   struct kref aux_refcount;
> 
> I'm not a fan of kref, pointless obfuscation that.

It has a good potential for debugging though. Sure right now
the get/put simple APIs only performs counting sanity checks
but I've seen patches that extend it to object debugging.

Sounds quite valuable on complicated object lifecycles like
perf events.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] Disable khugepaged thread

[Alex Thorlton]

This patch just removes any call to start khugepaged for now.  If we decide to
go forward with this new approach, then this patch will also dismantle the other
bits of khugepaged that we'll no longer need.

Signed-off-by: Alex Thorlton 
Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

---
 mm/huge_memory.c | 23 +++
 1 file changed, 3 insertions(+), 20 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 74c78aa..63abf52 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -295,24 +295,9 @@ static ssize_t enabled_store(struct kobject *kobj,
 struct kobj_attribute *attr,
 const char *buf, size_t count)
 {
-   ssize_t ret;
-
-   ret = double_flag_store(kobj, attr, buf, count,
-   TRANSPARENT_HUGEPAGE_FLAG,
-   TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG);
-
-   if (ret > 0) {
-   int err;
-
-   mutex_lock(_mutex);
-   err = start_khugepaged();
-   mutex_unlock(_mutex);
-
-   if (err)
-   ret = err;
-   }
-
-   return ret;
+   return double_flag_store(kobj, attr, buf, count,
+TRANSPARENT_HUGEPAGE_FLAG,
+TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG);
 }
 static struct kobj_attribute enabled_attr =
__ATTR(enabled, 0644, enabled_show, enabled_store);
@@ -655,8 +640,6 @@ static int __init hugepage_init(void)
if (totalram_pages < (512 << (20 - PAGE_SHIFT)))
transparent_hugepage_flags = 0;
 
-   start_khugepaged();
-
return 0;
 out:
hugepage_exit_sysfs(hugepage_kobj);
-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] Add /proc files to expose per-mm pgcollapse stats

[Alex Thorlton]

This patch adds a /proc file to read out the information that we've added to the
task_struct.  I'll need to split the information out to separate files, probably
in a subdirectory, change a few of the files to allow us to modify their values,
and it will need appropriate locks.

Signed-off-by: Alex Thorlton 
Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

---
 fs/proc/base.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 772efa4..7c5aca2 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2466,6 +2466,25 @@ static const struct file_operations 
proc_projid_map_operations = {
 };
 #endif /* CONFIG_USER_NS */
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+int proc_pgcollapse_show(struct seq_file *m, struct pid_namespace *ns,
+struct pid *pid, struct task_struct *tsk)
+{
+   /* need locks here */
+   seq_printf(m, "pages_to_scan: %u\n", tsk->pgcollapse_pages_to_scan);
+   seq_printf(m, "pages_collapsed: %u\n", tsk->pgcollapse_pages_collapsed);
+   seq_printf(m, "full_scans: %u\n", tsk->pgcollapse_full_scans);
+   seq_printf(m, "scan_sleep_millisecs: %u\n",
+  tsk->pgcollapse_scan_sleep_millisecs);
+   seq_printf(m, "alloc_sleep_millisecs: %u\n", 
+  tsk->pgcollapse_alloc_sleep_millisecs);
+   seq_printf(m, "last_scan: %lu\n", tsk->pgcollapse_last_scan);
+   seq_printf(m, "scan_address: 0x%0lx\n", tsk->pgcollapse_scan_address);
+
+   return 0;
+}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+
 static int proc_pid_personality(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
 {
@@ -2576,6 +2595,9 @@ static const struct pid_entry tgid_base_stuff[] = {
 #ifdef CONFIG_CHECKPOINT_RESTORE
REG("timers", S_IRUGO, proc_timers_operations),
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   ONE("pgcollapse", S_IRUGO, proc_pgcollapse_show),
+#endif
 };
 
 static int proc_tgid_base_readdir(struct file *file, struct dir_context *ctx)
@@ -2914,6 +2936,9 @@ static const struct pid_entry tid_base_stuff[] = {
REG("gid_map",S_IRUGO|S_IWUSR, proc_gid_map_operations),
REG("projid_map", S_IRUGO|S_IWUSR, proc_projid_map_operations),
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   ONE("pgcollapse", S_IRUGO, proc_pgcollapse_show),
+#endif
 };
 
 static int proc_tid_base_readdir(struct file *file, struct dir_context *ctx)
-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] Convert khugepaged to a task_work function

[Alex Thorlton]

Hey everyone,

Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread.  This will give us finer grained control over the
page collapse scans, eliminate some unnecessary scans since tasks that are
relatively inactive will not be scanned often, and eliminate the unwanted
behavior described in the email thread I mentioned.

This initial patch is fully functional, but there are quite a few areas that
will need to be polished up before it's ready to be considered for a merge.  I
wanted to get this initial version out with some basic test results quickly, so
that people can give their opinions and let me know if there's anything they'd
like to see done differently (and there probably is :).  I'll give details on
the code in the individual patches.

I gathered some pretty rudimentary test data using a 48-thread NAMD simulation
pinned to a cpuset with 8 cpus and about 60g of memory.  I'm checking to see if
I'm allowed to publish the input data so that others can replicate the test.  In
the meantime, if somebody knows of a publicly available benchmark that stresses
khugepaged, that would be helpful.

The only data point I gathered was the number of pages collapsed, sampled every
ten seconds, for the lifetime of the job.  This one statistic gives a pretty
decent illustration of the difference in behavior between the two kernels, but I
intend to add some other counters to measure fully completed scans, failed
allocations, and possibly scans skipped due to timer constraints.

The data for the standard kernel (with a very small patch to add the stat
counter that I used to the task_struct) is available here:

http://oss.sgi.com/projects/memtests/pgcollapse/output-khpd

This was a fairly recent kernel (last Tuesday).  Commit ID:
2d65a9f48fcdf7866aab6457bc707ca233e0c791.  I'll send the patches I used for that
kernel as a reply to this message shortly.

The output from the modified kernel is stored here:

http://oss.sgi.com/projects/memtests/pgcollapse/output-pgcollapse

The output is stored in a pretty dumb format (*really* wide).  Best viewed in a
simple text editor with word wrap off, just fyi.

Quick summary of what I found:  Both kernels performed about the same when it
comes to overall runtime, my kernel was 22 seconds faster with a total runtime
of 4:13:07.  Not a significant difference, but important to note that there was
no apparent performance degradation.  The most interesting result is that my
kernel completed the majority of the necessary page collapses for this job in
2:04, whereas the mainline kernel took 29:05 to get to the same point.

Let me know what you think.  Any suggestions are appreciated!

- Alex

Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

Alex Thorlton (4):
  Disable khugepaged thread
  Add pgcollapse controls to task_struct
  Convert khugepaged scan functions to work with task_work
  Add /proc files to expose per-mm pgcollapse stats

 fs/proc/base.c |  23 +++
 include/linux/khugepaged.h |  10 ++-
 include/linux/sched.h  |  16 +
 kernel/fork.c  |   7 ++
 kernel/sched/fair.c|  18 +
 mm/huge_memory.c   | 162 +++--
 6 files changed, 123 insertions(+), 113 deletions(-)

-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Add pgcollapse controls to task_struct

[Alex Thorlton]

This patch just adds the necessary bits to the task_struct so that the scans can
eventually be controlled on a per-mm basis.  As I mentioned previously, we might
want to add some more counters here.

Signed-off-by: Alex Thorlton 
Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

---
 include/linux/sched.h | 12 
 kernel/fork.c |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..109be66 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1661,6 +1661,18 @@ struct task_struct {
unsigned intsequential_io;
unsigned intsequential_io_avg;
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   struct callback_head pgcollapse_work;
+   /* default scan 8*512 pte (or vmas) every 30 second */
+   unsigned int pgcollapse_pages_to_scan;
+   unsigned int pgcollapse_pages_collapsed;
+   unsigned int pgcollapse_full_scans;
+   unsigned int pgcollapse_scan_sleep_millisecs;
+   /* during fragmentation poll the hugepage allocator once every minute */
+   unsigned int pgcollapse_alloc_sleep_millisecs;
+   unsigned long pgcollapse_last_scan;
+   unsigned long pgcollapse_scan_address;
+#endif
 };
 
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
diff --git a/kernel/fork.c b/kernel/fork.c
index 9b7d746..8c55309 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1355,6 +1355,12 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
p->sequential_io= 0;
p->sequential_io_avg= 0;
 #endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+   /* need to pull these values from sysctl or something */
+   p->pgcollapse_pages_to_scan = HPAGE_PMD_NR * 8;
+   p->pgcollapse_scan_sleep_millisecs = 1;
+   p->pgcollapse_alloc_sleep_millisecs = 6;
+#endif
 
/* Perform scheduler related setup. Assign this task to a CPU. */
retval = sched_fork(clone_flags, p);
-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions

[Rik van Riel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/22/2014 10:12 PM, Mike Galbraith wrote:
> On Wed, 2014-10-22 at 21:42 -0400, Rik van Riel wrote:
>> On 10/22/2014 07:20 PM, Mike Turquette wrote:
>>> On Wed, Oct 22, 2014 at 1:06 PM, Rik van Riel
>>>  wrote: On 10/22/2014 02:07 AM, Mike Turquette
>>> wrote:
>> arch_eval_cpu_freq and arch_scale_cpu_freq are added to
>> allow the scheduler to evaluate if cpu frequency should
>> change and to invoke that change from a safe context.
>> 
>> They are weakly defined arch functions that do nothing
>> by default. A CPUfreq governor could use these functions
>> to implement a frequency scaling policy based on updates
>> to per-task statistics or updates to per-cpu
>> utilization.
>> 
>> As discussed at Linux Plumbers Conference 2014, the goal
>> will be to focus on a single cpu frequency scaling policy
>> that works for everyone. That may mean that the weak
>> arch functions definitions can be removed entirely and a
>> single policy implements that logic for all
>> architectures.
>>> 
>>> On virtual machines, we probably want to use both frequency and
>>>  steal time to calculate the factor.
>>> 
 You mean for calculating desired cpu frequency on a virtual 
 guest? Is that something we want to do?
>> 
>> A guest will be unable to set the cpu frequency, but it should 
>> know what the frequency is, so it can take the capacity of each 
>> CPU into account when doing things like load balancing.
> 
> Hm.  Why does using vaporite freq/capacity/whatever make any sense,
> the silicon under the V(aporite)PU can/does change at the drop of a
> hat, no?

It can, but IIRC that should cause the kvmclock data for that VCPU
to be regenerated, and the VCPU should be able to use that to figure
out that the frequency changed the next time it runs the scheduler
code on that VCPU.

- -- 
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUSGsmAAoJEM553pKExN6DlhUH/RLmVoHmab2zfPgZfRXWD9PX
yKkx1tmoNPFAdp7l1xgz+fIVtp5I7gUnCo03r0x3JDL8dYiEfU1BfX1bs2WSresL
7q50DVLQe8VXIqgmu1INqzQSJGfF9yOW4Kgg2xHkNBoWUdt+3fjF9JSEMJFxOZOs
pFT85ITTs0zFIRDlwdEBEs0kRLEqh0JBeLx501RSC9VQ9OIZ3lp9O1BnawQ8WI0o
Qq8ODXFgy1BGUE+Ow+skP8MnQUyBgb6b+f0Q6AmK/Er6lzw8PMwNvnmYN14ruR3R
YkTjsyYxlYlzrx2IKZNWuYy5OXguRIslWi67fI0k/yE2WVHy/yXPbRErYQfM2o8=
=PeDr
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] Convert khugepaged to a task_work function

[Alex Thorlton]

Please ignore!  Screwed up my git send-email...  Sending the proper
version here in a bit...

On Wed, Oct 22, 2014 at 09:35:02PM -0500, Alex Thorlton wrote:
> Hey everyone,
> 
> Last week, while discussing possible fixes for some unexpected/unwanted 
> behavior
> from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
> mentioned possibly changing changing khugepaged to work as a task_work 
> function
> instead of a kernel thread.  This will give us finer grained control over the
> page collapse scans, eliminate some unnecessary scans since tasks that are
> relatively inactive will not be scanned often, and eliminate the unwanted
> behavior described in the email thread I mentioned.
> 
> This initial patch is fully functional, but there are quite a few areas that
> will need to be polished up before it's ready to be considered for a merge.  I
> wanted to get this initial version out with some basic test results quickly, 
> so
> that people can give their opinions and let me know if there's anything they'd
> like to see done differently (and there probably is :).  I'll give details on
> the code in the individual patches.
> 
> I gathered some pretty rudimentary test data using a 48-thread NAMD simulation
> pinned to a cpuset with 8 cpus and about 60g of memory.  I'm checking to see 
> if
> I'm allowed to publish the input data so that others can replicate the test.  
> In
> the meantime, if somebody knows of a publicly available benchmark that 
> stresses
> khugepaged, that would be helpful.
> 
> The only data point I gathered was the number of pages collapsed, sampled 
> every
> ten seconds, for the lifetime of the job.  This one statistic gives a pretty
> decent illustration of the difference in behavior between the two kernels, 
> but I
> intend to add some other counters to measure fully completed scans, failed
> allocations, and possibly scans skipped due to timer constraints.
> 
> The data for the standard kernel (with a very small patch to add the stat
> counter that I used to the task_struct) is available here:
> 
> http://oss.sgi.com/projects/memtests/pgcollapse/output-khpd
> 
> This was a fairly recent kernel (last Tuesday).  Commit ID:
> 2d65a9f48fcdf7866aab6457bc707ca233e0c791.  I'll send the patches I used for 
> that
> kernel as a reply to this message shortly.
> 
> The output from the modified kernel is stored here:
> 
> http://oss.sgi.com/projects/memtests/pgcollapse/output-pgcollapse
> 
> The output is stored in a pretty dumb format (*really* wide).  Best viewed in 
> a
> simple text editor with word wrap off, just fyi.
> 
> Quick summary of what I found:  Both kernels performed about the same when it
> comes to overall runtime, my kernel was 22 seconds faster with a total runtime
> of 4:13:07.  Not a significant difference, but important to note that there 
> was
> no apparent performance degradation.  The most interesting result is that my
> kernel completed the majority of the necessary page collapses for this job in
> 2:04, whereas the mainline kernel took 29:05 to get to the same point.
> 
> Let me know what you think.  Any suggestions are appreciated!
> 
> - Alex
> 
> Cc: Andrew Morton 
> Cc: Bob Liu 
> Cc: David Rientjes 
> Cc: Eric W. Biederman 
> Cc: Hugh Dickins 
> Cc: Ingo Molnar 
> Cc: Kees Cook 
> Cc: Kirill A. Shutemov 
> Cc: Mel Gorman 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Vladimir Davydov 
> Cc: linux-kernel@vger.kernel.org
> 
> Alex Thorlton (4):
>   Disable khugepaged thread
>   Add pgcollapse controls to task_struct
>   Convert khugepaged scan functions to work with task_work
>   Add /proc files to expose per-mm pgcollapse stats
> 
>  fs/proc/base.c |  23 +++
>  include/linux/khugepaged.h |  10 ++-
>  include/linux/sched.h  |  16 +
>  kernel/fork.c  |   7 ++
>  kernel/sched/fair.c|  18 +
>  mm/huge_memory.c   | 162 
> +++--
>  6 files changed, 123 insertions(+), 113 deletions(-)
> 
> -- 
> 1.7.12.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] Convert khugepaged to a task_work function

[Alex Thorlton]

Hey everyone,

Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread.  This will give us finer grained control over the
page collapse scans, eliminate some unnecessary scans since tasks that are
relatively inactive will not be scanned often, and eliminate the unwanted
behavior described in the email thread I mentioned.

This initial patch is fully functional, but there are quite a few areas that
will need to be polished up before it's ready to be considered for a merge.  I
wanted to get this initial version out with some basic test results quickly, so
that people can give their opinions and let me know if there's anything they'd
like to see done differently (and there probably is :).  I'll give details on
the code in the individual patches.

I gathered some pretty rudimentary test data using a 48-thread NAMD simulation
pinned to a cpuset with 8 cpus and about 60g of memory.  I'm checking to see if
I'm allowed to publish the input data so that others can replicate the test.  In
the meantime, if somebody knows of a publicly available benchmark that stresses
khugepaged, that would be helpful.

The only data point I gathered was the number of pages collapsed, sampled every
ten seconds, for the lifetime of the job.  This one statistic gives a pretty
decent illustration of the difference in behavior between the two kernels, but I
intend to add some other counters to measure fully completed scans, failed
allocations, and possibly scans skipped due to timer constraints.

The data for the standard kernel (with a very small patch to add the stat
counter that I used to the task_struct) is available here:

http://oss.sgi.com/projects/memtests/pgcollapse/output-khpd

This was a fairly recent kernel (last Tuesday).  Commit ID:
2d65a9f48fcdf7866aab6457bc707ca233e0c791.  I'll send the patches I used for that
kernel as a reply to this message shortly.

The output from the modified kernel is stored here:

http://oss.sgi.com/projects/memtests/pgcollapse/output-pgcollapse

The output is stored in a pretty dumb format (*really* wide).  Best viewed in a
simple text editor with word wrap off, just fyi.

Quick summary of what I found:  Both kernels performed about the same when it
comes to overall runtime, my kernel was 22 seconds faster with a total runtime
of 4:13:07.  Not a significant difference, but important to note that there was
no apparent performance degradation.  The most interesting result is that my
kernel completed the majority of the necessary page collapses for this job in
2:04, whereas the mainline kernel took 29:05 to get to the same point.

Let me know what you think.  Any suggestions are appreciated!

- Alex

Cc: Andrew Morton 
Cc: Bob Liu 
Cc: David Rientjes 
Cc: Eric W. Biederman 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: linux-kernel@vger.kernel.org

Alex Thorlton (4):
  Disable khugepaged thread
  Add pgcollapse controls to task_struct
  Convert khugepaged scan functions to work with task_work
  Add /proc files to expose per-mm pgcollapse stats

 fs/proc/base.c |  23 +++
 include/linux/khugepaged.h |  10 ++-
 include/linux/sched.h  |  16 +
 kernel/fork.c  |   7 ++
 kernel/sched/fair.c|  18 +
 mm/huge_memory.c   | 162 +++--
 6 files changed, 123 insertions(+), 113 deletions(-)

-- 
1.7.12.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] staging: skein: Add Loadable Module Support

[Eric Rost]

Adds loadable module support for skein_mod, containing skein256,
skein512, and skein1024 algorithms.

Signed-off-by: Eric Rost 
---
 drivers/staging/skein/Kconfig |   2 +-
 drivers/staging/skein/skein_generic.c | 122 ++
 2 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
index de8bdd7..012a823 100644
--- a/drivers/staging/skein/Kconfig
+++ b/drivers/staging/skein/Kconfig
@@ -1,5 +1,5 @@
 config CRYPTO_SKEIN
-   bool "Skein digest algorithm"
+   tristate "Skein digest algorithm"
depends on (X86 || UML_X86) && 64BIT && CRYPTO
select CRYPTO_HASH
select CRYPTO_ALGAPI
diff --git a/drivers/staging/skein/skein_generic.c 
b/drivers/staging/skein/skein_generic.c
index 14cc5bd..43e3cdf 100644
--- a/drivers/staging/skein/skein_generic.c
+++ b/drivers/staging/skein/skein_generic.c
@@ -16,6 +16,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -50,6 +51,22 @@ static int skein256_final(struct shash_desc *desc, u8 *out)
return ret;
 }
 
+static int skein256_export(struct shash_desc *desc, void *out)
+{
+   struct skein_256_ctx *sctx = shash_desc_ctx(desc);
+
+   memcpy(out, sctx, sizeof(*sctx));
+   return 0;
+}
+
+static int skein256_import(struct shash_desc *desc, const void *in)
+{
+   struct skein_256_ctx *sctx = shash_desc_ctx(desc);
+
+   memcpy(sctx, in, sizeof(*sctx));
+   return 0;
+}
+
 static int skein512_init(struct shash_desc *desc)
 {
struct skein_512_ctx *sctx = shash_desc_ctx(desc);
@@ -78,6 +95,22 @@ static int skein512_final(struct shash_desc *desc, u8 *out)
return ret;
 }
 
+static int skein512_export(struct shash_desc *desc, void *out)
+{
+   struct skein_512_ctx *sctx = shash_desc_ctx(desc);
+
+   memcpy(out, sctx, sizeof(*sctx));
+   return 0;
+}
+
+static int skein512_import(struct shash_desc *desc, const void *in)
+{
+   struct skein_512_ctx *sctx = shash_desc_ctx(desc);
+
+   memcpy(sctx, in, sizeof(*sctx));
+   return 0;
+}
+
 static int skein1024_init(struct shash_desc *desc)
 {
struct skein_1024_ctx *sctx = shash_desc_ctx(desc);
@@ -106,4 +139,93 @@ static int skein1024_final(struct shash_desc *desc, u8 
*out)
return ret;
 }
 
+static int skein1024_export(struct shash_desc *desc, void *out)
+{
+   struct skein_1024_ctx *sctx = shash_desc_ctx(desc);
+
+   memcpy(out, sctx, sizeof(*sctx));
+   return 0;
+}
+
+static int skein1024_import(struct shash_desc *desc, const void *in)
+{
+   struct skein_1024_ctx *sctx = shash_desc_ctx(desc);
+
+   memcpy(sctx, in, sizeof(*sctx));
+   return 0;
+}
+
+static struct shash_alg alg256 = {
+   .digestsize =   (SKEIN256_DIGEST_BIT_SIZE / 8),
+   .init   =   skein256_init,
+   .update =   skein256_update,
+   .final  =   skein256_final,
+   .export =   skein256_export,
+   .import =   skein256_import,
+   .descsize   =   sizeof(struct skein_256_ctx),
+   .statesize  =   sizeof(struct skein_256_ctx),
+   .base   =   {
+   .cra_name   =   "skein256",
+   .cra_driver_name=   "skein-mod",
+   .cra_flags  =   CRYPTO_ALG_TYPE_SHASH,
+   .cra_blocksize  =   SKEIN_256_BLOCK_BYTES,
+   .cra_module =   THIS_MODULE,
+   }
+};
+
+static struct shash_alg alg512 = {
+   .digestsize =   (SKEIN512_DIGEST_BIT_SIZE / 8),
+   .init   =   skein512_init,
+   .update =   skein512_update,
+   .final  =   skein512_final,
+   .export =   skein512_export,
+   .import =   skein512_import,
+   .descsize   =   sizeof(struct skein_512_ctx),
+   .statesize  =   sizeof(struct skein_512_ctx),
+   .base   =   {
+   .cra_name   =   "skein512",
+   .cra_driver_name=   "skein-mod",
+   .cra_flags  =   CRYPTO_ALG_TYPE_SHASH,
+   .cra_blocksize  =   SKEIN_512_BLOCK_BYTES,
+   .cra_module =   THIS_MODULE,
+   }
+};
+
+static struct shash_alg alg1024 = {
+   .digestsize =   (SKEIN1024_DIGEST_BIT_SIZE / 8),
+   .init   =   skein1024_init,
+   .update =   skein1024_update,
+   .final  =   skein1024_final,
+   .export =   skein1024_export,
+   .import =   skein1024_import,
+   .descsize   =   sizeof(struct skein_1024_ctx),
+   .statesize  =   sizeof(struct skein_1024_ctx),
+   .base   =   {
+   .cra_name   =   "skein1024",
+  

[patch][resend] MAP_HUGETLB munmap fails with size not 2MB aligned

[Davide Libenzi]

[Resending with proper CC list suggested by Andrew]

Calling munmap on a MAP_HUGETLB area, and a size which is not 2MB aligned, 
causes munmap to fail.  Tested on 3.13.x but tracking back to 3.2.x.
In do_munmap() we forcibly want a 4KB default page, and we wrongly 
calculate the end of the map.  Since the calculated end is within the end 
address of the target vma, we try to do a split with an address right in 
the middle of a huge page, which would fail with EINVAL.

Tentative (untested) patch and test case attached (be sure you have a few 
huge pages available via /proc/sys/vm/nr_hugepages tinkering).


Signed-Off-By: Davide Libenzi 


- Davide


diff --git a/mm/mmap.c b/mm/mmap.c
index 7f85520..6dba257 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2528,10 +2528,6 @@ int do_munmap(struct mm_struct *mm, unsigned long start, 
size_t len)
if ((start & ~PAGE_MASK) || start > TASK_SIZE || len > TASK_SIZE-start)
return -EINVAL;
 
-   len = PAGE_ALIGN(len);
-   if (len == 0)
-   return -EINVAL;
-
/* Find the first overlapping VMA */
vma = find_vma(mm, start);
if (!vma)
@@ -2539,6 +2535,16 @@ int do_munmap(struct mm_struct *mm, unsigned long start, 
size_t len)
prev = vma->vm_prev;
/* we have  start < vma->vm_end  */
 
+   if (likely(!is_vm_hugetlb_page(vma)))
+   len = PAGE_ALIGN(len);
+   else {
+   unsigned long hpage_size = huge_page_size(hstate_vma(vma));
+
+   len = ALIGN(len, hpage_size);
+   }
+   if (unlikely(len == 0))
+   return -EINVAL;
+
/* if it doesn't overlap, we have nothing.. */
end = start + len;
if (vma->vm_start >= end)




[hugebug.c]

#include 
#include 
#include 
#include 
#include 

static void test(int flags, size_t size)
{
void* addr = mmap(NULL, size, PROT_READ | PROT_WRITE,
  flags | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

if (addr == MAP_FAILED)
{
perror("mmap");
exit(1);
}
*(char*) addr = 17;

if (munmap(addr, size) != 0)
{
perror("munmap");
exit(1);
}
}

int main(int ac, const char** av)
{
static const size_t hugepage_size = 2 * 1024 * 1024;

printf("Testing normal pages with 2MB size ...\n");
test(0, hugepage_size);
printf("OK\n");

printf("Testing huge pages with 2MB size ...\n");
test(MAP_HUGETLB, hugepage_size);
printf("OK\n");


printf("Testing normal pages with 4KB byte size ...\n");
test(0, 4096);
printf("OK\n");

printf("Testing huge pages with 4KB byte size ...\n");
test(MAP_HUGETLB, 4096);
printf("OK\n");


printf("Testing normal pages with 1 byte size ...\n");
test(0, 1);
printf("OK\n");

printf("Testing huge pages with 1 byte size ...\n");
test(MAP_HUGETLB, 1);
printf("OK\n");

return 0;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] staging: skein: Add Crypto API support

[Eric Rost]

Adds crypto API support for the skein module. Also collapses the
threefish module into the skein module.

Signed-off-by: Eric Rost 
---
 drivers/staging/skein/Kconfig |  22 +--
 drivers/staging/skein/Makefile|  13 ++--
 drivers/staging/skein/skein.c |   1 +
 drivers/staging/skein/skein.h |   5 ++
 drivers/staging/skein/skein_generic.c | 109 ++
 5 files changed, 125 insertions(+), 25 deletions(-)
 create mode 100644 drivers/staging/skein/skein_generic.c

diff --git a/drivers/staging/skein/Kconfig b/drivers/staging/skein/Kconfig
index b9172bf..de8bdd7 100644
--- a/drivers/staging/skein/Kconfig
+++ b/drivers/staging/skein/Kconfig
@@ -1,8 +1,8 @@
 config CRYPTO_SKEIN
bool "Skein digest algorithm"
depends on (X86 || UML_X86) && 64BIT && CRYPTO
-   select CRYPTO_THREEFISH
select CRYPTO_HASH
+   select CRYPTO_ALGAPI
help
  Skein secure hash algorithm is one of 5 finalists from the NIST SHA3
  competition.
@@ -12,21 +12,5 @@ config CRYPTO_SKEIN
 
  http://www.skein-hash.info/sites/default/files/skein1.3.pdf
 
- for more information.  This module depends on the threefish block
- cipher module.
-
-config CRYPTO_THREEFISH
-   bool "Threefish tweakable block cipher"
-   depends on (X86 || UML_X86) && 64BIT && CRYPTO
-   select CRYPTO_ALGAPI
-   help
- Threefish cipher algorithm is the tweakable block cipher underneath
- the Skein family of secure hash algorithms.  Skein is one of 5
- finalists from the NIST SHA3 competition.
-
- Skein is optimized for modern, 64bit processors and is highly
- customizable.  See:
-
- http://www.skein-hash.info/sites/default/files/skein1.3.pdf
-
- for more information.
+ for more information. This module also contains the threefish block
+ cipher algorithm.
diff --git a/drivers/staging/skein/Makefile b/drivers/staging/skein/Makefile
index a14aadd..382b041 100644
--- a/drivers/staging/skein/Makefile
+++ b/drivers/staging/skein/Makefile
@@ -1,9 +1,10 @@
 #
 # Makefile for the skein secure hash algorithm
 #
-obj-$(CONFIG_CRYPTO_SKEIN) +=   skein.o \
-   skein_api.o \
-   skein_block.o
-
-obj-$(CONFIG_CRYPTO_THREEFISH) += threefish_block.o \
- threefish_api.o
+obj-$(CONFIG_CRYPTO_SKEIN) += skein_mod.o
+skein_mod-y := skein.o \
+   skein_api.o \
+   skein_block.o \
+   threefish_block.o \
+   threefish_api.o \
+   skein_generic.o
diff --git a/drivers/staging/skein/skein.c b/drivers/staging/skein/skein.c
index 8cc8358..1c3933d 100644
--- a/drivers/staging/skein/skein.c
+++ b/drivers/staging/skein/skein.c
@@ -11,6 +11,7 @@
 #define  SKEIN_PORT_CODE /* instantiate any code in skein_port.h */
 
 #include/* get the memcpy/memset functions */
+#include 
 #include "skein.h" /* get the Skein API definitions   */
 #include "skein_iv.h"/* get precomputed IVs */
 #include "skein_block.h"
diff --git a/drivers/staging/skein/skein.h b/drivers/staging/skein/skein.h
index e6669f1..79fac00 100644
--- a/drivers/staging/skein/skein.h
+++ b/drivers/staging/skein/skein.h
@@ -28,6 +28,11 @@
 **
 ***/
 
+/*Skein digest sizes for crypto api*/
+#define SKEIN256_DIGEST_BIT_SIZE (256)
+#define SKEIN512_DIGEST_BIT_SIZE (512)
+#define SKEIN1024_DIGEST_BIT_SIZE (1024)
+
 #ifndef rotl_64
 #define rotl_64(x, N)(((x) << (N)) | ((x) >> (64-(N
 #endif
diff --git a/drivers/staging/skein/skein_generic.c 
b/drivers/staging/skein/skein_generic.c
new file mode 100644
index 000..14cc5bd
--- /dev/null
+++ b/drivers/staging/skein/skein_generic.c
@@ -0,0 +1,109 @@
+/*
+ * Cryptographic API.
+ *
+ * Skein256 Hash Algorithm.
+ *
+ * Derived from cryptoapi implementation, adapted for in-place
+ * scatterlist interface.
+ *
+ * Copyright (c) Eric Rost 
+ *
+ * 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 "skein.h"
+#include 
+
+static int skein256_init(struct shash_desc *desc)
+{
+   struct skein_256_ctx *sctx = shash_desc_ctx(desc);
+
+   int ret = skein_256_init(sctx, SKEIN256_DIGEST_BIT_SIZE);
+
+   return ret;
+}
+
+int skein256_update(struct shash_desc *desc, const u8 *data,
+   unsigned int len)
+{
+   struct skein_256_ctx *sctx = shash_desc_ctx(desc);
+   size_t hbl = (size_t) len;
+   int ret = skein_256_update(sctx, data, hbl);
+
+   return ret;
+}
+EXPORT_SYMBOL(skein256_update);
+
+/* Add padding and return the message digest. */
+static int skein256_final(struct shash_desc 

[PATCH v2 0/2] staging: skein: Add Crypto API and Loadable Module support

[Eric Rost]

This patchset adds crypto api support and loadable module support to the
skein driver.

Eric Rost (2):
  staging: skein: Add Crypto API support
  staging: skein: Add Loadable Module Support

 drivers/staging/skein/Kconfig |  24 +---
 drivers/staging/skein/Makefile|  13 +-
 drivers/staging/skein/skein.c |   1 +
 drivers/staging/skein/skein.h |   5 +
 drivers/staging/skein/skein_generic.c | 231 ++
 5 files changed, 248 insertions(+), 26 deletions(-)
 create mode 100644 drivers/staging/skein/skein_generic.c

-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf tools: ensure return negitive value when write header error

[Wang Nan]

Hi Ingo,

Could you please collect this patch which fixes a perf problem?

Thanks.

On 2014/10/22 15:00, Namhyung Kim wrote:
> On Thu, 16 Oct 2014 11:08:29 +0800, Wang Nan wrote:
>> When 'perf record' write headers, it calls write_xxx in
>> tools/perf/util/header.c, and check return value. It rolls back all
>> working only when return value is negative.
>>
>> This patch ensures write_cpudesc() and write_total_mem() return negative 
>> number
>> when error. Without this patch, headers reported by 'perf report' header is
>> error in some platform. Following output is caputured on ARM, which doesn't
>> contain "Processor" field in /proc/cpuinfo. See "cpudesc", "total memory" and
>> "cmdline" field.
>>
>>bash-4.2# perf record ls
>>...
>>[ perf record: Woken up 1 times to write data ]
>>[ perf record: Captured and wrote 0.001 MB perf.data (~36 samples) ]
>>bash-4.2# perf report --stdio --header
>>Error:
>>The perf.data file has no samples!
>># 
>># captured on: Fri Sep 12 10:09:10 2014
>># hostname : arma15el
>># os release : 3.17.0+
>># perf version : 3.10.53
>># arch : armv7l
>># nrcpus online : 4
>># nrcpus avail : 1
>># cpudesc : (null)
>># total memory : 0 kB
>># cmdline :
>># event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = 
>> 0x0, excl_usr = 0, excl_kern = 0, excl_host = 0, excl_guest = 1, precise_ip 
>> = 0
>># pmu mappings: not available
>># 
>>#
>>
>> Signed-off-by: Wang Nan 
> 
> I guess the total_memory, cmdline and pmu mappings are somehow affected
> by the broken cpudesc.  Do they have their own problem on ARM?
> 
> Anyway I think it's good to check the result properly, so
> 
> Acked-by: Namhyung Kim 
> 
> Thanks,
> Namhyung
> 
> 
>> ---
>>  tools/perf/util/header.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
>> index ce0de00..39b80ac 100644
>> --- a/tools/perf/util/header.c
>> +++ b/tools/perf/util/header.c
>> @@ -605,8 +605,10 @@ static int write_cpudesc(int fd, struct perf_header *h 
>> __maybe_unused,
>>  break;
>>  }
>>  
>> -if (ret)
>> +if (ret) {
>> +ret = -1;
>>  goto done;
>> +}
>>  
>>  s = buf;
>>  
>> @@ -950,7 +952,8 @@ static int write_total_mem(int fd, struct perf_header *h 
>> __maybe_unused,
>>  n = sscanf(buf, "%*s %"PRIu64, );
>>  if (n == 1)
>>  ret = do_write(fd, , sizeof(mem));
>> -}
>> +} else
>> +ret = -1;
>>  free(buf);
>>  fclose(fp);
>>  return ret;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 4/4] fuse: Allow user namespace mounts

[Andy Lutomirski]

On Wed, Oct 22, 2014 at 5:22 PM, Seth Forshee
 wrote:
> On Wed, Oct 22, 2014 at 02:51:56PM -0700, Andy Lutomirski wrote:
>> On Wed, Oct 22, 2014 at 2:24 PM, Seth Forshee
>>  wrote:
>> > Cc: Eric W. Biederman 
>> > Cc: Serge H. Hallyn 
>> > Cc: Andy Lutomirski 
>> > Signed-off-by: Seth Forshee 
>> > ---
>> >  fs/fuse/inode.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
>> > index b88b5a780228..7d0e73e36e7b 100644
>> > --- a/fs/fuse/inode.c
>> > +++ b/fs/fuse/inode.c
>> > @@ -1201,7 +1201,7 @@ static void fuse_kill_sb_anon(struct super_block *sb)
>> >  static struct file_system_type fuse_fs_type = {
>> > .owner  = THIS_MODULE,
>> > .name   = "fuse",
>> > -   .fs_flags   = FS_HAS_SUBTYPE,
>> > +   .fs_flags   = FS_HAS_SUBTYPE | FS_USERNS_MOUNT,
>> > .mount  = fuse_mount,
>> > .kill_sb= fuse_kill_sb_anon,
>> >  };
>> > @@ -1233,7 +1233,7 @@ static struct file_system_type fuseblk_fs_type = {
>> > .name   = "fuseblk",
>> > .mount  = fuse_mount_blk,
>> > .kill_sb= fuse_kill_sb_blk,
>> > -   .fs_flags   = FS_REQUIRES_DEV | FS_HAS_SUBTYPE,
>> > +   .fs_flags   = FS_REQUIRES_DEV | FS_HAS_SUBTYPE | 
>> > FS_USERNS_MOUNT,
>> >  };
>> >  MODULE_ALIAS_FS("fuseblk");
>> >
>> > --
>> > 1.9.1
>> >
>>
>> This is mostly a sign of my ignorance, but how does this actually end
>> up working?  I assume that the mounter opens /dev/fuse and then passes
>> the fd to the mount call.  Which userns is captured?  The opener of
>> /dev/fuse or the mounter of the fs?
>
> You're correct that the mounter passes the fd to /dev/fuse to the mount
> call. The namespace of the mounter is used, but there's also a check to
> make sure that's the same as that of the opener of /dev/fuse, otherwise
> the mount fails.

As long as my nodev fix is either applied first or rejected,

Acked-by: Andy Lutomirski 

Although the LSM situation is still a mess.  Serge, any thoughts?

--Andy

>
> Seth



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build warning after merge of the block tree

[Jens Axboe]

On 2014-10-22 19:28, Stephen Rothwell wrote:

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

block/scsi_ioctl.c: In function 'sg_scsi_ioctl':
block/scsi_ioctl.c:520:1: warning: label 'out' defined but not used 
[-Wunused-label]
  out:
  ^


Fixed up, thanks.


--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] ACPI/OSL: Split memory operation region implementations to a seperate file.

[Lv Zheng]

This patch moves SystemMemory operation region implementations to a
seperate file before doing cleanups. No functional changes.

Signed-off-by: Lv Zheng 
Tested-by: Fei Yang 
---
 drivers/acpi/Makefile |2 +-
 drivers/acpi/mem.c|  395 +
 drivers/acpi/osl.c|  381 ---
 3 files changed, 396 insertions(+), 382 deletions(-)
 create mode 100644 drivers/acpi/mem.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 505d4d7..802b887 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -18,7 +18,7 @@ obj-y += acpi.o \
acpica/
 
 # All the builtin files are in the "acpi." module_param namespace.
-acpi-y += osl.o utils.o reboot.o
+acpi-y += mem.o osl.o utils.o reboot.o
 acpi-y += nvs.o
 
 # Power management related files
diff --git a/drivers/acpi/mem.c b/drivers/acpi/mem.c
new file mode 100644
index 000..722241e
--- /dev/null
+++ b/drivers/acpi/mem.c
@@ -0,0 +1,395 @@
+/*
+ * ACPI system memory implementation
+ *
+ * Copyright (C) 2014, Intel Corporation
+ *   Author: Lv Zheng 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+
+/*
+ * This list of permanent mappings is for memory that may be accessed from
+ * interrupt context, where we can't do the ioremap().
+ */
+struct acpi_ioremap {
+   struct list_head list;
+   void __iomem *virt;
+   acpi_physical_address phys;
+   acpi_size size;
+   unsigned long refcount;
+};
+
+static LIST_HEAD(acpi_ioremaps);
+static DEFINE_MUTEX(acpi_ioremap_lock);
+
+static void acpi_os_drop_map_ref(struct acpi_ioremap *map)
+{
+   if (!--map->refcount)
+   list_del_rcu(>list);
+}
+
+/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
+static struct acpi_ioremap *
+acpi_map_lookup(acpi_physical_address phys, acpi_size size)
+{
+   struct acpi_ioremap *map;
+
+   list_for_each_entry_rcu(map, _ioremaps, list)
+   if (map->phys <= phys &&
+   phys + size <= map->phys + map->size)
+   return map;
+
+   return NULL;
+}
+
+/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
+static struct acpi_ioremap *
+acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
+{
+   struct acpi_ioremap *map;
+
+   list_for_each_entry_rcu(map, _ioremaps, list)
+   if (map->virt <= virt &&
+   virt + size <= map->virt + map->size)
+   return map;
+
+   return NULL;
+}
+
+/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
+static void __iomem *
+acpi_map_vaddr_lookup(acpi_physical_address phys, unsigned int size)
+{
+   struct acpi_ioremap *map;
+
+   map = acpi_map_lookup(phys, size);
+   if (map)
+   return map->virt + (phys - map->phys);
+
+   return NULL;
+}
+
+#ifndef CONFIG_IA64
+#define should_use_kmap(pfn)   page_is_ram(pfn)
+#else
+/* ioremap will take care of cache attributes */
+#define should_use_kmap(pfn)   0
+#endif
+
+static void __iomem *acpi_map(acpi_physical_address pg_off, unsigned long 
pg_sz)
+{
+   unsigned long pfn;
+
+   pfn = pg_off >> PAGE_SHIFT;
+   if (should_use_kmap(pfn)) {
+   if (pg_sz > PAGE_SIZE)
+   return NULL;
+   return (void __iomem __force *)kmap(pfn_to_page(pfn));
+   }
+   return acpi_os_ioremap(pg_off, pg_sz);
+}
+
+static void acpi_unmap(acpi_physical_address pg_off, void __iomem *vaddr)
+{
+   unsigned long pfn;
+
+   pfn = pg_off >> PAGE_SHIFT;
+   if (should_use_kmap(pfn))
+   kunmap(pfn_to_page(pfn));
+   else
+   iounmap(vaddr);
+}
+
+static void acpi_os_map_cleanup(struct acpi_ioremap *map)
+{
+   if (!map->refcount) {
+   synchronize_rcu();
+   acpi_unmap(map->phys, map->virt);
+   kfree(map);
+   }
+}
+
+void __iomem *acpi_os_get_iomem(acpi_physical_address phys, unsigned int size)
+{
+   struct acpi_ioremap *map;
+   void __iomem *virt = NULL;
+
+   mutex_lock(_ioremap_lock);
+   map = acpi_map_lookup(phys, size);
+   if (map) {
+   virt = map->virt + (phys - map->phys);
+   map->refcount++;
+   }
+   mutex_unlock(_ioremap_lock);
+
+   return virt;
+}
+EXPORT_SYMBOL_GPL(acpi_os_get_iomem);
+
+void __iomem *__init_refok
+acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
+{
+   struct acpi_ioremap *map;
+   void __iomem *virt;
+   acpi_physical_address pg_off;
+   acpi_size pg_sz;
+
+   if (phys > 

[PATCH 4/6] ACPI/OSL: Add acpi_map2virt() to merge duplicate code.

[Lv Zheng]

This patch adds acpi_map2virt() so that some duplicated code can be merged.
No functional changes.

Signed-off-by: Lv Zheng 
Tested-by: Fei Yang 
---
 drivers/acpi/mem.c |   45 -
 1 file changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/mem.c b/drivers/acpi/mem.c
index ba74086..c472237 100644
--- a/drivers/acpi/mem.c
+++ b/drivers/acpi/mem.c
@@ -74,16 +74,10 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
return NULL;
 }
 
-static void __iomem *
-acpi_map_vaddr_lookup(acpi_physical_address phys, unsigned int size)
+static inline void __iomem *
+acpi_map2virt(struct acpi_ioremap *map, acpi_physical_address phys)
 {
-   struct acpi_ioremap *map;
-
-   map = acpi_map_lookup_phys(phys, size);
-   if (map)
-   return map->virt + (phys - map->phys);
-
-   return NULL;
+   return map ? map->virt + (phys - map->phys) : NULL;
 }
 
 #ifndef CONFIG_IA64
@@ -129,17 +123,14 @@ static void acpi_map_cleanup(struct acpi_ioremap *map)
 void __iomem *acpi_os_get_iomem(acpi_physical_address phys, unsigned int size)
 {
struct acpi_ioremap *map;
-   void __iomem *virt = NULL;
 
mutex_lock(_ioremap_lock);
map = acpi_map_lookup_phys(phys, size);
-   if (map) {
-   virt = map->virt + (phys - map->phys);
+   if (map)
acpi_map_get(map);
-   }
mutex_unlock(_ioremap_lock);
 
-   return virt;
+   return acpi_map2virt(map, phys);
 }
 EXPORT_SYMBOL_GPL(acpi_os_get_iomem);
 
@@ -168,18 +159,16 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size 
size)
}
 
map = kzalloc(sizeof(*map), GFP_KERNEL);
-   if (!map) {
-   mutex_unlock(_ioremap_lock);
-   return NULL;
-   }
+   if (!map)
+   goto out;
 
pg_off = round_down(phys, PAGE_SIZE);
pg_sz = round_up(phys + size, PAGE_SIZE) - pg_off;
virt = acpi_map(pg_off, pg_sz);
if (!virt) {
-   mutex_unlock(_ioremap_lock);
kfree(map);
-   return NULL;
+   map = NULL;
+   goto out;
}
 
INIT_LIST_HEAD(>list);
@@ -190,7 +179,7 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size 
size)
list_add_tail_rcu(>list, _ioremaps);
 out:
mutex_unlock(_ioremap_lock);
-   return map->virt + (phys - map->phys);
+   return acpi_map2virt(map, phys);
 }
 EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
 
@@ -310,10 +299,13 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u64 
*value, u32 width)
unsigned int size = width / 8;
bool unmap = false;
u64 dummy;
+   struct acpi_ioremap *map;
 
rcu_read_lock();
-   virt_addr = acpi_map_vaddr_lookup(phys_addr, size);
-   if (!virt_addr) {
+   map = acpi_map_lookup_phys(phys_addr, size);
+   if (map)
+   virt_addr = acpi_map2virt(map, phys_addr);
+   else {
rcu_read_unlock();
virt_addr = acpi_os_ioremap(phys_addr, size);
if (!virt_addr)
@@ -355,10 +347,13 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u64 
value, u32 width)
void __iomem *virt_addr;
unsigned int size = width / 8;
bool unmap = false;
+   struct acpi_ioremap *map;
 
rcu_read_lock();
-   virt_addr = acpi_map_vaddr_lookup(phys_addr, size);
-   if (!virt_addr) {
+   map = acpi_map_lookup_phys(phys_addr, size);
+   if (map)
+   virt_addr = acpi_map2virt(map, phys_addr);
+   else {
rcu_read_unlock();
virt_addr = acpi_os_ioremap(phys_addr, size);
if (!virt_addr)
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] ACPI/OSL: Fix performance issue in system memory lockings.

[Lv Zheng]

It is reported that the synchronize_rcu() used in the hot path is not
performance friendly:
 <6>[3.998532] acpi_ut_update_object_reference: obj:88003c305f78 type:10
 <6>[4.006137] acpi_ut_update_ref_count:locked count:1 action:1 flags:286
 <6>[4.013450] acpi_ut_delete_internal_obj: obj:88003c305f78 flag:2
 <6>[4.020569] acpi_ut_delete_internal_obj:second_desc 
handler_desc:88003c0784c8 flags:1
 <6>[4.029729] acpi_ut_delete_internal_obj: going to setup @ 
81489299
 <6>[4.037431] acpi_ev_system_memory_region_setup: addr:c90b0070, 
length:16
*<6>[4.045716] acpi_os_unmap_memory: locked
*<6>[4.050111] acpi_os_unmap_memory: found map
*<6>[4.054798] acpi_os_unmap_memory: map dropped
*<6>[4.059678] acpi_os_unmap_memory: unlocked
*<6>[  122.761255] acpi_os_map_cleanup: after synchronize_rcu
*<6>[  122.767027] acpi_os_unmap_memory: end
*<6>[  122.771134] After unmap
*<6>[  122.773877] After ACPI_FREE
 <6>[  122.777010] acpi_ut_delete_internal_obj: after setup
 <6>[  122.782576] acpi_ut_update_object_reference: obj:88003c0784c8 type:24
 <6>[  122.790183] acpi_ut_update_ref_count:locked count:1c action:1 flags:282
 <6>[  122.797595] acpi_ut_delete_internal_obj: handler_desc removed
 <6>[  122.804034] acpi_ut_delete_internal_obj: second_desc deleted
 <6>[  122.810376] acpi_ut_delete_internal_obj: object deleted
 <6>[  122.816231] acpi_ns_detach_object: reference removed
Note: The "*" marked acpi_os_unmap_memory() instrumentation messages are
  added by the reporter.

The patch converts RCU synchronization into the deferred executed work
queue item to eliminate the consumed time from the hot path. By doing so,
acpi_os_read_memory()/acpi_os_write_memory() need to hold the reference
count and the RCU locks will then be unnecessary. The original
acpi_ioremap_lock (renamed to acpi_map_lock) must be converted into
spinlock to be used for both the IRQ and the task contexts.
But it is still needed that the map operations are serialized because the
spinlock cannot be held around ioremap(), so that the parallel map
operations can wait for each other instead of inserting duplicated entries
into the acpi_ioremaps. This is achieved by introducing another
acpi_serial_map_mutex. Note that the unmap serialization is not required
due to the reference count protected list removal, thus
acpi_os_unmap_iomem() and acpi_map_relinquish() are not protected by the
acpi_serial_map_mutex.
The test feedback from the reporter:
 "The google reboot stability test passed with your 6 patches. Thanks for
  the help."

Known issues:
1. It is better to use a seperate work queue other than the ACPICA
   dedicated GPE work queue to perform mapping relinquishment. Until a real
   case can be seen on bugzilla.kernel.org complaining this, no further
   improvements are done in this patch.

Signed-off-by: Lv Zheng 
Reported-and-tested-by: Fei Yang 
---
 drivers/acpi/mem.c |   87 ++--
 1 file changed, 58 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/mem.c b/drivers/acpi/mem.c
index c7c35f7..b631007 100644
--- a/drivers/acpi/mem.c
+++ b/drivers/acpi/mem.c
@@ -30,13 +30,13 @@ struct acpi_ioremap {
unsigned long refcount;
 };
 
+/* ioremap() serialization, no need to serialize iounmap() operations */
+static DEFINE_MUTEX(acpi_serial_map_mutex);
+
 static LIST_HEAD(acpi_ioremaps);
-static DEFINE_MUTEX(acpi_ioremap_lock);
+static DEFINE_SPINLOCK(acpi_map_lock);
 
-/*
- * The following functions must be called with 'acpi_ioremap_lock' or RCU
- * read lock held.
- */
+/* The following functions must be called with 'acpi_map_lock' held. */
 static inline void acpi_map_get(struct acpi_ioremap *map)
 {
map->refcount++;
@@ -45,7 +45,7 @@ static inline void acpi_map_get(struct acpi_ioremap *map)
 static inline void acpi_map_put(struct acpi_ioremap *map)
 {
if (!--map->refcount)
-   list_del_rcu(>list);
+   list_del(>list);
 }
 
 static struct acpi_ioremap *
@@ -53,7 +53,7 @@ acpi_map_lookup_phys(acpi_physical_address phys, acpi_size 
size)
 {
struct acpi_ioremap *map;
 
-   list_for_each_entry_rcu(map, _ioremaps, list)
+   list_for_each_entry(map, _ioremaps, list)
if (map->phys <= phys &&
phys + size <= map->phys + map->size)
return map;
@@ -66,7 +66,7 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
 {
struct acpi_ioremap *map;
 
-   list_for_each_entry_rcu(map, _ioremaps, list)
+   list_for_each_entry(map, _ioremaps, list)
if (map->virt <= virt &&
virt + size <= map->virt + map->size)
return map;
@@ -80,6 +80,7 @@ acpi_map2virt(struct acpi_ioremap *map, acpi_physical_address 
phys)
return map ? map->virt + (phys - map->phys) : NULL;
 }
 
+/* The following functions must be called without 'acpi_map_lock' held. */
 #ifndef 

[PATCH 5/6] ACPI/OSL: Cleanup branch logics.

[Lv Zheng]

This patch cleans up trivial branch logics in acpi_os_unmap_iomem() to
eliminate several lines. No functional changes.

Signed-off-by: Lv Zheng 
Tested-by: Fei Yang 
---
 drivers/acpi/mem.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/mem.c b/drivers/acpi/mem.c
index c472237..c7c35f7 100644
--- a/drivers/acpi/mem.c
+++ b/drivers/acpi/mem.c
@@ -194,12 +194,10 @@ void __ref acpi_os_unmap_iomem(void __iomem *virt, 
acpi_size size)
 
mutex_lock(_ioremap_lock);
map = acpi_map_lookup_virt(virt, size);
-   if (!map) {
-   mutex_unlock(_ioremap_lock);
+   if (map)
+   acpi_map_put(map);
+   else
WARN(true, PREFIX "%s: bad address %p\n", __func__, virt);
-   return;
-   }
-   acpi_map_put(map);
mutex_unlock(_ioremap_lock);
 
acpi_map_cleanup(map);
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] ACPI/OSL: Rename system memory functions.

[Lv Zheng]

This patch cleans up system memory functions to make it easier to
understand the meaning of such functions.
No functional cleanup.

Signed-off-by: Lv Zheng 
Tested-by: Fei Yang 
---
 drivers/acpi/mem.c |   38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/mem.c b/drivers/acpi/mem.c
index 722241e..defd317 100644
--- a/drivers/acpi/mem.c
+++ b/drivers/acpi/mem.c
@@ -33,15 +33,23 @@ struct acpi_ioremap {
 static LIST_HEAD(acpi_ioremaps);
 static DEFINE_MUTEX(acpi_ioremap_lock);
 
-static void acpi_os_drop_map_ref(struct acpi_ioremap *map)
+/*
+ * The following functions must be called with 'acpi_ioremap_lock' or RCU
+ * read lock held.
+ */
+static inline void acpi_map_get(struct acpi_ioremap *map)
+{
+   map->refcount++;
+}
+
+static inline void acpi_map_put(struct acpi_ioremap *map)
 {
if (!--map->refcount)
list_del_rcu(>list);
 }
 
-/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
 static struct acpi_ioremap *
-acpi_map_lookup(acpi_physical_address phys, acpi_size size)
+acpi_map_lookup_phys(acpi_physical_address phys, acpi_size size)
 {
struct acpi_ioremap *map;
 
@@ -53,7 +61,6 @@ acpi_map_lookup(acpi_physical_address phys, acpi_size size)
return NULL;
 }
 
-/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
 static struct acpi_ioremap *
 acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
 {
@@ -67,13 +74,12 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
return NULL;
 }
 
-/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
 static void __iomem *
 acpi_map_vaddr_lookup(acpi_physical_address phys, unsigned int size)
 {
struct acpi_ioremap *map;
 
-   map = acpi_map_lookup(phys, size);
+   map = acpi_map_lookup_phys(phys, size);
if (map)
return map->virt + (phys - map->phys);
 
@@ -111,7 +117,7 @@ static void acpi_unmap(acpi_physical_address pg_off, void 
__iomem *vaddr)
iounmap(vaddr);
 }
 
-static void acpi_os_map_cleanup(struct acpi_ioremap *map)
+static void acpi_map_cleanup(struct acpi_ioremap *map)
 {
if (!map->refcount) {
synchronize_rcu();
@@ -126,10 +132,10 @@ void __iomem *acpi_os_get_iomem(acpi_physical_address 
phys, unsigned int size)
void __iomem *virt = NULL;
 
mutex_lock(_ioremap_lock);
-   map = acpi_map_lookup(phys, size);
+   map = acpi_map_lookup_phys(phys, size);
if (map) {
virt = map->virt + (phys - map->phys);
-   map->refcount++;
+   acpi_map_get(map);
}
mutex_unlock(_ioremap_lock);
 
@@ -155,9 +161,9 @@ acpi_os_map_iomem(acpi_physical_address phys, acpi_size 
size)
 
mutex_lock(_ioremap_lock);
/* Check if there's a suitable mapping already. */
-   map = acpi_map_lookup(phys, size);
+   map = acpi_map_lookup_phys(phys, size);
if (map) {
-   map->refcount++;
+   acpi_map_get(map);
goto out;
}
 
@@ -204,10 +210,10 @@ void __ref acpi_os_unmap_iomem(void __iomem *virt, 
acpi_size size)
WARN(true, PREFIX "%s: bad address %p\n", __func__, virt);
return;
}
-   acpi_os_drop_map_ref(map);
+   acpi_map_put(map);
mutex_unlock(_ioremap_lock);
 
-   acpi_os_map_cleanup(map);
+   acpi_map_cleanup(map);
 }
 EXPORT_SYMBOL_GPL(acpi_os_unmap_iomem);
 
@@ -265,15 +271,15 @@ void acpi_os_unmap_generic_address(struct 
acpi_generic_address *gas)
return;
 
mutex_lock(_ioremap_lock);
-   map = acpi_map_lookup(addr, gas->bit_width / 8);
+   map = acpi_map_lookup_phys(addr, gas->bit_width / 8);
if (!map) {
mutex_unlock(_ioremap_lock);
return;
}
-   acpi_os_drop_map_ref(map);
+   acpi_map_put(map);
mutex_unlock(_ioremap_lock);
 
-   acpi_os_map_cleanup(map);
+   acpi_map_cleanup(map);
 }
 EXPORT_SYMBOL(acpi_os_unmap_generic_address);
 
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions

[Mike Galbraith]

On Wed, 2014-10-22 at 21:42 -0400, Rik van Riel wrote: 
> On 10/22/2014 07:20 PM, Mike Turquette wrote:
> > On Wed, Oct 22, 2014 at 1:06 PM, Rik van Riel 
> > wrote: On 10/22/2014 02:07 AM, Mike Turquette wrote:
>  arch_eval_cpu_freq and arch_scale_cpu_freq are added to allow
>  the scheduler to evaluate if cpu frequency should change and
>  to invoke that change from a safe context.
>  
>  They are weakly defined arch functions that do nothing by
>  default. A CPUfreq governor could use these functions to
>  implement a frequency scaling policy based on updates to
>  per-task statistics or updates to per-cpu utilization.
>  
>  As discussed at Linux Plumbers Conference 2014, the goal will
>  be to focus on a single cpu frequency scaling policy that
>  works for everyone. That may mean that the weak arch
>  functions definitions can be removed entirely and a single
>  policy implements that logic for all architectures.
> > 
> > On virtual machines, we probably want to use both frequency and 
> > steal time to calculate the factor.
> > 
> >> You mean for calculating desired cpu frequency on a virtual
> >> guest? Is that something we want to do?
> 
> A guest will be unable to set the cpu frequency, but it should
> know what the frequency is, so it can take the capacity of each
> CPU into account when doing things like load balancing.

Hm.  Why does using vaporite freq/capacity/whatever make any sense, the
silicon under the V(aporite)PU can/does change at the drop of a hat, no?

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] ACPI/OSL: Rework of ACPICA memory OSLs to improve performance.

[Lv Zheng]

It is reported that there is a performance issue in the ACPICA OSL
implementation around memory mappings.

On the reported platforms, there is a debugging facility implemented in the
ACPI namespace using circular logging buffer:
Name (DPTR, 0x3AFEB000)
Name (EPTR, 0x3AFFB000)
Name (CPTR, 0x3AFEB010)
Mutex (MMUT, 0x00)
Method (MDBG, 1, Serialized)
{
Store (Acquire (MMUT, 0x03E8), Local0)
If (Local0 == Zero)
{
OperationRegion (ABLK, SystemMemory, CPTR, 0x10)
Field (ABLK, ByteAcc, NoLock, Preserve)
{
,   128
}
Store (Arg0, ) /* \MDBG. */
CPTR = (CPTR + 0x10) /* \CPTR */
If (CPTR >= EPTR)
{
CPTR = (DPTR + 0x10) /* \CPTR */
}
Release (MMUT)
}
Return (Local0)
}
This function is heavily invoked by other ACPI control methods.
The reported platforms suffer from 2-5 minutes kernel stuck in the end of
accessing the mapped circular buffer system memory region. By
instrumentation, the 2-5 minutes time consumption overhead can be seen to
happen on the synchronize_rcu() invoked in the acpi_os_unmap_memory().

This patchset removes the synchronize_rcu() from the hot path to improve
the performance.

Lv Zheng (6):
  ACPI/OSL: Split memory operation region implementations to a seperate
file.
  ACPI/OSL: Rename system memory functions.
  ACPI/OSL: Cleanup memory access functions by merging duplicate code.
  ACPI/OSL: Add acpi_map2virt() to merge duplicate code.
  ACPI/OSL: Cleanup branch logics.
  ACPI/OSL: Fix performance issue in system memory lockings.

 drivers/acpi/Makefile |2 +-
 drivers/acpi/mem.c|  414 +
 drivers/acpi/osl.c|  381 -
 3 files changed, 415 insertions(+), 382 deletions(-)
 create mode 100644 drivers/acpi/mem.c

-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] ACPI/OSL: Cleanup memory access functions by merging duplicate code.

[Lv Zheng]

This patch merges duplicate code to cleanup ACPI memory access
implementations. No functional changes.

Signed-off-by: Lv Zheng 
Tested-by: Fei Yang 
---
 drivers/acpi/mem.c |   13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/mem.c b/drivers/acpi/mem.c
index defd317..ba74086 100644
--- a/drivers/acpi/mem.c
+++ b/drivers/acpi/mem.c
@@ -260,7 +260,6 @@ EXPORT_SYMBOL(acpi_os_map_generic_address);
 void acpi_os_unmap_generic_address(struct acpi_generic_address *gas)
 {
u64 addr;
-   struct acpi_ioremap *map;
 
if (gas->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY)
return;
@@ -270,16 +269,8 @@ void acpi_os_unmap_generic_address(struct 
acpi_generic_address *gas)
if (!addr || !gas->bit_width)
return;
 
-   mutex_lock(_ioremap_lock);
-   map = acpi_map_lookup_phys(addr, gas->bit_width / 8);
-   if (!map) {
-   mutex_unlock(_ioremap_lock);
-   return;
-   }
-   acpi_map_put(map);
-   mutex_unlock(_ioremap_lock);
-
-   acpi_map_cleanup(map);
+   acpi_os_unmap_iomem((void __iomem *)((unsigned long)addr),
+   gas->bit_width / 8);
 }
 EXPORT_SYMBOL(acpi_os_unmap_generic_address);
 
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] Staging: iio: adc: fix line over 80 characters

[Brian Vandre]

On Thu, Oct 23, 2014 at 01:47:37AM +0200, Hartmut Knaack wrote:
> Sudip Mukherjee schrieb am 22.10.2014 06:21:
> > On Tue, Oct 21, 2014 at 05:56:47PM -0500, Brian Vandre wrote:
> >> This fixes the 2 checkpatch.pl warnings:
> >> WARNING: line over 80 characters
> >>
> > please check your patch with --strict option of checkpatch.pl , and you 
> > will get :
> > "Alignment should match open parenthesis" .
> > 
> Good point, but what solution would you propose?

Hey All,

Thanks for all the feedback.  This is my first attempt at a patch so I thank 
you all
for helping me through it.  I have a question about the strict option on 
checkpatch.pl.
I thought that the stict option was not necessarily part of the coding 
standards but
more of a nice to have.  Should I be always using the strict option?

On this particular patch if I were to align to the open parenthesis it would 
push the
comment "/* trigger DELAY unit#3 */" off to the next line which I thought we be 
less
clear.  If --strict is optional then I would argue to leave it the way it is, 
but again
this is my first time and I am learning.

If I were to align to the parenthesis should I just move the comment to the 
next line
or possibly delete the comment altogether?  The code is clear and the comment 
might not
be necessary but I didn't want to remove anything the original author wrote.

Thanks,
Brian Vandre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sysctl: terminate strings also on \r

[Andrew Morton]

On Wed, 22 Oct 2014 16:43:10 -0700 Kees Cook  wrote:

> On Wed, Oct 22, 2014 at 4:26 PM, Andrew Morton
>  wrote:
> > On Tue, 21 Oct 2014 13:21:37 -0700 Kees Cook  wrote:
> >
> >> From: Paul Wise 
> >>
> >> This partially mitigates a common strategy used by attackers for hiding
> >> the full contents of strings in procfs from naive sysadmins who use cat,
> >> more or sysctl to inspect the contents of strings in procfs.
> >>
> >> ...
> >>
> >> --- a/kernel/sysctl.c
> >> +++ b/kernel/sysctl.c
> >> @@ -1739,7 +1739,7 @@ static int _proc_do_string(char *data, int maxlen, 
> >> int write,
> >>   while ((p - buffer) < *lenp && len < maxlen - 1) {
> >>   if (get_user(c, p++))
> >>   return -EFAULT;
> >> - if (c == 0 || c == '\n')
> >> + if (c == 0 || c == '\n' || c == '\r')
> >>   break;
> >>   data[len++] = c;
> >>   }
> >
> > There are no valid uses of \r in a procfs write?
> 
> I struggle to imagine one; everything I found that uses proc_dostring
> seems to be names, paths, and commands.
> 

You're insufficiently pessimistic.

I wonder if the chances of damage would be lower if we were to continue
to accept the \r, but turn it into something else ("\r"?) when it is
read.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks

[Martin K. Petersen]

> "Sitsofe" == Sitsofe Wheeler  writes:

Sitsofe> 2. On top of the above, when a disk is "small" (has less than
Sitsofe>2^32 sectors which is typically < 2 TBytes in size) READ
Sitsofe>CAPACITY(16) won't be triggered.

static int sd_try_rc16_first(struct scsi_device *sdp)
{
if (sdp->host->max_cmd_len < 16)
return 0;
if (sdp->try_rc_10_first)
return 0;
if (sdp->scsi_level > SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
return 1;
return 0;
}

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag

[Martin K. Petersen]

> "Sitsofe" == Sitsofe Wheeler  writes:

>> Last time around we identified this as a problem with Microsoft's
>> interpretation of the T10 SBC spec. And they promised that they are
>> going to fix that.

Sitsofe> OK but if we were happy to wait for Microsoft to fix the
Sitsofe> problem on the host why were the (broken and incomplete)
Sitsofe> BLIST_SKIP_VPD_PAGES patches committed to 3.17 rather than
Sitsofe> withdrawn? What's going to be done about those patches now?

There are two orthogonal problems. One being that the driver advertised
conformance to an old SCSI spec. That's being addressed with the
separate SPC-3 patch.

The other issue is that thin provisioning is being incorrectly
advertised. Because that's being addressed by Microsoft and is an
isolated use case I'm hesitant to add quirk for it. Whereas I know
several other devices that will benefit from the TRY_VPD_PAGES blacklist
option.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions

[Rik van Riel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/22/2014 07:20 PM, Mike Turquette wrote:
> On Wed, Oct 22, 2014 at 1:06 PM, Rik van Riel 
> wrote: On 10/22/2014 02:07 AM, Mike Turquette wrote:
 arch_eval_cpu_freq and arch_scale_cpu_freq are added to allow
 the scheduler to evaluate if cpu frequency should change and
 to invoke that change from a safe context.
 
 They are weakly defined arch functions that do nothing by
 default. A CPUfreq governor could use these functions to
 implement a frequency scaling policy based on updates to
 per-task statistics or updates to per-cpu utilization.
 
 As discussed at Linux Plumbers Conference 2014, the goal will
 be to focus on a single cpu frequency scaling policy that
 works for everyone. That may mean that the weak arch
 functions definitions can be removed entirely and a single
 policy implements that logic for all architectures.
> 
> On virtual machines, we probably want to use both frequency and 
> steal time to calculate the factor.
> 
>> You mean for calculating desired cpu frequency on a virtual
>> guest? Is that something we want to do?

A guest will be unable to set the cpu frequency, but it should
know what the frequency is, so it can take the capacity of each
CPU into account when doing things like load balancing.

This has little impact on this patch series, the impact is more
in the load balancer, which can see how much compute capacity is
available on each CPU, and adjust the load accordingly.

I have seen some code come by that adjusts each cpu's compute_capacity,
but do not remember whether it looks at cpu frequency, and am pretty
sure it does not look at steal time currently :)

- -- 
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUSF0DAAoJEM553pKExN6DYgkIALSZxKxQhMAJl0VUrBtPEFlr
cXOr0jKS/0FowS22agzpJr/OoWi58mGGm6mKr6LkoZJ34K96Y6/H4ie7Sr7Q4BL/
A4hQpTwxHzGasawQwdQOG/lW2q2oDUqsQuxRQDOs97I4vtYwxsj+D3qDtfIyaosf
f7ctWDQMzBBgLlrDn1wWmDE6K1pxa2eqnf0rRVSRNRXQ/lncHHzPdFOj4sJE9RVQ
E47gqeisDf+m7TyvG1I9MN6ZIHMEfgaQcmVvO8/QGqnb1ZMom6JTCDa4UqAd97XB
1NQ/QSJvQ5ED/cCfLy91YguEr/GY+QFsKeCjL1604e+3lsN4DjuejtcUP9/LQVs=
=On7B
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH resend] ARM: perf: remove useless return and check of idx in counter handling

[Chai Wen]

On 10/22/2014 08:31 PM, Mark Rutland wrote:

> On Wed, Oct 22, 2014 at 01:16:49PM +0100, chai wen wrote:
>> Idx sanity check was once implemented separately in these counter
>> handling functions and then return value was treated as a judgement.
>>  armv7_pmnc_select_counter()
>>  armv7_pmnc_enable_counter()
>>  armv7_pmnc_disable_counter()
>>  armv7_pmnc_enable_intens()
>>  armv7_pmnc_disable_intens()
>> But we do not need to do this now, as idx validation check was moved
>> out all these functions by commit 7279adbd9bb8ef8f(ARM: perf: check ARMv7
>> counter validity on a per-pmu basis).
>> Let's remove the useless return of idx from these functions.
> 
> In future when you fix up a patch, please send as "PATCHv2" (or v3, etc
> as appropriate), and only as "PATCH RESEND" if there are no changes. It
> makes it far easier to keep track of the stat of the patch. Don't worry
> about sending again this time, however.
> 


Thanks a lot for your exact description about difference between 'resend' and 
'v1..v2..'.
(Sincerely speaking, I did not know the true meaning of the 'resend', although
I have done the 'resend' for times before :( )
Will follow up this in the future.

> Thanks for fixing up the braces since v1; this looks good to me.
> 



thanks
chai wen

> Mark.
> 
>>
>> Acked-by: Mark Rutland 
>> Signed-off-by: chai wen 
>> ---
>>  arch/arm/kernel/perf_event_v7.c |   40 
>> +-
>>  1 files changed, 18 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm/kernel/perf_event_v7.c 
>> b/arch/arm/kernel/perf_event_v7.c
>> index 116758b..aaf5314 100644
>> --- a/arch/arm/kernel/perf_event_v7.c
>> +++ b/arch/arm/kernel/perf_event_v7.c
>> @@ -564,13 +564,11 @@ static inline int 
>> armv7_pmnc_counter_has_overflowed(u32 pmnc, int idx)
>>  return pmnc & BIT(ARMV7_IDX_TO_COUNTER(idx));
>>  }
>>  
>> -static inline int armv7_pmnc_select_counter(int idx)
>> +static inline void armv7_pmnc_select_counter(int idx)
>>  {
>>  u32 counter = ARMV7_IDX_TO_COUNTER(idx);
>>  asm volatile("mcr p15, 0, %0, c9, c12, 5" : : "r" (counter));
>>  isb();
>> -
>> -return idx;
>>  }
>>  
>>  static inline u32 armv7pmu_read_counter(struct perf_event *event)
>> @@ -580,13 +578,15 @@ static inline u32 armv7pmu_read_counter(struct 
>> perf_event *event)
>>  int idx = hwc->idx;
>>  u32 value = 0;
>>  
>> -if (!armv7_pmnc_counter_valid(cpu_pmu, idx))
>> +if (!armv7_pmnc_counter_valid(cpu_pmu, idx)) {
>>  pr_err("CPU%u reading wrong counter %d\n",
>>  smp_processor_id(), idx);
>> -else if (idx == ARMV7_IDX_CYCLE_COUNTER)
>> +} else if (idx == ARMV7_IDX_CYCLE_COUNTER) {
>>  asm volatile("mrc p15, 0, %0, c9, c13, 0" : "=r" (value));
>> -else if (armv7_pmnc_select_counter(idx) == idx)
>> +} else {
>> +armv7_pmnc_select_counter(idx);
>>  asm volatile("mrc p15, 0, %0, c9, c13, 2" : "=r" (value));
>> +}
>>  
>>  return value;
>>  }
>> @@ -597,45 +597,43 @@ static inline void armv7pmu_write_counter(struct 
>> perf_event *event, u32 value)
>>  struct hw_perf_event *hwc = >hw;
>>  int idx = hwc->idx;
>>  
>> -if (!armv7_pmnc_counter_valid(cpu_pmu, idx))
>> +if (!armv7_pmnc_counter_valid(cpu_pmu, idx)) {
>>  pr_err("CPU%u writing wrong counter %d\n",
>>  smp_processor_id(), idx);
>> -else if (idx == ARMV7_IDX_CYCLE_COUNTER)
>> +} else if (idx == ARMV7_IDX_CYCLE_COUNTER) {
>>  asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (value));
>> -else if (armv7_pmnc_select_counter(idx) == idx)
>> +} else {
>> +armv7_pmnc_select_counter(idx);
>>  asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" (value));
>> +}
>>  }
>>  
>>  static inline void armv7_pmnc_write_evtsel(int idx, u32 val)
>>  {
>> -if (armv7_pmnc_select_counter(idx) == idx) {
>> -val &= ARMV7_EVTYPE_MASK;
>> -asm volatile("mcr p15, 0, %0, c9, c13, 1" : : "r" (val));
>> -}
>> +armv7_pmnc_select_counter(idx);
>> +val &= ARMV7_EVTYPE_MASK;
>> +asm volatile("mcr p15, 0, %0, c9, c13, 1" : : "r" (val));
>>  }
>>  
>> -static inline int armv7_pmnc_enable_counter(int idx)
>> +static inline void armv7_pmnc_enable_counter(int idx)
>>  {
>>  u32 counter = ARMV7_IDX_TO_COUNTER(idx);
>>  asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r" (BIT(counter)));
>> -return idx;
>>  }
>>  
>> -static inline int armv7_pmnc_disable_counter(int idx)
>> +static inline void armv7_pmnc_disable_counter(int idx)
>>  {
>>  u32 counter = ARMV7_IDX_TO_COUNTER(idx);
>>  asm volatile("mcr p15, 0, %0, c9, c12, 2" : : "r" (BIT(counter)));
>> -return idx;
>>  }
>>  
>> -static inline int armv7_pmnc_enable_intens(int idx)
>> +static inline void armv7_pmnc_enable_intens(int idx)
>>  {
>>  u32 counter = ARMV7_IDX_TO_COUNTER(idx);
>>  asm volatile("mcr p15, 0, %0, c9, c14, 1" : : 

linux-next: build warning after merge of the block tree

[Stephen Rothwell]

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

block/scsi_ioctl.c: In function 'sg_scsi_ioctl':
block/scsi_ioctl.c:520:1: warning: label 'out' defined but not used 
[-Wunused-label]
 out:
 ^

Introduced by commit 374f8fdea4aa ("scsi: Fix error handling in 
SCSI_IOCTL_SEND_COMMAND").
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

RE: [PATCH v8 00/13] input: cyapa: intruction of cyapa patches

[Dudley Du]

Hi Dmitry,

It has been long time after the v8 patches submitted, with your busy time, 
could you help take a little time to update the status of the schedule or 
reviews?
Any information will halp a lot.

Thanks,
Dudley

> -Original Message-
> From: Dudley Du
> Sent: 2014?10?20? 9:16
> To: 'Dudley Du'; dmitry.torok...@gmail.com; rydb...@euromail.se
> Cc: ble...@google.com; patr...@google.com; linux-in...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 00/13] input: cyapa: intruction of cyapa patches
>
> Hi Dmitry,
>
> Is there any update on the v8 patchs for input cyapa trackpad drivers?
>
> Thanks,
> Dudley
>
> > -Original Message-
> > From: Dudley Du [mailto:dudley.duli...@gmail.com]
> > Sent: 2014?10?15? 15:19
> > To: dmitry.torok...@gmail.com; rydb...@euromail.se
> > Cc: Dudley Du; ble...@google.com; patr...@google.com;
> > linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH 00/13] input: cyapa: intruction of cyapa patches
> >
> > Based on Dmitry's comments, I made v8 patches of cyapa trackpad device
> > with below updates compared with v7 patches:
> > 1) [PATCH v8 01/13] - Remove the async thread for device detect in
> >proble routine, now the device detect process is completly done within
> >the device proble routine.
> > 2) [PATCH v8 01/13] - Split the irq cmd hander function to separated
> >function cyapa_default_irq_cmd_handler() and set it to interface
> >cyapa_default_ops.irq_cmd_handler.
> > 3) [PATCH v8 06/13] - Add cyapa->gen check in cyapa_gen3_irq_cmd_handler()
> >to avoid miss-enter when device protocol is still in detecting.
> >
> >
> > V7 patches have below updates compared with v6 patches:
> > 1) [PATCH v7 01/13] - Split the irq cmd hander function to separated
> >function cyapa_default_irq_cmd_handler() and set it to interface
> >cyapa_default_ops.irq_cmd_handler.
> > 2) [PATCH v7 06/13] - Add cyapa->gen check in cyapa_gen3_irq_cmd_handler()
> >to avoid miss-enter when device protocol is still in detecting.
> >
> >
> > V6 patches have below updates compared with v5 patches:
> > 1) Remove patch 14 of the lid filtering from the cyapa driver.
> >
> > V5 patches have below updates compared with v4 patches:
> > 1) Uses get_device()/put_device() instead of kobject_get()/kobject_put();
> > 2) Fix memories freed before debugfs entries issue;
> > 3) Make cyapa_debugs_root valid in driver module level
> >in module_init()/moudle_exit() ;
> > 4) Fix i2c_transfer() may return partial transfer issues.
> > 5) Add cyapa->removed flag to avoid detecting thread may still running
> >when driver module is removed.
> > 6) Fix the meanings of some comments and return error code not clear issue.
> >
> > This patch set is aimed to re-architecture the cyapa driver to support
> > old gen3 trackpad device and new gen5 trackpad device in one
> > cyapa driver for easily productions support based on
> > customers' requirements, and add sysfs functions and interfaces
> > supported that required by users and customers.
> > Because the earlier gen3 and the latest gen5 trackpad devies using
> > two different chipsets, and have different protocol and interfaces.
> > If supported these two trackpad devices in two different drivers, then
> > it will be difficult to manage productions and later firmware updates.
> > it will cause customer don't know which one to use and update
> > because these two trackpad devices have been used and integrated
> > in same one productions at a time, so must to support these two trackpad
> > devices in same on driver.
> >
> > The new architecture is made of:
> > cyapa.c - the core of the architecture, supply interfaces and
> > functions to system and read trackpad devices.
> > cyapa.h - header file including macros and data structure definitions.
> > cyapa_gen3.c - functions support for gen3 trackpad devices,
> > cyapa_gen5.c - functions support for gen5 trackpad devices.
> >
> > Beside this introduction patch, it has 14 patches listed as below.
> > For these patches each one is patched based on previous one.
> >
> > patch 1/13: re-architecture cyapa driver with core functions,
> > and applying the device detecting function in async thread to speed
> > up system boot time.
> >
> > patch 2/13: add cyapa driver power management interfaces support.
> >
> > patch 3/13: add cyapa driver runtime power management interfaces support.
> >
> > patch 4/13: add cyapa key function interfaces in sysfs system.
> > Including read firmware version, get production ID, read baseline,
> > re-calibrate trackpad baselines and do trackpad firmware update.
> >
> > patch 5/13: add read firmware image and read raw trackpad device'
> > sensors' raw data interface in debugfs system.
> >
> > patch 6/13: add gen3 trackpad device basic functions support.
> >
> > patch 7/13: add gen3 trackpad device firmware update function support.
> >
> > patch 8/13: add gen3 trackpad device report baseline and do force
> > 

Re: btrfs: WARN_ON(data_sinfo->bytes_may_use < bytes);

[Dave Jones]

On Wed, Oct 22, 2014 at 09:07:31PM -0400, Dave Jones wrote:
 > Just hit this while running trinity.
 > 
 > WARNING: CPU: 3 PID: 9612 at fs/btrfs/extent-tree.c:3799 
 > btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]()
 > Modules linked in: rfcomm hidp bnep af_key llc2 scsi_transport_iscsi 
 > nfnetlink sctp libcrc32c can_raw can_bcm nfc caif_socket caif af_802154 
 > ieee802154 phonet af_rxrpc bluetooth can pppoe pppox ppp_generic slhc irda 
 > crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 
 > cfg80211 rfkill btrfs xor coretemp hwmon x86_pkg_temp_thermal kvm_intel 
 > snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic kvm 
 > crct10dif_pclmul crc32c_intel ghash_clmulni_intel raid6_pq snd_hda_intel 
 > microcode snd_hda_controller pcspkr snd_hda_codec serio_raw snd_hwdep 
 > snd_seq snd_seq_device usb_debug snd_pcm e1000e ptp shpchp pps_core 
 > snd_timer snd soundcore
 > CPU: 3 PID: 9612 Comm: trinity-c85 Not tainted 3.18.0-rc1+ #74
 >  0009 9989d5b8 88018a337ba8 af86cc97
 >    88018a337be8 af07f301
 >  88022ddf8d40 88023f799148 7fbbf000 88009c2b59c8
 > Call Trace:
 >  [] dump_stack+0x4f/0x7c
 >  [] warn_slowpath_common+0x81/0xa0
 >  [] warn_slowpath_null+0x1a/0x20
 >  [] btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]
 >  [] btrfs_delalloc_release_space+0x22/0x30 [btrfs]
 >  [] btrfs_direct_IO+0x33b/0x350 [btrfs]
 >  [] ? btrfs_page_exists_in_range+0x2c0/0x2c0 [btrfs]
 >  [] ? btrfs_real_readdir+0x5e0/0x5e0 [btrfs]
 >  [] generic_file_direct_write+0xc4/0x1a0
 >  [] btrfs_file_write_iter+0x186/0x560 [btrfs]
 >  [] new_sync_write+0x8e/0xd0
 >  [] vfs_write+0xba/0x1f0
 >  [] ? __fget_light+0xbe/0xe0
 >  [] SyS_pwrite64+0x92/0xc0
 >  [] tracesys_phase2+0xd4/0xd9

I also see this WARN_ON being hit from the sync path..

WARNING: CPU: 2 PID: 11166 at fs/btrfs/extent-tree.c:3799 
btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]()
CPU: 2 PID: 11166 Comm: trinity-c61 Tainted: GW  3.18.0-rc1+ #74
 0009 aee2e4e2 8801b0dfbcc8 8d86cc97
   8801b0dfbd08 8d07f301
 88023f328000 88023953d668 0004 880239358548
Call Trace:
 [] dump_stack+0x4f/0x7c
 [] warn_slowpath_common+0x81/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]
 [] btrfs_write_dirty_block_groups+0x6f3/0x740 [btrfs]
 [] commit_cowonly_roots+0x17a/0x234 [btrfs]
 [] btrfs_commit_transaction+0x45b/0xc10 [btrfs]
 [] btrfs_sync_fs+0x8b/0x270 [btrfs]
 [] ? do_fsync+0x80/0x80
 [] sync_fs_one_sb+0x20/0x30
 [] iterate_supers+0xb2/0x110
 [] sys_sync+0x64/0xb0
 [] tracesys_phase2+0xd4/0xd9

After rebooting, and restarting the fuzzer, it happened again very quickly.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 24/27] IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq

[Yijing Wang]

On 2014/10/23 7:53, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
> 
> This needs slightly more detail.  You're using the MSI chip framework
> "instead of arch MSI functions".  Well, there are still arch-specific
> functions, i.e., arch_ia64_setup_msi_irq() and
> arch_ia64_teardown_msi_irq().
> 
> We used to have arch_setup_msi_irq() which had a weak default
> implementation, and a strong arch-specific implementation here, and you're
> replacing that model with the new "msi-ops" model.  I don't know how you
> want to write that, but it's not that you're getting rid of the
> arch-specific code; you're keeping arch-specific code but structuring it
> differently.

Hm, I will rename the msi-ops functions.

> 
>> Signed-off-by: Yijing Wang 
>> ---
>>  arch/ia64/include/asm/pci.h |   10 ++
>>  arch/ia64/kernel/msi_ia64.c |   14 ++
>>  arch/ia64/pci/pci.c |1 +
>>  3 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
>> index 52af5ed..907dcba 100644
>> --- a/arch/ia64/include/asm/pci.h
>> +++ b/arch/ia64/include/asm/pci.h
>> @@ -94,6 +94,7 @@ struct pci_controller {
>>  int segment;
>>  int node;   /* nearest node with memory or NUMA_NO_NODE for 
>> global allocation */
>>  
>> +struct msi_chip *msi_chip;
>>  void *platform_data;
>>  };
>>  
>> @@ -101,6 +102,15 @@ struct pci_controller {
>>  #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)
>>  #define pci_domain_nr(busdev)(PCI_CONTROLLER(busdev)->segment)
>>  
>> +extern struct msi_chip chip;
> 
> Please make this name more descriptive.  "chip" is way too generic for a
> global name.

OK, what about rename it to ia64_msi_chip, and rename the original static 
irq_chip ia64_msi_chip to
static irq_chip msi_chip like in x86.

> 
>> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
>> +{
>> +struct pci_controller *ctrl = bus->sysdata;
>> +
>> +return ctrl->msi_chip;
>> +}
>> +
>>  extern struct pci_ops pci_root_ops;
>>  
>>  static inline int pci_proc_domain(struct pci_bus *bus)
>> diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
>> index 8c3730c..401fc98 100644
>> --- a/arch/ia64/kernel/msi_ia64.c
>> +++ b/arch/ia64/kernel/msi_ia64.c
>> @@ -112,15 +112,16 @@ static struct irq_chip ia64_msi_chip = {
>>  };
>>  
>>  
>> -int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
>> +static int arch_ia64_setup_msi_irq(struct msi_chip *chip,
>> +struct pci_dev *dev, struct msi_desc *desc)
>>  {
>>  if (platform_setup_msi_irq)
>> -return platform_setup_msi_irq(pdev, desc);
>> +return platform_setup_msi_irq(dev, desc);
>>  
>> -return ia64_setup_msi_irq(pdev, desc);
>> +return ia64_setup_msi_irq(dev, desc);
> 
> Please don't make gratuitous changes ("pdev" -> "dev") at the same time,
> especially since the rest of the file still uses "pdev".

OK.

> 
>>  }
>>  
>> -void arch_teardown_msi_irq(unsigned int irq)
>> +static void arch_ia64_teardown_msi_irq(struct msi_chip *chip, unsigned int 
>> irq)
>>  {
>>  if (platform_teardown_msi_irq)
>>  return platform_teardown_msi_irq(irq);
>> @@ -128,6 +129,11 @@ void arch_teardown_msi_irq(unsigned int irq)
>>  return ia64_teardown_msi_irq(irq);
>>  }
>>  
>> +struct msi_chip chip = {
>> +.setup_irq = arch_ia64_setup_msi_irq,
>> +.teardown_irq = arch_ia64_teardown_msi_irq,
>> +};
>> +
>>  #ifdef CONFIG_INTEL_IOMMU
>>  #ifdef CONFIG_SMP
>>  static int dmar_msi_set_affinity(struct irq_data *data,
>> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
>> index 291a582..299b67d 100644
>> --- a/arch/ia64/pci/pci.c
>> +++ b/arch/ia64/pci/pci.c
>> @@ -437,6 +437,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
>> *root)
>>  
>>  controller->companion = device;
>>  controller->node = acpi_get_node(device->handle);
>> +controller->msi_chip = 
>>  
>>  info = kzalloc(sizeof(*info), GFP_KERNEL);
>>  if (!info) {
>> -- 
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> .
> 


-- 
Thanks!
Yijing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: dw_mmc: Remove old card detect infrastructure

[Jaehoon Chung]

Dear, Doug.

On 10/23/2014 01:36 AM, Doug Anderson wrote:
> Hi,
> 
> On Sun, Oct 19, 2014 at 8:23 PM, Jaehoon Chung  wrote:
>> Hi.
>>
>> On 10/17/2014 09:44 PM, Alim Akhtar wrote:
>>> Hi Doug,
>>>
>>> On Thu, Oct 16, 2014 at 9:40 PM, Doug Anderson  
>>> wrote:
 Alim,

 On Thu, Oct 16, 2014 at 5:57 AM, Alim Akhtar  wrote:
> Hi Doug,
>
> On Tue, Oct 14, 2014 at 10:03 PM, Doug Anderson  
> wrote:
>> The dw_mmc driver had a bunch of code that ran whenever a card was
>> ejected and inserted.  However, this code was old and crufty and
>> should be removed.  Some evidence that it's really not needed:
>>
>> 1. Is is supposed to be legal to use 'cd-gpio' on dw_mmc instead of
>>using the built-in card detect mechanism.  The 'cd-gpio' code
>>doesn't run any of the crufty old code but yet still works.
>>
>> 2. While looking at this, I realized that my old change (369ac86 mmc:
>>dw_mmc: don't queue up a card detect at slot startup) actually
>>castrated the old code a little bit already and nobody noticed.
>>Specifically "last_detect_state" was left as 0 at bootup.  That
>>means that on the first card removal none of the crufty code ran.
>>
> Yes, right most of these codes are _almost_ never call. But I see
> dw_mci_reset() being called on card removal (after first
> insert/removal).

 Right.  The old crufty code was called on the 2nd removal, not the
 1st.  That meant that the two were accidentally different.  My point
 was that if the old code was really required that someone would have
 noticed crashes on the 1st removal after each boot.  Since nobody is
 reporting crashes with that then it means it can't be too terrible.

 One thing to note: I remember in the last Chromebook project you were
 trying to track down crashes associated with constant eject / insert
 of SD Cards.  I wonder if my patch will fix these crashes?

>>> Ah, yes, reproducing that and checking with this patch will be really
>>> interesting.
>>>

> I tested this on exynos5800 and this looks working fine. We need to
> test once cross suspend/resume as well.

 Good idea.  Can you test that?  I know that there's been lots of flux
 with suspend/resume on exynos and I'm not sure I have all the latest
 patches, but I'll search for them if you are unable to test easily.

>>> Sure, I will do that..but probably sometime next week, as I will out
>>> of office for few days.

> And as Jaehoon pointed out,probably lets look in TRM if there are some
> recommended  steps for cd-detect.
> Otherwise this looks good to me.

 If you see some other requirement than the one I addressed in my email
 to Jaehoon, please let me know.
>>
>> I know there is no other requirement for detecting card.
>> So this patch can be applied after testing the above case(suspend/resume).
> 
> I put a kernel based upon 3.17 on an exynos5250-snow (specifically
> git://git.collabora.co.uk/git/user/javier/linux.git branch
> max77802-op-modes-v3, git hash 98cf5a0).  Snow uses the builtin card
> detect on dw_mmc.  Resume wasn't terribly reliable to start with even
> without my patch (it often woke up right after suspend), but it worked
> well enough for testing.  I tested the following scenarios:
> 
> 1. Leave card in and mounted.  Suspend/resume.  Card is still usable
> after resume
> 
> 2. Suspend and insert card.  Resume.  Card is detected upon resume.
> 
> 3. Suspend and remove card.  Resume.  Card is removed upon resume.
> 
> How does that sound?

I think these test cases are enough, and if it's working fine, sounds good.

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> 
> -Doug
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kbuild: Fix output of make kernelrelease

[Steven Rostedt]

On Wed, 22 Oct 2014 21:44:08 +0200
Michal Marek  wrote:

> Dne 22.10.2014 v 16:19 Steven Rostedt napsal(a):
> > 
> > Commit 7ff525712acf "kbuild: fake the "Entering directory ..." message
> > more simply" changed the output of "make kernelrelease" such that the
> > kernel release version was not the last line printed. This broke various
> > tools that would find the kernel release with "make kernelrelease | tail 
> > -1".
> 
> The cleaner and recommended (see recent make help) way is to use make -s:
> 
> $ make O=build -s kernelrelease
> 3.18.0-rc1+
> 
> no further processing is needed.


I don't mind changing my script with your patch. But this does break
other scripts of mine that I need to hunt down and change. My fear is
why do we need the '-s' when there may be other methods to preserve the
old functionality.

If this is breaking my scripts, I wonder if it is also breaking other
scripts out there too? As you stated, it wasn't until recently that the
help message recommended the '-s'.

-- Steve


> 
> 
> > One of those tools that broke was ktest.pl which resides in the kernel.
> 
> Can you please apply this patch?
> 
> Thanks,
> Michal
> 
> >From c660b235e25eee053337e0e6c952e87f39839c63 Mon Sep 17 00:00:00 2001
> From: Michal Marek 
> Date: Wed, 22 Oct 2014 21:25:39 +0200
> Subject: [PATCH] ktest: Use make -s kernelrelease
> 
> The previous tail -1 broke with commit 7ff525712acf ("kbuild: fake the
> "Entering directory ..." message more simply")
> 
> Reported-by: Steven Rostedt 
> Signed-off-by: Michal Marek 
> ---
>  tools/testing/ktest/ktest.pl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> index bf13981..60fe020 100755
> --- a/tools/testing/ktest/ktest.pl
> +++ b/tools/testing/ktest/ktest.pl
> @@ -2005,7 +2005,7 @@ sub get_version {
>  # get the release name
>  return if ($have_version);
>  doprint "$make kernelrelease ... ";
> -$version = `$make kernelrelease | tail -1`;
> +$version = `$make -s kernelrelease`;
>  chomp($version);
>  doprint "$version\n";
>  $have_version = 1;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

btrfs: WARN_ON(data_sinfo->bytes_may_use < bytes);

[Dave Jones]

Just hit this while running trinity.

WARNING: CPU: 3 PID: 9612 at fs/btrfs/extent-tree.c:3799 
btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]()
Modules linked in: rfcomm hidp bnep af_key llc2 scsi_transport_iscsi nfnetlink 
sctp libcrc32c can_raw can_bcm nfc caif_socket caif af_802154 ieee802154 phonet 
af_rxrpc bluetooth can pppoe pppox ppp_generic slhc irda crc_ccitt rds rose x25 
atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 rfkill btrfs xor 
coretemp hwmon x86_pkg_temp_thermal kvm_intel snd_hda_codec_realtek 
snd_hda_codec_hdmi snd_hda_codec_generic kvm crct10dif_pclmul crc32c_intel 
ghash_clmulni_intel raid6_pq snd_hda_intel microcode snd_hda_controller pcspkr 
snd_hda_codec serio_raw snd_hwdep snd_seq snd_seq_device usb_debug snd_pcm 
e1000e ptp shpchp pps_core snd_timer snd soundcore
CPU: 3 PID: 9612 Comm: trinity-c85 Not tainted 3.18.0-rc1+ #74
 0009 9989d5b8 88018a337ba8 af86cc97
   88018a337be8 af07f301
 88022ddf8d40 88023f799148 7fbbf000 88009c2b59c8
Call Trace:
 [] dump_stack+0x4f/0x7c
 [] warn_slowpath_common+0x81/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]
 [] btrfs_delalloc_release_space+0x22/0x30 [btrfs]
 [] btrfs_direct_IO+0x33b/0x350 [btrfs]
 [] ? btrfs_page_exists_in_range+0x2c0/0x2c0 [btrfs]
 [] ? btrfs_real_readdir+0x5e0/0x5e0 [btrfs]
 [] generic_file_direct_write+0xc4/0x1a0
 [] btrfs_file_write_iter+0x186/0x560 [btrfs]
 [] new_sync_write+0x8e/0xd0
 [] vfs_write+0xba/0x1f0
 [] ? __fget_light+0xbe/0xe0
 [] SyS_pwrite64+0x92/0xc0
 [] tracesys_phase2+0xd4/0xd9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/