Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods

[Jean-Christophe PLAGNIOL-VILLARD]

> On Feb 9, 2015, at 10:50 PM, Jean-Christophe PLAGNIOL-VILLARD 
>  wrote:
> 
> 
>> On Feb 9, 2015, at 2:23 AM, Boris Brezillon 
>>  wrote:
>> 
>> The gpiochip_lock_as_irq call can fail and return an error, while the
>> irq_startup is not expected to fail (returns an unsigned int which is not
>> checked by irq core code).
>> 
>> irq_request/release_resources functions have been created to address this
>> problem.
>> 
>> Move gpiochip_lock/unlock_as_irq calls into
>> irq_request/release_resources functions to prevent using a gpio as an irq
>> if the gpiochip_lock_as_irq call failed.
>> 
>> Signed-off-by: Boris Brezillon 
>> —
> 
> I’m travelling will take a look end of the week

just get back from travelling will take a look after Chinese new year
as all my hw are at the office

Best Regards,
J.
> 
> Best Regards,
> J.
>> drivers/pinctrl/pinctrl-at91.c | 17 +++--
>> 1 file changed, 7 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
>> index f4cd0b9..a481406 100644
>> --- a/drivers/pinctrl/pinctrl-at91.c
>> +++ b/drivers/pinctrl/pinctrl-at91.c
>> @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
>>  /* the interrupt is already cleared before by reading ISR */
>> }
>> 
>> -static unsigned int gpio_irq_startup(struct irq_data *d)
>> +static int gpio_irq_request_res(struct irq_data *d)
>> {
>>  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>>  unsignedpin = d->hwirq;
>>  int ret;
>> 
>>  ret = gpiochip_lock_as_irq(_gpio->chip, pin);
>> -if (ret) {
>> +if (ret)
>>  dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
>>  d->hwirq);
>> -return ret;
>> -}
>> -gpio_irq_unmask(d);
>> -return 0;
>> +
>> +return ret;
>> }
>> 
>> -static void gpio_irq_shutdown(struct irq_data *d)
>> +static void gpio_irq_release_res(struct irq_data *d)
>> {
>>  struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
>>  unsignedpin = d->hwirq;
>> 
>> -gpio_irq_mask(d);
>>  gpiochip_unlock_as_irq(_gpio->chip, pin);
>> }
>> 
>> @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
>> static struct irq_chip gpio_irqchip = {
>>  .name   = "GPIO",
>>  .irq_ack= gpio_irq_ack,
>> -.irq_startup= gpio_irq_startup,
>> -.irq_shutdown   = gpio_irq_shutdown,
>> +.irq_request_resources = gpio_irq_request_res,
>> +.irq_release_resources = gpio_irq_release_res,
>>  .irq_disable= gpio_irq_mask,
>>  .irq_mask   = gpio_irq_mask,
>>  .irq_unmask = gpio_irq_unmask,
>> -- 
>> 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 3/3] ixgbe: Add new ndo to allow VF multicast promiscuous mode

[Or Gerlitz]

On Fri, Feb 20, 2015 at 3:01 AM, Hiroshi Shimamoto
 wrote:

> The administrator can allow to VF multicast promiscuous mode for only
> trusted VM.
>  # ./ip link set dev eth0 vf 1 mc_promisc on
> When disallowing multicast promiscuous mode, we can only use 30 IPv6 
> addresses.
>  # ./ip link set dev eth0 vf 1 mc_promisc off

all the above text belongs to the change-log of the patch that
introduces the new ndo also use just "ip" not "./ip" and specify that
the default is off.
--
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/

[GIT PULL] s390 patches for the 3.20 merge window #2

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:
Two patches to save some memory if CONFIG_NR_CPUS is large, a changed
default for the use of compare-and-delay, and a couple of bug fixes.

Heiko Carstens (5):
  s390/topology: delay initialization of topology cpu masks
  s390/topology: convert cpu_topology array to per cpu variable
  s390/smp: reduce size of struct pcpu
  s390/cacheinfo: fix shared cpu masks
  s390/cacheinfo: coding style changes

Martin Schwidefsky (3):
  s390/vdso: fix clock_gettime for CLOCK_THREAD_CPUTIME_ID, -2 and -3
  s390/mm: align 64-bit PIE binaries to 4GB
  s390/spinlock: disabled compare-and-delay by default

 arch/s390/include/asm/topology.h|  24 ++
 arch/s390/kernel/cache.c|  25 ++
 arch/s390/kernel/early.c|  12 +--
 arch/s390/kernel/setup.c|   1 -
 arch/s390/kernel/smp.c  |  54 ++---
 arch/s390/kernel/topology.c | 134 +++-
 arch/s390/kernel/vdso64/clock_gettime.S |   6 +-
 arch/s390/mm/mmap.c |   5 +-
 8 files changed, 119 insertions(+), 142 deletions(-)

diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index c4fbb95..b1453a2 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -18,15 +18,15 @@ struct cpu_topology_s390 {
cpumask_t book_mask;
 };
 
-extern struct cpu_topology_s390 cpu_topology[NR_CPUS];
+DECLARE_PER_CPU(struct cpu_topology_s390, cpu_topology);
 
-#define topology_physical_package_id(cpu)  (cpu_topology[cpu].socket_id)
-#define topology_thread_id(cpu)
(cpu_topology[cpu].thread_id)
-#define topology_thread_cpumask(cpu)   (_topology[cpu].thread_mask)
-#define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
-#define topology_core_cpumask(cpu) (_topology[cpu].core_mask)
-#define topology_book_id(cpu)  (cpu_topology[cpu].book_id)
-#define topology_book_cpumask(cpu) (_topology[cpu].book_mask)
+#define topology_physical_package_id(cpu) (per_cpu(cpu_topology, 
cpu).socket_id)
+#define topology_thread_id(cpu)  (per_cpu(cpu_topology, 
cpu).thread_id)
+#define topology_thread_cpumask(cpu) (_cpu(cpu_topology, 
cpu).thread_mask)
+#define topology_core_id(cpu)(per_cpu(cpu_topology, cpu).core_id)
+#define topology_core_cpumask(cpu)   (_cpu(cpu_topology, 
cpu).core_mask)
+#define topology_book_id(cpu)(per_cpu(cpu_topology, cpu).book_id)
+#define topology_book_cpumask(cpu)   (_cpu(cpu_topology, 
cpu).book_mask)
 
 #define mc_capable() 1
 
@@ -51,14 +51,6 @@ static inline void topology_expect_change(void) { }
 #define POLARIZATION_VM(2)
 #define POLARIZATION_VH(3)
 
-#ifdef CONFIG_SCHED_BOOK
-void s390_init_cpu_topology(void);
-#else
-static inline void s390_init_cpu_topology(void)
-{
-};
-#endif
-
 #include 
 
 #endif /* _ASM_S390_TOPOLOGY_H */
diff --git a/arch/s390/kernel/cache.c b/arch/s390/kernel/cache.c
index 632fa06..0969d113 100644
--- a/arch/s390/kernel/cache.c
+++ b/arch/s390/kernel/cache.c
@@ -91,12 +91,9 @@ static inline enum cache_type get_cache_type(struct 
cache_info *ci, int level)
 {
if (level >= CACHE_MAX_LEVEL)
return CACHE_TYPE_NOCACHE;
-
ci += level;
-
if (ci->scope != CACHE_SCOPE_SHARED && ci->scope != CACHE_SCOPE_PRIVATE)
return CACHE_TYPE_NOCACHE;
-
return cache_type_map[ci->type];
 }
 
@@ -111,23 +108,19 @@ static inline unsigned long ecag(int ai, int li, int ti)
 }
 
 static void ci_leaf_init(struct cacheinfo *this_leaf, int private,
-enum cache_type type, unsigned int level)
+enum cache_type type, unsigned int level, int cpu)
 {
int ti, num_sets;
-   int cpu = smp_processor_id();
 
if (type == CACHE_TYPE_INST)
ti = CACHE_TI_INSTRUCTION;
else
ti = CACHE_TI_UNIFIED;
-
this_leaf->level = level + 1;
this_leaf->type = type;
this_leaf->coherency_line_size = ecag(EXTRACT_LINE_SIZE, level, ti);
-   this_leaf->ways_of_associativity = ecag(EXTRACT_ASSOCIATIVITY,
-   level, ti);
+   this_leaf->ways_of_associativity = ecag(EXTRACT_ASSOCIATIVITY, level, 
ti);
this_leaf->size = ecag(EXTRACT_SIZE, level, ti);
-
num_sets = this_leaf->size / this_leaf->coherency_line_size;
num_sets /= this_leaf->ways_of_associativity;
this_leaf->number_of_sets = num_sets;
@@ -145,7 +138,6 @@ int init_cache_level(unsigned int cpu)
 
if (!this_cpu_ci)
return -EINVAL;
-
ct.raw = ecag(EXTRACT_TOPOLOGY, 0, 0);
do {

Re: [PATCH] kasan, module, vmalloc: rework shadow allocation for modules

[Andrey Ryabinin]

On 02/20/2015 03:15 AM, Rusty Russell wrote:
> Andrey Ryabinin  writes:
>> On 02/19/2015 02:10 AM, Rusty Russell wrote:
>>> This is not portable.  Other archs don't use vmalloc, or don't use
>>> (or define) MODULES_VADDR.  If you really want to hook here, you'd
>>> need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).
>>>
>>
>> Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
>> I could hide this into arch-specific function: 
>> 'kasan_need_to_allocate_shadow(const void *addr)'
>> or make make all those functions weak and allow arch code to redefine them.
> 
> That adds another layer of indirection.  And how would the caller of
> plain vmalloc() even know what to return?
> 

I think I don't understand what do you mean here. vmalloc() callers shouldn't 
know
anything about kasan/shadow.

You were concerned that this patch is not portable, so I suggested to hide arch 
specific
part in arch code. That's it.

>>> Thus I think modifying the callers is the better choice.
>>>
>>
>> I could suggest following (though, I still prefer 'modifying vmalloc' 
>> approach):
>>   * In do_init_module(), instead of call_rcu(>rcu, do_free_init);
>> use synchronyze_rcu() + module_memfree(). Of course this will be
>>   under CONFIG_KASAN.
> 
> But it would be slow, and a disparate code path, which is usually a bad
> idea.
> 
>> As you said there other module_memfree() users, so what if they will 
>> decide
>> to free memory in atomic context?
> 
> Hmm, how about a hybrid:
> 
> 1) Add kasan_module_alloc(p, size) after module alloc as your original.
> 2) Hook into vfree(), and ignore it if you can't find the map.
> 

That should work, but it looks messy IMO.

> Or is the latter too expensive?
> 

Not sure whether this will be too expensive or not,
but definitely more expensive than simple (addr >= MODULES_VADDR && addr < 
MODULES_END) check.


--
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 1/3] sched: add sched_task_call()

[Jiri Kosina]

On Thu, 19 Feb 2015, Josh Poimboeuf wrote:

> So I've looked at kgr_needs_lazy_migration(), but I still have no idea
> how it works.
> 
> First of all, I think reading the stack while its being written to could
> give you some garbage values, and a completely wrong nr_entries value
> from save_stack_trace_tsk().

I believe we've already been discussing this some time ago ...

I agree that this is a very crude optimization that should probably be 
either removed (which would only cause slower convergence in the presence 
of CPU-bound tasks), or rewritten to perform IPI-based stack dumping 
(probably on a voluntarily-configurable basis).

Reading garbage values could only happen if the task would be running in 
kernelspace. nr_entries would then be at least 2.

But I agree that relying on this very specific behavior is not really 
safe in general in case someone changes the stack dumping implementation 
in the future in an unpredictable way.

> But also, how would you walk a stack without knowing its stack pointer? 
> That function relies on the saved stack pointer in 
> task_struct.thread.sp, which, AFAICT, was last saved during the last 
> call to schedule().  Since then, the stack could have been completely 
> rewritten, with different size stack frames, before the task exited the 
> kernel.

Same argument holds here as well, I believe.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
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/

Hello dear reply

[Carolina Jones]

-- 
How are you doing? It's a wonderful compliment to write to you today.
My name is Carolina. I am a Simple and Honest girl. I have something
to tell you, perhaps you might be of assistance to me. I Had always
wanted to be a medical Doctor and my teachers in school used to
encourage me that I could do it But I could not go further because of
the untimely death of my parent. I lost my family in a Fatal Car
accident. It was really a sad day for me and as I was crying the
people present started crying as-well because I am the only child.
 so I didn’t get the chance to go to higher institution though I
managed to finish secondary school. I cried my eyes out but I could do
nothing.

Before my Father died, He told me he kept $5.9 M in the bank. I need
your ASSISTANCE TO TRANSFER the money into your Bank Account for
Investment.
 I have the LEGAL documents here with me; I will send them to you IF
you can help me out from this situation SO that I can further my
education, while you MANAGE the money in a Lucrative Business of YOUR
choice and HELP the less privileged. As I write this, I am uncertainty
of what future is ahead of me. Please tell me what Percentage of the
total money will be GOOD for you after the money is TRANSFERRED to
your account? I need an Honest and Trustworthy person who can take
good care of me, make good use of my Father Wealth and get me through
in life. I hope to hear from you soon.

Yours sincerely,
Carolina
--
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/4] Staging: rtl8192u: r819xU_firmware: added space after comma

[Joe Perches]

On Thu, 2015-02-19 at 21:54 -0800, Tolga Ceylan wrote:
> Resolved space required after that ',' errors reported by checkpatch.

trivia:

> diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c 
> b/drivers/staging/rtl8192u/r819xU_firmware.c
[]
> @@ -66,7 +66,7 @@ static bool fw_download_code(struct net_device *dev, u8 
> *code_virtual_address,
>   skb  = dev_alloc_skb(USB_HWDESC_HEADER_LEN + frag_length + 4);
>   if (!skb)
>   return false;
> - memcpy((unsigned char *)(skb->cb),,sizeof(dev));
> + memcpy((unsigned char *)(skb->cb), , sizeof(dev));


Might as well remove the unnecessary cast too:

memcpy(skb->cb, , sizeof(dev));

but it might be better to avoid the memcpy and use an assign

*(struct net_device *)skb->cb = dev;

--
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: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[Benjamin Herrenschmidt]

On Thu, 2015-02-19 at 21:45 -0800, James Bottomley wrote:
> Ben, this is legal by design.  It was specifically designed for the
> aic79xx SCSI card, but can be used for a variety of other reasons.  The
> aic79xx hardware problem was that the DMA engine could address the whole
> of memory (it had two address modes, a 39 bit one and a 64 bit one) but
> the script engine that runs the mailboxes only had a 32 bit activation
> register (the activating write points at the physical address of the
> script to begin executing).  This meant that the scripts that run in
> memory had to be in the first 4GB of physical memory, hence the split
> mask.  The DMA mask specifies that the card can transfer from anywhere
> in physical memory, but the consistent_dma_mask says that the consistent
> allocation used to get scripts memory must come from the lower 4GB.

Right, ok, it looks like it's easy enough to support with ZONE_DMA32, I'm
testing patches to create it unconditionally on ppc64 (it used to depend
on us using swiotlb on embedded platforms) and I'll shoot that upstream
if it passes.

Ben.


--
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: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[Benjamin Herrenschmidt]

On Fri, 2015-02-20 at 16:22 +1100, Benjamin Herrenschmidt wrote:

> Looking a bit more closely, you basically do
> 
>  - set_dma_mask(64-bit)
>  - set_consistent_dma_mask(32-bit)
> 
> Now, I don't know how x86 will react to the conflicting masks, but on
> ppc64, I'm pretty sure the second one will barf. IE, the first one will
> establish a set of direct mapping ops which give you a bypass of the
> iommu to all of memory. The second one will then do a
> dma_supported(mask) call which will hit the direct ops, and they will
> fail since a 32-bit mask cannot address the bypass completely.
> 
> Are architectures really required to support such mismatching dma_mask
> and consistent_dma_mask ? what a bloody trainwreck ... :-(

Oh well, looks like x86 supports it and it won't be too hard to support
it on ppc64 as well. We even had some code along those lines for FSL
platforms with an ifdef due to the amount of drivers that used to fail
setting the consistent mask properly but that seems to be mostly fixed
nowadays.

Ben.


--
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: [RESEND PATCH 2/2] arm: socfpga: Set share override bit of the l2 cache controller

[Dinh Nguyen]

Hi Rob,

On 2/19/15 12:13 PM, Rob Herring wrote:
> On Thu, Feb 19, 2015 at 11:06 AM,   wrote:
>> From: Dinh Nguyen 
>>
>> By not having bit 22 set in the PL310 Auxiliary Control register (shared
>> attribute override enable) has the side effect of transforming Normal
>> Shared Non-cacheable reads into Cacheable no-allocate reads.
>>
>> Coherent DMA buffers in Linux always have a Cacheable alias via the
>> kernel linear mapping and the processor can speculatively load cache
>> lines into the PL310 controller. With bit 22 cleared, Non-cacheable
>> reads would unexpectedly hit such cache lines leading to buffer
>> corruption.
> 
> You really should be doing this in your bootloader.
> 

Can I ask what is your reasoning for doing this in the bootloader? It's
seems like this is such a nice mechanism to do it here.

Dinh
--
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] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

[Robert Baldyga]

Hi David,

On 02/19/2015 08:59 PM, David Cohen wrote:
> Some Intel platforms have an USB OTG port fully (or partially)
> controlled by GPIOs:
> 
> (1) USB ID is connected directly to a pulled up GPIO.
> 
> Optionally:
> (2) VBUS is enabled/disabled by a GPIO
> (3) Platform has 2 USB controllers connected to same port: one for
> device and one for host role. D+/- are switched between phys.
> according to this GPIO level.
> 
> This driver configures USB OTG port for device or host role according to
> USB ID value.
>  - If USB ID's GPIO level is low, OTG port is configured for host role
>by sourcing VBUS and switching D+/- to host phy.
>  - If USB ID's GPIO level is high, by standard, the OTG port is
>configured for device role by not sourcing VBUS and switching D+/- to
>device controller.

IMO it's not very elegant to handle VBUS power on/off in extcon driver.
Creating fixed regulator would allow to make VBUS handling more generic.
Then extcon client could handle VBUS regulator. Also D+/- routing would
be separated but I don't see better place for it.

Odroid platforms also uses GPIO for USB cable detection so your driver
would be useful in that case. I created some simple driver for it but I
see I could use your driver after adding VBUS detection.

BTW don't you have VBUS detection on your board? It would allow to
distinguish between USB, USB-Host and disconnected states.

--
Robert

> 
> Signed-off-by: David Cohen 
> ---
> 
> Hi,
> 
> Since splitting this driver into smaller pieces would result in ugly fixes WRT
> ACPI, I'm resending the same approach.
> This time I addressed all comments I got from RFC version.
> 
> As always, comments are welcome.
> 
> Br, David
> ---
> 
>  drivers/extcon/Kconfig   |   8 ++
>  drivers/extcon/Makefile  |   1 +
>  drivers/extcon/extcon-otg_gpio.c | 186 
> +++
>  3 files changed, 195 insertions(+)
>  create mode 100644 drivers/extcon/extcon-otg_gpio.c
> 
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de6fa54..986ca7da9c1b 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -63,6 +63,14 @@ config EXTCON_MAX8997
> Maxim MAX8997 PMIC. The MAX8997 MUIC is a USB port accessory
> detector and switch.
>  
> +config EXTCON_OTG_GPIO
> + tristate "VIRTUAL USB OTG PORT support"
> + depends on GPIOLIB && ACPI
> + help
> +   Say Y here to enable support for virtual USB OTG port device
> +   controlled by GPIOs. This driver can be used when at least USB ID pin
> +   is connected directly to GPIO.
> +
>  config EXTCON_PALMAS
>   tristate "Palmas USB EXTCON support"
>   depends on MFD_PALMAS
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42e5a27..0d5b152b51ea 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
>  obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
>  obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
>  obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> +obj-$(CONFIG_EXTCON_OTG_GPIO)+= extcon-otg_gpio.o
>  obj-$(CONFIG_EXTCON_PALMAS)  += extcon-palmas.o
>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
>  obj-$(CONFIG_EXTCON_SM5502)  += extcon-sm5502.o
> diff --git a/drivers/extcon/extcon-otg_gpio.c 
> b/drivers/extcon/extcon-otg_gpio.c
> new file mode 100644
> index ..7dfa2c15b562
> --- /dev/null
> +++ b/drivers/extcon/extcon-otg_gpio.c
> @@ -0,0 +1,186 @@
> +/*
> + * Virtual USB OTG Port driver controlled by gpios
> + *
> + * Copyright (c) 2014, Intel Corporation.
> + * Author: David Cohen 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME "usb_otg_port"
> +
> +struct vuport {
> + struct device *dev;
> + struct gpio_desc *gpio_vbus_en;
> + struct gpio_desc *gpio_usb_id;
> + struct gpio_desc *gpio_usb_mux;
> +
> + struct extcon_dev edev;
> +};
> +
> +static const char *vuport_extcon_cable[] = {
> + [0] = "USB-Host",
> + NULL,
> +};
> +
> +/*
> + * If id == 1, USB port should be set to peripheral
> + * if id == 0, USB port should be set to host
> + *
> + * Peripheral: set USB mux to peripheral and disable VBUS
> + * Host: set USB mux to host and enable VBUS
> + */
> +static void vuport_set_port(struct vuport *vup, int id)
> +{
> + int mux_val = id;
> + int vbus_val = !id;
> +
> + if 

[PATCH] clockevents: Add (missing) default case for switch blocks

[Viresh Kumar]

Many clockevent drivers are using a switch block for handling modes in their
->set_mode() callback. Some of these do not have a 'default' case and adding a
new mode in the 'enum clock_event_mode', starts giving following warnings for
these platforms about unhandled modes (e.g. XXX).

warning: enumeration value ‘XXX’ not handled in switch [-Wswitch]

This patch adds default cases for them.

In order to keep things simple, add following to the switch blocks:

default:
break;

This can lead to different behavior for individual cases.

1) Some of the drivers don't have any special stuff in their ->set_mode()
   callback before or after the switch blocks. And so this default case would
   simply return for them without any updates to the clockevent device.

2) But in some cases, the clockevent device is disabled/stopped as soon as we
   enter the ->set_mode() callback and is enabled within the switch block or
   after it. And the clockevent device *may* stay disabled for default case.

The rationale behind only adding a 'break' was that the default case *will
never* be hit during execution of code. All new modes (beyond RESUME) are
handled with mode specific ->set_mode_*() callbacks and ->set_mode() is never
called for them. And all modes before and including RESUME are already
explicitly handled by the clockevent drivers.

Reviewed-by: Preeti U Murthy 
Signed-off-by: Viresh Kumar 
---
Rebased over: tip/master, due to recently added rockchip driver.
8e3210338295 Merge branch 'x86/urgent'

 arch/arm/mach-at91/at91rm9200_time.c| 2 ++
 arch/arm/mach-davinci/time.c| 2 ++
 arch/arm/mach-footbridge/dc21285-timer.c| 2 ++
 arch/arm/mach-imx/epit.c| 2 ++
 arch/arm/mach-imx/time.c| 2 ++
 arch/arm/mach-lpc32xx/timer.c   | 2 ++
 arch/arm/mach-mmp/time.c| 2 ++
 arch/arm/mach-omap1/time.c  | 2 ++
 arch/arm/mach-omap1/timer32k.c  | 2 ++
 arch/arm/mach-omap2/timer.c | 2 ++
 arch/arm/mach-sa1100/time.c | 2 ++
 arch/arm/mach-w90x900/time.c| 2 ++
 arch/blackfin/kernel/time-ts.c  | 4 
 arch/c6x/platforms/timer64.c| 2 ++
 arch/m68k/coldfire/pit.c| 2 ++
 arch/microblaze/kernel/timer.c  | 2 ++
 arch/mips/kernel/cevt-bcm1480.c | 2 ++
 arch/mips/kernel/cevt-sb1250.c  | 2 ++
 arch/mips/kernel/cevt-txx9.c| 2 ++
 arch/mips/loongson/common/cs5536/cs5536_mfgpt.c | 2 ++
 arch/mips/loongson/loongson-3/hpet.c| 2 ++
 arch/mips/sni/time.c| 2 ++
 arch/nios2/kernel/time.c| 2 ++
 arch/openrisc/kernel/time.c | 2 ++
 arch/sparc/kernel/time_64.c | 2 ++
 arch/um/kernel/time.c   | 2 ++
 arch/unicore32/kernel/time.c| 2 ++
 arch/x86/kernel/apic/apic.c | 2 ++
 arch/x86/kernel/hpet.c  | 2 ++
 arch/x86/lguest/boot.c  | 2 ++
 arch/x86/platform/uv/uv_time.c  | 2 ++
 arch/x86/xen/time.c | 4 
 drivers/clocksource/cadence_ttc_timer.c | 2 ++
 drivers/clocksource/dw_apb_timer.c  | 2 ++
 drivers/clocksource/exynos_mct.c| 4 
 drivers/clocksource/i8253.c | 2 ++
 drivers/clocksource/metag_generic.c | 2 ++
 drivers/clocksource/mxs_timer.c | 2 ++
 drivers/clocksource/nomadik-mtu.c   | 2 ++
 drivers/clocksource/pxa_timer.c | 2 ++
 drivers/clocksource/qcom-timer.c| 2 ++
 drivers/clocksource/rockchip_timer.c| 2 ++
 drivers/clocksource/samsung_pwm_timer.c | 2 ++
 drivers/clocksource/tegra20_timer.c | 2 ++
 drivers/clocksource/time-efm32.c| 2 ++
 drivers/clocksource/timer-atmel-pit.c   | 2 ++
 drivers/clocksource/timer-prima2.c  | 2 ++
 drivers/clocksource/timer-u300.c| 2 ++
 drivers/clocksource/vt8500_timer.c  | 2 ++
 49 files changed, 104 insertions(+)

diff --git a/arch/arm/mach-at91/at91rm9200_time.c 
b/arch/arm/mach-at91/at91rm9200_time.c
index 51761f8927b7..053ae0e3c3cb 100644
--- a/arch/arm/mach-at91/at91rm9200_time.c
+++ b/arch/arm/mach-at91/at91rm9200_time.c
@@ -138,6 +138,8 @@ clkevt32k_mode(enum clock_event_mode mode, struct 
clock_event_device *dev)
case CLOCK_EVT_MODE_RESUME:
irqmask = 0;
break;
+   default:
+   break;
}
at91_st_write(AT91_ST_IER, irqmask);
 }
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 160c9602f490..59347b8e8228 100644
--- a/arch/arm/mach-davinci/time.c
+++ 

Re: [PATCH v4] dma: Add Xilinx AXI Direct Memory Access Engine driver support

[Vinod Koul]

On Sat, Feb 14, 2015 at 02:21:52PM +, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
> 
> 
> > -Original Message-
> > From: Vinod Koul [mailto:vinod.k...@intel.com]
> > Sent: Thursday, February 12, 2015 3:05 PM
> > To: Appana Durga Kedareswara Rao
> > Cc: Arnd Bergmann; linux-arm-ker...@lists.infradead.org;
> > devicet...@vger.kernel.org; Srikanth Vemula; linux-
> > ker...@vger.kernel.org; Srikanth Thokala; dmaeng...@vger.kernel.org;
> > robh...@kernel.org; Michal Simek; Anirudha Sarangi;
> > grant.lik...@linaro.org; dan.j.willi...@intel.com
> > Subject: Re: [PATCH v4] dma: Add Xilinx AXI Direct Memory Access Engine
> > driver support
> >
> > On Thu, Jan 29, 2015 at 11:24:41AM +, Appana Durga Kedareswara Rao
> > wrote:
> > > >  Earlier in the driver we are embedding dma_slave_config into custom
> > > > structs But Lars suggested to modify it. please refer to the below
> > > > thread for more details.
> > > >  http://www.spinics.net/lists/dmaengine/msg00010.html
> > > >
> > > >  And later we thought of creating a separate private member in
> > > > dma_slave_config for sharing additional configuration between slave
> > > > device and dma engine Or a new dma_ctrl_cmd like
> > > >
> > FSLDMA_EXTERNAL_START(http://www.kernelhub.org/?msg=405535=2 )
> > > >
> > > >  Finally Vinod was ok with the existing suggestion so we dropped the
> > > > above thought.
> > > >
> > > >  @Vinod : Could you please comment on this.
> > FSLDMA_EXTERNAL_START has been removed, and you cna use the removal
> > as a guidance of how to solve your issue
> >
> 
Please limit you mailer to set wrap at 80 chars, otherwise it becomes
unreadable

> The current VDMA driver that got merged in the open source and the
> current patch (dma: xilinx dma v4) Srikanth T submitted both contains the
> Similar implementation that you pointed as above(I mean similar to the
> free scale dma driver).
> 
> The discussion starts here is why we need the header file(Xilinx_dma.h) in
> the include/linux/amba/Xilinx_dma.h  folder.
> 
> Like for FSL DMA it is got defined (fsl_dma_external_start) as a function
> prototype in include/linux/fsldma.h And it is being getting used in the
> drivers/misc/carma/carma-fpga-program.c
> 
> Similarly in the Xilinx VDMA driver(xilinx_vdma_channel_set_config )
> defined as a function prototype in the include/linux/amba/xilinx_dma.h And
> is being used by Xilinx videos  drivers.  Those video driver need to use
> the (xilinx_vdma_channel_set_config) which requires this global header
> file.
> 
> Could you please suggest us whether that header file (Xilinx_dma.h) should
> be there  in include/linux/amba or we should move it to include/linux?
> And any functional comments for this v4 patch?
Let me ask you a question, what is the relation of xilinx_dma with amba?

If none then only include/linux/ seems to be the right choice. If not then
amba maybe okay but you need to provide justfication why it should be in amba?

-- 
~Vinod

--
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 59/61] dmaengine: Add a warning for drivers not using the generic slave caps retrieval

[Vinod Koul]

On Thu, Feb 19, 2015 at 02:23:27PM +0530, Viresh Kumar wrote:
> On 19 February 2015 at 13:39, Jean Delvare  wrote:
> > My understanding is that the warning message is here on purpose to
> > instruct DMA driver authors to fix their code. So if anyone need to fix
> > anything, that would be you and Andy. That being said, I suspect Andy
> 
> To some extent yes, but Andy has already tried to fix that for most of
> the drivers and so I just pointed out that something is missed.
> 
> > already did that:
> >
> > commit 029a40e97d0db269f4a7fc02b0f29f627f628309
> > Author: Andy Shevchenko 
> > Date:   Fri Jan 2 16:17:24 2015 +0200
> >
> > dmaengine: dw: provide DMA capabilities
> >
> > Brian, can you please try the latest Linus or linux-next kernel (or
> > backport the above commit to your current kernel) and confirm that the
> > backtraces are no longer printed?
> 
> Maybe yes.
This warning was intentionally added to help move driver use the right
method. And I have applied patch from Andy for this, so this should be no
longer seen on Linus's tree

-- 
~Vinod
--
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/4] Staging: rtl8192u: r819xU_firmware: removed commented out assert

[Tolga Ceylan]

Removed an assert that was commented out. The comment provides
no documentation value as rt_status is properly handled.

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/rtl8192u/r819xU_firmware.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c 
b/drivers/staging/rtl8192u/r819xU_firmware.c
index 9d0067e..6a818c4 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -329,8 +329,6 @@ bool init_firmware(struct net_device *dev)
}
 
RT_TRACE(COMP_FIRMWARE, "Firmware Download Success\n");
-   //assert(pfirmware->firmware_status == FW_STATUS_5_READY, ("Firmware 
Download Fail\n"));
-
return rt_status;
 
 download_firmware_fail:
-- 
2.3.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 3/4] Staging: rtl9182u: r819xU_firmware: Replaced C99 comments with C89

[Tolga Ceylan]

Replaced C99 comments with C89.

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/rtl8192u/r819xU_firmware.c | 33 +++---
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c 
b/drivers/staging/rtl8192u/r819xU_firmware.c
index 6a818c4..e7b2f33 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -47,7 +47,7 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
u8  index;
 
firmware_init_param(dev);
-   //Fragmentation might be required
+   /* Fragmentation might be required */
frag_threshold = pfirmware->cmdpacket_frag_thresold;
do {
if ((buffer_len - frag_offset) > frag_threshold) {
@@ -106,19 +106,20 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
 
 }
 
-//-
-// Procedure:Check whether main code is download OK. If OK, turn on CPU
-//
-// Description:   CPU register locates in different page against general 
register.
-// Switch to CPU register in the begin and switch back 
before return
-//
-//
-// Arguments:   The pointer of the adapter
-//
-// Returns:
-//NDIS_STATUS_FAILURE - the following initialization process should be 
terminated
-//NDIS_STATUS_SUCCESS - if firmware initialization process success
-//-
+/*
+ * Procedure:  Check whether main code is download OK. If OK, turn on CPU
+ *
+ * Description:CPU register locates in different page against general 
register.
+ * Switch to CPU register in the begin and switch back before return
+ *
+ *
+ * Arguments:   The pointer of the adapter
+ *
+ * Returns:
+ *NDIS_STATUS_FAILURE - the following initialization process should
+ * be terminated
+ *NDIS_STATUS_SUCCESS - if firmware initialization process success
+ */
 static bool CPUcheck_maincodeok_turnonCPU(struct net_device *dev)
 {
boolrt_status = true;
@@ -221,7 +222,7 @@ bool init_firmware(struct net_device *dev)
/* it is called by reset */
rst_opt = OPT_SYSTEM_RESET;
starting_state = FW_INIT_STEP0_BOOT;
-   // TODO: system reset
+   /* TODO: system reset */
 
} else if (pfirmware->firmware_status == FW_STATUS_5_READY) {
/* it is called by Initialize */
@@ -290,7 +291,7 @@ bool init_firmware(struct net_device *dev)
 * will set polling bit when firmware code is also 
configured
 */
pfirmware->firmware_status = FW_STATUS_1_MOVE_BOOT_CODE;
-   //mdelay(1000);
+   /* mdelay(1000); */
/*
 * To initialize IMEM, CPU move code  from 0x8080,
 * hence, we send 0x80 byte packet
-- 
2.3.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 1/4] Staging: rtl8192u: r819xU_firmware: removed commented out variable

[Tolga Ceylan]

Removed commented out variable

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/rtl8192u/r819xU_firmware.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c 
b/drivers/staging/rtl8192u/r819xU_firmware.c
index c230be2..9d0067e 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -37,7 +37,6 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
boolrt_status = true;
u16 frag_threshold;
u16 frag_length, frag_offset = 0;
-   //u16   total_size;
int i;
 
rt_firmware *pfirmware = priv->pFirmware;
-- 
2.3.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 4/4] Staging: rtl8192u: r819xU_firmware: added space after comma

[Tolga Ceylan]

Resolved space required after that ',' errors reported by checkpatch.

Signed-off-by: Tolga Ceylan 
---
 drivers/staging/rtl8192u/r819xU_firmware.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c 
b/drivers/staging/rtl8192u/r819xU_firmware.c
index e7b2f33..8e7fe82 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -66,7 +66,7 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
skb  = dev_alloc_skb(USB_HWDESC_HEADER_LEN + frag_length + 4);
if (!skb)
return false;
-   memcpy((unsigned char *)(skb->cb),,sizeof(dev));
+   memcpy((unsigned char *)(skb->cb), , sizeof(dev));
tcb_desc = (cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
tcb_desc->queue_index = TXCMD_QUEUE;
tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
@@ -91,7 +91,7 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
if (!priv->ieee80211->check_nic_enough_desc(dev, index) ||
   (!skb_queue_empty(>ieee80211->skb_waitQ[index])) ||
   (priv->ieee80211->queue_stop)) {
-   
RT_TRACE(COMP_FIRMWARE,"=> 
tx full!\n");
+   RT_TRACE(COMP_FIRMWARE, 
"=> tx full!\n");

skb_queue_tail(>ieee80211->skb_waitQ[tcb_desc->queue_index], skb);
} else {
priv->ieee80211->softmac_hard_start_xmit(skb, dev);
@@ -242,7 +242,8 @@ bool init_firmware(struct net_device *dev)
 * or read image file from array. Default load from IMG file
 */
if (rst_opt == OPT_SYSTEM_RESET) {
-   rc = request_firmware(_entry, 
fw_name[init_step],>udev->dev);
+   rc = request_firmware(_entry, fw_name[init_step],
+ >udev->dev);
if (rc < 0) {
RT_TRACE(COMP_ERR, "request firmware fail!\n");
goto download_firmware_fail;
@@ -254,12 +255,14 @@ bool init_firmware(struct net_device *dev)
}
 
if (init_step != FW_INIT_STEP1_MAIN) {
-   
memcpy(pfirmware->firmware_buf,fw_entry->data,fw_entry->size);
+   memcpy(pfirmware->firmware_buf, fw_entry->data,
+  fw_entry->size);
mapped_file = pfirmware->firmware_buf;
file_length = fw_entry->size;
} else {
memset(pfirmware->firmware_buf, 0, 128);
-   
memcpy(>firmware_buf[128],fw_entry->data,fw_entry->size);
+   memcpy(>firmware_buf[128],
+  fw_entry->data, fw_entry->size);
mapped_file = pfirmware->firmware_buf;
file_length = fw_entry->size + 128;
}
@@ -319,7 +322,9 @@ bool init_firmware(struct net_device *dev)
 
rt_status = CPUcheck_firmware_ready(dev);
if (rt_status != TRUE) {
-   RT_TRACE(COMP_ERR, "CPUcheck_firmware_ready 
fail(%d)!\n",rt_status);
+   RT_TRACE(COMP_ERR,
+"CPUcheck_firmware_ready fail(%d)!\n",
+rt_status);
goto download_firmware_fail;
}
 
-- 
2.3.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/

Re: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[James Bottomley]

On Fri, 2015-02-20 at 16:22 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2015-02-20 at 16:06 +1100, Benjamin Herrenschmidt wrote:
> 
> > Note that even on powerpc platforms where it would work because we
> > maintain both 32-bit and 64-bit bypass windows in the device address
> > space simultaneously, you will leak iommu entries unless you also switch
> > back to 32-bit when freeing the 32-bit mappings... (and you would
> > probably crash if you tried to free a 64-bit mapping while in 32-bit
> > mode).
> > 
> > The iommu APIs weren't designed with that "switching mask" facility in
> > mind...
> 
> Looking a bit more closely, you basically do
> 
>  - set_dma_mask(64-bit)
>  - set_consistent_dma_mask(32-bit)
> 
> Now, I don't know how x86 will react to the conflicting masks, but on
> ppc64, I'm pretty sure the second one will barf. IE, the first one will
> establish a set of direct mapping ops which give you a bypass of the
> iommu to all of memory. The second one will then do a
> dma_supported(mask) call which will hit the direct ops, and they will
> fail since a 32-bit mask cannot address the bypass completely.
> 
> Are architectures really required to support such mismatching dma_mask
> and consistent_dma_mask ? what a bloody trainwreck ... :-(

Ben, this is legal by design.  It was specifically designed for the
aic79xx SCSI card, but can be used for a variety of other reasons.  The
aic79xx hardware problem was that the DMA engine could address the whole
of memory (it had two address modes, a 39 bit one and a 64 bit one) but
the script engine that runs the mailboxes only had a 32 bit activation
register (the activating write points at the physical address of the
script to begin executing).  This meant that the scripts that run in
memory had to be in the first 4GB of physical memory, hence the split
mask.  The DMA mask specifies that the card can transfer from anywhere
in physical memory, but the consistent_dma_mask says that the consistent
allocation used to get scripts memory must come from the lower 4GB.

James


--
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] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Alexandre Courbot]

On Fri, Feb 20, 2015 at 2:33 PM, Dmitry Torokhov
 wrote:
>> I should have commented at that time, but let's do it now: I agree
>> with the idea, but this leaves the door open to confusing situations
>> in case gpiolib was unintentionally disabled. Could you also add a
>> note in the documentation of this function to explain this behavior,
>> to spare a few headaches to users of this function?
>
> You mean the inline documentation in drivers/gpio/gpiolib.c and
> drivers/gpio/devres.c? I can certainly mention there that is GPIOLIB is 
> disabled
> thy will return NULL unlike the non-optional variants.

I was thinking about Documentation/gpio/consumer.txt, but having a
note in the inline documentation as well certainly makes sense.
--
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/2] HID: huion: add libinput support

[Peter Hutterer]

On Thu, Feb 19, 2015 at 01:54:17PM +0200, Nikolai Kondrashov wrote:
[...]
> >>>Last, I think we could add these tablets in the libwacom project, so that 
> >>>there
> >>>will be a nice GUI to configure the buttons.
> >>
> >>That would be a very welcome change, without doubt, thank you.
> >>
> >>However, I can't help wondering, would it be more productive to allow 
> >>libwacom
> >>to work with just any basic tablet, without the need to add each one to the
> >>database?
> >
> >Actually, libwacom is not tight to Wacom devices at all (or should not
> >be). It is just a database of devices to add what the kernel doesn't or
> >can not provide. The things that are in the db are for example how the
> >buttons are physically mapped on the device, what is the actual layout
> >(one svg file), if there are LEDs attached to the tablet.
> >
> >All this needs a fine per-device tuning. We can add a generic
> >Huion/UClogic tablet too, but having a specific per-device definition
> >allows to show the exact mapping of the buttons on the overlay when
> >setting the functions.
> 
> I agree, that's a nice feature. However, I think being able to configure all
> the applicable Wacom driver features relatively comfortably, even if the
> tablet on screen doesn't exactly match your tablet, is still a win, compared
> to not being able to do it.
> 
> For the unknown tablets we can just draw abstract tablets, emphasising that
> control locations on the screen don't map to the actual locations. For
> example, have the tablet drawn like an exploded diagram: surface, buttons,
> dials - all separate.  Something like this:
> 
> Buttons: * * * * * * *
>   Dials: O O
>   Work area: ++
>  ||
>  ||
>  ||
>  ++
> 
> I think the users will be able to figure out the mapping by experimentation.
> 
> While it's just about possible to keep an up-to-date database of Wacom
> tablets, I don't think we'll ever be able to list all those generic tablets
> out there. Meanwhile a lot of people are left in the cold of xsetwacom and
> xinput.

not a reason to give up, IMO. most of these generic tablets are relatively
simple, so adding a libwacom entry should be a matter of minutes.
we'll never get full support of everything, but perfect is the enemy of good
here.

Cheers,
   Peter

--
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/6] thinkpad_acpi: Add support for more adaptive kbd buttons

[Darren Hart]

On Wed, Feb 18, 2015 at 09:53:48PM +0100, Bastien Nocera wrote:
> This commit adds new elements to the ThinkPad keymaps, and
> will send key events for keys for which an input.h declaration
> exists.
> 
> Signed-off-by: Bastien Nocera 
> ---
>  drivers/platform/x86/thinkpad_acpi.c | 80 
> +++-
>  1 file changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 562d958..a47a56a 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -1911,6 +1911,27 @@ enum { /* hot key scan codes (derived from ACPI DSDT) 
> */
>   TP_ACPI_HOTKEYSCAN_UNK7,
>   TP_ACPI_HOTKEYSCAN_UNK8,
>  
> + TP_ACPI_HOTKEYSCAN_MUTE2,
> + TP_ACPI_HOTKEYSCAN_BRIGHTNESS_ZERO,
> + TP_ACPI_HOTKEYSCAN_CLIPPING_TOOL,
> + TP_ACPI_HOTKEYSCAN_CLOUD,
> + TP_ACPI_HOTKEYSCAN_UNK9,
> + TP_ACPI_HOTKEYSCAN_VOICE,
> + TP_ACPI_HOTKEYSCAN_UNK10,
> + TP_ACPI_HOTKEYSCAN_GESTURES,
> + TP_ACPI_HOTKEYSCAN_UNK11,
> + TP_ACPI_HOTKEYSCAN_UNK12,
> + TP_ACPI_HOTKEYSCAN_UNK13,
> + TP_ACPI_HOTKEYSCAN_CONFIG,
> + TP_ACPI_HOTKEYSCAN_NEW_TAB,
> + TP_ACPI_HOTKEYSCAN_RELOAD,
> + TP_ACPI_HOTKEYSCAN_BACK,
> + TP_ACPI_HOTKEYSCAN_MIC_DOWN,
> + TP_ACPI_HOTKEYSCAN_MIC_UP,
> + TP_ACPI_HOTKEYSCAN_MIC_CANCELLATION,
> + TP_ACPI_HOTKEYSCAN_CAMERA_MODE,
> + TP_ACPI_HOTKEYSCAN_ROTATE_DISPLAY,
> +
>   /* Hotkey keymap size */
>   TPACPI_HOTKEY_MAP_LEN
>  };
> @@ -3171,6 +3192,13 @@ static int __init hotkey_init(struct ibm_init_struct 
> *iibm)
>   /* (assignments unknown, please report if found) */
>   KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
>   KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> +
> + /* no assignments, only used for Adaptive keyboards */

Sentence formatting please.

> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
>   },
>  
>   /* Generic keymap for Lenovo ThinkPads */
> @@ -3227,6 +3255,33 @@ static int __init hotkey_init(struct ibm_init_struct 
> *iibm)
>  
>   /* Extra keys in use since the X240 / T440 / T540 */
>   KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_FILE,
> +
> + /* Adaptive keyboard keycodes for Carbon X1 2014,
> +  * The first item in this list is the Mute button
> +  * which is emitted with 0x103 through
> +  * adaptive_keyboard_hotkey_notify_hotkey ()
> +  * when the sound symbol is held
> +  * We'll need to offset those by 0x20 */

Please follow CodingStyle with /* and */ on their own lines. Also, wrapping is
strange, as is capitalization, etc.  Please terminate sentences with periods,
and only capitalize the beginning of sentences or proper nouns.

> + KEY_RESERVED,/* Mute held, 0x103 */
> + KEY_BRIGHTNESS_MIN,  /* Backlight off */
> + KEY_RESERVED,/* Clipping tool */
> + KEY_RESERVED,/* Cloud */
> + KEY_RESERVED,
> + KEY_VOICECOMMAND,/* Voice */
> + KEY_RESERVED,
> + KEY_RESERVED,/* Gestures */
> + KEY_RESERVED,
> + KEY_RESERVED,
> + KEY_RESERVED,
> + KEY_CONFIG,  /* Settings */
> + KEY_RESERVED,/* New tab */
> + KEY_REFRESH, /* Reload */
> + KEY_BACK,/* Back */
> + KEY_RESERVED,/* Microphone down */
> + KEY_RESERVED,/* Microphone up */
> + KEY_RESERVED,/* Microphone cancellation */
> + KEY_RESERVED,/* Camera mode */
> + KEY_RESERVED,/* Rotate display, 0x116 */
>   },
>   };
>  
> @@ -3526,6 +3581,8 @@ const int adaptive_keyboard_modes[] = {
>  
>  #define DFR_CHANGE_ROW   0x101
>  #define DFR_SHOW_QUICKVIEW_ROW   0x102
> +#define FIRST_ADAPTIVE_KEY   0x103
> +#define ADAPTIVE_KEY_OFFSET  0x020
>  
>  /* press Fn key a while second, it will switch to Function Mode. Then
>   * release Fn key, previous mode be restored.
> @@ -3581,6 +3638,7 @@ static bool 
> adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
>  {
>   u32 current_mode = 0;
>   int new_mode = 0;
> + int keycode;
>  
>   switch (scancode) {
>   case DFR_CHANGE_ROW:
> @@ -3613,7 +3671,27 @@ static bool 
> adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
>   return true;
>  
>   default:
> - return false;
> +  

Re: [PATCH] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Dmitry Torokhov]

On Fri, Feb 20, 2015 at 01:59:43PM +0900, Alexandre Courbot wrote:
> On Fri, Feb 20, 2015 at 9:30 AM, Dmitry Torokhov
>  wrote:
> > Given the intent behind gpiod_get_optional() and friends it does not make
> > sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
> > work just fine without gpio so let's behave as if gpio was not found.
> > Otherwise we have to special-case -ENOSYS in drivers.
> 
> Interestingly Uwe sent a RFC for this one week ago:
> 
> http://patchwork.ozlabs.org/patch/439135/
> 
> Maybe credit him with a Suggested-by.?

I certainly am fine with crediting him with Suggested-by even though I did not
see that Uwe's e-mail but this patch was prompted by his other patch changing a
few input drivers to use gpiod_get_optional() and me recalling that I
explicitly did not use it as it made no difference from gpiod_get() since I had
to handle -ENOSYS anyway.

> 
> I should have commented at that time, but let's do it now: I agree
> with the idea, but this leaves the door open to confusing situations
> in case gpiolib was unintentionally disabled. Could you also add a
> note in the documentation of this function to explain this behavior,
> to spare a few headaches to users of this function?

You mean the inline documentation in drivers/gpio/gpiolib.c and
drivers/gpio/devres.c? I can certainly mention there that is GPIOLIB is disabled
thy will return NULL unlike the non-optional variants.

> 
> >
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >  include/linux/gpio/consumer.h | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> > index fd85cb1..f68244f 100644
> > --- a/include/linux/gpio/consumer.h
> > +++ b/include/linux/gpio/consumer.h
> > @@ -132,14 +132,14 @@ static inline struct gpio_desc *__must_check
> >  __gpiod_get_optional(struct device *dev, const char *con_id,
> >  enum gpiod_flags flags)
> >  {
> > -   return ERR_PTR(-ENOSYS);
> > +   return NULL;
> >  }
> >
> >  static inline struct gpio_desc *__must_check
> >  __gpiod_get_index_optional(struct device *dev, const char *con_id,
> >unsigned int index, enum gpiod_flags flags)
> >  {
> > -   return ERR_PTR(-ENOSYS);
> > +   return NULL;
> >  }
> >
> >  static inline void gpiod_put(struct gpio_desc *desc)
> > @@ -171,14 +171,14 @@ static inline struct gpio_desc *__must_check
> >  __devm_gpiod_get_optional(struct device *dev, const char *con_id,
> >   enum gpiod_flags flags)
> >  {
> > -   return ERR_PTR(-ENOSYS);
> > +   return NULL;
> >  }
> >
> >  static inline struct gpio_desc *__must_check
> >  __devm_gpiod_get_index_optional(struct device *dev, const char *con_id,
> > unsigned int index, enum gpiod_flags flags)
> >  {
> > -   return ERR_PTR(-ENOSYS);
> > +   return NULL;
> >  }
> >
> >  static inline void devm_gpiod_put(struct device *dev, struct gpio_desc 
> > *desc)
> > --
> > 2.2.0.rc0.207.ga3a616c
> >
> >
> > --
> > Dmitry

-- 
Dmitry
--
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 3/6] thinkpad_acpi: Add adaptive_kbd_mode sysfs attr

[Darren Hart]

On Wed, Feb 18, 2015 at 09:53:44PM +0100, Bastien Nocera wrote:

Commit message please.

> Signed-off-by: Bastien Nocera 
> ---
>  drivers/platform/x86/thinkpad_acpi.c | 71 
> +++-
>  1 file changed, 62 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index a6dd017..562d958 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c

...

> +static struct device_attribute dev_attr_adaptive_kbd_mode =
> + __ATTR(adaptive_kbd_mode, S_IWUSR | S_IRUGO,
> + adaptive_kbd_mode_show, adaptive_kbd_mode_store);
> +

Please use DEVICE_ATTR_RW() macros for new sysfs files.

I'd very much like to see a cleanup of the driver to use these as well.

Henrique, your thoughts / preference?

-- 
Darren Hart
Intel Open Source Technology Center
--
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] af_packet: allow packets defragmentation not only for hash fanout type

[Alexander Drozdov]

Packets defragmentation was introduced for PACKET_FANOUT_HASH only,
see 7736d33f4262 ("packet: Add pre-defragmentation support for ipv4
fanouts")

It may be useful to have defragmentation enabled regardless of
fanout type. Without that, the AF_PACKET user may have to:
1. Collect fragments from different rings
2. Defragment by itself

Signed-off-by: Alexander Drozdov 
---
 net/packet/af_packet.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 9c28cec..99fc628 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1349,14 +1349,14 @@ static int packet_rcv_fanout(struct sk_buff *skb, 
struct net_device *dev,
return 0;
}
 
+   if (fanout_has_flag(f, PACKET_FANOUT_FLAG_DEFRAG)) {
+   skb = ip_check_defrag(skb, IP_DEFRAG_AF_PACKET);
+   if (!skb)
+   return 0;
+   }
switch (f->type) {
case PACKET_FANOUT_HASH:
default:
-   if (fanout_has_flag(f, PACKET_FANOUT_FLAG_DEFRAG)) {
-   skb = ip_check_defrag(skb, IP_DEFRAG_AF_PACKET);
-   if (!skb)
-   return 0;
-   }
idx = fanout_demux_hash(f, skb, num);
break;
case PACKET_FANOUT_LB:
-- 
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: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[Benjamin Herrenschmidt]

On Fri, 2015-02-20 at 16:06 +1100, Benjamin Herrenschmidt wrote:

> Note that even on powerpc platforms where it would work because we
> maintain both 32-bit and 64-bit bypass windows in the device address
> space simultaneously, you will leak iommu entries unless you also switch
> back to 32-bit when freeing the 32-bit mappings... (and you would
> probably crash if you tried to free a 64-bit mapping while in 32-bit
> mode).
> 
> The iommu APIs weren't designed with that "switching mask" facility in
> mind...

Looking a bit more closely, you basically do

 - set_dma_mask(64-bit)
 - set_consistent_dma_mask(32-bit)

Now, I don't know how x86 will react to the conflicting masks, but on
ppc64, I'm pretty sure the second one will barf. IE, the first one will
establish a set of direct mapping ops which give you a bypass of the
iommu to all of memory. The second one will then do a
dma_supported(mask) call which will hit the direct ops, and they will
fail since a 32-bit mask cannot address the bypass completely.

Are architectures really required to support such mismatching dma_mask
and consistent_dma_mask ? what a bloody trainwreck ... :-(

Cheers,
Ben.


--
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/6] thinkpad_acpi: Factor out get/set adaptive kbd mode

[Darren Hart]

On Wed, Feb 18, 2015 at 09:53:35PM +0100, Bastien Nocera wrote:

Please provide a commit message. There is always something to say beyond what is
in the subject. In this case, I suggest the motivation and justification for the
change.

While I appreciate the abstraction, it makes the code at the call site easier to
read, note that you added more code than you removed.

So, please provide a justificaiton.

Under no circumstances will I accept a patch without a commit message body.

> Signed-off-by: Bastien Nocera 
> ---
>  drivers/platform/x86/thinkpad_acpi.c | 61 
> ++--
>  1 file changed, 38 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 80db3ce..a6dd017 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -3480,6 +3480,32 @@ const int adaptive_keyboard_modes[] = {
>  static bool adaptive_keyboard_mode_is_saved;
>  static int adaptive_keyboard_prev_mode;
>  
> +static int adaptive_keyboard_get_mode(void)
> +{
> + u32 mode = 0;

acpi_evalf second argument takes an "int" and this function returns "int". Is
there a reason to use u32 for mode?

...

> @@ -3509,39 +3535,28 @@ static bool 
> adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
>   new_mode = adaptive_keyboard_prev_mode;
>   adaptive_keyboard_mode_is_saved = false;
>   } else {
> - if (!acpi_evalf(
> - hkey_handle, _mode,
> - "GTRW", "dd", 0)) {
> - pr_err("Cannot read adaptive keyboard mode\n");
> + current_mode = adaptive_keyboard_get_mode();
> + if (current_mode < 0)
>   return false;
> - } else {
> - new_mode = adaptive_keyboard_get_next_mode(
> - current_mode);
> - }
> + new_mode = adaptive_keyboard_get_next_mode(
> + current_mode);

This now fits on one line I believe.

...

-- 
Darren Hart
Intel Open Source Technology Center
--
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 RFC tip/core/rcu 2/4] rcu: Add rcu_expedite_gp() and rcu_unexpedite_gp() to rcutorture

[Paul E. McKenney]

From: "Paul E. McKenney" 

Signed-off-by: Paul E. McKenney 
---
 kernel/rcu/rcutorture.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 30d42aa55d83..3a60815ce97c 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -853,6 +853,8 @@ rcu_torture_fqs(void *arg)
 static int
 rcu_torture_writer(void *arg)
 {
+   bool can_expedite = !rcu_gp_is_expedited();
+   int expediting = 0;
unsigned long gp_snap;
bool gp_cond1 = gp_cond, gp_exp1 = gp_exp, gp_normal1 = gp_normal;
bool gp_sync1 = gp_sync;
@@ -865,6 +867,12 @@ rcu_torture_writer(void *arg)
int nsynctypes = 0;
 
VERBOSE_TOROUT_STRING("rcu_torture_writer task started");
+   pr_alert("%s" TORTURE_FLAG
+" Grace periods expedited from boot/sysfs for %s,\n",
+torture_type, cur_ops->name);
+   pr_alert("%s" TORTURE_FLAG
+" Testing of dynamic grace-period expediting diabled.\n",
+torture_type);
 
/* Initialize synctype[] array.  If none set, take default. */
if (!gp_cond1 && !gp_exp1 && !gp_normal1 && !gp_sync)
@@ -949,9 +957,25 @@ rcu_torture_writer(void *arg)
}
}
rcutorture_record_progress(++rcu_torture_current_version);
+   /* Cycle through nesting levels of rcu_expedite_gp() calls. */
+   if (can_expedite && torture_random()) {
+   WARN_ON_ONCE(expediting == 0 && rcu_gp_is_expedited());
+   if (expediting >= 0)
+   rcu_expedite_gp();
+   else
+   rcu_unexpedite_gp();
+   if (++expediting > 3)
+   expediting = -expediting;
+   }
rcu_torture_writer_state = RTWS_STUTTER;
stutter_wait("rcu_torture_writer");
} while (!torture_must_stop());
+   /* Reset expediting back to unexpedited. */
+   if (expediting > 0)
+   expediting = -expediting;
+   while (can_expedite && expediting++ < 0)
+   rcu_unexpedite_gp();
+   WARN_ON_ONCE(can_expedite && rcu_gp_is_expedited());
rcu_torture_writer_state = RTWS_STOPPING;
torture_kthread_stopping("rcu_torture_writer");
return 0;
-- 
1.8.1.5

--
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 RFC tip/core/rcu 1/4] rcu: Provide rcu_expedite_gp() and rcu_unexpedite_gp()

[Paul E. McKenney]

From: "Paul E. McKenney" 

Currently, expediting of normal synchronous grace-period primitives
(synchronize_rcu() and friends) is controlled by the rcu_expedited()
boot/sysfs parameter.  This works well, but does not handle nesting.
This commit therefore provides rcu_expedite_gp() to enable expediting
and rcu_unexpedite_gp() to cancel a prior rcu_expedite_gp(), both of
which support nesting.

Reported-by: Arjan van de Ven 
Signed-off-by: Paul E. McKenney 
---
 include/linux/rcupdate.h | 20 
 kernel/rcu/update.c  | 48 
 2 files changed, 68 insertions(+)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 9d3d0e1d0766..0189ac088c67 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -48,6 +48,26 @@
 
 extern int rcu_expedited; /* for sysctl */
 
+#ifdef CONFIG_TINY_RCU
+/* Tiny RCU doesn't expedite, as its purpose in life is instead to be tiny. */
+static inline bool rcu_gp_is_expedited(void)  /* Internal RCU use. */
+{
+   return false;
+}
+
+static inline void rcu_expedite_gp(void)
+{
+}
+
+static inline void rcu_unexpedite_gp(void)
+{
+}
+#else /* #ifdef CONFIG_TINY_RCU */
+bool rcu_gp_is_expedited(void);  /* Internal RCU use. */
+void rcu_expedite_gp(void);
+void rcu_unexpedite_gp(void);
+#endif /* #else #ifdef CONFIG_TINY_RCU */
+
 enum rcutorture_type {
RCU_FLAVOR,
RCU_BH_FLAVOR,
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 8864ed90f0d7..44a74c24936a 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -62,6 +62,54 @@ MODULE_ALIAS("rcupdate");
 
 module_param(rcu_expedited, int, 0);
 
+#ifndef CONFIG_TINY_RCU
+
+static atomic_t rcu_expedited_nesting;
+
+/*
+ * Should normal grace-period primitives be expedited?  Intended for
+ * use within RCU.  Note that this function takes the rcu_expedited
+ * sysfs/boot variable into account as well as the rcu_expedite_gp()
+ * nesting.  So looping on rcu_unexpedite_gp() until rcu_gp_is_expedited()
+ * returns false is a -really- bad idea.
+ */
+bool rcu_gp_is_expedited(void)
+{
+   return rcu_expedited || atomic_read(_expedited_nesting);
+}
+EXPORT_SYMBOL_GPL(rcu_gp_is_expedited);
+
+/**
+ * rcu_expedite_gp - Expedite future RCU grace periods
+ *
+ * After a call to this function, future calls to synchronize_rcu() and
+ * friends act as the corresponding synchronize_rcu_expedited() function
+ * had instead been called.
+ */
+void rcu_expedite_gp(void)
+{
+   atomic_inc(_expedited_nesting);
+}
+EXPORT_SYMBOL_GPL(rcu_expedite_gp);
+
+/**
+ * rcu_unexpedite_gp - Cancel prior rcu_expedite_gp() invocation
+ *
+ * Undo a prior call to rcu_expedite_gp().  If all prior calls to
+ * rcu_expedite_gp() are undone by a subsequent call to rcu_unexpedite_gp(),
+ * and if the rcu_expedited sysfs/boot parameter is not set, then all
+ * subsequent calls to synchronize_rcu() and friends will return to
+ * their normal non-expedited behavior.
+ */
+void rcu_unexpedite_gp(void)
+{
+   atomic_dec(_expedited_nesting);
+}
+EXPORT_SYMBOL_GPL(rcu_unexpedite_gp);
+
+#endif /* #ifndef CONFIG_TINY_RCU */
+
+
 #ifdef CONFIG_PREEMPT_RCU
 
 /*
-- 
1.8.1.5

--
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 RFC tip/core/rcu 4/4] rcu: Add Kconfig option to expedite grace periods during boot

[Paul E. McKenney]

From: "Paul E. McKenney" 

This commit adds a CONFIG_RCU_EXPEDITE_BOOT Kconfig parameter
that emulates a very early boot rcu_expedite_gp().  A late-boot
call to rcu_end_inkernel_boot() will provide the corresponding
rcu_unexpedite_gp().  The late-boot call to rcu_end_inkernel_boot()
should be made just before init is spawned.

Reported-by: Arjan van de Ven 
Signed-off-by: Paul E. McKenney 
---
 include/linux/rcupdate.h |  1 +
 init/Kconfig | 13 +
 kernel/rcu/update.c  | 11 ++-
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 0189ac088c67..573a5afd5ed8 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -287,6 +287,7 @@ static inline int rcu_preempt_depth(void)
 
 /* Internal to kernel */
 void rcu_init(void);
+void rcu_end_inkernel_boot(void);
 void rcu_sched_qs(void);
 void rcu_bh_qs(void);
 void rcu_check_callbacks(int user);
diff --git a/init/Kconfig b/init/Kconfig
index 1354ac09b516..ece7e9380867 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -791,6 +791,19 @@ config RCU_NOCB_CPU_ALL
 
 endchoice
 
+config RCU_EXPEDITE_BOOT
+   bool
+   default n
+   help
+ This option enables expedited grace periods at boot time,
+ as if rcu_expedite_gp() had been invoked early in boot.
+ The corresponding rcu_unexpedite_gp() is invoked from
+ rcu_end_inkernel_boot(), which is intended to be invoked
+ at the end of the kernel-only boot sequence, just before
+ init is exec'ed.
+
+ Accept the default if unsure.
+
 endmenu # "RCU Subsystem"
 
 config BUILD_BIN2C
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 44a74c24936a..1f133350da01 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -64,7 +64,8 @@ module_param(rcu_expedited, int, 0);
 
 #ifndef CONFIG_TINY_RCU
 
-static atomic_t rcu_expedited_nesting;
+static atomic_t rcu_expedited_nesting =
+   ATOMIC_INIT(IS_ENABLED(CONFIG_RCU_EXPEDITE_BOOT) ? 1 : 0);
 
 /*
  * Should normal grace-period primitives be expedited?  Intended for
@@ -109,6 +110,14 @@ EXPORT_SYMBOL_GPL(rcu_unexpedite_gp);
 
 #endif /* #ifndef CONFIG_TINY_RCU */
 
+/*
+ * Inform RCU of the end of the in-kernel boot sequence.
+ */
+void rcu_end_inkernel_boot(void)
+{
+   if (IS_ENABLED(CONFIG_RCU_EXPEDITE_BOOT))
+   rcu_unexpedite_gp();
+}
 
 #ifdef CONFIG_PREEMPT_RCU
 
-- 
1.8.1.5

--
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 RFC tip/core/rcu 3/4] rcu: Update from rcu_expedited variable to rcu_gp_is_expedited()

[Paul E. McKenney]

From: "Paul E. McKenney" 

This commit updates open-coded tests of the rcu_expedited variable
to instead use rcu_gp_is_expedited().

Signed-off-by: Paul E. McKenney 
---
 kernel/rcu/srcu.c| 2 +-
 kernel/rcu/tree.c| 9 +
 kernel/rcu/tree_plugin.h | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
index 81f53b504c18..cad76e76b4e7 100644
--- a/kernel/rcu/srcu.c
+++ b/kernel/rcu/srcu.c
@@ -490,7 +490,7 @@ static void __synchronize_srcu(struct srcu_struct *sp, int 
trycount)
  */
 void synchronize_srcu(struct srcu_struct *sp)
 {
-   __synchronize_srcu(sp, rcu_expedited
+   __synchronize_srcu(sp, rcu_gp_is_expedited()
   ? SYNCHRONIZE_SRCU_EXP_TRYCOUNT
   : SYNCHRONIZE_SRCU_TRYCOUNT);
 }
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 715e7bb35852..5fb9888af6d5 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3064,7 +3064,7 @@ void synchronize_sched(void)
   "Illegal synchronize_sched() in RCU-sched read-side 
critical section");
if (rcu_blocking_is_gp())
return;
-   if (rcu_expedited)
+   if (rcu_gp_is_expedited())
synchronize_sched_expedited();
else
wait_rcu_gp(call_rcu_sched);
@@ -3091,7 +3091,7 @@ void synchronize_rcu_bh(void)
   "Illegal synchronize_rcu_bh() in RCU-bh read-side 
critical section");
if (rcu_blocking_is_gp())
return;
-   if (rcu_expedited)
+   if (rcu_gp_is_expedited())
synchronize_rcu_bh_expedited();
else
wait_rcu_gp(call_rcu_bh);
@@ -3783,11 +3783,12 @@ static int rcu_pm_notify(struct notifier_block *self,
case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
if (nr_cpu_ids <= 256) /* Expediting bad for large systems. */
-   rcu_expedited = 1;
+   rcu_expedite_gp();
break;
case PM_POST_HIBERNATION:
case PM_POST_SUSPEND:
-   rcu_expedited = 0;
+   if (nr_cpu_ids <= 256) /* Expediting bad for large systems. */
+   rcu_unexpedite_gp();
break;
default:
break;
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 65629cc3c6cf..d11612ff3daa 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -572,7 +572,7 @@ void synchronize_rcu(void)
   "Illegal synchronize_rcu() in RCU read-side critical 
section");
if (!rcu_scheduler_active)
return;
-   if (rcu_expedited)
+   if (rcu_gp_is_expedited())
synchronize_rcu_expedited();
else
wait_rcu_gp(call_rcu);
-- 
1.8.1.5

--
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 tip/core/rcu 0/4] Programmatic nestable expedited grace periods

[Paul E. McKenney]

Hello!

This series, possibly for v3.21, contains changes that allow in-kernel
code to specify that all subsequent synchronous grace-period primitives
(synchronize_rcu() and friends) be expedited.  New rcu_expedite_gp()
and rcu_unexpedite_gp() primitives enable and disable expediting,
and these may be nested.  Note that the rcu_expedited boot/sysfs
variable, if non-zero, causes expediting to happen regardless of calls
to rcu_expedite_gp().

Because one of the use cases for these primitives is to expedite
grace periods during the in-kernel portion of boot, a new Kconfig
parameter named CONFIG_RCU_EXPEDITE_BOOT causes the kernel to act
as if rcu_expedite_gp() was called very early in boot.  At the end
of boot (presumably just before init is spawned), a call to
rcu_end_inkernel_boot() will provide the matching rcu_unexpedite_gp()
if required.

The patches in this series are as follows:

1.  Add rcu_expedite_gp() and rcu_unexpedite_gp() functions.

2.  Add rcutorture tests for rcu_expedite_gp() and rcu_unexpedite_gp().

3.  Change open-coded access to the rcu_expedited variable to
instead use a new rcu_gp_is_expedited() function.

4.  Add the CONFIG_RCU_EXPEDITE_BOOT Kconfig parameter and
the rcu_end_inkernel_boot() function.

This passes light rcutorture testing.

Thanx, Paul



 b/include/linux/rcupdate.h |   21 
 b/init/Kconfig |   13 +
 b/kernel/rcu/rcutorture.c  |   24 ++
 b/kernel/rcu/srcu.c|2 -
 b/kernel/rcu/tree.c|9 +++---
 b/kernel/rcu/tree_plugin.h |2 -
 b/kernel/rcu/update.c  |   59 -
 7 files changed, 123 insertions(+), 7 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 1/6] thinkpad_acpi: Remember adaptive kbd presence

[Darren Hart]

On Wed, Feb 18, 2015 at 09:53:28PM +0100, Bastien Nocera wrote:
> Rather than checking on each suspend and resume whether the laptop
> has an adaptive keyboard, check when the driver is initialised.

Reasonable.

> 
> Signed-off-by: Bastien Nocera 
> ---
>  drivers/platform/x86/thinkpad_acpi.c | 38 
> ++--
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index c3d11fa..80db3ce 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
...
> @@ -3226,6 +3227,13 @@ static int __init hotkey_init(struct ibm_init_struct 
> *iibm)
>   if (!tp_features.hotkey)
>   return 1;
>  
> + /* does it have an adaptive keyboard, like
> +  * the Lenovo Carbon X1 2014 (2nd gen) */

Please follow CodingStyle here:

/*
 * Sentence formatting.
 * Second line.
 */

The above is a question, just state what you're doing:

/*
 * Check if we have an adaptive keyboard, like on the
 * Lenovo Carbon X1 2014 (2nd Gen).
 */

> + if (acpi_evalf(hkey_handle, , "MHKV", "qd")) {
> + if ((hkeyv >> 8) == 2)
> + tp_features.has_adaptive_kbd = true;
> + }
> +
>   quirks = tpacpi_check_quirks(tpacpi_hotkey_qtable,
>ARRAY_SIZE(tpacpi_hotkey_qtable));
>  
> @@ -3834,28 +3842,22 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 
> event)
>  
>  static void hotkey_suspend(void)
>  {
> - int hkeyv;
> -
>   /* Do these on suspend, we get the events on early resume! */
>   hotkey_wakeup_reason = TP_ACPI_WAKEUP_NONE;
>   hotkey_autosleep_ack = 0;
>  
>   /* save previous mode of adaptive keyboard of X1 Carbon */
> - if (acpi_evalf(hkey_handle, , "MHKV", "qd")) {
> - if ((hkeyv >> 8) == 2) {
> - if (!acpi_evalf(hkey_handle,
> - _keyboard_prev_mode,
> - "GTRW", "dd", 0)) {
> - pr_err("Cannot read adaptive keyboard mode.\n");
> - }
> + if (tp_features.has_adaptive_kbd) {
> + if (!acpi_evalf(hkey_handle,
> + _keyboard_prev_mode,
> + "GTRW", "dd", 0)) {
> + pr_err("Cannot read adaptive keyboard mode.\n");
>   }
>   }
>  }
>  
>  static void hotkey_resume(void)
>  {
> - int hkeyv;
> -
>   tpacpi_disable_brightness_delay();
>  
>   if (hotkey_status_set(true) < 0 ||
> @@ -3870,14 +3872,12 @@ static void hotkey_resume(void)
>   hotkey_poll_setup_safe(false);
>  
>   /* restore previous mode of adapive keyboard of X1 Carbon */
> - if (acpi_evalf(hkey_handle, , "MHKV", "qd")) {
> - if ((hkeyv >> 8) == 2) {
> - if (!acpi_evalf(hkey_handle,
> - NULL,
> - "STRW", "vd",
> - adaptive_keyboard_prev_mode)) {
> - pr_err("Cannot set adaptive keyboard mode.\n");
> - }
> + if (tp_features.has_adaptive_kbd) {
> + if (!acpi_evalf(hkey_handle,
> + NULL,
> + "STRW", "vd",
> + adaptive_keyboard_prev_mode)) {

You've saved a level of indentation, please group the arguments into fewer
lines, should be two instead of four.

Otherwise, looks good.

-- 
Darren Hart
Intel Open Source Technology Center
--
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 RT 1/2] rwsem-rt: Do not allow readers to nest

[Jason Low]

On Wed, Feb 18, 2015 at 12:13 PM, Steven Rostedt  wrote:
> On Wed, 18 Feb 2015 20:57:10 +0100
> Sebastian Andrzej Siewior  wrote:
>
>> * Steven Rostedt | 2014-04-08 22:47:01 [-0400]:
>>
>> >From: "Steven Rostedt (Red Hat)" 
>> >
>> >The readers of mainline rwsems are not allowed to nest, the rwsems in the
>> >PREEMPT_RT kernel should not nest either.
>>
>> I applied this and this is the reason why cpufreq isn't working. What I
>> see in cpufreq is:
>> | test.sh-788   [004] ...61.416288: store: down_read_try
>> | test.sh-788   [004] ...61.416296: cpufreq_cpu_get: 
>> down_read_try
>> | test.sh-788   [004] ...61.416301: cpufreq_cpu_put.part.6: 
>> up_read
>> | test.sh-788   [004] ...61.416332: store: up_read
>>
>> as you see, one code path takes the read path of rw_sema twice.
>>
>> Looking at the generic implementation, we have:
>> |#define RWSEM_UNLOCKED_VALUE0xL
>> |#define RWSEM_ACTIVE_BIAS   0x0001L
>> |#define RWSEM_WAITING_BIAS  (-RWSEM_ACTIVE_MASK-1)
>>
>> | static inline int __down_read_trylock(struct rw_semaphore *sem)
>> | {
>> | long tmp;
>> |
>> | while ((tmp = sem->count) >= 0) {
>> | if (tmp == cmpxchg(>count, tmp,
>> |tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> | return 1;
>> | }
>> | }
>> | return 0;
>> | }
>>
>> While sem->count is >= 0 we loop and take the semaphore. So we can have
>> five readers at once. The first writer would set count to a negative
>> value resulting in trylock failure.
>>
>> |static inline void __down_read(struct rw_semaphore *sem)
>> |{
>> |if (unlikely(atomic_long_inc_return((atomic_long_t*)>count) <= 
>> 0))
>> |rwsem_down_read_failed(sem);
>> |}
>>
>> Here the same thing but without cmpxchg(). _If_ after an increment the
>> value is negative then we take slowpath. Otherwise we have the lock.
>
> OK, so I need to make it so it can nest with trylock. I have to look at
> the patch again because it has been a while.

When we reported this a few months ago, Thomas provided the following
patch to fix the issue (which essentially reverted the patch) and
appeared to be agreed on:

https://lkml.org/lkml/2014/11/5/844
--
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/6] CRIS: remove SMP code

[Mikael Starvik]

There was a discussions about making a SMP CRIS once and the code actually ran 
on emulator. But I guess something went wrong during uppstreamimg. Anyway there 
is no real silicone so removing it is correct.

> 20 feb 2015 kl. 01:06 skrev "Paul Bolle" :
> 
>> On Thu, 2015-02-19 at 20:29 +0100, Rabin Vincent wrote:
>> The CRIS SMP code cannot be built since there is no (and appears to
>> never have been) a CONFIG_SMP Kconfig option in arch/cris/.  Remove it.
> 
> Yes, it appears there never was a Kconfig symbol SMP for cris so this
> probably was dead code ever since it was added in, I think, v2.6.13. (I
> should mention I didn't review this patch, or cris' apparently
> non-functional SMP code, in detail.)
> 
> Mind if I ask how you spotted this?
> 
> 
> Paul Bolle
> 
--
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: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[Benjamin Herrenschmidt]

On Fri, 2015-02-20 at 16:01 +1100, Benjamin Herrenschmidt wrote:
> Hi Sreekanth !
> 
> While looking at some (unrelated) issue where mtp2sas seems to be using
> 32-bit DMA instead of 64-bit DMA on some POWER platforms, I noticed this
> patch which was merged as 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c.
> 
> Can you confirm my understanding that you are:
> 
>  - Setting the DMA mask to 32-bit
> 
>  - Mapping pages for DMA
> 
>  - Changing the DMA mask to 64-bit
> 
> ?
> 
> If yes, then I don't think this is a legal thing to do and definitely
> not something supported by all architectures. It might work by accident,
> but there is no telling that any translation/DMA mapping provided before
> a call to set_dma_mask() is still valid after that call.
> 
> The architecture might have to completely reconfigure the iommu, for
> example on some PowerPC platforms, we switch from a remapped mapping to
> a direct linear map of all memory, all translations established before
> the switch might be lost (it depends on the specific implementation).
> 
> How does it work on x86 with DMAR ?

Note that even on powerpc platforms where it would work because we
maintain both 32-bit and 64-bit bypass windows in the device address
space simultaneously, you will leak iommu entries unless you also switch
back to 32-bit when freeing the 32-bit mappings... (and you would
probably crash if you tried to free a 64-bit mapping while in 32-bit
mode).

The iommu APIs weren't designed with that "switching mask" facility in
mind...

Ben.


--
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/

Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[Benjamin Herrenschmidt]

Hi Sreekanth !

While looking at some (unrelated) issue where mtp2sas seems to be using
32-bit DMA instead of 64-bit DMA on some POWER platforms, I noticed this
patch which was merged as 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c.

Can you confirm my understanding that you are:

 - Setting the DMA mask to 32-bit

 - Mapping pages for DMA

 - Changing the DMA mask to 64-bit

?

If yes, then I don't think this is a legal thing to do and definitely
not something supported by all architectures. It might work by accident,
but there is no telling that any translation/DMA mapping provided before
a call to set_dma_mask() is still valid after that call.

The architecture might have to completely reconfigure the iommu, for
example on some PowerPC platforms, we switch from a remapped mapping to
a direct linear map of all memory, all translations established before
the switch might be lost (it depends on the specific implementation).

How does it work on x86 with DMAR ?

Cheers,
Ben.


--
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] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Alexandre Courbot]

On Fri, Feb 20, 2015 at 9:30 AM, Dmitry Torokhov
 wrote:
> Given the intent behind gpiod_get_optional() and friends it does not make
> sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
> work just fine without gpio so let's behave as if gpio was not found.
> Otherwise we have to special-case -ENOSYS in drivers.

Interestingly Uwe sent a RFC for this one week ago:

http://patchwork.ozlabs.org/patch/439135/

Maybe credit him with a Suggested-by.?

I should have commented at that time, but let's do it now: I agree
with the idea, but this leaves the door open to confusing situations
in case gpiolib was unintentionally disabled. Could you also add a
note in the documentation of this function to explain this behavior,
to spare a few headaches to users of this function?

>
> Signed-off-by: Dmitry Torokhov 
> ---
>  include/linux/gpio/consumer.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> index fd85cb1..f68244f 100644
> --- a/include/linux/gpio/consumer.h
> +++ b/include/linux/gpio/consumer.h
> @@ -132,14 +132,14 @@ static inline struct gpio_desc *__must_check
>  __gpiod_get_optional(struct device *dev, const char *con_id,
>  enum gpiod_flags flags)
>  {
> -   return ERR_PTR(-ENOSYS);
> +   return NULL;
>  }
>
>  static inline struct gpio_desc *__must_check
>  __gpiod_get_index_optional(struct device *dev, const char *con_id,
>unsigned int index, enum gpiod_flags flags)
>  {
> -   return ERR_PTR(-ENOSYS);
> +   return NULL;
>  }
>
>  static inline void gpiod_put(struct gpio_desc *desc)
> @@ -171,14 +171,14 @@ static inline struct gpio_desc *__must_check
>  __devm_gpiod_get_optional(struct device *dev, const char *con_id,
>   enum gpiod_flags flags)
>  {
> -   return ERR_PTR(-ENOSYS);
> +   return NULL;
>  }
>
>  static inline struct gpio_desc *__must_check
>  __devm_gpiod_get_index_optional(struct device *dev, const char *con_id,
> unsigned int index, enum gpiod_flags flags)
>  {
> -   return ERR_PTR(-ENOSYS);
> +   return NULL;
>  }
>
>  static inline void devm_gpiod_put(struct device *dev, struct gpio_desc *desc)
> --
> 2.2.0.rc0.207.ga3a616c
>
>
> --
> Dmitry
--
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 v6 0/2] gpio: add GPIO hogging mechanism

[Alexandre Courbot]

On Thu, Feb 19, 2015 at 2:23 AM, Benoit Parrot  wrote:
> Gentle ping.
>
> Is there any chance this will make it in 3.21?

I'm good with it - Linus will probably come to it after the 3.20 merge
window closes.
--
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 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!

[Steven Rostedt]

On Thu, 19 Feb 2015 18:31:05 -0700
Thavatchai Makphaibulchoke  wrote:

> This patch fixes the problem that the ownership of a mutex acquired by an
> interrupt handler(IH) gets incorrectly attributed to the interrupted thread.

*blink*

> 
> This could result in an incorrect deadlock detection in function
> rt_mutex_adjust_prio_chain(), causing thread to be killed and possibly leading
> up to a system hang.

I highly doubt this is an incorrect deadlock that was detected. My
money is on a real deadlock that happened.

> 
> Here is the approach taken: when calling from an interrupt handler, instead of
> attributing ownership to the interrupted task, use a reserved task_struct 
> value
> to indicate that the owner is a interrupt handler.  This approach avoids the
> incorrect deadlock detection.

How is this an incorrect deadlock? Please explain.

> 
> This also includes changes in several function in rtmutex.c now that the 
> lock's
> requester may be a interrupt handler, not a real task struct.  This impacts
> the way how the lock is acquired and prioritized and decision whether to do
> the house keeping functions required for a real task struct.
> 
> The reserved task_struct values for interrupt handler are
> 
>   current | 0x2
> 
> where current is the task_struct value of the interrupted task.
> 
> Since IH will both acquire and release the lock only during an interrupt
> handling, during which current is not changed, the reserved task_struct value
> for an IH should be distinct from another instances of IH on a different cpu.
> 

The interrupt handler is a thread just like any other task. It's not
special. If there was a deadlock detected, it most likely means that a
deadlock exists.

-- Steve


> Kernel version 3.14.25 + patch-3.14.25-rt22
> 
> Signed-off-by: T. Makphaibulchoke 
> ---
>  include/linux/spinlock_rt.h |   4 +
>  kernel/locking/rtmutex-debug.c  |  15 ++-
>  kernel/locking/rtmutex.c| 212 
> 
>  kernel/locking/rtmutex_common.h |  21 
>  kernel/timer.c  |   4 +-
>  5 files changed, 188 insertions(+), 68 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 v2] x86: fix output of show_stack_log_lvl()

[Steven Rostedt]

On Fri, 20 Feb 2015 03:34:21 +0100
Adrien Schildknecht  wrote:

> show_stack_log_lvl() does not set the log level after a new line,
> the following messages printed with pr_cont are thus assigned to the
> default log level.

This looks like a bug in printk(). Why doesn't pr_cont() continue? It
shouldn't care if there's a newline or not. pr_cont() is supposed to
continue whatever the last printk log level was.

If this is broken here, it's probably broken elsewhere. The fix is to
fix printk, not to hunt and peck for the places with work arounds that
are broken by it.

-- Steve

> This patch prepends the log level to the next message following a new
> line.
> 
> print_trace_address() uses printk(log_lvl). Using printk with just
> a log level is ignored and thus has no effect on the next pr_cont.
> We need to prepend the log level directly into the message.
> 
> Signed-off-by: Adrien Schildknecht 
--
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/4] powerpc/mpic: remove unused functions

[Arseny Solokha]

> If I just get a patch saying "removed unused foo()", I have to go and dig and
> find out:
>   - was it recently added and will be used soon?
>   - is it ancient and never used, if so can we work out why, ie. feature X
> never landed so this code is no longer needed.
>   - is it old code that *was* used but isn't now because commit ... removed 
> the
> last user.
>   - is it code that *should* be used, but isn't for some odd reason?
>
>
> So if you can provide that sort of detail for me, that really adds value to 
> the
> patch. Otherwise the patch is basically just a TODO for me, to go and work out
> why the code is unused.

Got it. Will resend the whole series one of these days.

Arsény


> cheers
--
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 v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

On Fri, Feb 20, 2015 at 11:07:21AM +0800, zhangfei wrote:
> Hi, Balbi
> 
> On 02/18/2015 10:35 PM, Felipe Balbi wrote:
> >On Wed, Feb 18, 2015 at 01:44:21PM +0800, zhangfei wrote:
> >>Hi, Kishon
> >>
> >>On 02/18/2015 01:35 PM, Kishon Vijay Abraham I wrote:
> >>>Hi,
> >>>
> >>>On Thursday 12 February 2015 01:07 PM, Zhangfei Gao wrote:
> Add usb phy controller for hi6220 platform
> 
> Signed-off-by: Zhangfei Gao 
> ---
>   drivers/phy/Kconfig  |   9 ++
>   drivers/phy/Makefile |   1 +
>   drivers/phy/phy-hi6220-usb.c | 306
> +++
>   3 files changed, 316 insertions(+)
>   create mode 100644 drivers/phy/phy-hi6220-usb.c
> >>>
> >>>why is this driver in drivers/phy when it doesn't use the generic PHY
> >>>framework at all?
> >>>
> >>
> >>Balbi recommended "new drivers only on drivers/phy/", including usb
> >>phy.
> >
> >but it should use the API too. It's not only about a directory, you need
> >to use the new API.
> >
> >>So Move drivers/usb/phy/phy-hi6220-usb.c to
> >>drivers/phy/phy-hi6220-usb.c, required by Balbi.
> >
> >you're reading what I stated the way you like.
> 
> Sorry for my bad understanding.
> 
> Still not clear about the otg_set_peripheral, which is required in
> phy-hi6220-usb.c
> 
> 1. drivers/usb/dwc2/gadget.c use
> otg_set_peripheral(hsotg->uphy->otg, >gadget);
> 
> 2. include/linux/phy/phy.h
> struct phy do not have member otg, while struct usb_phy has.
> 
> Could you give more hints?

your set_peripheral doesn't do anything, just holds a pointer. Might as
well not implement it. I'll review your driver more fully tomorrow.

There a few things which must be changed.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] efi: fix boundary checking in efi_high_alloc()

[Yinghai Lu]

While adding support loading kernel and initrd above 4G to grub2 in legacy
mode, I was referring to efi_high_alloc().
That will allocate buffer for kernel and then initrd, and initrd will
use kernel buffer start as limit.

During testing found two buffers will be overlapped when initrd size is
very big like 400M.

It turns out efi_high_alloc() boundary checking is not right.
end - size will be the new start, and should not compare new
start with max, we need to make sure end is smaller than max.

Signed-off-by: Yinghai Lu 

---
 drivers/firmware/efi/libstub/efi-stub-helper.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/drivers/firmware/efi/libstub/efi-stub-helper.c
===
--- linux-2.6.orig/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ linux-2.6/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -183,12 +183,12 @@ again:
start = desc->phys_addr;
end = start + desc->num_pages * (1UL << EFI_PAGE_SHIFT);
 
-   if ((start + size) > end || (start + size) > max)
-   continue;
-
-   if (end - size > max)
+   if (end > max)
end = max;
 
+   if ((start + size) > end)
+   continue;
+
if (round_down(end - size, align) < start)
continue;
 
--
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 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

[Jeff Kirsher]

On Fri, 2015-02-20 at 00:59 +, Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto 
> 
> The limitation of the number of multicast address for VF is not enough
> for the large scale server with SR-IOV feature.
> IPv6 requires the multicast MAC address for each IP address to handle
> the Neighbor Solicitation message.
> We couldn't assign over 30 IPv6 addresses to a single VF interface.
> 
> The easy way to solve this is enabling multicast promiscuous mode.
> It is good to have a functionality to enable multicast promiscuous
> mode
> for each VF from VF driver.
> 
> This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
> enable/disable multicast promiscuous mode in VF. If multicast
> promiscuous
> mode is enabled the VF can receive all multicast packets.
> 
> With this patch, the ixgbevf driver automatically enable multicast
> promiscuous mode when the number of multicast addresses is over than
> 30
> if possible.
> 
> This also bump the API version up to 1.2 to check whether the API,
> IXGBE_VF_SET_MC_PROMISC is available.
> 
> Signed-off-by: Hiroshi Shimamoto 
> Reviewed-by: Hayato Momma 
> CC: Choi, Sy Jong 
> ---
> 
> This patchset is against Jeff's tree.
> 
> cfba326 e1000e: Fix 82574/82583 TimeSync errata handling for SYSTIM
> read
> 
> The tree hasn't haven the fix of the IPv6 checksum issue yet,
> but I cherry-picked the commit and tested.
> 
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h  |  1 +
>  drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h  |  4 ++
>  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 88
> ++-
>  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++-
>  drivers/net/ethernet/intel/ixgbevf/mbx.h  |  4 ++
>  drivers/net/ethernet/intel/ixgbevf/vf.c   | 28 +++-
>  drivers/net/ethernet/intel/ixgbevf/vf.h   |  1 +
>  7 files changed, 135 insertions(+), 4 deletions(-)

I have added this to my queue, thanks!


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 3/3] ixgbe: Add new ndo to allow VF multicast promiscuous mode

[Jeff Kirsher]

On Fri, 2015-02-20 at 01:01 +, Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto 
> 
> Implements the new netdev op to allow VF multicast promiscuous mode.
> 
> The administrator can allow to VF multicast promiscuous mode for only
> trusted VM. After allowing multicast promiscuous mode from the host,
> we can use over 30 IPv6 addresses on VM.
>  # ./ip link set dev eth0 vf 1 mc_promisc on
> 
> When disallowing multicast promiscuous mode, we can only use 30 IPv6
> addresses.
>  # ./ip link set dev eth0 vf 1 mc_promisc off
> 
> Signed-off-by: Hiroshi Shimamoto 
> Reviewed-by: Hayato Momma 
> CC: Choi, Sy Jong 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 +
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  |  7 ++
>  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 35
> --
>  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h |  2 ++
>  4 files changed, 43 insertions(+), 2 deletions(-)

I have added this to my queue, thanks!


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control

[Jeff Kirsher]

On Fri, 2015-02-20 at 01:00 +, Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto 
> 
> Add netlink directives and ndo entry to allow VF multicast promiscuous
> mode.
> 
> The administrator wants to allow dedicatedly multicast promiscuous per
> VF.
> 
> Signed-off-by: Hiroshi Shimamoto 
> Reviewed-by: Hayato Momma 
> CC: Choi, Sy Jong 
> ---
>  include/linux/if_link.h  |  1 +
>  include/linux/netdevice.h|  3 +++
>  include/uapi/linux/if_link.h |  6 ++
>  net/core/rtnetlink.c | 18 --
>  4 files changed, 26 insertions(+), 2 deletions(-)

I have added this to my queue, thanks!


signature.asc
Description: This is a digitally signed message part

Re: [RFC PATCH v3 15/26] early kprobes: x86: directly modify code.

[Masami Hiramatsu]

(2015/02/13 14:40), Wang Nan wrote:
> When registering early kprobes, SMP should has not been enabled, so
> doesn't require synchronization in text_poke_bp(). Simply memcpy is
> enough.

BTW, we've already have text_poke_early for this purpose.

Thank you,

> 
> Signed-off-by: Wang Nan 
> ---
>  arch/x86/kernel/kprobes/opt.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
> index 0dd8d08..21847ab 100644
> --- a/arch/x86/kernel/kprobes/opt.c
> +++ b/arch/x86/kernel/kprobes/opt.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "common.h"
>  
> @@ -397,8 +398,15 @@ void arch_optimize_kprobes(struct list_head *oplist)
>   insn_buf[0] = RELATIVEJUMP_OPCODE;
>   *(s32 *)(_buf[1]) = rel;
>  
> - text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE,
> -  op->optinsn.insn);
> + if (unlikely(kprobes_is_early())) {
> + BUG_ON(!(op->kp.flags & KPROBE_FLAG_EARLY));
> + memcpy(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE);
> + local_flush_tlb();
> + sync_core();
> + } else {
> + text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE,
> +  op->optinsn.insn);
> + }
>  
>   list_del_init(>list);
>   }
> 


-- 
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: [RFC PATCH v3 00/26] Early kprobe: enable kprobes at very early booting stage.

[Masami Hiramatsu]

Hi,

Sorry for replying late.

(2015/02/13 14:39), Wang Nan wrote:
> I fell very sorry for people who reviewed my v2 patch series yesterday
> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
> information in commit log. This v3 patch series add those missing
> commit messages. There are also 2 small fix based on v2:
>
>  1. Fixes ftrace_sort_mcount_area. Original patch doesn't work for module.
>  2. Wraps setting of kprobes_initialized in stop_machine() context.

>From the viewpoint of the maintenance, it seems over-engineered and
not general implementation. Please reconsider just initializing breakpoint
handler in earlier stage. Since those exceptions may happen anywhere,
those trap handlers setup very early stage. E.g. on x86, setup_arch()
setup early_trap_init() at beginning. So we just need to initialize
kprobes earlier.
I think this is almost enough for debugging, and very general because
we don't need optprobe for porting to other arch.

And for ftrace-based kprobe, we can just put breakpoint on mcount call at
beginning. ftrace will need to check and keep it when replacing mcount-call
with nop. Afterward, we can cleanly update those kprobes with ftrace-based
kprobe.

So, please start with smaller changes.

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/

[GIT PULL] KGDB/KDB fixes for 3.20-rc1

[Jason Wessel]

Linus,

Please pull the kgdb tree.

Summary of changes:

New:
   * KDB: improved searching
   * No longer enter debug core on panic if panic timeout is set

KGDB/KDB regressions / cleanups
   * fix pdf doc build errors
   * prevent junk characters on kdb console from printk levels

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linus-3.20-rc1

Thanks,
Jason.

The following changes since commit bfa76d49576599a4b9f9b7a71f23d73d6dcff735:

  Linux 3.19 (2015-02-08 18:54:22 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git 
tags/for_linux-3.20-rc1

for you to fetch changes up to dd8f30cc0550f36861ddfa42c27cc5c580b0bf8c:

  kgdb, docs: Fix  pdfdocs build errors (2015-02-19 12:39:04 -0600)


KGDB/KDB New:
   * KDB: improved searching
   * No longer enter debug core on panic if panic timeout is set

KGDB/KDB regressions / cleanups
   * fix pdf doc build errors
   * prevent junk characters on kdb console from printk levels


Colin Cross (1):
  debug: prevent entering debug mode on panic/exception.

Daniel Thompson (5):
  kdb: Avoid printing KERN_ levels to consoles
  kdb: Remove stack dump when entering kgdb due to NMI
  kdb: Fix a prompt management bug when using | grep
  kdb: Provide forward search at more prompt
  kdb: Const qualifier for kdb_getstr's prompt argument

Jason Wessel (1):
  kdb: Fix off by one error in kdb_cpu()

Jay Lan (1):
  kdb: fix incorrect counts in KDB summary command output

Rajaneesh Acharya (1):
  kgdb, docs: Fix  pdfdocs build errors

 Documentation/DocBook/kgdb.tmpl |  6 +++---
 include/linux/kdb.h |  8 +++-
 kernel/debug/debug_core.c   | 19 ++-
 kernel/debug/kdb/kdb_io.c   | 46 
++
 kernel/debug/kdb/kdb_main.c | 16 
 kernel/debug/kdb/kdb_private.h  |  4 +++-
 kernel/printk/printk.c  |  2 +-
 7 files changed, 74 insertions(+), 27 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] kasan, module, vmalloc: rework shadow allocation for modules

[Rusty Russell]

Andrey Ryabinin  writes:
> On 02/19/2015 02:10 AM, Rusty Russell wrote:
>> This is not portable.  Other archs don't use vmalloc, or don't use
>> (or define) MODULES_VADDR.  If you really want to hook here, you'd
>> need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).
>> 
>
> Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
> I could hide this into arch-specific function: 
> 'kasan_need_to_allocate_shadow(const void *addr)'
> or make make all those functions weak and allow arch code to redefine them.

That adds another layer of indirection.  And how would the caller of
plain vmalloc() even know what to return?

>> Thus I think modifying the callers is the better choice.
>> 
>
> I could suggest following (though, I still prefer 'modifying vmalloc' 
> approach):
>   * In do_init_module(), instead of call_rcu(>rcu, do_free_init);
> use synchronyze_rcu() + module_memfree(). Of course this will be
>   under CONFIG_KASAN.

But it would be slow, and a disparate code path, which is usually a bad
idea.

> As you said there other module_memfree() users, so what if they will 
> decide
> to free memory in atomic context?

Hmm, how about a hybrid:

1) Add kasan_module_alloc(p, size) after module alloc as your original.
2) Hook into vfree(), and ignore it if you can't find the map.

Or is the latter too expensive?

Cheers,
Rusty.
--
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] pci: spear: Drop __initdata from spear13xx_pcie_driver

[Viresh Kumar]

On 19 February 2015 at 23:11, Matwey V. Kornilov  wrote:
> spear13xx_pcie_driver.driver is allocated in text.init section
> and then the pointer to it is passed futher. This patch is to avoid
> crashes like the following, when freed memory is used.
>
> Also, __init has been dropped from the probe() function referred from the 
> struct
> and all called functions.
>
>  #0  __device_attach (drv=0xc0ed5608 , 
> data=0xdb622610) at ../drivers/base/dd.c:409
>  #1  0xc07a4798 in bus_for_each_drv (bus=, start= out>, data=0xda0, fn=0xc07a6740 <__device_attach>)
> at ../drivers/base/bus.c:463
>  #2  0xc07a6324 in device_attach (dev=0xdb622610) at ../drivers/base/dd.c:447
>  #3  0xc07a5814 in bus_probe_device (dev=0xdb622610) at 
> ../drivers/base/bus.c:558
>  #4  0xc07a38d8 in device_add (dev=) at 
> ../drivers/base/core.c:1058
>  #5  0xc08b6a5c in of_device_add (ofdev=) at 
> ../drivers/of/device.c:66
>  #6  0xc08b742c in of_platform_device_create_pdata (np=, 
> bus_id=0x0 <__vectors_start>, platform_data=0x0 <__vectors_start>,
> parent=) at ../drivers/of/platform.c:241
>  #7  0xc08b7568 in of_platform_bus_create (bus=0xdfa46780, matches=0x0 
> <__vectors_start>, lookup=0x0 <__vectors_start>, parent=0xdb183410,
> strict=true) at ../drivers/of/platform.c:414
>  #8  0xc08b79bc in of_platform_populate (root=0xc0ed5608 
> , matches=0xdb622610, lookup=0xda0,
> parent=0xc07a6740 <__device_attach>) at ../drivers/of/platform.c:501
>  #9  0xbf30 in am335x_child_probe (pdev=0xdb183400) at 
> ../drivers/usb/musb/musb_am335x.c:12
>  #10 0xc07a83f0 in platform_drv_probe (_dev=0xdb183410) at 
> ../drivers/base/platform.c:512
>  #11 0xc07a64e8 in really_probe (drv=, dev=) at 
> ../drivers/base/dd.c:302
>  #12 driver_probe_device (drv=0xbf000234, dev=0xdb183410) at 
> ../drivers/base/dd.c:399
>  #13 0xc07a6820 in __driver_attach (dev=0xdb183410, data=0xbf000234) at 
> ../drivers/base/dd.c:477
>  #14 0xc07a46e8 in bus_for_each_dev (bus=, start= out>, data=0xda0, fn=0xc07a83a4 )
> at ../drivers/base/bus.c:313
>  #15 0xc07a5ebc in driver_attach (drv=) at 
> ../drivers/base/dd.c:496
>  #16 0xc07a5af0 in bus_add_driver (drv=0xbf000234) at 
> ../drivers/base/bus.c:694
>  #17 0xc07a6fec in driver_register (drv=0xbf000234) at 
> ../drivers/base/driver.c:167
>  #18 0xc0209c34 in do_one_initcall (fn=0xbf002000) at ../init/main.c:801
>  #19 0xc02e0494 in do_init_module (mod=) at 
> ../kernel/module.c:3142
>  #20 load_module (info=0xdb6b1f54, uargs=, flags= out>) at ../kernel/module.c:3461
>  #21 0xc02e0a44 in SYSC_finit_module (flags=, uargs= out>, fd=) at ../kernel/module.c:3537
>  #22 SyS_finit_module (fd=7, uargs=-1225602132, flags=0) at 
> ../kernel/module.c:3518
>  #23 0xc021a680 in ?? ()
>
> Signed-off-by: Matwey V. Kornilov 
> ---
> Changes from v2:
>  - Drop __init from all probing functions to allow deferred probing.
> Changes from v1:
>  - Use platform_driver_probe instead of platform_driver_register to make 
> linker happy.
>
>  drivers/pci/host/pcie-designware.c | 2 +-
>  drivers/pci/host/pcie-spear13xx.c  | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index df781cd..5b8a056 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -339,7 +339,7 @@ static const struct irq_domain_ops msi_domain_ops = {
> .map = dw_pcie_msi_map,
>  };
>
> -int __init dw_pcie_host_init(struct pcie_port *pp)
> +int dw_pcie_host_init(struct pcie_port *pp)
>  {
> struct device_node *np = pp->dev->of_node;
> struct platform_device *pdev = to_platform_device(pp->dev);
> diff --git a/drivers/pci/host/pcie-spear13xx.c 
> b/drivers/pci/host/pcie-spear13xx.c
> index 866465f..020d788 100644
> --- a/drivers/pci/host/pcie-spear13xx.c
> +++ b/drivers/pci/host/pcie-spear13xx.c
> @@ -269,7 +269,7 @@ static struct pcie_host_ops spear13xx_pcie_host_ops = {
> .host_init = spear13xx_pcie_host_init,
>  };
>
> -static int __init spear13xx_add_pcie_port(struct pcie_port *pp,
> +static int spear13xx_add_pcie_port(struct pcie_port *pp,
>  struct platform_device *pdev)
>  {
> struct device *dev = >dev;
> @@ -299,7 +299,7 @@ static int __init spear13xx_add_pcie_port(struct 
> pcie_port *pp,
> return 0;
>  }
>
> -static int __init spear13xx_pcie_probe(struct platform_device *pdev)
> +static int spear13xx_pcie_probe(struct platform_device *pdev)
>  {
> struct spear13xx_pcie *spear13xx_pcie;
> struct pcie_port *pp;
> @@ -370,7 +370,7 @@ static const struct of_device_id 
> spear13xx_pcie_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, spear13xx_pcie_of_match);
>
> -static struct platform_driver spear13xx_pcie_driver __initdata = {
> +static struct platform_driver spear13xx_pcie_driver = {
> .probe  = spear13xx_pcie_probe,
> .driver = {
> .name   = "spear-pcie",

Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G

[Yinghai Lu]

On Thu, Feb 19, 2015 at 6:13 PM, Baoquan He  wrote:
> On 02/18/15 at 11:47am, Yinghai Lu wrote:
>
> Kaslr need both virtual and physical address be randomized, otherwise
> it doesn't make sense. Please check what hpa said about this issue:
>
> https://lkml.org/lkml/2014/10/13/350
>

If I read correctly, it could be separated. phy one could be on bootloader
and virtual could be in kernel.

> And usually no bootloader often load kernel onto a random physical
> address. Fow now we can often see kexec/kdump did this. I believe Kees
> introduced kaslr to mainly solve security issue of normal kernel which
> is not like kexec/kdump for testing or debugging. Randomizing physical
> address makes sense for kaslr feature.

I put some grub2 patches that extend grub2 to load kernel/initrd above
4G into github tree.

https://github.com/yhlu/grub2.git

main purpose for that feature is to handle initrd that bigger than 4G.

or you can try you solution on system that have 64bit EFI support,
then you will don't need to
worry about set ident mapping even.

Thanks

Yinghai
--
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/4] powerpc/mpic: remove unused functions

[Michael Ellerman]

On Thu, 2015-02-19 at 19:26 +0700, Arseny Solokha wrote:
> > On Mon, 2015-02-16 at 17:56 +0700, Arseny Solokha wrote:
> >> Drop unused fsl_mpic_primary_get_version(), mpic_set_clk_ratio(),
> >> mpic_set_serial_int().
> >
> > I'm always happy to remove unused code, but the interesting question is why 
> > are
> > they unused? Please tell me in the changelog.
> 
> To being able to give a definitive answer, it's necessary to understand
> the intentions of original developers of these pieces. I just can tell
> these functions have no users and trivial grepping easily proves it;
> I've got the impression they are here only for the sake of
> implementation completeness.

Yeah OK. I didn't expect you to read the minds of the developers who wrote the
code :)
 
> Two machines at hands, e300 and e500 based, boot and run without
> regressions on my workload with this series applied. The removed code
> seems also been rarely touched, so it seems the series is safe at least
> in general. But I can't obviously express any strong point in support of
> the series, so it's completely OK to leave things as is.

OK that's a good data point.

>   + fsl_mpic_primary_get_version() is just a safe wrapper around
> fsl_mpic_get_version() for SMP configurations. While the latter is
> called explicitly for handling PIC initialization and setting up error
> interrupt vector depending on PIC hardware version, the former isn't
> used for anything.
> 
>   + As for mpic_set_clk_ratio() and mpic_set_serial_int(), they both
> are almost nine years old[1] but still have no chance to be called even
> from out-of-tree modules because they both are __init and of course
> aren't exported. Non-demanded functionality?
> 
> Of course I'll include the last two paragraphs into the V2 patch
> description if the explanation is convincing enough and you ACK it. If
> the patch is safe it's also necessary to extend it a bit, making its
> second part actually a complete revert of [1].
> 
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2006-June/023867.html

That is more like what I was looking for.

If I just get a patch saying "removed unused foo()", I have to go and dig and
find out:
  - was it recently added and will be used soon?
  - is it ancient and never used, if so can we work out why, ie. feature X
never landed so this code is no longer needed.
  - is it old code that *was* used but isn't now because commit ... removed the
last user.
  - is it code that *should* be used, but isn't for some odd reason?


So if you can provide that sort of detail for me, that really adds value to the
patch. Otherwise the patch is basically just a TODO for me, to go and work out
why the code is unused.

cheers


--
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] clk: Only recalculate the rate if needed

[Mike Turquette]

Quoting Tomeu Vizoso (2015-02-06 06:13:01)
> We don't really need to recalculate the effective rate of a clock when a
> per-user clock is removed, if the constraints of the later aren't
> limiting the requested rate.
> 
> This was causing problems with clocks that never had a rate set before,
> as rate_req would be zero. Though this could be considered a bug in the
> implementation of those clocks, this should be checked somewhere else.
> 
> Cc: Thierry Reding 
> Cc: Peter De Schrijver 
> Signed-off-by: Tomeu Vizoso 

Fixes: 1c8e600440c7 ("clk: Add rate constraints to clocks")

Applied to clk-next. With this fix sunxi no longer vomits WARNs
everywhere due to divide-by-zero in the following path:

of_clk_init -> parent_ready -> __clk_put

Thanks,
Mike

> 
> ---
> 
> This applies on top of https://lkml.org/lkml/2015/2/5/769
> ---
>  drivers/clk/clk.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index a7d37c3..4ea2d53 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2664,7 +2664,11 @@ void __clk_put(struct clk *clk)
> clk_prepare_lock();
>  
> hlist_del(>clks_node);
> -   clk_core_set_rate_nolock(clk->core, clk->core->req_rate);
> +
> +   if (clk->min_rate > clk->core->req_rate ||
> +   clk->max_rate < clk->core->req_rate)
> +   clk_core_set_rate_nolock(clk->core, clk->core->req_rate);
> +
> owner = clk->core->owner;
> kref_put(>core->ref, __clk_release);
>  
> -- 
> 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/

Re: [alsa-devel] [PATCH] ASoC: max98088: Add master clock handling

[Tushar Behera]

On 02/20/2015 12:48 AM, Andreas Färber wrote:
> If master clock is provided through device tree, then update
> the master clock frequency during set_sysclk.
> 
> Cc: Tushar Behera 
> Signed-off-by: Andreas Färber 
> ---
>  sound/soc/codecs/max98088.c | 24 
>  1 file changed, 24 insertions(+)
> 

Looks good.

Acked-by: Tushar Behera 

-- 
Tushar Behera
--
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: usb serial: pl2303 driver TxD "break" stays after close() bug

[Johan Hovold]

On Thu, Feb 19, 2015 at 03:38:39PM +0200, Jari Ruusu wrote:
> On 2/19/15, Johan Hovold  wrote:
> > What happens when you reopen the port? Is the break state cleared then?
> 
> Stuck "break" signal is not cleared on re-open.
> 
> To clear it, you need to poke it with ioctl(fd, TIOCCBRK, 0)
> or disconnect the device.

That's definitely a bug.

Care to test the patch below?

Thanks,
Johan


>From ee3f2d35adc59822d72f3908078da7f361c26577 Mon Sep 17 00:00:00 2001
From: Johan Hovold 
Date: Fri, 20 Feb 2015 10:05:51 +0700
Subject: [PATCH] USB: pl2303: disable break on shutdown

Currently an enabled break state is not disabled on final close nor on
re-open and has to be disabled manually.

Fix this by disabling break on port shutdown.

Reported-by: Jari Ruusu 
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/pl2303.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 0f872e6b2c87..f6fe4737185d 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -132,6 +132,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 #define UART_OVERRUN_ERROR 0x40
 #define UART_CTS   0x80
 
+static void pl2303_set_break(struct usb_serial_port *port, bool enable);
 
 enum pl2303_type {
TYPE_01,/* Type 0 and 1 (difference unknown) */
@@ -613,6 +614,7 @@ static void pl2303_dtr_rts(struct usb_serial_port *port, 
int on)
 
 static void pl2303_close(struct usb_serial_port *port)
 {
+   pl2303_set_break(port, false);
usb_serial_generic_close(port);
usb_kill_urb(port->interrupt_in_urb);
 }
@@ -741,17 +743,16 @@ static int pl2303_ioctl(struct tty_struct *tty,
return -ENOIOCTLCMD;
 }
 
-static void pl2303_break_ctl(struct tty_struct *tty, int break_state)
+static void pl2303_set_break(struct usb_serial_port *port, bool enable)
 {
-   struct usb_serial_port *port = tty->driver_data;
struct usb_serial *serial = port->serial;
u16 state;
int result;
 
-   if (break_state == 0)
-   state = BREAK_OFF;
-   else
+   if (enable)
state = BREAK_ON;
+   else
+   state = BREAK_OFF;
 
dev_dbg(>dev, "%s - turning break %s\n", __func__,
state == BREAK_OFF ? "off" : "on");
@@ -763,6 +764,13 @@ static void pl2303_break_ctl(struct tty_struct *tty, int 
break_state)
dev_err(>dev, "error sending break = %d\n", result);
 }
 
+static void pl2303_break_ctl(struct tty_struct *tty, int state)
+{
+   struct usb_serial_port *port = tty->driver_data;
+
+   pl2303_set_break(port, state);
+}
+
 static void pl2303_update_line_status(struct usb_serial_port *port,
  unsigned char *data,
  unsigned int actual_length)
-- 
2.0.5

--
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] Update kernel math-emu code from current glibc soft-fp

[Kaz Kojima]

Joseph Myers  wrote:
> Please try this patch on top of the previous one.  The way abort is 
> redefined in the kernel code doesn't work for one place using it in an 
> expression; this patch changes a comma expression to a statement 
> expression.  This didn't appear in my powerpc testing because the powerpc 
> emulation never uses FP_FROM_INT; I'm not sure how Kaz's sh testing 
> avoided the problem appearing there.

My bad.  It turned out that I've configured the kernel wrongly and
CONFIG_SH_FPU_EMU isn't enabled.  With the proper configuration,
the build got the similar error with sparc64 during compiling
arch/sh/math.c and your patch for op-common.h fixes it.

Regards,
kaz
--
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] ipmi: Remove uses of return value of seq_printf

[Corey Minyard]

Not a big deal, thanks for following up.  Send a relative patch,
please.  I already have this queued for upstream.

-corey

On 02/18/2015 06:02 PM, Joe Perches wrote:
> On Wed, 2015-02-18 at 11:56 -0600, Corey Minyard wrote:
>> Thanks, queued for 3.20.
> Hey Corey, thanks, but I'll either have to send a new
> patch or an updated patch changing these new
> seq_has_overflowed() uses to 0.
>
> There's no functional difference, but there is a logical
> one.  has_overflowed(), if it returns "true" (it won't here
> because the first alloc seq_fs does has sufficient space)
> would not retry and simply not emit anything.
>
> Anyway, do you want a new patch or a relative patch?
>
> sorry 'bout that,  Joe
>

--
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 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls

[Felipe Balbi]

On Fri, Feb 20, 2015 at 01:09:48AM +0100, Pali Rohár wrote:
> On Thursday 05 February 2015 13:38:58 Pali Rohár wrote:
> > On Tuesday 03 February 2015 20:57:11 Pali Rohár wrote:
> > > On Tuesday 03 February 2015 20:35:25 Felipe Balbi wrote:
> > > > On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote:
> > > > > On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> > > > > > On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár
> > 
> > wrote:
> > > > > > > On Tuesday 03 February 2015 16:43:45 Felipe Balbi
> > 
> > wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali
> > > > > > > > Rohár
> > > 
> > > wrote:
> > > > > > > > > On Tuesday 03 February 2015 00:15:19 Felipe
> > > > > > > > > Balbi
> > > 
> > > wrote:
> > > > > > > > > > f_phonet's ->set_alt() method will call
> > > > > > > > > > usb_ep_disable() potentially on an endpoint
> > > > > > > > > > which is already disabled. That's something
> > > > > > > > > > the gadget/function driver must guarantee
> > > > > > > > > > that it's always balanced.
> > > > > > > > > > 
> > > > > > > > > > In order to balance the calls, just make sure
> > > > > > > > > > the endpoint was enabled before by means of
> > > > > > > > > > checking the validity of driver_data.
> > > > > > > > > > 
> > > > > > > > > > Reported-by: Pali Rohár 
> > > > > > > > > > Signed-off-by: Felipe Balbi 
> > > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > > Your patches cause that kernel does not print
> > > > > > > > > any error message to n900 screen anymore and
> > > > > > > > > reboot device in 10 seconds. I did not loaded
> > > > > > > > > any external modules.
> > > > > > > > 
> > > > > > > > > In qemu I see this crash in early boot:
> > > > > > > > alright, so n900's working fine. I'll wait until
> > > > > > > > you debug qemu a little more, thank you
> > > > > > > 
> > > > > > > NO! It does not working, see . It break n900
> > > > > > > totally!
> > > > > > 
> > > > > > settle down a bit more. I don't have the HW you have
> > > > > > and things are working fine on boards I _do_ have,
> > > > > > there's not much more I can do to help without you
> > > > > > doing your homework. Debug a bit more and bring more
> > > > > > information as to what's going on, until then you're
> > > > > > on your own.
> > > > > 
> > > > > And what more do you need? It crash on my n900 and also
> > > > > in qemu. I sent you kernel crash dump from qemu which
> > > > > introduced *your* patches. Before applying your patches
> > > > > there was no crash in early boot stage.
> > > > > 
> > > > > In current state I review all 3 patches as:
> > > > > 
> > > > > Rejected-by: Pali Rohár 
> > > > > [It breaks booting Nokia N900 device]
> > > > 
> > > > next step, figure why it's broken. Working just fine here
> > > > on AM335x which has the same musb IP.
> > > 
> > > Why is broken? That is easy. You send 3 patches which broke
> > > it.
> > 
> > Actually when I reverted only that patch which adds line:
> > 
> > pm_runtime_irq_safe(musb->controller)
> > 
> > then early boot crash disappeared.
> > 
> > But other two patches did not fixed support for external .ko
> > gadget modules. State is same -- crash after modprobe.
> 
> Here is crash from qemu when musb is compiled into kernel:
> 
> [0.641662] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [0.642211] pgd = c0004000
> [0.642425] [] *pgd=
> [0.642913] Internal error: Oops: 8005 [#1] PREEMPT ARM
> [0.643371] Modules linked in:
> [0.643737] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc5+ #329
> [0.644195] Hardware name: Nokia RX-51 board
> [0.644531] task: cf8a8000 ti: cf8ac000 task.ti: cf8ac000
> [0.644958] PC is at 0x0
> [0.645263] LR is at omap2430_runtime_resume+0x80/0x100
> [0.645660] pc : [<>]lr : []psr: 6113
> [0.645660] sp : cf8adda0  ip : 0001  fp : c0059c64
> [0.646423] r10: cf8adde8  r9 : cf9b5884  r8 : cf9b58cc
> [0.646789] r7 : 0004  r6 : cf93ee10  r5 : c06ac84c  r4 : cf83a010
> [0.647216] r3 :   r2 : c0565716  r1 : 0414  r0 : fa0ab000
> [0.647735] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> kernel
> [0.648254] Control: 10c53c7d  Table: 80004059  DAC: 0015
> [0.648651] Process swapper (pid: 1, stack limit = 0xcf8ac238)
> [0.649078] Stack: (0xcf8adda0 to 0xcf8ae000)
> [0.649444] dda0: c0022428 cf9b5810 cf93ee10 c026bb44 0001 c026d3e0 
>  cf9b5810
> [0.650085] ddc0:  c026d4a0 cf9b5810 cf9b5810  c026e9a4 
> c0441790 cfa29410
> [0.650634] dde0: cfb33800 c0441790 cfa29410 cfa2b700  6113 
> cfa2b6c0 cfa29410
> [0.651153] de00: c0660c80 006c c06210c4 c05de6d4  c026ee74 
> cfa2c180 cfa29410
> [0.651702] de20: cfa2b6c0 c026eed4 cf83a010 c02c53f8 cfa29410 006c 
> fa0ab000 ffed
> [0.652252] de40: cfa29410 

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[zhangfei]

Hi, Balbi

On 02/18/2015 10:35 PM, Felipe Balbi wrote:

On Wed, Feb 18, 2015 at 01:44:21PM +0800, zhangfei wrote:

Hi, Kishon

On 02/18/2015 01:35 PM, Kishon Vijay Abraham I wrote:

Hi,

On Thursday 12 February 2015 01:07 PM, Zhangfei Gao wrote:

Add usb phy controller for hi6220 platform

Signed-off-by: Zhangfei Gao 
---
  drivers/phy/Kconfig  |   9 ++
  drivers/phy/Makefile |   1 +
  drivers/phy/phy-hi6220-usb.c | 306
+++
  3 files changed, 316 insertions(+)
  create mode 100644 drivers/phy/phy-hi6220-usb.c


why is this driver in drivers/phy when it doesn't use the generic PHY
framework at all?



Balbi recommended "new drivers only on drivers/phy/", including usb
phy.


but it should use the API too. It's not only about a directory, you need
to use the new API.


So Move drivers/usb/phy/phy-hi6220-usb.c to
drivers/phy/phy-hi6220-usb.c, required by Balbi.


you're reading what I stated the way you like.


Sorry for my bad understanding.

Still not clear about the otg_set_peripheral, which is required in 
phy-hi6220-usb.c


1. drivers/usb/dwc2/gadget.c use
otg_set_peripheral(hsotg->uphy->otg, >gadget);

2. include/linux/phy/phy.h
struct phy do not have member otg, while struct usb_phy has.

Could you give more hints?

Thanks
--
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/

Pull request for the IPMI driver

[Corey Minyard]

The following changes since commit e3a1f6cac1fe20e7ac01d96c914c25726723a64e:

  x86: pte_protnone() and pmd_protnone() must check entry is not present
(2015-02-19 15:04:49 -0800)

are available in the git repository at:

  git://git.code.sf.net/p/openipmi/linux-ipmi tags/for-linus-3.20-1

for you to fetch changes up to 1d86e29b4a612eb01c39daa48749ab7964e77e03:

  ipmi: Fix a memory ordering issue (2015-02-19 20:58:42 -0600)


Some minor fixes and cleanups, nothing big.

In for-next for a while and I've done some extensive beating on the
driver since I have it working in qemu and can do creatively cruel
things to it

Thanks,

-corey.


Arnd Bergmann (1):
  ipmi: avoid gcc warning

Corey Minyard (2):
  ipmi: Remove a FIXME for slab conversion
  ipmi: Fix a memory ordering issue

Joe Perches (1):
  ipmi: Remove uses of return value of seq_printf

John Stultz (2):
  ipmi: Cleanup DEBUG_TIMING ifdef usage
  ipmi: Update timespec usage to timespec64

Nicholas Krause (2):
  drivers:char:ipmi: Remove unneeded FIXME comment in the
file,ipmi_si_intf.c
  ipmi: Free ipmi_recv_msg messages from the linked list on close

Takashi Iwai (1):
  ipmi: Use is_visible callback for conditional sysfs entries

Wolfram Sang (1):
  char: ipmi: Remove obsolete cleanup for clientdata

 drivers/char/ipmi/ipmi_devintf.c|   6 +-
 drivers/char/ipmi/ipmi_msghandler.c | 102 ++
 drivers/char/ipmi/ipmi_si_intf.c| 121
+---
 drivers/char/ipmi/ipmi_ssif.c   |   6 +-
 4 files changed, 110 insertions(+), 125 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/

[PATCH v2] mmc: dw_mmc: fix bug that cause mmc_test failture

[Addy Ke]

The STOP command can terminate a data transfer between a memory card and
mmc controller.

As show in Synopsys DesignWare Cores Mobile Stroage Host Databook:
Data timeout and Data end-bit error will terminate further data transfer
by mmc controller. So we should not send abort command to terminate a
data transfer again if we got DRTO and EBE interrupt.

After this patch, all mmc_test cases can pass on RK3288-Pink2 board.

Signed-off-by: Addy Ke 
---
Changes in v2:
- DRTO and EBE are both set, should not send abort command too,
  suggested by Doug Anderson. 

 drivers/mmc/host/dw_mmc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..a27048a 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1520,7 +1520,10 @@ static void dw_mci_tasklet_func(unsigned long priv)
if (test_and_clear_bit(EVENT_DATA_ERROR,
   >pending_events)) {
dw_mci_stop_dma(host);
-   send_stop_abort(host, data);
+   if (data->stop ||
+   !(host->data_status & (SDMMC_INT_DRTO |
+  SDMMC_INT_EBE)))
+   send_stop_abort(host, data);
state = STATE_DATA_ERROR;
break;
}
@@ -1547,7 +1550,10 @@ static void dw_mci_tasklet_func(unsigned long priv)
if (test_and_clear_bit(EVENT_DATA_ERROR,
   >pending_events)) {
dw_mci_stop_dma(host);
-   send_stop_abort(host, data);
+   if (data->stop ||
+   !(host->data_status & (SDMMC_INT_DRTO |
+  SDMMC_INT_EBE)))
+   send_stop_abort(host, data);
state = STATE_DATA_ERROR;
break;
}
-- 
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 v2] mmc: dw_mmc: rockchip: add support MMC_CAP_RUNTIME_RESUME capability

[Addy Ke]

To support HS200 and UHS mode, mmc core will call init_card() to
execute tuning:
- sdio: init_card can be executed at runtime resume.
- sd and mmc: init_card can be executed at resume or runtime resume,
  which depends on MMC_CAP_RUNTIME_RESUME capability.

On rk3288 SoC, host will get DRTO interrupt when host send command
to read tuning data. This will spend more than 111ms:
drto_ms = drto_clks * 1000 / bus_hz = 111ms.

And the total tuning time will be more than 400ms.

So we should add MMC_CAP_RUNTIME_RESUME capability to execute tuning
at runtime resume. Only if we do so, can we pass resume test.

Reviewed-by: Doug Anderson 
Signed-off-by: Addy Ke 
---
Changes in v2:
- add this capability for all 4 slots, suggested by Doug Anderson.

 drivers/mmc/host/dw_mmc-rockchip.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
b/drivers/mmc/host/dw_mmc-rockchip.c
index e2a726a..dbf166f 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -76,12 +76,20 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
return 0;
 }
 
+/* Common capabilities of RK3288 SoC */
+static unsigned long dw_mci_rk3288_dwmmc_caps[4] = {
+   MMC_CAP_RUNTIME_RESUME, /* emmc */
+   MMC_CAP_RUNTIME_RESUME, /* sdmmc */
+   MMC_CAP_RUNTIME_RESUME, /* sdio0 */
+   MMC_CAP_RUNTIME_RESUME, /* sdio1 */
+};
 static const struct dw_mci_drv_data rk2928_drv_data = {
.prepare_command= dw_mci_rockchip_prepare_command,
.init   = dw_mci_rockchip_init,
 };
 
 static const struct dw_mci_drv_data rk3288_drv_data = {
+   .caps   = dw_mci_rk3288_dwmmc_caps,
.prepare_command= dw_mci_rockchip_prepare_command,
.set_ios= dw_mci_rk3288_set_ios,
.setup_clock= dw_mci_rk3288_setup_clock,
-- 
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/

Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework

[Stephen Boyd]

On 02/19/15 09:08, Srinivas Kandagatla wrote:
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index c70d6e4..d7afc82 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -184,4 +184,6 @@ source "drivers/thunderbolt/Kconfig"
>  
>  source "drivers/android/Kconfig"
>  
> +source "drivers/eeprom/Kconfig"
> +
>  endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 527a6da..57eb5b0 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
>  obj-$(CONFIG_THUNDERBOLT)+= thunderbolt/
>  obj-$(CONFIG_CORESIGHT)  += coresight/
>  obj-$(CONFIG_ANDROID)+= android/
> +obj-$(CONFIG_EEPROM) += eeprom/
> diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
> new file mode 100644
> index 000..2c5452a
> --- /dev/null
> +++ b/drivers/eeprom/Kconfig
> @@ -0,0 +1,19 @@
> +menuconfig EEPROM
> + bool "EEPROM Support"
> + depends on OF

Doesn't this need some sort of select REGMAP somewhere?

Also, why do we need to use regmap for the eeprom framework read/write
ops? I liked the simple eeprom::{read,write} API that Maxime had. The
regmap part could be a regmap-eeprom driver that implements read/write
ops like you've done in the core.

> + help
> +   Support for EEPROM alike devices.
> +
> +   This framework is designed to provide a generic interface to EEPROM
> +   from both the Linux Kernel and the userspace.
> +
> +   If unsure, say no.
> +
> +if EEPROM
> +
> +config EEPROM_DEBUG
> + bool "EEPROM debug support"
> + help
> +   Say yes here to enable debugging support.
> +
> +endif
>
> diff --git a/include/linux/eeprom-provider.h b/include/linux/eeprom-provider.h
> new file mode 100644
> index 000..3943c2f
> --- /dev/null
> +++ b/include/linux/eeprom-provider.h
> @@ -0,0 +1,51 @@
> +/*
> + * EEPROM framework provider.
> + *
> + * Copyright (C) 2015 Srinivas Kandagatla 
> + * Copyright (C) 2013 Maxime Ripard 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef _LINUX_EEPROM_PROVIDER_H
> +#define _LINUX_EEPROM_PROVIDER_H
> +
> +#include 
> +#include 
> +#include 
> +
> +struct eeprom_device {
> + struct regmap   *regmap;
> + int stride;
> + size_t  size;
> + struct device   *dev;
> +
> + /* Internal to framework */
> + struct device   edev;
> + int id;
> + struct list_headlist;

Should there be a module owner here to handle module removal?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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] x86: fix output of show_stack_log_lvl()

[Adrien Schildknecht]

show_stack_log_lvl() does not set the log level after a new line,
the following messages printed with pr_cont are thus assigned to the
default log level.
This patch prepends the log level to the next message following a new
line.

print_trace_address() uses printk(log_lvl). Using printk with just
a log level is ignored and thus has no effect on the next pr_cont.
We need to prepend the log level directly into the message.

Signed-off-by: Adrien Schildknecht 
---
 arch/x86/kernel/dumpstack.c| 11 ++-
 arch/x86/kernel/dumpstack_32.c |  9 ++---
 arch/x86/kernel/dumpstack_64.c |  9 ++---
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index cf3df1d..81b3932 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -25,10 +25,12 @@ unsigned int code_bytes = 64;
 int kstack_depth_to_print = 3 * STACKSLOTS_PER_LINE;
 static int die_counter;
 
-static void printk_stack_address(unsigned long address, int reliable)
+static void printk_stack_address(unsigned long address, int reliable,
+   void *data)
 {
-   pr_cont(" [<%p>] %s%pB\n",
-   (void *)address, reliable ? "" : "? ", (void *)address);
+   printk("%s [<%p>] %s%pB\n",
+   (char *)data, (void *)address, reliable ? "" : "? ",
+   (void *)address);
 }
 
 void printk_address(unsigned long address)
@@ -155,8 +157,7 @@ static int print_trace_stack(void *data, char *name)
 static void print_trace_address(void *data, unsigned long addr, int reliable)
 {
touch_nmi_watchdog();
-   printk(data);
-   printk_stack_address(addr, reliable);
+   printk_stack_address(addr, reliable, data);
 }
 
 static const struct stacktrace_ops print_trace_ops = {
diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
index 5abd4cd..efff5ed 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -108,9 +108,12 @@ show_stack_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
for (i = 0; i < kstack_depth_to_print; i++) {
if (kstack_end(stack))
break;
-   if (i && ((i % STACKSLOTS_PER_LINE) == 0))
-   pr_cont("\n");
-   pr_cont(" %08lx", *stack++);
+   if ((i % STACKSLOTS_PER_LINE) == 0) {
+   if (i != 0)
+   pr_cont("\n");
+   printk("%s %08lx", log_lvl, *stack++);
+   } else
+   pr_cont(" %08lx", *stack++);
touch_nmi_watchdog();
}
pr_cont("\n");
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index ff86f19..553573b 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -283,9 +283,12 @@ show_stack_log_lvl(struct task_struct *task, struct 
pt_regs *regs,
if (((long) stack & (THREAD_SIZE-1)) == 0)
break;
}
-   if (i && ((i % STACKSLOTS_PER_LINE) == 0))
-   pr_cont("\n");
-   pr_cont(" %016lx", *stack++);
+   if ((i % STACKSLOTS_PER_LINE) == 0) {
+   if (i != 0)
+   pr_cont("\n");
+   printk("%s %016lx", log_lvl, *stack++);
+   } else
+   pr_cont(" %016lx", *stack++);
touch_nmi_watchdog();
}
preempt_enable();
-- 
2.2.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] x86, boot: Allow 64bit EFI kernel to be loaded above 4G

[Baoquan He]

On 02/18/15 at 11:47am, Yinghai Lu wrote:
> On Wed, Feb 18, 2015 at 3:29 AM, Baoquan He  wrote:
> > On 02/17/15 at 11:22pm, Yinghai Lu wrote:
> >> On Tue, Feb 10, 2015 at 10:11 PM, Baoquan He  wrote:
> > I am sorry I didn't get what you mean. I have tried to set another ident
> > mapping for new range and it is successful seeing from debug message
> > printing. However it always reboot because of GPF. That's why I made
> > that small debug patch which add another 4G ident mapping and hardcoded
> > to put kernel between 4G and 8G.
> >
> > Could you say more of it?  Or which direction should I go?
> 
> I would suggest:
> leave physical address random handling to bootloader, as bootloader always
> need to set ident mapping to cover kernel/bootparam/cmdline.
> 
> For virtual address random handling it should go kasl in kernel.

Kaslr need both virtual and physical address be randomized, otherwise
it doesn't make sense. Please check what hpa said about this issue:

https://lkml.org/lkml/2014/10/13/350

And usually no bootloader often load kernel onto a random physical
address. Fow now we can often see kexec/kdump did this. I believe Kees
introduced kaslr to mainly solve security issue of normal kernel which
is not like kexec/kdump for testing or debugging. Randomizing physical
address makes sense for kaslr feature.

In normal kernel it jump from 32bit to 64bit and enter into 64bit mode
of long mode. I am wondering why it will cause a GPF when kernel is put
above 4G. Adding a IDT and #PF handler to solve the ident page mapping
on demand has been done now, I am blocked by the GPF now, otherwise I can
post it very soon for testing.

Thanks
Baoquan
> 
> Thanks
> 
> Yinghai
--
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 v4 27/28] vfio: powerpc/spapr: Register memory

[Alexey Kardashevskiy]

Just noticed - this patch should be split into two, they were squashed by 
mistake, my bad.



On 02/16/2015 09:06 PM, Alexey Kardashevskiy wrote:

The existing implementation accounts the whole DMA window in
the locked_vm counter which is going to be even worse with multiple
containers and huge DMA windows.

This introduces 2 ioctls to register/unregister DMA memory which
receive user space address and size of the memory region which
needs to be pinned/unpinned and counted in locked_vm.

If any memory region was registered, all subsequent DMA map requests
should address already pinned memory. If no memory was registered,
then the amount of memory required for a single default memory will be
accounted when the container is enabled and every map/unmap will pin/unpin
a page.

Dynamic DMA window and in-kernel acceleration will require memory to
be registered in order to work.

The accounting is done per VFIO container. When the support of
multiple groups per container is added, we will have accurate locked_vm
accounting.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v4:
* updated docs
* s/kzmalloc/vzalloc/
* in tce_pin_pages()/tce_unpin_pages() removed @vaddr, @size and
replaced offset with index
* renamed vfio_iommu_type_register_memory to vfio_iommu_spapr_register_memory
and removed duplicating vfio_iommu_spapr_register_memory
---
  drivers/vfio/vfio_iommu_spapr_tce.c | 222 
  1 file changed, 148 insertions(+), 74 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c 
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 4ff8289..ee91d51 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -91,10 +91,16 @@ static void decrement_locked_vm(long npages)
   */
  struct tce_container {
struct mutex lock;
-   struct iommu_group *grp;
bool enabled;
unsigned long locked_pages;
struct list_head mem_list;
+   struct iommu_table tables[POWERPC_IOMMU_MAX_TABLES];
+   struct list_head group_list;
+};
+
+struct tce_iommu_group {
+   struct list_head next;
+   struct iommu_group *grp;
  };

  struct tce_memory {
@@ -300,19 +306,20 @@ static bool tce_page_is_contained(struct page *page, 
unsigned page_shift)
return false;
  }

+static inline bool tce_groups_attached(struct tce_container *container)
+{
+   return !list_empty(>group_list);
+}
+
  static struct iommu_table *spapr_tce_find_table(
struct tce_container *container,
phys_addr_t ioba)
  {
long i;
struct iommu_table *ret = NULL;
-   struct powerpc_iommu *iommu = iommu_group_get_iommudata(container->grp);
-
-   if (!iommu)
-   return NULL;

for (i = 0; i < POWERPC_IOMMU_MAX_TABLES; ++i) {
-   struct iommu_table *tbl = >tables[i];
+   struct iommu_table *tbl = >tables[i];
unsigned long entry = ioba >> tbl->it_page_shift;
unsigned long start = tbl->it_offset;
unsigned long end = start + tbl->it_size;
@@ -330,11 +337,8 @@ static int tce_iommu_enable(struct tce_container 
*container)
  {
int ret = 0;
unsigned long locked;
-   struct iommu_table *tbl;
struct powerpc_iommu *iommu;
-
-   if (!container->grp)
-   return -ENXIO;
+   struct tce_iommu_group *tcegrp;

if (!current->mm)
return -ESRCH; /* process exited */
@@ -368,12 +372,24 @@ static int tce_iommu_enable(struct tce_container 
*container)
 * KVM agnostic.
 */
if (!tce_preregistered(container)) {
-   iommu = iommu_group_get_iommudata(container->grp);
+   if (!tce_groups_attached(container))
+   return -ENODEV;
+
+   tcegrp = list_first_entry(>group_list,
+   struct tce_iommu_group, next);
+   iommu = iommu_group_get_iommudata(tcegrp->grp);
if (!iommu)
return -ENODEV;

-   tbl = >tables[0];
-   locked = (tbl->it_size << tbl->it_page_shift) >> PAGE_SHIFT;
+   /*
+* We do not allow enabling a group if no DMA-able memory was
+* registered as there is no way to know how much we should
+* increment the locked_vm counter.
+*/
+   if (!iommu->tce32_size)
+   return -EPERM;
+
+   locked = iommu->tce32_size >> PAGE_SHIFT;
ret = try_increment_locked_vm(locked);
if (ret)
return ret;
@@ -386,6 +402,10 @@ static int tce_iommu_enable(struct tce_container 
*container)
return ret;
  }

+static int tce_iommu_clear(struct tce_container *container,
+   struct iommu_table *tbl,
+   unsigned long entry, unsigned long pages);
+
  static void tce_iommu_disable(struct tce_container *container)
  

Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting

[Luis R. Rodriguez]

On Thu, Feb 19, 2015 at 5:03 PM,   wrote:
> On Fri, 20 Feb 2015 01:53:44 +0100, "Luis R. Rodriguez" said:
>> Wider community:
>>
>> anyone aware of any *need* in the kernel to know whether one is indoor or
>> not on a device running Linux other than wifi? Clearly it should be something
>> that might be of interest to at least other RF devices, so that is at least
>> one possibilty to consider already, but what else?
>
> I can think of a lot of reasons for the kernel to make indoor/outdoor
> status available to userspace, but am coming up empty why the kernel itself
> should care

Some devices enable regulatory control through the kernel, in such
cases the wireless-regdb is used and there is an INDOOR flag that
enables / disables specific functionality.

 Luis
--
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: Tree for Feb 20

[Stephen Rothwell]

Hi all,

Please do not add any material destined for v3.21 to your linux-next
included trees until after v3.20-rc1 has been released.

Changes since 20150219:

The clk tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 1232
 870 files changed, 32474 insertions(+), 19892 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 206 trees (counting Linus' and 30 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 (89d3fa45b4ad Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (8e6480667246 ARM: 8299/1: mm: ensure local active 
ASID is marked as allocated on rollover)
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
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 (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (aa183323312d ehea: Register memory hotplug, reboot and 
crash hooks on adapter probe)
Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in 
xfrm_lookup())
Merging sound-current/for-linus (3cd1ce0420ce ALSA: usb: Fix support for Denon 
DA-300USB DAC (ID 154e:1003))
Merging pci-current/for-linus (feb28979c137 of/pci: Remove duplicate kfree in 
of_pci_get_host_bridge_resources())
Merging wireless-drivers/master (aeb2d2a4c0ae rtlwifi: Remove logging statement 
that is no longer needed)
Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6)
Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging usb.current/usb-linus (e36f014edff7 Linux 3.19-rc7)
Merging usb-gadget-fixes/fixes (f5af19d10d15 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for 
RUGGEDCOM USB Serial Console)
Merging staging.current/staging-linus (e36f014edff7 Linux 3.19-rc7)
Merging char-misc.current/char-misc-linus (e36f014edff7 Linux 3.19-rc7)
Merging input-current/for-linus (4ba24fef3eb3 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (96692a7305c4 crypto: tcrypt - do not allocate iv 
on stack for aead speed tests)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays 
with sub-devices tests)
Merging rr-fixes/fixes (f47689345931 lguest: update help text.)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for 
transhuge-stress test)
Merging drm-intel-fixes/for-linux-next-fixes (bfa76d495765 Linux 3.19)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vh

Re: NUMA_BALANCING and Xen PV guest regression in 3.20-rc0

[Linus Torvalds]

On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
 wrote:
>
> I'm feeling I miss very basic background on how Xen works, but why does it
> set _PAGE_GLOBAL on userspace entries? It sounds strange to me.

It is definitely strange. I'm guessing that it's some ancient Xen hack
for the early Intel virtualization that used to have absolutely
horrendous vmenter/exit costs, including very much the TLB overhead. \

These days, Intel has address space identifiers, and doesn't flush the
whole TLB on VM entry/exit, so it's probably pointless to play games
with the global bit.

I get the feeling that a lot of Xen stuff is that kind of "legacy
hacks" that should just be cleaned up, but nobody has the energy or
the interest.  There was the whole odd crazy SHARED_KERNEL_PMD hackery
too.

 Linus
--
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.14.25-rt22 2/2] kernel/locking/rtmutex.c: some code optimization

[Thavatchai Makphaibulchoke]

Adding the following code optimization,

- Reducing the number of cmpxchgs.  Only call mark_rt_mutex_waiters() when
  needed, waiters bit is not set.
- Reducing the hold time of wait_lock lock.
- Calling fixup_rt_mutex_waiters() only when needed.

Signed-off-by: T. Makphaibulchoke 
---
 kernel/locking/rtmutex.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 8b66f81..2600026 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -622,7 +622,8 @@ __try_to_take_rt_mutex(struct rt_mutex *lock, struct 
task_struct *task,
 * any more. This is fixed up when we take the ownership.
 * This is the transitional state explained at the top of this file.
 */
-   mark_rt_mutex_waiters(lock);
+   if (!((unsigned long)lock->owner & RT_MUTEX_HAS_WAITERS))
+   mark_rt_mutex_waiters(lock);
 
if (rt_mutex_owner(lock))
return 0;
@@ -854,8 +855,8 @@ static void remove_waiter(struct rt_mutex *lock,
struct rt_mutex *next_lock = NULL;
unsigned long flags;
 
-   raw_spin_lock_irqsave(>pi_lock, flags);
rt_mutex_dequeue(lock, waiter);
+   raw_spin_lock_irqsave(>pi_lock, flags);
current->pi_blocked_on = NULL;
raw_spin_unlock_irqrestore(>pi_lock, flags);
 
@@ -960,6 +961,9 @@ static int adaptive_wait(struct rt_mutex *lock,
 {
int res = 0;
 
+   if (!owner)
+   return res;
+
rcu_read_lock();
for (;;) {
if (owner != rt_mutex_owner(lock))
@@ -1050,11 +1054,11 @@ static void  noinline __sched 
rt_spin_lock_slowlock(struct rt_mutex *lock)
if (top_waiter !=  || adaptive_wait(lock, lock_owner))
schedule_rt_mutex(lock);
 
-   raw_spin_lock(>wait_lock);
-
pi_lock(>pi_lock);
__set_current_state(TASK_UNINTERRUPTIBLE);
pi_unlock(>pi_lock);
+
+   raw_spin_lock(>wait_lock);
}
 
/*
@@ -1070,10 +1074,11 @@ static void  noinline __sched 
rt_spin_lock_slowlock(struct rt_mutex *lock)
pi_unlock(>pi_lock);
 
/*
-* try_to_take_rt_mutex() sets the waiter bit
-* unconditionally. We might have to fix that up:
+* No need to call fixup_rt_mutex_waiters(), as we only get
+* here when __try_to_take_rt_mutex() returns TRUE.
+* In this case, rt_mutex_set_owner() has already take care of the
+* waiter bit.
 */
-   fixup_rt_mutex_waiters(lock);
 
BUG_ON(rt_mutex_has_waiters(lock) &&  == 
rt_mutex_top_waiter(lock));
BUG_ON(!RB_EMPTY_NODE(_entry));
@@ -1127,7 +1132,16 @@ static inline void rt_spin_lock_fastunlock_in_irq(struct 
rt_mutex *lock,
if (likely(rt_mutex_cmpxchg(lock, intr_owner, NULL)))
return;
do {
+   /*
+* Alternate between fast acquire and try lock and proceed
+* to slow lock whichever succeeds first.
+*
+* Also use reserved INTERRUPT_HANDLER task_strcut.
+*/
ret = raw_spin_trylock(>wait_lock);
+   if (!ret && unlikely(rt_mutex_cmpxchg(lock, intr_owner,
+   NULL)))
+   return;
} while (!ret);
 
slowfn(lock, intr_owner);
@@ -1538,10 +1552,12 @@ rt_mutex_slowtrylock(struct rt_mutex *lock, struct 
task_struct *task)
 
ret = try_to_take_rt_mutex(lock, task, NULL);
/*
-* try_to_take_rt_mutex() sets the lock waiters
-* bit unconditionally. Clean this up.
+* try_to_take_rt_mutex() leaves the lock waiters bit set
+* if we fail to take the lock.  Clean this up if we
+* don't get the lock.
 */
-   fixup_rt_mutex_waiters(lock);
+   if (!ret)
+   fixup_rt_mutex_waiters(lock);
}
 
raw_spin_unlock(>wait_lock);
-- 
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.14.25-rt22 0/2] rtmutex Real-Time Linux: fix kernel BUG at kernel/locking/rtmutex.c:997! and some optimization

[Thavatchai Makphaibulchoke]

This patch series compose of 2 patches.

First patch, fixing kernel BUG at kernel/locking/rtmutex.c:997!

Second patch, some code optimation in kernel/locking/rtmutex.c

Thavatchai Makphaibulchoke (2):
  rtmutex Real-Time Linux: Fixing kernel BUG at
kernel/locking/rtmutex.c:997!
  kernel/locking/rtmutex.c: some code optimization

 include/linux/spinlock_rt.h |   4 +
 kernel/locking/rtmutex-debug.c  |  15 ++-
 kernel/locking/rtmutex.c| 248 
 kernel/locking/rtmutex_common.h |  21 
 kernel/timer.c  |   4 +-
 5 files changed, 214 insertions(+), 78 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 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!

[Thavatchai Makphaibulchoke]

This patch fixes the problem that the ownership of a mutex acquired by an
interrupt handler(IH) gets incorrectly attributed to the interrupted thread.

This could result in an incorrect deadlock detection in function
rt_mutex_adjust_prio_chain(), causing thread to be killed and possibly leading
up to a system hang.

Here is the approach taken: when calling from an interrupt handler, instead of
attributing ownership to the interrupted task, use a reserved task_struct value
to indicate that the owner is a interrupt handler.  This approach avoids the
incorrect deadlock detection.

This also includes changes in several function in rtmutex.c now that the lock's
requester may be a interrupt handler, not a real task struct.  This impacts
the way how the lock is acquired and prioritized and decision whether to do
the house keeping functions required for a real task struct.

The reserved task_struct values for interrupt handler are

current | 0x2

where current is the task_struct value of the interrupted task.

Since IH will both acquire and release the lock only during an interrupt
handling, during which current is not changed, the reserved task_struct value
for an IH should be distinct from another instances of IH on a different cpu.

Kernel version 3.14.25 + patch-3.14.25-rt22

Signed-off-by: T. Makphaibulchoke 
---
 include/linux/spinlock_rt.h |   4 +
 kernel/locking/rtmutex-debug.c  |  15 ++-
 kernel/locking/rtmutex.c| 212 
 kernel/locking/rtmutex_common.h |  21 
 kernel/timer.c  |   4 +-
 5 files changed, 188 insertions(+), 68 deletions(-)

diff --git a/include/linux/spinlock_rt.h b/include/linux/spinlock_rt.h
index c0d1367..eeb4188 100644
--- a/include/linux/spinlock_rt.h
+++ b/include/linux/spinlock_rt.h
@@ -27,6 +27,7 @@ extern void __lockfunc rt_spin_unlock_wait(spinlock_t *lock);
 extern int __lockfunc rt_spin_trylock_irqsave(spinlock_t *lock, unsigned long 
*flags);
 extern int __lockfunc rt_spin_trylock_bh(spinlock_t *lock);
 extern int __lockfunc rt_spin_trylock(spinlock_t *lock);
+extern int __lockfunc rt_spin_trylock_in_interrupt(spinlock_t *lock);
 extern int atomic_dec_and_spin_lock(atomic_t *atomic, spinlock_t *lock);
 
 /*
@@ -52,6 +53,9 @@ extern int __lockfunc __rt_spin_trylock(struct rt_mutex 
*lock);
 
 #define spin_lock_irq(lock)spin_lock(lock)
 
+#define spin_do_trylock_in_interrupt(lock) \
+   __cond_lock(lock, rt_spin_trylock_in_interrupt(lock))
+
 #define spin_do_trylock(lock)  __cond_lock(lock, rt_spin_trylock(lock))
 
 #define spin_trylock(lock) \
diff --git a/kernel/locking/rtmutex-debug.c b/kernel/locking/rtmutex-debug.c
index 49b2ed3..c36d629 100644
--- a/kernel/locking/rtmutex-debug.c
+++ b/kernel/locking/rtmutex-debug.c
@@ -40,6 +40,8 @@ static void printk_task(struct task_struct *p)
 
 static void printk_lock(struct rt_mutex *lock, int print_owner)
 {
+   struct task_struct *owner = rt_mutex_owner(lock);
+
if (lock->name)
printk(" [%p] {%s}\n",
lock, lock->name);
@@ -47,10 +49,13 @@ static void printk_lock(struct rt_mutex *lock, int 
print_owner)
printk(" [%p] {%s:%d}\n",
lock, lock->file, lock->line);
 
-   if (print_owner && rt_mutex_owner(lock)) {
+   if (print_owner && owner) {
printk(".. ->owner: %p\n", lock->owner);
printk(".. held by:  ");
-   printk_task(rt_mutex_owner(lock));
+   if (rt_mutex_owner_is_task(owner))
+   printk_task(owner);
+   else
+   printk(" an interrupt handler.");
printk("\n");
}
 }
@@ -76,6 +81,8 @@ void debug_rt_mutex_deadlock(int detect, struct 
rt_mutex_waiter *act_waiter,
 
task = rt_mutex_owner(act_waiter->lock);
if (task && task != current) {
+   /* Interrupt handler should not be deadlocking. */
+   BUG_ON(!rt_mutex_owner_is_task(task));
act_waiter->deadlock_task_pid = get_pid(task_pid(task));
act_waiter->deadlock_lock = lock;
}
@@ -138,7 +145,9 @@ void debug_rt_mutex_lock(struct rt_mutex *lock)
 
 void debug_rt_mutex_unlock(struct rt_mutex *lock)
 {
-   DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current);
+   DEBUG_LOCKS_WARN_ON(in_interrupt() ?
+   !rt_mutex_owner_is_task(rt_mutex_owner(lock)) :
+   rt_mutex_owner(lock) != current);
 }
 
 void
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6c40660..8b66f81 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -51,6 +51,9 @@
  * waiters. This can happen when grabbing the lock in the slow path.
  * To prevent a cmpxchg of the owner releasing the lock, we need to
  * set this bit before looking at the lock.
+ *
+ * owner can also be reserved value, INTERRUPT_HANDLER, in case the 

Re: [PATCH] MODSIGN: Change default key details

[Sedat Dilek]

Hi,

docs need some update, too?

Regards,
- Sedat -

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/module-signing.txt#n118
--
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: NUMA_BALANCING and Xen PV guest regression in 3.20-rc0

[Kirill A. Shutemov]

On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
> Mel,
> 
> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
> dereference pmd outside of the lock during NUMA hinting fault) and
> specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to
> p[te|md]_protnone_numa) breaks Xen 64-bit PV guests.
> 
> Any fault on a present userspace mapping (e.g., a write to a read-only
> mapping) is being misinterpreted as a NUMA hinting fault and not handled
> correctly.  All userspace programs end up continuously  faulting.
> 
> This is because the hypervisor sets _PAGE_GLOBAL (== _PAGE_PROTNONE) on
> all present userspace page table entries.

I'm feeling I miss very basic background on how Xen works, but why does it
set _PAGE_GLOBAL on userspace entries? It sounds strange to me.

> 
> Note that the comment in asm/pgtable_types.h that says that
> _PAGE_BIT_PROTNONE is only valid on non-present entries.
> 
>   /* If _PAGE_BIT_PRESENT is clear, we use these: */
>   /* - if the user mapped it with PROT_NONE; pte_present gives true */
>   #define _PAGE_BIT_PROTNONE  _PAGE_BIT_GLOBAL
> 
> Adjusting pte_protnone() and pmd_protnone() to check for the absence of
> _PAGE_PRESENT allows 64-bit Xen PV guests to work correctly again (see
> following patch), but I'm not sure if NUMA_BALANCING would correctly
> work with this change.
-- 
 Kirill A. Shutemov
--
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 v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage

[Doug Anderson]

Hi,

On Thu, Feb 19, 2015 at 3:49 PM, Doug Anderson  wrote:
> I've got that coded up but I'm still testing it...  If you want to try
> it too, you can find it at
> .
>
> Note that without my patch I find that I _really_ need Addy's patch to
> make sure that the card isn't busy in setup_bus.  With my patch Addy's
> code catches the card busy less often.  I'm still trying to see if
> there's a way to totally remove the need for his setup_bus and still
> trying to grok all the patches flying around...

Ah, this might be the magic needed:

https://chromium-review.googlesource.com/251344


I think that together with the previous patch things are happy for me
without any of Addy's patches, though it's the end of my work day and
I haven't given this nearly as much testing as I'd like.

I'll continue testing tomorrow and then post both patches together upstream.

-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/

[PATCH v2 3/3] ixgbe: Add new ndo to allow VF multicast promiscuous mode

[Hiroshi Shimamoto]

From: Hiroshi Shimamoto 

Implements the new netdev op to allow VF multicast promiscuous mode.

The administrator can allow to VF multicast promiscuous mode for only
trusted VM. After allowing multicast promiscuous mode from the host,
we can use over 30 IPv6 addresses on VM.
 # ./ip link set dev eth0 vf 1 mc_promisc on

When disallowing multicast promiscuous mode, we can only use 30 IPv6 addresses.
 # ./ip link set dev eth0 vf 1 mc_promisc off

Signed-off-by: Hiroshi Shimamoto 
Reviewed-by: Hayato Momma 
CC: Choi, Sy Jong 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h   |  1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  |  7 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 35 --
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h |  2 ++
 4 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 41ed5ab..05293d7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -152,6 +152,7 @@ struct vf_data_storage {
u16 tx_rate;
u16 vlan_count;
u8 spoofchk_enabled;
+   u8 mc_promisc_allowed;
unsigned int vf_api;
 };
 
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 70cc4c5..c169fba 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3604,6 +3604,12 @@ static void ixgbe_configure_virtualization(struct 
ixgbe_adapter *adapter)
if (hw->mac.ops.set_ethertype_anti_spoofing)
hw->mac.ops.set_ethertype_anti_spoofing(hw, true, i);
}
+
+   /* Reconfigure multicast promiscuous mode */
+   for (i = 0; i < adapter->num_vfs; i++) {
+   ixgbe_ndo_set_vf_mc_promisc(adapter->netdev, i,
+   adapter->vfinfo[i].mc_promisc_allowed);
+   }
 }
 
 static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter)
@@ -8052,6 +8058,7 @@ static const struct net_device_ops ixgbe_netdev_ops = {
.ndo_set_vf_vlan= ixgbe_ndo_set_vf_vlan,
.ndo_set_vf_rate= ixgbe_ndo_set_vf_bw,
.ndo_set_vf_spoofchk= ixgbe_ndo_set_vf_spoofchk,
+   .ndo_set_vf_mc_promisc  = ixgbe_ndo_set_vf_mc_promisc,
.ndo_get_vf_config  = ixgbe_ndo_get_vf_config,
.ndo_get_stats64= ixgbe_get_stats64,
 #ifdef CONFIG_IXGBE_DCB
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 965ad29..288f39f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -108,8 +108,11 @@ static int __ixgbe_enable_sriov(struct ixgbe_adapter 
*adapter)
for (i = 0; i < adapter->num_vfs; i++) {
/* Enable spoof checking for all VFs */
adapter->vfinfo[i].spoofchk_enabled = true;
-   /* Turn multicast promiscuous mode off for all VFs */
+   /* Disallow VF multicast promiscuous capability
+* and turn it off for all VFs
+*/
adapter->vfinfo[i].mc_promisc = false;
+   adapter->vfinfo[i].mc_promisc_allowed = false;
}
return 0;
}
@@ -1016,7 +1019,7 @@ static int ixgbe_set_vf_mc_promisc(struct ixgbe_adapter 
*adapter,
 
adapter->vfinfo[vf].mc_promisc = enable;
 
-   if (enable)
+   if (enable && adapter->vfinfo[vf].mc_promisc_allowed)
return ixgbe_enable_vf_mc_promisc(adapter, vf);
else
return ixgbe_disable_vf_mc_promisc(adapter, vf);
@@ -1414,6 +1417,32 @@ int ixgbe_ndo_set_vf_spoofchk(struct net_device *netdev, 
int vf, bool setting)
return 0;
 }
 
+int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf, bool 
setting)
+{
+   struct ixgbe_adapter *adapter = netdev_priv(netdev);
+   struct ixgbe_hw *hw = >hw;
+   u32 vmolr;
+
+   if (vf >= adapter->num_vfs)
+   return -EINVAL;
+
+   /* nothing to do */
+   if (adapter->vfinfo[vf].mc_promisc_allowed == setting)
+   return 0;
+
+   adapter->vfinfo[vf].mc_promisc_allowed = setting;
+
+   /* if VF requests multicast promiscuous */
+   if (adapter->vfinfo[vf].mc_promisc) {
+   if (setting)
+   ixgbe_enable_vf_mc_promisc(adapter, vf);
+   else
+   ixgbe_disable_vf_mc_promisc(adapter, vf);
+   }
+
+   return 0;
+}
+
 int ixgbe_ndo_get_vf_config(struct net_device *netdev,
int vf, struct ifla_vf_info *ivi)
 {
@@ -1427,5 +1456,7 @@ int ixgbe_ndo_get_vf_config(struct net_device *netdev,
ivi->vlan = adapter->vfinfo[vf].pf_vlan;
ivi->qos = 

[PATCH v2 2/3] if_link: Add VF multicast promiscuous control

[Hiroshi Shimamoto]

From: Hiroshi Shimamoto 

Add netlink directives and ndo entry to allow VF multicast promiscuous mode.

The administrator wants to allow dedicatedly multicast promiscuous per VF.

Signed-off-by: Hiroshi Shimamoto 
Reviewed-by: Hayato Momma 
CC: Choi, Sy Jong 
---
 include/linux/if_link.h  |  1 +
 include/linux/netdevice.h|  3 +++
 include/uapi/linux/if_link.h |  6 ++
 net/core/rtnetlink.c | 18 --
 4 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 119130e..bc29ddf 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -14,5 +14,6 @@ struct ifla_vf_info {
__u32 linkstate;
__u32 min_tx_rate;
__u32 max_tx_rate;
+   __u32 mc_promisc;
 };
 #endif /* _LINUX_IF_LINK_H */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d115256..fd15d87 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -870,6 +870,7 @@ typedef u16 (*select_queue_fallback_t)(struct net_device 
*dev,
  * int (*ndo_set_vf_rate)(struct net_device *dev, int vf, int min_tx_rate,
  *   int max_tx_rate);
  * int (*ndo_set_vf_spoofchk)(struct net_device *dev, int vf, bool setting);
+ * int (*ndo_set_vf_mc_promisc)(struct net_device *dev, int vf, bool setting);
  * int (*ndo_get_vf_config)(struct net_device *dev,
  * int vf, struct ifla_vf_info *ivf);
  * int (*ndo_set_vf_link_state)(struct net_device *dev, int vf, int 
link_state);
@@ -1086,6 +1087,8 @@ struct net_device_ops {
   int max_tx_rate);
int (*ndo_set_vf_spoofchk)(struct net_device *dev,
   int vf, bool setting);
+   int (*ndo_set_vf_mc_promisc)(struct net_device *dev,
+int vf, bool setting);
int (*ndo_get_vf_config)(struct net_device *dev,
 int vf,
 struct ifla_vf_info *ivf);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 0deee3e..d7dc39c 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -458,6 +458,7 @@ enum {
IFLA_VF_SPOOFCHK,   /* Spoof Checking on/off switch */
IFLA_VF_LINK_STATE, /* link state enable/disable/auto switch */
IFLA_VF_RATE,   /* Min and Max TX Bandwidth Allocation */
+   IFLA_VF_MC_PROMISC, /* Multicast Promiscuous allow/disallow */
__IFLA_VF_MAX,
 };
 
@@ -502,6 +503,11 @@ struct ifla_vf_link_state {
__u32 link_state;
 };
 
+struct ifla_vf_mc_promisc {
+   __u32 vf;
+   __u32 setting;
+};
+
 /* VF ports management section
  *
  * Nested layout of set/get msg is:
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 5be499b..b668e96 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -818,7 +818,8 @@ static inline int rtnl_vfinfo_size(const struct net_device 
*dev,
 nla_total_size(sizeof(struct ifla_vf_vlan)) +
 nla_total_size(sizeof(struct ifla_vf_spoofchk)) +
 nla_total_size(sizeof(struct ifla_vf_rate)) +
-nla_total_size(sizeof(struct ifla_vf_link_state)));
+nla_total_size(sizeof(struct ifla_vf_link_state)) +
+nla_total_size(sizeof(struct ifla_vf_mc_promisc)));
return size;
} else
return 0;
@@ -,6 +1112,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct 
net_device *dev,
struct ifla_vf_tx_rate vf_tx_rate;
struct ifla_vf_spoofchk vf_spoofchk;
struct ifla_vf_link_state vf_linkstate;
+   struct ifla_vf_mc_promisc vf_mc_promisc;
 
/*
 * Not all SR-IOV capable drivers support the
@@ -1119,6 +1121,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct 
net_device *dev,
 * report anything.
 */
ivi.spoofchk = -1;
+   ivi.mc_promisc = -1;
memset(ivi.mac, 0, sizeof(ivi.mac));
/* The default value for VF link state is "auto"
 * IFLA_VF_LINK_STATE_AUTO which equals zero
@@ -1131,7 +1134,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct 
net_device *dev,
vf_rate.vf =
vf_tx_rate.vf =
vf_spoofchk.vf =
-   vf_linkstate.vf = ivi.vf;
+   vf_linkstate.vf =
+   vf_mc_promisc.vf = 

[PATCH v2 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode

[Hiroshi Shimamoto]

From: Hiroshi Shimamoto 

The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over 30 IPv6 addresses to a single VF interface.

The easy way to solve this is enabling multicast promiscuous mode.
It is good to have a functionality to enable multicast promiscuous mode
for each VF from VF driver.

This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
enable/disable multicast promiscuous mode in VF. If multicast promiscuous
mode is enabled the VF can receive all multicast packets.

With this patch, the ixgbevf driver automatically enable multicast
promiscuous mode when the number of multicast addresses is over than 30
if possible.

This also bump the API version up to 1.2 to check whether the API,
IXGBE_VF_SET_MC_PROMISC is available.

Signed-off-by: Hiroshi Shimamoto 
Reviewed-by: Hayato Momma 
CC: Choi, Sy Jong 
---

This patchset is against Jeff's tree.

cfba326 e1000e: Fix 82574/82583 TimeSync errata handling for SYSTIM read

The tree hasn't haven the fix of the IPv6 checksum issue yet,
but I cherry-picked the commit and tested.

 drivers/net/ethernet/intel/ixgbe/ixgbe.h  |  1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h  |  4 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c| 88 ++-
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++-
 drivers/net/ethernet/intel/ixgbevf/mbx.h  |  4 ++
 drivers/net/ethernet/intel/ixgbevf/vf.c   | 28 +++-
 drivers/net/ethernet/intel/ixgbevf/vf.h   |  1 +
 7 files changed, 135 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 7dcbbec..41ed5ab 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -146,6 +146,7 @@ struct vf_data_storage {
u16 vlans_enabled;
bool clear_to_send;
bool pf_set_mac;
+   bool mc_promisc;
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index a5cb755..2963557 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -73,6 +73,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_10,  /* API version 1.0, linux/freebsd VF driver */
ixgbe_mbox_api_20,  /* API version 2.0, solaris Phase1 VF driver */
ixgbe_mbox_api_11,  /* API version 1.1, linux/freebsd VF driver */
+   ixgbe_mbox_api_12,  /* API version 1.2, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
 };
@@ -91,6 +92,9 @@ enum ixgbe_pfvf_api_rev {
 /* mailbox API, version 1.1 VF requests */
 #define IXGBE_VF_GET_QUEUES0x09 /* get queue configuration */
 
+/* mailbox API, version 1.2 VF requests */
+#define IXGBE_VF_SET_MC_PROMISC0x0a /* VF requests PF to set MC 
promiscuous */
+
 /* GET_QUEUES return data indices within the mailbox */
 #define IXGBE_VF_TX_QUEUES 1   /* number of Tx queues supported */
 #define IXGBE_VF_RX_QUEUES 2   /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 7f37fe7..965ad29 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -105,9 +105,12 @@ static int __ixgbe_enable_sriov(struct ixgbe_adapter 
*adapter)
adapter->flags2 &= ~(IXGBE_FLAG2_RSC_CAPABLE |
 IXGBE_FLAG2_RSC_ENABLED);
 
-   /* enable spoof checking for all VFs */
-   for (i = 0; i < adapter->num_vfs; i++)
+   for (i = 0; i < adapter->num_vfs; i++) {
+   /* Enable spoof checking for all VFs */
adapter->vfinfo[i].spoofchk_enabled = true;
+   /* Turn multicast promiscuous mode off for all VFs */
+   adapter->vfinfo[i].mc_promisc = false;
+   }
return 0;
}
 
@@ -308,6 +311,40 @@ int ixgbe_pci_sriov_configure(struct pci_dev *dev, int 
num_vfs)
return ixgbe_pci_sriov_enable(dev, num_vfs);
 }
 
+static int ixgbe_enable_vf_mc_promisc(struct ixgbe_adapter *adapter, u32 vf)
+{
+   struct ixgbe_hw *hw;
+   u32 vmolr;
+
+   hw = >hw;
+   vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+   e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
+
+   vmolr |= IXGBE_VMOLR_MPE;
+
+   IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+   return 0;
+}
+
+static int ixgbe_disable_vf_mc_promisc(struct 

Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting

[Valdis . Kletnieks]

On Fri, 20 Feb 2015 01:53:44 +0100, "Luis R. Rodriguez" said:
> Wider community:
>
> anyone aware of any *need* in the kernel to know whether one is indoor or
> not on a device running Linux other than wifi? Clearly it should be something
> that might be of interest to at least other RF devices, so that is at least
> one possibilty to consider already, but what else?

I can think of a lot of reasons for the kernel to make indoor/outdoor
status available to userspace, but am coming up empty why the kernel itself
should care


pgpcNlUSzNEt1.pgp
Description: PGP signature

Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting

[Luis R. Rodriguez]

Wider community:

anyone aware of any *need* in the kernel to know whether one is indoor or
not on a device running Linux other than wifi? Clearly it should be something
that might be of interest to at least other RF devices, so that is at least
one possibilty to consider already, but what else?

On Sun, Feb 15, 2015 at 12:26:04PM +, Peer, Ilan wrote:
> Hi Luis,
> 
> > >
> > > This differs from the country setting that would potentially require
> > > user space interaction and might invoke more complex flows. The flow
> > > in this case is immediate, and does not require the somewhat complex
> > > handling of country settings (it even complicates the flow
> > > unnecessarily, with the REG_REQ_USER_HINT_HANDLED etc.).
> > 
> > There's two things you should address then:
> > 
> >   0) Try to mitigate the issue with the old userspace API if possible.
> >  This will enable old userspace to continue to work with the
> >  old API but also mitigate the issue you have described for which
> >  you are providing a new optimized solution for but that requires
> >  a new API.
> > 
> 
> Not sure I have a good solution for this. The problem here is that with the
> current API, the indoor setting will stick as long as a station interface is
> connected, although the indoor setting might no longer be true. For example
> when a station interface is connected to P2P GO (or a soft AP) and both
> devices are moving out of the indoor environment. The motivation for this
> patch was to move the full control of this setting to user space.
>
> Any suggestion are welcomed.

Why not just clear it upon disconnect for the old case? It seems that would
be better if that is better regulatory wise.

> 
> >   1) With the new API have userspace be able to send to the kernel that
> >  userspace will do socket monitoring and because of this and the
> >  reasons you mentioned it will have more control over the environment
> >  boolean.
> > 
> 
> Ok. Will add such an API.

Great.

> > > > > 2. Track the socket on which the indoor hint is issued, and reset
> > > > >indoor setting if the socket was released. The motivation here is 
> > > > > to
> > > > >force a user space process that sets the indoor setting to 
> > > > > constantly
> > > > >monitor this setting, and be responsible to correctly toggling it,
> > > > >so indoor operation will not be enabled uncontrolled.
> > > >
> > > > That seems to imply a new requirement for something that used to
> > > > work, what having an option to set this requirement?
> > >
> > > (Sadly) I would not consider the previous implementation as working as
> > > it would leave the regulatory core in a state that it considers to be
> > > indoor although it is no longer true.
> > 
> > Let's review the current implementation for indoor thing.
> > 
> > We assume we're not indoor unless userspace sends a
> > regulatory_hint_indoor_user(), this is with the user reg hint type set to
> > NL80211_USER_REG_HINT_INDOOR.
> > For country IEs we never trust the country IE data since it may contain 
> > bogus
> > data, but we also end up ignoring the environment aspect too.
> > 
> > If we disconnect we should be reseting the indoor setting to false.
> > I just checked and restore_regulatory_settings() does set reg_is_indoor =
> > false so if we are keeping the indoor setting I am missing something here, 
> > and
> > it does indeed rather an issue that should be fixed. Where is the indoor
> > setting being upkept?
> > 
> 
> This is generally true, but is not fully compatible with moving APs/P2P GOs,
> where you can be indoor, connect to an AP/P2P GO, and then move out of the
> indoor environment, while connected. Point is the being connected does not
> guarantee that the indoor setting is kept. 

Ah so then the above description does satisfy the concern you stated.
What you are describing *now* is a dynamic environment new requirement.

That's a very different picture than what you originally stated and
your commit message does not clarify what worked and what really are
the issue well. As it stands your changes will be an ammendment to
help with dynamic environment setting, and it will also enable environment
options to remain post disconnect.

> > > > > 3. Do not reset the indoor setting when restoring the regulatory
> > > > >settings as it has nothing to do with CRDA or interface
> > > > >disconnection.
> > > >
> > > > I disagree, if we disconnect we want the more restrictive setting
> > > > and if we put the indoor setting out of general regulatory requests
> > > > then we do want to reset this no?
> > > >
> > >
> > > I do not think so. This setting is in the responsibility of the user
> > > space daemon, so it should be the one controlling it.
> > 
> > Right now the API requires sending the userspace regulatory hint and the
> > kenrel should indeed reset to non-indoor upon disconnect, the later is an
> > issue which should be fixed and what you introduce seems 

Re: [PATCH] MODSIGN: Change default key details

[James Morris]

On Mon, 16 Feb 2015, David Howells wrote:

> Change default key details to be more obviously unspecified.
> 
> Reported-by: Linus Torvalds 
> Signed-off-by: David Howells 
> ---
> 
>  kernel/Makefile |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 1408b3353a3c..11efbfa542a9 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -195,9 +195,9 @@ x509.genkey:
>   @echo >>x509.genkey "x509_extensions = myexts"
>   @echo >>x509.genkey
>   @echo >>x509.genkey "[ req_distinguished_name ]"
> - @echo >>x509.genkey "O = Magrathea"
> - @echo >>x509.genkey "CN = Glacier signing key"
> - @echo >>x509.genkey "emailAddress = slartibartfast@magrathea.h2g2"
> + @echo >>x509.genkey "#O = Unspecified company"
> + @echo >>x509.genkey "CN = Build time autogenerated kernel key"
> + @echo >>x509.genkey "#emailAddress = 
> unspecified.user@unspecified.company"
>   @echo >>x509.genkey
>   @echo >>x509.genkey "[ myexts ]"
>   @echo >>x509.genkey "basicConstraints=critical,CA:FALSE"

Acked-by: James Morris 


-- 
James Morris


--
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] Add initial DT support for Qualcomm SPMI PMIC devices

[Stephen Boyd]

On 02/03/15 04:17, Ivan T. Ivanov wrote:
> Following set of patches add initial DT support for PMIC devices
> found on recent Quqalcomm chipsets. Details for SPMI bus and PMIC arbiter
> could be found here [1].

Can you please put the specific compatible strings for the pmic model
into the nodes in addition to the generic "qcom,spmi-pmic"? We may want
to have regmap config tables in the future that describe the
cache/read/write abilities of the regsiters. If all we have is the
generic binding then we don't have a way to populate these tables.
Unless the plan there is to use the revid registers?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 1/6] ASoC: max98088: Document DT bindings

[Andreas Färber]

Am 19.02.2015 um 21:48 schrieb Javier Martinez Canillas:
> On 02/19/2015 07:54 PM, Andreas Färber wrote:
>> Am 19.02.2015 um 19:40 schrieb Andreas Färber:
>>> I updated max98088 and had it working on first boot, but on
>>> second boot it complained about the frequency:
>>>
>>> [7.896834] max98088 7-0010: revision A
>>> [7.912776] snow-audio sound: HiFi <-> 383.i2s mapping ok
>>> [7.919367] max98088 7-0010: Invalid master clock frequency
>>> [7.919429] snow-audio sound: ASoC: Spring-I2S-MAX98089 late_probe()
>>> failed: -22
>>> [7.920019] snow-audio sound: snd_soc_register_card failed (-22)
>>> [7.920109] snow-audio: probe of sound failed with error -22
>>
> 
> I had the same error on Snow but even on the first boot and after doing some
> code archeology, I found the following commit [0] in a Samsung downstream
> tree that solves the issue.
> 
> The problem is that clk_round_rate(max98095->mclk, freq) returns 0 as the
> rounded rate if XCLOUT is not allowed to be re-parented on rate change.

Same on Spring:

diff --git a/sound/soc/codecs/max98088.c b/sound/soc/codecs/max98088.c
index 1aa81321afba..46dc64675c26 100644
--- a/sound/soc/codecs/max98088.c
+++ b/sound/soc/codecs/max98088.c
@@ -1365,6 +1365,7 @@ static int max98088_dai_set_sysclk(struct
snd_soc_dai *dai,

if (!IS_ERR(max98088->mclk)) {
freq = clk_round_rate(max98088->mclk, freq);
+   dev_warn(codec->dev, "freq = %u\n", freq);
clk_set_rate(max98088->mclk, freq);
}


> With Tushar's patch I see that clk_round_rate() returns 2400 (24MHz)
> so the codec driver setups the correct PLL clock.

Ditto. With the clkout reparenting patch, clk_round_rate() returns 24MHz
just like when double-beep-initialized. However when not
double-beep-initialized, the driver initializes, but no audible output,
so there must be another missing puzzle piece.

>> On a suspicion, the fourth boot I waited for the double-beep of the
>> firmware (waiting for Ctrl+d/u), and then it did work.
>>
>> So it seems the mclk is not always set up properly by the kernel,
>> relying on firmware. Who's in charge of setting that clock up?
> 
> Right, it seems audio is only working due the firmware doing some previous
> setup. Probably it works on every boot if you have "sound init" as a part of
> the u-boot boot commands?

Indeed it does, 24 MHz without the reparenting patch, and sound working.

'sound init' code:
https://github.com/afaerber/u-boot/blob/spring/drivers/sound/max98088.c

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
--
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/6] CRIS: remove SMP code

[Jesper Nilsson]

On Thu, Feb 19, 2015 at 08:29:52PM +0100, Rabin Vincent wrote:
> The CRIS SMP code cannot be built since there is no (and appears to
> never have been) a CONFIG_SMP Kconfig option in arch/cris/.  Remove it.
> 
> Signed-off-by: Rabin Vincent 

Nice, added to the queue for the CRIS-tree.

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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 4/6] CRIS: use generic atomic.h

[Jesper Nilsson]

On Thu, Feb 19, 2015 at 08:29:54PM +0100, Rabin Vincent wrote:
> CRIS can use asm-generic's atomic.h.
> 
> Signed-off-by: Rabin Vincent 

Agreed, added to the CRIS-tree.

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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 6/6] CRIS: use generic headers via Kbuild

[Jesper Nilsson]

On Thu, Feb 19, 2015 at 08:29:56PM +0100, Rabin Vincent wrote:
> Delete headers which do nothing but include the asm-generic versions and
> use Kbuild magic instead.
> 
> Signed-off-by: Rabin Vincent 

Nice! Added to the CRIS-tree.

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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/

[PATCH] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Dmitry Torokhov]

Given the intent behind gpiod_get_optional() and friends it does not make
sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
work just fine without gpio so let's behave as if gpio was not found.
Otherwise we have to special-case -ENOSYS in drivers.

Signed-off-by: Dmitry Torokhov 
---
 include/linux/gpio/consumer.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index fd85cb1..f68244f 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -132,14 +132,14 @@ static inline struct gpio_desc *__must_check
 __gpiod_get_optional(struct device *dev, const char *con_id,
 enum gpiod_flags flags)
 {
-   return ERR_PTR(-ENOSYS);
+   return NULL;
 }
 
 static inline struct gpio_desc *__must_check
 __gpiod_get_index_optional(struct device *dev, const char *con_id,
   unsigned int index, enum gpiod_flags flags)
 {
-   return ERR_PTR(-ENOSYS);
+   return NULL;
 }
 
 static inline void gpiod_put(struct gpio_desc *desc)
@@ -171,14 +171,14 @@ static inline struct gpio_desc *__must_check
 __devm_gpiod_get_optional(struct device *dev, const char *con_id,
  enum gpiod_flags flags)
 {
-   return ERR_PTR(-ENOSYS);
+   return NULL;
 }
 
 static inline struct gpio_desc *__must_check
 __devm_gpiod_get_index_optional(struct device *dev, const char *con_id,
unsigned int index, enum gpiod_flags flags)
 {
-   return ERR_PTR(-ENOSYS);
+   return NULL;
 }
 
 static inline void devm_gpiod_put(struct device *dev, struct gpio_desc *desc)
-- 
2.2.0.rc0.207.ga3a616c


-- 
Dmitry
--
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/6] CRIS: use generic cmpxchg.h

[Jesper Nilsson]

On Thu, Feb 19, 2015 at 08:29:55PM +0100, Rabin Vincent wrote:
> CRIS can use asm-generic's cmpxchg.h
> 
> Signed-off-by: Rabin Vincent 

Looks good, adding to the CRIS-tree.

Thanks!

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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 3/6] CRIS: use generic atomic bitops

[Jesper Nilsson]

On Thu, Feb 19, 2015 at 08:29:53PM +0100, Rabin Vincent wrote:
> The generic atomic bitops are the same as the CRIS-specific ones.
> 
> Signed-off-by: Rabin Vincent 

Looks good, added to the CRIS-tree.

Thanks,

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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 1/6] CRISv32: don't enable irqs in INIT_THREAD

[Jesper Nilsson]

On Thu, Feb 19, 2015 at 08:29:51PM +0100, Rabin Vincent wrote:
> INIT_THREAD enables interrupts in the thread_struct's saved flags.  This
> means that interrupts get enabled in the middle of context_switch()
> while switching to new tasks that get forked off the init task during
> boot.  Don't do this.
> 
> Fixes the following splat on boot with spinlock debugging on:
> 
>   BUG: spinlock cpu recursion on CPU#0, swapper/2
>lock: runqueues+0x0/0x47c, .magic: dead4ead, .owner: swapper/0,
>   .owner_cpu: 0
>   CPU: 0 PID: 2 Comm: swapper Not tainted 3.19.0-08796-ga747b55 #285
> 
>   Call Trace:
>   [] spin_bug+0x2a/0x36
>   [] do_raw_spin_lock+0xa2/0x126
>   [] _raw_spin_lock+0x20/0x2a
>   [] scheduler_tick+0x22/0x76
>   [] update_process_times+0x5e/0x72
>   [] timer_interrupt+0x4e/0x6a
>   [] handle_irq_event_percpu+0x54/0xf2
>   [] handle_irq_event+0x50/0x74
>   [] handle_simple_irq+0x6c/0xbe
>   [] generic_handle_irq+0x2a/0x36
>   [] do_IRQ+0x38/0x84
>   [] crisv32_do_IRQ+0x54/0x60
>   [] IRQ0x4b_interrupt+0x34/0x3c
>   [] __schedule+0x24a/0x532
>   [] ret_from_kernel_thread+0x0/0x14
> 
> Signed-off-by: Rabin Vincent 

Looks good, adding to the CRIS-tree.

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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 v4 3/3] mmc: dw_mmc: Don't start command while data busy

[Doug Anderson]

Addy,

On Fri, Feb 13, 2015 at 10:17 PM, Addy Ke  wrote:
> We should wait until unbusy before the next request.
> But this does't need if the command is CMD13, which can access
> SD Status register regardless of data busy.
>
> Signed-off-by: Addy Ke 
> ---
> Changes in v4:
> - CMD13 doesn't need wait until unbusy.
>
>  drivers/mmc/host/dw_mmc.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index ac21863..692d97a 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1076,6 +1076,10 @@ static void dw_mci_request(struct mmc_host *mmc, 
> struct mmc_request *mrq)
>
> WARN_ON(slot->mrq);
>
> +   /* Wait until unbusy if the command isn't CMD13 */
> +   if (mrq->cmd->opcode != MMC_SEND_STATUS)
> +   dw_mci_wait_busy(slot);
> +

I think you need to be more general.  You really should be checking
"cmd_flags & SDMMC_CMD_PRV_DAT_WAIT".  That leverages dw_mmc's
knowledge about whether it needs to wait.  Right now you'll be waiting
for CMD52 (SDIO) which I don't think is a good idea.

It also seems like this would be better in dw_mci_start_command() so
that we have the least chance of hitting the case.  The downside is
that you can't sleep there, though...  Hrm.

I updated a version of my take on this at
.  I'll put a
timeout on it soon-ish.  Any extra testing that folks can do would be
appreciated...

-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/

linux-next: manual merge of the clk tree with Linus' tree

[Stephen Rothwell]

Hi Mike,

Today's linux-next merge of the clk tree got a conflict in
arch/powerpc/configs/corenet32_smp_defconfig between commit
a85cade6762b ("powerpc: Update all configs using savedefconfig") from
the  tree and commit 8f0ab1e14139 ("powerpc/corenet: Enable CLK_QORIQ")
from the clk tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/powerpc/configs/corenet32_smp_defconfig
index 51866f170684,cce62e934e0c..
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@@ -138,10 -143,11 +138,11 @@@ CONFIG_RTC_DRV_DS1307=
  CONFIG_RTC_DRV_DS1374=y
  CONFIG_RTC_DRV_DS3232=y
  CONFIG_UIO=y
 -CONFIG_STAGING=y
 -CONFIG_MEMORY=y
  CONFIG_VIRT_DRIVERS=y
  CONFIG_FSL_HV_MANAGER=y
 +CONFIG_STAGING=y
 +CONFIG_FSL_CORENET_CF=y
+ CONFIG_CLK_QORIQ=y
  CONFIG_EXT2_FS=y
  CONFIG_EXT3_FS=y
  # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set


pgp9uen3fkYoF.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls

[Pali Rohár]

On Thursday 05 February 2015 13:38:58 Pali Rohár wrote:
> On Tuesday 03 February 2015 20:57:11 Pali Rohár wrote:
> > On Tuesday 03 February 2015 20:35:25 Felipe Balbi wrote:
> > > On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> > > > > On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár
> 
> wrote:
> > > > > > On Tuesday 03 February 2015 16:43:45 Felipe Balbi
> 
> wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali
> > > > > > > Rohár
> > 
> > wrote:
> > > > > > > > On Tuesday 03 February 2015 00:15:19 Felipe
> > > > > > > > Balbi
> > 
> > wrote:
> > > > > > > > > f_phonet's ->set_alt() method will call
> > > > > > > > > usb_ep_disable() potentially on an endpoint
> > > > > > > > > which is already disabled. That's something
> > > > > > > > > the gadget/function driver must guarantee
> > > > > > > > > that it's always balanced.
> > > > > > > > > 
> > > > > > > > > In order to balance the calls, just make sure
> > > > > > > > > the endpoint was enabled before by means of
> > > > > > > > > checking the validity of driver_data.
> > > > > > > > > 
> > > > > > > > > Reported-by: Pali Rohár 
> > > > > > > > > Signed-off-by: Felipe Balbi 
> > > > > > > > > ---
> > > > > > > > 
> > > > > > > > Your patches cause that kernel does not print
> > > > > > > > any error message to n900 screen anymore and
> > > > > > > > reboot device in 10 seconds. I did not loaded
> > > > > > > > any external modules.
> > > > > > > 
> > > > > > > > In qemu I see this crash in early boot:
> > > > > > > alright, so n900's working fine. I'll wait until
> > > > > > > you debug qemu a little more, thank you
> > > > > > 
> > > > > > NO! It does not working, see . It break n900
> > > > > > totally!
> > > > > 
> > > > > settle down a bit more. I don't have the HW you have
> > > > > and things are working fine on boards I _do_ have,
> > > > > there's not much more I can do to help without you
> > > > > doing your homework. Debug a bit more and bring more
> > > > > information as to what's going on, until then you're
> > > > > on your own.
> > > > 
> > > > And what more do you need? It crash on my n900 and also
> > > > in qemu. I sent you kernel crash dump from qemu which
> > > > introduced *your* patches. Before applying your patches
> > > > there was no crash in early boot stage.
> > > > 
> > > > In current state I review all 3 patches as:
> > > > 
> > > > Rejected-by: Pali Rohár 
> > > > [It breaks booting Nokia N900 device]
> > > 
> > > next step, figure why it's broken. Working just fine here
> > > on AM335x which has the same musb IP.
> > 
> > Why is broken? That is easy. You send 3 patches which broke
> > it.
> 
> Actually when I reverted only that patch which adds line:
> 
> pm_runtime_irq_safe(musb->controller)
> 
> then early boot crash disappeared.
> 
> But other two patches did not fixed support for external .ko
> gadget modules. State is same -- crash after modprobe.

Here is crash from qemu when musb is compiled into kernel:

[0.641662] Unable to handle kernel NULL pointer dereference at virtual 
address 
[0.642211] pgd = c0004000
[0.642425] [] *pgd=
[0.642913] Internal error: Oops: 8005 [#1] PREEMPT ARM
[0.643371] Modules linked in:
[0.643737] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc5+ #329
[0.644195] Hardware name: Nokia RX-51 board
[0.644531] task: cf8a8000 ti: cf8ac000 task.ti: cf8ac000
[0.644958] PC is at 0x0
[0.645263] LR is at omap2430_runtime_resume+0x80/0x100
[0.645660] pc : [<>]lr : []psr: 6113
[0.645660] sp : cf8adda0  ip : 0001  fp : c0059c64
[0.646423] r10: cf8adde8  r9 : cf9b5884  r8 : cf9b58cc
[0.646789] r7 : 0004  r6 : cf93ee10  r5 : c06ac84c  r4 : cf83a010
[0.647216] r3 :   r2 : c0565716  r1 : 0414  r0 : fa0ab000
[0.647735] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[0.648254] Control: 10c53c7d  Table: 80004059  DAC: 0015
[0.648651] Process swapper (pid: 1, stack limit = 0xcf8ac238)
[0.649078] Stack: (0xcf8adda0 to 0xcf8ae000)
[0.649444] dda0: c0022428 cf9b5810 cf93ee10 c026bb44 0001 c026d3e0 
 cf9b5810
[0.650085] ddc0:  c026d4a0 cf9b5810 cf9b5810  c026e9a4 
c0441790 cfa29410
[0.650634] dde0: cfb33800 c0441790 cfa29410 cfa2b700  6113 
cfa2b6c0 cfa29410
[0.651153] de00: c0660c80 006c c06210c4 c05de6d4  c026ee74 
cfa2c180 cfa29410
[0.651702] de20: cfa2b6c0 c026eed4 cf83a010 c02c53f8 cfa29410 006c 
fa0ab000 ffed
[0.652252] de40: cfa29410 c0660c80 c0660c80 c062cfe0 c06210c4 c05de6d4 
 c0267ad8
[0.652770] de60:  cfa29410  c026624c  cfa29410 
c0660c80 c0660c80
[0.653320] de80:  c0266478  cfa29410 cfa29444 c02664f0 
c0660c80 cf8adea8
[0.653839] dea0: c0266490 c0264dd0 

Re: [PATCH 1/2] x86: fix output of show_stack_log_lvl()

[Borislav Petkov]

On Thu, Feb 19, 2015 at 11:43:15PM +0100, Adrien Schildknecht wrote:
> Prepend the log level at the message following a newline.
> It is not possible to use pr_cont after a newline, the log level will be
> reseted.
> 
> Signed-off-by: Adrien Schildknecht 
> ---
>  arch/x86/kernel/dumpstack_32.c | 9 ++---
>  arch/x86/kernel/dumpstack_64.c | 9 ++---
>  2 files changed, 12 insertions(+), 6 deletions(-)

So those two patches belong into one as they logically are one fix.
Please merge them.

Then, please change your commit message to the format:

"Problem is A.

We need to do B.

This patch does it or this patch does C in order fix it."

Something like that in free form. Being verbose is a good thing when
explaning why this fix is needed and for people looking at those commit
messages months and years from now.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/6] CRIS: remove SMP code

[Paul Bolle]

On Thu, 2015-02-19 at 20:29 +0100, Rabin Vincent wrote:
> The CRIS SMP code cannot be built since there is no (and appears to
> never have been) a CONFIG_SMP Kconfig option in arch/cris/.  Remove it.

Yes, it appears there never was a Kconfig symbol SMP for cris so this
probably was dead code ever since it was added in, I think, v2.6.13. (I
should mention I didn't review this patch, or cris' apparently
non-functional SMP code, in detail.)

Mind if I ask how you spotted this?


Paul Bolle

--
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 v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage

[Russell King - ARM Linux]

On Thu, Feb 19, 2015 at 03:49:46PM -0800, Doug Anderson wrote:
> Alim and Addy,
> 
> On Sun, Feb 15, 2015 at 3:28 PM, Alim Akhtar  wrote:
> > Hi Addy,
> >
> > On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke  wrote:
> >> As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
> >> stable and we may get 'data busy' which can't be cleaned by resetting
> >> all blocks. So we should not send command to update clock in this state.
> >>
> >> Signed-off-by: Addy Ke 
> >> ---
> >>  drivers/mmc/host/dw_mmc.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> >> index 4d2e3c2..3472f9b 100644
> >> --- a/drivers/mmc/host/dw_mmc.c
> >> +++ b/drivers/mmc/host/dw_mmc.c
> >> @@ -1102,7 +1102,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
> >> struct mmc_ios *ios)
> >> drv_data->set_ios(slot->host, ios);
> >>
> >> /* Slot specific timing and width adjustment */
> >> -   dw_mci_setup_bus(slot, false);
> >> +   if (ios->power_mode != MMC_POWER_UP)
> >> +   dw_mci_setup_bus(slot, false);
> >>
> > This looks a HACK to me.
> > If stabilizing host voltage regulator is the problem, can you try out
> > below patch, and see if this resolve your issue?
> 
> Actually, IMHO Alim's patch is more of a hack than Addy's.  There's
> already a 10ms delay between "power up" and "power on" in the MMC core
> in mmc_power_up() state.  That delay is commented as:
> 
>   /*
>* This delay should be sufficient to allow the power supply
>* to reach the minimum voltage.
>*/
>   mmc_delay(10);
> 
> That means that assuming that the voltage is stable in MMC_POWER_UP is
> not valid anyway.
> 
> 
> Addy's patch certainly needs more comments.  In another context Olof 
> suggested:
> 
> /*
>  * Skip bus setup while voltage is still stabilizing. Instead,
>  * bus setup will be done at MMC_POWER_ON.
>  */
> 
> 
> ...thinking about this more, though: really the voltage should be
> stabilized when the regulator call returns (see my comments below).
> In actuality the "right" fix might be to just rearrange this function
> a little not to turn the clock on _before_ we even try to turn the
> voltage on.

This is exactly why I've been saying that we need to get away from the
POWER_UP vs POWER_ON stuff.  We instead need a _single_ call into
drivers to tell them to apply power and bring the card to a state
where it can be talked to.

That includes waiting for the power to stabilise, and sending the
initial clocks to allow the card to initialise.

In the case of extra GPIOs, host drivers will need to call back into
the MMC core at the point where they have stabilised the power.

The current situation where we split the power-up/power-on sequence
between the host drivers and the core is really a hinderance to getting
a working implementation - it's additional complexity where none is
needed.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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 v4 1/3] mmc: dw_mmc: update clock after host reach a stable voltage

[Doug Anderson]

Alim and Addy,

On Sun, Feb 15, 2015 at 3:28 PM, Alim Akhtar  wrote:
> Hi Addy,
>
> On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke  wrote:
>> As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
>> stable and we may get 'data busy' which can't be cleaned by resetting
>> all blocks. So we should not send command to update clock in this state.
>>
>> Signed-off-by: Addy Ke 
>> ---
>>  drivers/mmc/host/dw_mmc.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 4d2e3c2..3472f9b 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1102,7 +1102,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
>> struct mmc_ios *ios)
>> drv_data->set_ios(slot->host, ios);
>>
>> /* Slot specific timing and width adjustment */
>> -   dw_mci_setup_bus(slot, false);
>> +   if (ios->power_mode != MMC_POWER_UP)
>> +   dw_mci_setup_bus(slot, false);
>>
> This looks a HACK to me.
> If stabilizing host voltage regulator is the problem, can you try out
> below patch, and see if this resolve your issue?

Actually, IMHO Alim's patch is more of a hack than Addy's.  There's
already a 10ms delay between "power up" and "power on" in the MMC core
in mmc_power_up() state.  That delay is commented as:

  /*
   * This delay should be sufficient to allow the power supply
   * to reach the minimum voltage.
   */
  mmc_delay(10);

That means that assuming that the voltage is stable in MMC_POWER_UP is
not valid anyway.


Addy's patch certainly needs more comments.  In another context Olof suggested:

/*
 * Skip bus setup while voltage is still stabilizing. Instead,
 * bus setup will be done at MMC_POWER_ON.
 */


...thinking about this more, though: really the voltage should be
stabilized when the regulator call returns (see my comments below).
In actuality the "right" fix might be to just rearrange this function
a little not to turn the clock on _before_ we even try to turn the
voltage on.

I've got that coded up but I'm still testing it...  If you want to try
it too, you can find it at
.

Note that without my patch I find that I _really_ need Addy's patch to
make sure that the card isn't busy in setup_bus.  With my patch Addy's
code catches the card busy less often.  I'm still trying to see if
there's a way to totally remove the need for his setup_bus and still
trying to grok all the patches flying around...


> ===
> [PATCH] mmc: dw_mmc: Wait for host voltage regulator to be stable
>
> Signed-off-by: Alim Akhtar 
> ---
>  drivers/mmc/host/dw_mmc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 4d2e3c2..dc10fbb 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1202,6 +1202,9 @@ static int dw_mci_switch_voltage(struct mmc_host
> *mmc, struct mmc_ios *ios)
>   }
>   mci_writel(host, UHS_REG, uhs);
>
> + /* wait for 5ms so that host voltage regulator is stable */
> + usleep_range(5000, 5500);
> +

Alim: if you have some other instance where you actually need VQMMC to
stabilize it should probably be done in a different way.  If I
understand correctly it is the regulator core's job to make sure that
voltage is stable before returning.  If you have a gpio-regulator you
may be able to use "startup-delay-us" to specify how long the
regulator takes to come up.  You could also look at
'regulator-enable-ramp-delay'

-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 3.12 065/122] lib/checksum.c: fix carry in csum_tcpudp_nofold

[Karl Beldan]

On Wed, Feb 18, 2015 at 09:40:23AM +, David Laight wrote:
> From: Karl Beldan 
> > On Tue, Feb 17, 2015 at 12:04:22PM +, David Laight wrote:
> > > > +static inline u32 from64to32(u64 x)
> > > > +{
> > > > +   /* add up 32-bit and 32-bit for 32+c bit */
> > > > +   x = (x & 0x) + (x >> 32);
> > > > +   /* add up carry.. */
> > > > +   x = (x & 0x) + (x >> 32);
> > > > +   return (u32)x;
> > > > +}
> > >
> > > As a matter of interest, does the compiler optimise away the
> > > second (x & 0x) ?
> > > The code could just be:
> > >   x = (x & 0x) + (x >> 32);
> > >   return x + (x >> 32);
> > >
> >
> > On my side, from what I've seen so far, your version results in better
> > assembly, esp. with clang, but my first version
> > http://article.gmane.org/gmane.linux.kernel/1875407:
> > x += (x << 32) + (x >> 32);
> > return (__force __wsum)(x >> 32);
> > resulted in even better assembly, I just verified with gcc/clang,
> > x86_64/ARM and -O1,2,3.
> 
> The latter looks to have a shorter dependency chain as well.
> Although I'd definitely include a comment saying that it is equivalent
> to the two lines in the current patch.
> 
> Does either compiler manage to use a rotate for the two shifts?
> Using '(x << 32) | (x >> 32)' might convince it to do so.
> That would reduce it to three 'real' instructions and a register rename.
> 
gcc and clang rotate for tile (just checked gcc) and x86_64, not for arm
(and IMHO rightly so).
Both '|' and '+' yielded the same asm for those 3 archs.
 
Karl
--
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/