Re: [lm-sensors] [PATCH] hwmon: (ads7828) Make sample interval configurable
On 01/16/2015 07:30 PM, Guenter Roeck wrote: I sent a couple of patches a minute ago which should take care of the issue. Would be great if you can test it. I applied the v2 versions of the patches for a quick test, but it was not successful. Haven't done any further investigation on what the problem might be, but when trying to read the sysfs driver I get "read error: No such device or address". The sysfs path have moved with the REGMAP settings, from /sys/bus/i2c/devices//in0_input to /sys/bus/i2c/devices//hwmon/hwmon0/in0_input. Any ideas? Haven't had REGMAP configured in my kernel earlier, might it be some specific configuration I miss? BR, Robert -- 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]PM/Sleep: Timer quiesce in freeze state
On 2015/1/26 22:41, Rafael J. Wysocki wrote:
> On Monday, January 26, 2015 10:40:24 AM Thomas Gleixner wrote:
>> On Mon, 26 Jan 2015, Li, Aubrey wrote:
>>> On 2015/1/22 18:15, Thomas Gleixner wrote:
>
> [...]
>
> + /*
> + * cpuidle_enter will return with interrupt enabled
> + */
> + cpuidle_enter(drv, dev, next_state);
How is that supposed to work?
If timekeeping is not yet unfrozen, then any interrupt handling code
which calls anything time related is going to hit lala land.
You must guarantee that timekeeping is unfrozen before any interrupt
is handled. If you cannot guarantee that, you cannot freeze
timekeeping ever.
The cpu local tick device is less critical, but it happens to work by
chance, not by design.
>>>
>>> There are two way to guarantee this: the first way is, disable interrupt
>>> before timekeeping frozen and enable interrupt after timekeeping is
>>> unfrozen. However, we need to handle wakeup handler before unfreeze
>>> timekeeping to wake freeze task up from wait queue.
>>>
>>> So we have to go the other way, the other way is, we ignore time related
>>> calls during freeze, like what I added in irq_enter below.
>>
>> Groan. You just do not call in irq_enter/exit(), but what prevents any
>> interrupt handler or whatever to call into the time/timer code after
>> interrupts got reenabled?
>>
>> Nothing.
>>
>>> Or, we need to re-implement freeze wait and wake up mechanism?
>>
>> You need to make sure in the low level idle implementation that this
>> cannot happen.
>>
>> tick_freeze()
>> {
>> raw_spin_lock(&tick_freeze_lock);
>> tick_frozen++;
>> if (tick_frozen == num_online_cpus())
>> timekeeping_suspend();
>> else
>> tick_suspend_local();
>> raw_spin_unlock(&tick_freeze_lock);
>> }
>>
>> tick_unfreeze()
>> {
>> raw_spin_lock(&tick_freeze_lock);
>> if (tick_frozen == num_online_cpus())
>> timekeeping_resume();
>> else
>> tick_resume_local();
>> tick_frozen--;
>> raw_spin_unlock(&tick_freeze_lock);
>> }
>>
>> idle_freeze()
>> {
>> local_irq_disable();
>>
>> tick_freeze();
>>
>> /* Must keep interrupts disabled! */
>> go_deep_idle()
>>
>> tick_unfreeze();
>>
>> local_irq_enable();
>> }
>>
>> That's the only way you can do it proper, everything else will just be
>> a horrible mess of bandaids and duct tape.
>>
>> So that does not need any of the irq_enter/exit conditionals, it does
>> not need the real_handler hack. It just works.
>
> As long as go_deep_idle() above does not enable interrupts. This means we
> won't
> be able to use some C-states for suspend-to-idle (hald-induced C1 on some x86
> for one example), but that's not a very big deal.
Does the legacy ACPI system IO method to enter C2/C3 need interrupt
enabled as well?
Do we need some platform ops to cover those legacy platforms? Different
platform go different branch here.
Thanks,
-Aubrey
>
>> The only remaining issue might be a NMI calling into
>> ktime_get_mono_fast_ns() before timekeeping is resumed. Its probably a
>> non issue on x86/tsc, but it might be a problem on other platforms
>> which turn off devices, clocks, It's not rocket science to prevent
>> that.
>
> I don't see any users of ktime_get_mono_fast_ns() at all, unless some
> non-trivial
> macros are involved. At least grepping for it only returns the definition,
> declarations and the line in trace.c.
>
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/4] ARM:sunxi:drivers:input Add support for A10/A20 PS2
Hi Vishnu,
On Sun, Jan 25, 2015 at 07:10:07PM +0530, Vishnu Patekar wrote:
> Signed-off-by: VishnuPatekar
> ---
> drivers/input/serio/Kconfig | 11 ++
> drivers/input/serio/Makefile|1 +
> drivers/input/serio/sun4i-ps2.c | 347
> +++
> 3 files changed, 359 insertions(+)
> create mode 100644 drivers/input/serio/sun4i-ps2.c
>
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index bc2d474..964afc5 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -281,4 +281,15 @@ config HYPERV_KEYBOARD
> To compile this driver as a module, choose M here: the module will
> be called hyperv_keyboard.
>
> +config SERIO_SUN4I_PS2
> + tristate "Allwinner A10 PS/2 controller support"
> + default n
> + depends on ARCH_SUNXI || COMPILE_TEST
> + help
> + This selects support for the PS/2 Host Controller on
> + Allwinner A10.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called sun4i-ps2.
> +
> endif
> diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
> index 815d874..c600089 100644
> --- a/drivers/input/serio/Makefile
> +++ b/drivers/input/serio/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_SERIO_ARC_PS2) += arc_ps2.o
> obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
> obj-$(CONFIG_SERIO_OLPC_APSP)+= olpc_apsp.o
> obj-$(CONFIG_HYPERV_KEYBOARD)+= hyperv-keyboard.o
> +obj-$(CONFIG_SERIO_SUN4I_PS2)+= sun4i-ps2.o
> diff --git a/drivers/input/serio/sun4i-ps2.c b/drivers/input/serio/sun4i-ps2.c
> new file mode 100644
> index 000..d3cf6bc
> --- /dev/null
> +++ b/drivers/input/serio/sun4i-ps2.c
> @@ -0,0 +1,347 @@
> +/*
> + * Driver for Allwinner A10 PS2 host controller
> + *
> + * Author: Vishnu Patekar
> + * Aaron.maoye
> + *
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
You do not really need all these of_* includes. Neither you need list.h.
> +#include
> +#include
> +
> +#define DRIVER_NAME "sun4i-ps2"
> +
> +/* register offset definitions */
> +#define PS2_REG_GCTL 0x00/* PS2 Module Global Control Reg */
> +#define PS2_REG_DATA 0x04/* PS2 Module Data Reg */
> +#define PS2_REG_LCTL 0x08/* PS2 Module Line Control Reg */
> +#define PS2_REG_LSTS 0x0C/* PS2 Module Line Status Reg */
> +#define PS2_REG_FCTL 0x10/* PS2 Module FIFO Control Reg */
> +#define PS2_REG_FSTS 0x14/* PS2 Module FIFO Status Reg */
> +#define PS2_REG_CLKDR0x18/* PS2 Module Clock Divider
> Reg*/
> +
> +/* PS2 GLOBAL CONTROL REGISTER PS2_GCTL */
> +#define PS2_GCTL_INTFLAG BIT(4)
> +#define PS2_GCTL_INTEN BIT(3)
> +#define PS2_GCTL_RESET BIT(2)
> +#define PS2_GCTL_MASTER BIT(1)
> +#define PS2_GCTL_BUSEN BIT(0)
> +
> +/* PS2 LINE CONTROL REGISTER */
> +#define PS2_LCTL_NOACK BIT(18)
> +#define PS2_LCTL_TXDTOEN BIT(8)
> +#define PS2_LCTL_STOPERREN BIT(3)
> +#define PS2_LCTL_ACKERRENBIT(2)
> +#define PS2_LCTL_PARERRENBIT(1)
> +#define PS2_LCTL_RXDTOEN BIT(0)
> +
> +/* PS2 LINE STATUS REGISTER */
> +#define PS2_LSTS_TXTDO BIT(8)
> +#define PS2_LSTS_STOPERR BIT(3)
> +#define PS2_LSTS_ACKERR BIT(2)
> +#define PS2_LSTS_PARERR BIT(1)
> +#define PS2_LSTS_RXTDO BIT(0)
> +
> +#define PS2_LINE_ERROR_BIT \
> + (PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR | \
> + PS2_LSTS_PARERR | PS2_LSTS_RXTDO)
> +
> +/* PS2 FIFO CONTROL REGISTER */
> +#define PS2_FCTL_TXRST BIT(17)
> +#define PS2_FCTL_RXRST BIT(16)
> +#define PS2_FCTL_TXUFIEN BIT(10)
> +#define PS2_FCTL_TXOFIEN BIT(9)
> +#define PS2_FCTL_TXRDYIENBIT(8)
> +#define PS2_FCTL_RXUFIEN BIT(2)
> +#define PS2_FCTL_RXOFIEN BIT(1)
> +#define PS2_FCTL_RXRDYIENBIT(0)
> +
> +/* PS2 FIFO STATUS REGISTER */
> +#define PS2_FSTS_TXUFBIT(10)
> +#define PS2_FSTS_TXOFBIT(9)
> +#define PS2_FSTS_TXRDY BIT(8)
> +#define PS2_FSTS_RXUFBIT(2)
> +#define PS2_FSTS_RXOFBIT(1)
> +#define PS2_FSTS_RXRDY BIT(0)
> +
> +#define PS2_FIFO_ERROR_BIT \
> + (PS2_FSTS_TXUF | PS2_FSTS_TXOF | PS2_FSTS_RXUF | PS2_FSTS_RXOF)
> +
> +#define PS2_SAMPLE_CLK 100
> +#define PS2_SCLK 125000
> +
> +struct sun4i_ps2data {
> + struct serio *serio;
> + struct device *dev;
> +
> + /* IO mapping base */
> + void __iomem*reg_base;
> +
> + /* clock management */
> + struct clk *clk;
> +
> + /* irq */
> + spinlock_t lock;
> + int irq;
> +};
> +
> +/*/
> +/* Interrupt handler
linux-next: build failure after merge of the wireless-drivers-next tree
Hi Kalle,
After merging the wireless-drivers-next tree, today's linux-next build
(powerpc allyesconfig) failed like this:
drivers/net/wireless/ath/ath9k/ath9k_htc.o:(.data+0x29d0): multiple definition
of `led_blink'
drivers/net/wireless/ath/ath9k/ath9k.o:(.bss+0x1654): first defined here
Caused by commit 3a939a671225 ("ath9k_htc: Add a module parameter to
disable blink").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpBmdoXmqviz.pgp
Description: OpenPGP digital signature
Re: [PATCH] net: dsa/mv88e6xxx: add reg read and write debug
From: Vivien Didelot Date: Fri, 23 Jan 2015 16:10:36 -0500 > This commit adds debug messages for the generic mv88e6xxx read and write > routines. The output is similar to this: > > mdio-gpio mdio-gpio.0: <- addr: 0x1b reg: 0x05 val: 0x4000 > mdio-gpio mdio-gpio.0: -> addr: 0x1b reg: 0x07 val: 0x3113 > mdio-gpio mdio-gpio.0: -> addr: 0x1b reg: 0x08 val: 0x0330 > mdio-gpio mdio-gpio.0: -> addr: 0x1b reg: 0x09 val: 0x > > This is convenient to dynamically debug operations through debugfs with: > > echo file mv88e6xxx.c +p > /dynamic_debug/control > > Signed-off-by: Vivien Didelot Applied, 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/
Re: [PATCH v2 2/3] mm: cma: allocation trigger
On Mon, Jan 26, 2015 at 09:26:04AM -0500, Sasha Levin wrote:
> Provides a userspace interface to trigger a CMA allocation.
>
> Usage:
>
> echo [pages] > alloc
>
> This would provide testing/fuzzing access to the CMA allocation paths.
>
> Signed-off-by: Sasha Levin
> ---
> mm/cma_debug.c | 60
> ++--
> 1 file changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/mm/cma_debug.c b/mm/cma_debug.c
> index 3a25413..39c7116 100644
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -7,9 +7,22 @@
>
> #include
> #include
> +#include
> +#include
> +#include
dma-contiguous.h doesn't needed now.
> +#include
>
> #include "cma.h"
>
> +struct cma_mem {
> + struct hlist_node node;
> + struct page *p;
> + unsigned long n;
> +};
> +
> +static HLIST_HEAD(cma_mem_head);
> +static DEFINE_SPINLOCK(cma_mem_head_lock);
> +
> static struct dentry *cma_debugfs_root;
How about keeping cma_mem_head on each cma area separately?
> static int cma_debugfs_get(void *data, u64 *val)
> @@ -23,8 +36,48 @@ static int cma_debugfs_get(void *data, u64 *val)
>
> DEFINE_SIMPLE_ATTRIBUTE(cma_debugfs_fops, cma_debugfs_get, NULL, "%llu\n");
>
> -static void cma_debugfs_add_one(struct cma *cma, int idx)
> +static void cma_add_to_cma_mem_list(struct cma_mem *mem)
> +{
> + spin_lock(&cma_mem_head_lock);
> + hlist_add_head(&mem->node, &cma_mem_head);
> + spin_unlock(&cma_mem_head_lock);
> +}
> +
> +static int cma_alloc_mem(struct cma *cma, int count)
> {
> + struct cma_mem *mem;
> + struct page *p;
> +
> + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> + if (!mem)
> + return -ENOMEM;
> +
> + p = cma_alloc(cma, count, CONFIG_CMA_ALIGNMENT);
> + if (!p) {
> + kfree(mem);
> + return -ENOMEM;
> + }
CONFIG_CMA_ALIGNMENT looks not good. It means just maximum aligment
so it is odd to use this value in testing. Is there special meaning
to use it here?
Could we also get alignment parameter from user? Something like below.
echo "4 1" > alloc
4 for number of pages
1 for alignment.
If it is impossible, just 0 looks better than CONFIG_CMA_ALIGNMENT.
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/
Re: [PATCH] net: dsa/mv88e6352: make mv88e6352_wait generic
From: Vivien Didelot Date: Fri, 23 Jan 2015 18:34:41 -0500 > Some busy bits are available in the global register 1, such as the ATU > Busy bit. We may want to use this function to wait for them to change, > so add a new parameter to mv88e6352_wait() instead of hard-coding > REG_GLOBAL2. > > In the meantime, since the REG_READ() macro already checks for error, > remove the redundant check for ret < 0. > > Signed-off-by: Vivien Didelot Applied. -- 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 20/32] net: use %*pb[l] to print bitmaps including cpumasks and nodemasks
From: Tejun Heo Date: Sat, 24 Jan 2015 09:03:26 -0500 > printk and friends can now formap bitmaps using '%*pb[l]'. cpumask > and nodemask also provide cpumask_pr_args() and nodemask_pr_args() > respectively which can be used to generate the two printf arguments > necessary to format the specified cpu/nodemask. > > This patch is dependent on the following two patches. > > lib/vsprintf: implement bitmap printing through '%*pb[l]' > cpumask, nodemask: implement cpumask/nodemask_pr_args() > > Please wait till the forementioned patches are merged to mainline > before applying to subsystem trees. > > Signed-off-by: Tejun Heo Please just apply this directly with those prerequisites, thanks: Acked-by: David S. Miller -- 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: Edited kexec_load(2) [kexec_file_load()] man page for review
Hello Vivek,
Ping!
Cheers,
Michael
On 16 January 2015 at 14:30, Michael Kerrisk (man-pages)
wrote:
> Hello Vivek,
>
> Thanks for your comments! I've added some further text to
> the page based on those comments. See some follow-up
> questions below.
>
> On 01/12/2015 11:16 PM, Vivek Goyal wrote:
>> On Wed, Jan 07, 2015 at 10:17:56PM +0100, Michael Kerrisk (man-pages) wrote:
>>
>> [..]
> .BR KEXEC_ON_CRASH " (since Linux 2.6.13)"
> Execute the new kernel automatically on a system crash.
> .\" FIXME Explain in more detail how KEXEC_ON_CRASH is actually used
>>>
>>> I wasn't expecting that you would respond to the FIXMEs that were
>>> not labeled "kexec_file_load", but I was hoping you might ;-). Thanks!
>>> I have a few additional questions to your nice notes.
>>>
Upon boot first kernel reserves a chunk of contiguous memory (if
crashkernel=<> command line paramter is passed). This memory is
is used to load the crash kernel (Kernel which will be booted into
if first kernel crashes).
>>>
>>
>> Hi Michael,
>>
>>> Can I just confirm: is it in all cases only possible to use kexec_load()
>>> and kexec_file_load() if the kernel was booted with the 'crashkernel'
>>> parameter set?
>>
>> As of now, only kexec_load() and kexec_file_load() system calls can
>> make use of memory reserved by crashkernel=<> kernel parameter. And
>> this is used only if we are trying to load a crash kernel (KEXEC_ON_CRASH
>> flag specified).
>
> Okay.
>
Location of this reserved memory is exported to user space through
/proc/iomem file.
>>>
>>> Is that export via an entry labeled "Crash kernel" in the
>>> /proc/iomem file?
>>
>> Yes.
>
> Okay -- thanks.
>
User space can parse it and prepare list of segments
specifying this reserved memory as destination.
>>>
>>> I'm not quite clear on "specifying this reserved memory as destination".
>>> Is that done by specifying the address in the kexec_segment.mem fields?
>>
>> You are absolutely right. User space can specify in kexec_segment.mem
>> field the memory location where it expecting a particular segment to
>> be loaded by kernel.
>>
>>>
Once kernel sees the flag KEXEC_ON_CRASH, it makes sure that all the
segments are destined for reserved memory otherwise kernel load operation
fails.
>>>
>>> Could you point me to where this checking is done? Also, what is the
>>> error (errno) that occurs when the load operation fails? (I think the
>>> answers to these questions are "at the start of kimage_alloc_init()"
>>> and "EADDRNOTAVAIL", but I'd like to confirm.)
>>
>> This checking happens in sanity_check_segment_list() which is called
>> by kimage_alloc_init().
>>
>> And yes, error code returned is -EADDRNOTAVAIL.
>
> Thanks. I added EADDRNOTAVAIL to the ERRORS.
>
[..]
> struct kexec_segment {
> void *buf;/* Buffer in user space */
> size_t bufsz; /* Buffer length in user space */
> void *mem;/* Physical address of kernel */
> size_t memsz; /* Physical address length */
> };
> .fi
> .in
> .PP
> .\" FIXME Explain the details of how the kernel image defined by segments
> .\" is copied from the calling process into previously reserved memory.
Kernel image defined by segments is copied into kernel either in regular
memory
>>>
>>> Could you clarify what you mean by "regular memory"?
>>
>> I meant memory which is not reserved memory.
>
> Okay.
>
or in reserved memory (if KEXEC_ON_CRASH is set). Kernel first
copies list of segments in kernel memory and then goes does various
sanity checks on the segments. If everything looks line, kernel copies
segment data to kernel memory.
In case of normal kexec, segment data is loaded in any available memory
and segment data is moved to final destination at the kexec reboot time.
>>>
>>> By "moved to final destination", do you mean "moved from user space to the
>>> final kernel-space destination"?
>>
>> No. Segment data moves from user space to kernel space once kexec_load()
>> call finishes successfully. But when user does reboot (kexec -e), at that
>> time kernel moves that segment data to its final location. Kernel could
>> not place the segment at its final location during kexec_load() time as
>> that memory is already in use by running kernel. But once we are about
>> to reboot to new kernel, we can overwrite the old kernel's memory.
>
> Got it.
>
In case of kexec on panic (KEXEC_ON_CRASH flag set), segment data is
directly loaded to reserved memory and after crash kexec simply jumps
>>>
>>> By "directly", I assume you mean "at the time of the kexec_laod() call",
>>> right?
>>
>> Yes.
>
> Thanks.
>
> So, returning to the kexeec_segment structure:
>
>struct kexec_segment {
>void *buf;/* Buffer in user space */
>size_t bufsz; /* Buffer length in user space */
>void
Re: [PATCH v2 3/3] mm: cma: release trigger
On Mon, Jan 26, 2015 at 09:26:05AM -0500, Sasha Levin wrote:
> Provides a userspace interface to trigger a CMA release.
>
> Usage:
>
> echo [pages] > free
>
> This would provide testing/fuzzing access to the CMA release paths.
>
> Signed-off-by: Sasha Levin
> ---
> mm/cma_debug.c | 54 ++
> 1 file changed, 54 insertions(+)
>
> diff --git a/mm/cma_debug.c b/mm/cma_debug.c
> index 39c7116..0a63945 100644
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
Is mm_types.h needed?
>
> #include "cma.h"
>
> @@ -43,6 +44,56 @@ static void cma_add_to_cma_mem_list(struct cma_mem *mem)
> spin_unlock(&cma_mem_head_lock);
> }
>
> +static struct cma_mem *cma_get_entry_from_list(void)
> +{
> + struct cma_mem *mem = NULL;
> +
> + spin_lock(&cma_mem_head_lock);
> + if (!hlist_empty(&cma_mem_head)) {
> + mem = hlist_entry(cma_mem_head.first, struct cma_mem, node);
> + hlist_del_init(&mem->node);
> + }
> + spin_unlock(&cma_mem_head_lock);
> +
> + return mem;
> +}
> +
> +static int cma_free_mem(struct cma *cma, int count)
> +{
> + struct cma_mem *mem = NULL;
> +
> + while (count) {
> + mem = cma_get_entry_from_list();
> + if (mem == NULL)
> + return 0;
> +
> + if (mem->n <= count) {
> + cma_release(cma, mem->p, mem->n);
> + count -= mem->n;
> + kfree(mem);
> + } else {
> + cma_release(cma, mem->p, count);
> + mem->p += count;
> + mem->n -= count;
> + count = 0;
> + cma_add_to_cma_mem_list(mem);
> + }
> + }
If order_per_bit is not 0 and count used in cma_release() is
different with the count used in cma_alloc(), problem could
occur since bitmap management code can't handle that situation.
Could we just disable this case in this testing module?
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/
Re: [PATCH v2] net: hyperv: else branch not necessary
From: Nicholas Mc Guire Date: Sun, 25 Jan 2015 19:08:37 +0100 > As the if completes with a unconditional goto the else branch > is not needed here. > > Signed-off-by: Nicholas Mc Guire > --- > > v2: added missing subsystem string in subject line - patch unchanged The feedback you were given was completely bogus. Saying "net: " in addition to "hyperv: " is unnecessary, redundant, and something you should not do. Just plain "hyperv: " is complete and unambiguous enough to stand upon itself. Nobody says "net: ixgbe: " for Intel ethernet driver changes. That's just stupid. -- 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: build warnings after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
In file included from mm/slab_common.c:26:0:
mm/slab_common.c: In function 'kmem_cache_destroy':
mm/slab.h:259:30: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
for (iter = NULL, tmp = NULL, (root); 0; )
^
mm/slab_common.c:620:2: note: in expansion of macro 'for_each_memcg_cache_safe'
for_each_memcg_cache_safe(c, c2, s) {
^
mm/slab_common.c: In function 'memcg_accumulate_slabinfo':
mm/slab.h:257:18: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
for (iter = NULL, (root); 0; )
^
mm/slab_common.c:959:2: note: in expansion of macro 'for_each_memcg_cache'
for_each_memcg_cache(c, s) {
^
In file included from mm/slub.c:19:0:
mm/slub.c: In function '__kmem_cache_alias':
mm/slab.h:257:18: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
for (iter = NULL, (root); 0; )
^
mm/slub.c:3652:3: note: in expansion of macro 'for_each_memcg_cache'
for_each_memcg_cache(c, s) {
^
Introduced by commit 3019931a000b ("slab: link memcg caches of the same
kind into a list").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpqbXe6ztDAU.pgp
Description: OpenPGP digital signature
[PATCH v7 0/2] Add Spreadtrum Sharkl64 Platform support
This patch-set split the last version, and addressed the review comments from last version on serial driver code. Changes from v6: - Setted stdout-path with "serial1:115200n8" Changes from v5: - Added maintenance interrupt for gic - Removed reg property from 'soc' and 'apb' nodes Zhizhou Zhang (2): arm64: dts: Add support for Spreadtrum SC9836 SoC in dts and Makefile arm64: Add support for Spreadtrum's Sharkl64 Platform in Kconfig and defconfig arch/arm64/Kconfig|5 ++ arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/sprd/Makefile |5 ++ arch/arm64/boot/dts/sprd/sc9836-openphone.dts | 49 arch/arm64/boot/dts/sprd/sc9836.dtsi | 74 + arch/arm64/boot/dts/sprd/sharkl64.dtsi| 65 ++ arch/arm64/configs/defconfig |1 + 7 files changed, 200 insertions(+) create mode 100644 arch/arm64/boot/dts/sprd/Makefile create mode 100644 arch/arm64/boot/dts/sprd/sc9836-openphone.dts create mode 100644 arch/arm64/boot/dts/sprd/sc9836.dtsi create mode 100644 arch/arm64/boot/dts/sprd/sharkl64.dtsi -- 1.7.9.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 v7 2/2] arm64: Add support for Spreadtrum's Sharkl64 Platform in Kconfig and defconfig
From: Zhizhou Zhang Adds support for Spreadtrum's SoC Platform in the arm64 Kconfig and defconfig files. Signed-off-by: Zhizhou Zhang Signed-off-by: Orson Zhai Signed-off-by: Chunyan Zhang --- arch/arm64/Kconfig |5 + arch/arm64/configs/defconfig |1 + 2 files changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b1f9a20..885c1f4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -153,6 +153,11 @@ config ARCH_SEATTLE help This enables support for AMD Seattle SOC Family +config ARCH_SPRD + bool "Spreadtrum SoC platform" + help + Support for Spreadtrum ARM based SoCs + config ARCH_THUNDER bool "Cavium Inc. Thunder SoC Family" help diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index dd301be..2eb303a 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -32,6 +32,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_SPRD=y CONFIG_ARCH_THUNDER=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y -- 1.7.9.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: linux-next: build failure after merge of the wireless-drivers-next tree
Stephen Rothwell writes:
> After merging the wireless-drivers-next tree, today's linux-next build
> (powerpc allyesconfig) failed like this:
>
> drivers/net/wireless/ath/ath9k/ath9k_htc.o:(.data+0x29d0): multiple
> definition of `led_blink'
> drivers/net/wireless/ath/ath9k/ath9k.o:(.bss+0x1654): first defined here
>
> Caused by commit 3a939a671225 ("ath9k_htc: Add a module parameter to
> disable blink").
>
> I have reverted that commit for today.
Sorry about that, we have a patch pending to fix it:
https://patchwork.kernel.org/patch/5699001/
--
Kalle Valo
--
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 v7 1/2] arm64: dts: Add support for Spreadtrum SC9836 SoC in dts and Makefile
From: Zhizhou Zhang
Adds the device tree support for Spreadtrum SC9836 SoC which is based on
Sharkl64 platform.
Sharkl64 platform contains the common nodes of Spreadtrum's arm64-based SoCs.
Signed-off-by: Zhizhou Zhang
Signed-off-by: Orson Zhai
Signed-off-by: Chunyan Zhang
---
arch/arm64/boot/dts/Makefile |1 +
arch/arm64/boot/dts/sprd/Makefile |5 ++
arch/arm64/boot/dts/sprd/sc9836-openphone.dts | 49
arch/arm64/boot/dts/sprd/sc9836.dtsi | 74 +
arch/arm64/boot/dts/sprd/sharkl64.dtsi| 65 ++
5 files changed, 194 insertions(+)
create mode 100644 arch/arm64/boot/dts/sprd/Makefile
create mode 100644 arch/arm64/boot/dts/sprd/sc9836-openphone.dts
create mode 100644 arch/arm64/boot/dts/sprd/sc9836.dtsi
create mode 100644 arch/arm64/boot/dts/sprd/sharkl64.dtsi
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 3b8d427..806a717 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -2,6 +2,7 @@ dts-dirs += amd
dts-dirs += apm
dts-dirs += arm
dts-dirs += cavium
+dts-dirs += sprd
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/Makefile
b/arch/arm64/boot/dts/sprd/Makefile
new file mode 100644
index 000..b658c5e
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+
+always := $(dtb-y)
+subdir-y := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/sprd/sc9836-openphone.dts
b/arch/arm64/boot/dts/sprd/sc9836-openphone.dts
new file mode 100644
index 000..e5657c3
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9836-openphone.dts
@@ -0,0 +1,49 @@
+/*
+ * Spreadtrum SC9836 openphone board DTS file
+ *
+ * Copyright (C) 2014, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+
+/dts-v1/;
+
+#include "sc9836.dtsi"
+
+/ {
+ model = "Spreadtrum SC9836 Openphone Board";
+
+ compatible = "sprd,sc9836-openphone", "sprd,sc9836";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0 0x8000 0 0x2000>;
+ };
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/sprd/sc9836.dtsi
b/arch/arm64/boot/dts/sprd/sc9836.dtsi
new file mode 100644
index 000..f92f1b4
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9836.dtsi
@@ -0,0 +1,74 @@
+/*
+ * Spreadtrum SC9836 SoC DTS file
+ *
+ * Copyright (C) 2014, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+
+#include "sharkl64.dtsi"
+#include
+
+/ {
+ compatible = "sprd,sc9836";
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ gic: interrupt-controller@12001000 {
+ compatible = "arm,gic-400";
+ reg = <0 0x12001000 0 0x1000>,
+ <0 0x12002000 0 0x2000>,
+ <0 0x12004000 0 0x2000>,
+ <0 0x12006000 0 0x2000>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = ;
+ };
+
+ psci {
+ compatible = "arm,psci";
+ method = "smc";
+ cpu_on = <0xc403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0xc401>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+
Re: [RFC 1/3] Slab infrastructure for array operations
On Fri, Jan 23, 2015 at 03:37:28PM -0600, Christoph Lameter wrote: > This patch adds the basic infrastructure for alloc / free operations > on pointer arrays. It includes a fallback function that can perform > the array operations using the single alloc and free that every > slab allocator performs. > > Allocators must define _HAVE_SLAB_ALLOCATOR_OPERATIONS in their > header files in order to implement their own fast version for > these array operations. > > Array operations allow a reduction of the processing overhead > during allocation and therefore speed up acquisition of larger > amounts of objects. > > Signed-off-by: Christoph Lameter > > Index: linux/include/linux/slab.h > === > --- linux.orig/include/linux/slab.h > +++ linux/include/linux/slab.h > @@ -123,6 +123,7 @@ struct kmem_cache *memcg_create_kmem_cac > void kmem_cache_destroy(struct kmem_cache *); > int kmem_cache_shrink(struct kmem_cache *); > void kmem_cache_free(struct kmem_cache *, void *); > +void kmem_cache_free_array(struct kmem_cache *, size_t, void **); > > /* > * Please use this macro to create slab caches. Simply specify the > @@ -290,6 +291,39 @@ static __always_inline int kmalloc_index > void *__kmalloc(size_t size, gfp_t flags); > void *kmem_cache_alloc(struct kmem_cache *, gfp_t flags); > > +/* > + * Additional flags that may be specified in kmem_cache_alloc_array()'s > + * gfp flags. > + * > + * If no flags are specified then kmem_cache_alloc_array() will first exhaust > + * the partial slab page lists of the local node, then allocate new pages > from > + * the page allocator as long as more than objects per page objects are > wanted > + * and fill up the rest from local cached objects. If that is not enough then > + * the remaining objects will be allocated via kmem_cache_alloc() > + */ > + > +/* Use objects cached for the processor */ > +#define GFP_SLAB_ARRAY_LOCAL ((__force gfp_t)0x4000) > + > +/* Use slabs from this node that have objects available */ > +#define GFP_SLAB_ARRAY_PARTIAL ((__force gfp_t)0x2000) > + > +/* Allocate new slab pages from page allocator */ > +#define GFP_SLAB_ARRAY_NEW ((__force gfp_t)0x1000) Hello, Christoph. Please correct my e-mail address next time. :) iamjoonsoo@lge.com or js1...@gmail.com IMHO, exposing these options is not a good idea. It's really implementation specific. And, this flag won't show consistent performance according to specific slab implementation. For example, to get best performance, if SLAB is used, GFP_SLAB_ARRAY_LOCAL would be the best option, but, for the same purpose, if SLUB is used, GFP_SLAB_ARRAY_NEW would be the best option. And, performance could also depend on number of objects and size. And, overriding gfp flag isn't a good idea. Someday gfp could use these values and they can't notice that these are used in slab subsystem with different meaning. 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/
Re: [PATCH -mm 3/3] slub: make dead caches discard free slabs immediately
Hi Joonsoo,
On Tue, Jan 27, 2015 at 05:00:09PM +0900, Joonsoo Kim wrote:
> On Mon, Jan 26, 2015 at 03:55:29PM +0300, Vladimir Davydov wrote:
> > @@ -3381,6 +3390,15 @@ void __kmem_cache_shrink(struct kmem_cache *s)
> > kmalloc(sizeof(struct list_head) * objects, GFP_KERNEL);
> > unsigned long flags;
> >
> > + if (deactivate) {
> > + /*
> > +* Disable empty slabs caching. Used to avoid pinning offline
> > +* memory cgroups by freeable kmem pages.
> > +*/
> > + s->cpu_partial = 0;
> > + s->min_partial = 0;
> > + }
> > +
>
> Maybe, kick_all_cpus_sync() is needed here since object would
> be freed asynchronously so they can't see this updated value.
I thought flush_all() should do the trick, no?
Thanks,
Vladimir
--
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/
[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
device_dma_parameters.
In case the attaching device's constraints don't match up, attach() fails.
At detach, the constraints are recalculated based on the remaining
attached devices.
Two helpers are added:
- dma_buf_get_constraints - which gives the current constraints as calculated
during each attach on the buffer till the time,
- dma_buf_recalc_constraints - which recalculates the constraints for all
currently attached devices for the 'paranoid' ones amongst us.
The idea of this patch is largely taken from Rob Clark's RFC at
https://lkml.org/lkml/2012/7/19/285, and the comments received on it.
Cc: Rob Clark
Signed-off-by: Sumit Semwal
---
v3:
- Thanks to Russell's comment, remove dma_mask and coherent_dma_mask from
constraints' calculation; has a nice side effect of letting us use
device_dma_parameters directly to list constraints.
- update the debugfs output to show constraint info as well.
v2: split constraints-sharing and allocation helpers
drivers/dma-buf/dma-buf.c | 126 +-
include/linux/dma-buf.h | 7 +++
2 files changed, 132 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..f363f1440803 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -264,6 +264,66 @@ static inline int is_dma_buf_file(struct file *file)
return file->f_op == &dma_buf_fops;
}
+static inline void init_constraints(struct device_dma_parameters *cons)
+{
+ cons->max_segment_count = (unsigned int)-1;
+ cons->max_segment_size = (unsigned int)-1;
+ cons->segment_boundary_mask = (unsigned long)-1;
+}
+
+/*
+ * calc_constraints - calculates if the new attaching device's constraints
+ * match, with the constraints of already attached devices; if yes, returns
+ * the constraints; else return ERR_PTR(-EINVAL)
+ */
+static int calc_constraints(struct device *dev,
+ struct device_dma_parameters *calc_cons)
+{
+ struct device_dma_parameters cons = *calc_cons;
+
+ cons.max_segment_count = min(cons.max_segment_count,
+ dma_get_max_seg_count(dev));
+ cons.max_segment_size = min(cons.max_segment_size,
+ dma_get_max_seg_size(dev));
+ cons.segment_boundary_mask &= dma_get_seg_boundary(dev);
+
+ if (!cons.max_segment_count ||
+ !cons.max_segment_size ||
+ !cons.segment_boundary_mask) {
+ pr_err("Dev: %s's constraints don't match\n", dev_name(dev));
+ return -EINVAL;
+ }
+
+ *calc_cons = cons;
+
+ return 0;
+}
+
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ * useful for detach() recalculation, and for dma_buf_recalc_constraints()
+ * helper.
+ * Returns recalculated constraints in recalc_cons, or error in the unlikely
+ * case when constraints of attached devices might have changed.
+ */
+static int recalc_constraints(struct dma_buf *dmabuf,
+ struct device_dma_parameters *recalc_cons)
+{
+ struct device_dma_parameters calc_cons;
+ struct dma_buf_attachment *attach;
+ int ret = 0;
+
+ init_constraints(&calc_cons);
+
+ list_for_each_entry(attach, &dmabuf->attachments, node) {
+ ret = calc_constraints(attach->dev, &calc_cons);
+ if (ret)
+ return ret;
+ }
+ *recalc_cons = calc_cons;
+ return 0;
+}
+
/**
* dma_buf_export_named - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
@@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+
+ init_constraints(&dmabuf->constraints);
+
init_waitqueue_head(&dmabuf->poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
@@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
struct device *dev)
{
struct dma_buf_attachment *attach;
- int ret;
+ int ret = 0;
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
@@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
mutex_lock(&dmabuf->lock);
+ if (calc_constraints(dev, &dmabuf->constraints))
+ goto err_constraints;
+
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, dev, attach);
[RFCv3 1/2] device: add dma_params->max_segment_count
From: Rob Clark
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark
[sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal
---
v3: include Robin Murphy's fix[1] for handling '0' as a value for
max_segment_count
v2: minor updates wrt comments on the first version
[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct
device *dev,
return -EIO;
}
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ if (dev->dma_parms && dev->dma_parms->max_segment_count)
+ return dev->dma_parms->max_segment_count;
+ return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev->dma_parms) {
+ dev->dma_parms->max_segment_count = count;
+ return 0;
+ }
+ return -EIO;
+}
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev->dma_parms ?
--
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: linux-next: build warnings after merge of the akpm-current tree
Hi, On Tue, Jan 27, 2015 at 07:12:43PM +1100, Stephen Rothwell wrote: > In file included from mm/slab_common.c:26:0: > mm/slab_common.c: In function 'kmem_cache_destroy': > mm/slab.h:259:30: warning: right-hand operand of comma expression has no > effect [-Wunused-value] > for (iter = NULL, tmp = NULL, (root); 0; ) > ^ It's already been fixed, please see https://lkml.org/lkml/2015/1/24/39 Thanks, Vladimir -- 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/4] mm/page_alloc: expands broken freepage to proper buddy list when steal
On Tue, Jan 27, 2015 at 08:35:17AM +0100, Vlastimil Babka wrote: > On 12/10/2014 07:38 AM, Joonsoo Kim wrote: > > After your patch is merged, I will resubmit these on top of it. > > Hi Joonsoo, > > my page stealing patches are now in -mm so are you planning to resubmit this? > At > least patch 1 is an obvious bugfix, and patch 4 a clear compaction overhead > reduction. Those don't need to wait for the rest of the series. If you are > busy > with other stuff, I can also resend those two myself if you want. Hello, I've noticed that your patches are merged. :) If you are in hurry, you can resend them. I'm glad if you handle it. If not, I will resend them, maybe, on end of this week. In fact, I'm testing your stealing patches on my add-hoc fragmentation benchmark. It would be finished soon and, after that, I can resend this patchset. 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/
Re: [PATCH 1/1] mm/page_ext: remove unnecessary stack_trace field
On Tue, Jan 27, 2015 at 12:52:12AM +0300, Sergei Rogachev wrote:
> Page owner uses the page_ext structure to keep meta-information
> for every page in the system. The structure also contains a field
> of type 'struct stack_trace', page owner uses this field during
> invocation of the function save_stack_trace. It is easy to notice
> that keeping a copy of this structure for every page in the system
> is very inefficiently in terms of memory.
>
> The patch removes this unnecessary field of page_ext and forces
> page owner to use a stack_trace structure allocated on the stack.
>
> Signed-off-by: Sergei Rogachev
> ---
> include/linux/page_ext.h | 2 +-
> mm/page_owner.c | 21 -
> 2 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
> index d2a2c84..c42981c 100644
> --- a/include/linux/page_ext.h
> +++ b/include/linux/page_ext.h
> @@ -40,7 +40,7 @@ struct page_ext {
> #ifdef CONFIG_PAGE_OWNER
> unsigned int order;
> gfp_t gfp_mask;
> - struct stack_trace trace;
> + unsigned int nr_entries;
> unsigned long trace_entries[8];
> #endif
> };
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 9ab4a9b..f7f3318 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -60,19 +60,19 @@ void __reset_page_owner(struct page *page, unsigned int
> order)
> void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
> {
> struct page_ext *page_ext;
> - struct stack_trace *trace;
> + struct stack_trace trace;
>
> page_ext = lookup_page_ext(page);
>
> - trace = &page_ext->trace;
> - trace->nr_entries = 0;
> - trace->max_entries = ARRAY_SIZE(page_ext->trace_entries);
> - trace->entries = &page_ext->trace_entries[0];
> - trace->skip = 3;
> - save_stack_trace(&page_ext->trace);
> + trace.nr_entries = 0;
> + trace.max_entries = ARRAY_SIZE(page_ext->trace_entries);
> + trace.entries = &page_ext->trace_entries[0];
> + trace.skip = 3;
> + save_stack_trace(&trace);
>
> page_ext->order = order;
> page_ext->gfp_mask = gfp_mask;
> + page_ext->nr_entries = trace.nr_entries;
>
> __set_bit(PAGE_EXT_OWNER, &page_ext->flags);
> }
> @@ -83,6 +83,7 @@ print_page_owner(char __user *buf, size_t count, unsigned
> long pfn,
> {
> int ret;
> int pageblock_mt, page_mt;
> + struct stack_trace trace;
> char *kbuf;
>
> kbuf = kmalloc(count, GFP_KERNEL);
> @@ -121,8 +122,10 @@ print_page_owner(char __user *buf, size_t count,
> unsigned long pfn,
> if (ret >= count)
> goto err;
>
> - ret += snprint_stack_trace(kbuf + ret, count - ret,
> - &page_ext->trace, 0);
> + trace.nr_entries = page_ext->nr_entries;
> + trace.entries = &page_ext->trace_entries[0];
> +
> + ret += snprint_stack_trace(kbuf + ret, count - ret, &trace, 0);
> if (ret >= count)
> goto err;
Acked-by: Joonsoo Kim
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/
Re: [PATCH v5 2/2] x86/xen: allow privcmd hypercalls to be preempted on 64-bit
>>> On 27.01.15 at 02:51, wrote: Even if David told you this would be acceptable, I have to question an abstract model of fixing issues on only 64-bit kernels - this may be acceptable for distro purposes, but seems hardly the right approach for upstream. If 32-bit ones are to become deliberately broken, the XEN config option should become dependent on !X86_32. Jan -- 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/4] mm/page_alloc: expands broken freepage to proper buddy list when steal
On 01/27/2015 09:34 AM, Joonsoo Kim wrote: > On Tue, Jan 27, 2015 at 08:35:17AM +0100, Vlastimil Babka wrote: >> On 12/10/2014 07:38 AM, Joonsoo Kim wrote: >> > After your patch is merged, I will resubmit these on top of it. >> >> Hi Joonsoo, >> >> my page stealing patches are now in -mm so are you planning to resubmit >> this? At >> least patch 1 is an obvious bugfix, and patch 4 a clear compaction overhead >> reduction. Those don't need to wait for the rest of the series. If you are >> busy >> with other stuff, I can also resend those two myself if you want. > > Hello, > > I've noticed that your patches are merged. :) > If you are in hurry, you can resend them. I'm glad if you handle it. > If not, I will resend them, maybe, on end of this week. Hi, end of week is fine! I'm in no hurry, just wanted to know the status. > In fact, I'm testing your stealing patches on my add-hoc fragmentation > benchmark. It would be finished soon and, after that, I can resend this > patchset. Good to hear! Thanks. > 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/
Re: [PATCH 1/3] IPVS: add wlib & wlip schedulers
Hello,
On Fri, 23 Jan 2015, Julian Anastasov wrote:
> On Tue, 20 Jan 2015, Chris Caputo wrote:
>
> > My application consists of incoming TCP streams being load balanced to
> > servers which receive the feeds. These are long lived multi-gigabyte
> > streams, and so I believe the estimator's 2-second timer is fine. As an
> > example:
> >
> > # cat /proc/net/ip_vs_stats
> >Total Incoming Outgoing Incoming Outgoing
> >Conns Packets PacketsBytesBytes
> > 9AB 58B7C170 1237CA2C3250
> >
> > Conns/s Pkts/s Pkts/s Bytes/s Bytes/s
> >1 387C0 B16C4AE0
>
> Not sure, may be everything here should be u64 because
> we have shifted values. I'll need some days to investigate
> this issue...
For now I don't see hope in using schedulers that rely
on IPVS byte/packet stats, due to the slow update (2 seconds).
If we reduce this period we can cause performance problems to
other users.
Every *-LEAST-* (eg. LC, WLC) algorithm needs actual information
to take decision on every new connection. OTOH, all *-ROUND-ROBIN-*
algorithms (RR, WRR) use information (weights) from user space,
by this way kernel performs as expected.
Currently, LC/WLC use feedback from the 3-way TCP handshake,
see ip_vs_dest_conn_overhead() where the established connections
have large preference. Such feedback from real servers is delayed
usually with microseconds, up to milliseconds. More time if
depends on clients.
The proposed schedulers have round-robin function but
only among least loaded servers, so it is not dominant
and we suffer from slow feedback from the estimator.
For load information that is not present in kernel
an user space daemon is needed to determine weights to use
with WRR. It can take actual stats from real server, for
example, it can take into account non-IPVS traffic.
As alternative, it is possible to implement some new svc
method that can be called for every packet, for example, in
ip_vs_in_stats(). It does not look fatal to add some fields in
struct ip_vs_dest that only specific schedulers will update,
for example, byte/packet counters. Of course, the spin_locks
the scheduler must use will suffer on many CPUs. Such info can
be also attached as allocated structure in RCU pointer
dest->sched_info where data and corresponding methods can be
stored. It will need careful RCU-kind of update, especially when
scheduler is updated in svc. If you think such idea can work
we can discuss the RCU and scheduler changes that are needed.
The proposed schedulers have to implement counters, their
own estimator and WRR function.
Another variant can be to extend WRR with some
support for automatic dynamic-weight update depending on
parameters: -s wrr --sched-flags {wlip,wlib,...}
or using new option --sched-param that can also
provide info for wrr estimator, etc. In any case, the
extended WRR scheduler will need above support to check
every packet.
Regards
--
Julian Anastasov
--
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 v8 1/2] Documentation: DT: Add bindings for Spreadtrum SoC Platform
Adds Spreadtrum's prefix "sprd" to vendor-prefixes file. Adds the devicetree binding documentations for Spreadtrum's sc9836-uart and SC9836 SoC based on the Sharkl64 Platform which is a 64-bit SoC Platform of Spreadtrum. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/arm/sprd.txt | 11 +++ .../devicetree/bindings/serial/sprd-uart.txt |7 +++ .../devicetree/bindings/vendor-prefixes.txt|1 + 3 files changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/sprd.txt create mode 100644 Documentation/devicetree/bindings/serial/sprd-uart.txt diff --git a/Documentation/devicetree/bindings/arm/sprd.txt b/Documentation/devicetree/bindings/arm/sprd.txt new file mode 100644 index 000..31a629d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sprd.txt @@ -0,0 +1,11 @@ +Spreadtrum SoC Platforms Device Tree Bindings + + +Sharkl64 is a Spreadtrum's SoC Platform which is based +on ARM 64-bit processor. + +SC9836 openphone board with SC9836 SoC based on the +Sharkl64 Platform shall have the following properties. + +Required root node properties: +- compatible = "sprd,sc9836-openphone", "sprd,sc9836"; diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt b/Documentation/devicetree/bindings/serial/sprd-uart.txt new file mode 100644 index 000..2aff0f2 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt @@ -0,0 +1,7 @@ +* Spreadtrum serial UART + +Required properties: +- compatible: must be "sprd,sc9836-uart" +- reg: offset and length of the register set for the device +- interrupts: exactly one interrupt specifier +- clocks: phandles to input clocks. diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b1df0ad..0a8384f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -153,6 +153,7 @@ snpsSynopsys, Inc. solidrun SolidRun sony Sony Corporation spansion Spansion Inc. +sprd Spreadtrum Communications Inc. st STMicroelectronics steST-Ericsson stericsson ST-Ericsson -- 1.7.9.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] sched: Fix race between task_group and sched_task_group
On Mon, Jan 26, 2015 at 06:46:12PM -0500, Sasha Levin wrote: > This seems to cause the following lockdep warning: unlikely, the fork -> sched_move_task() was only used to establish that rq->lock nests inside p->pi_lock, and there's a gazillion other ways to establish that. That said, its a right mess indeed. Let me stare a wee bit more at this rats nets. -- 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] ARM: clocksource: fix compile of asm9260_timer driver on ARCH=parisc
On 01/27/2015 08:27 AM, Oleksij Rempel wrote:
make sure this driver depends on GENERIC_CLOCKEVENTS
compiler error was found by kbuild test robot:
drivers/clocksource/asm9260_timer.c:114:14: warning: its scope is only this
definition or declaration, which is probably not what you want
drivers/clocksource/asm9260_timer.c:124:16: warning: 'struct
clock_event_device' declared inside parameter list
struct clock_event_device *evt)
drivers/clocksource/asm9260_timer.c:124:16: warning: 'enum clock_event_mode'
declared inside parameter list
drivers/clocksource/asm9260_timer.c:123:58: error: parameter 1 ('mode') has
incomplete type
static void asm9260_timer_set_mode(enum clock_event_mode mode,
Signed-off-by: Oleksij Rempel
I would like to fold this patch with the asm9260 timer patch in order to
prevent git bisecting breakage. Ok for you ?
---
drivers/clocksource/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 13b8152..bfaaae4 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -231,6 +231,7 @@ config CLKSRC_MIPS_GIC
config ASM9260_TIMER
bool "Alphascale ASM9260 timer driver"
+ depends on GENERIC_CLOCKEVENTS
select CLKSRC_MMIO
select CLKSRC_OF
default y if MACH_ASM9260
--
Facebook |
Twitter |
Re: [PATCH] ARM: clocksource: fix compile of asm9260_timer driver on ARCH=parisc
Am 27.01.2015 um 09:49 schrieb Daniel Lezcano:
> On 01/27/2015 08:27 AM, Oleksij Rempel wrote:
>> make sure this driver depends on GENERIC_CLOCKEVENTS
>>
>> compiler error was found by kbuild test robot:
>>
drivers/clocksource/asm9260_timer.c:114:14: warning: its scope is
only this definition or declaration, which is probably not what you
want
drivers/clocksource/asm9260_timer.c:124:16: warning: 'struct
clock_event_device' declared inside parameter list
>> struct clock_event_device *evt)
>>
drivers/clocksource/asm9260_timer.c:124:16: warning: 'enum
clock_event_mode' declared inside parameter list
drivers/clocksource/asm9260_timer.c:123:58: error: parameter 1
('mode') has incomplete type
>> static void asm9260_timer_set_mode(enum clock_event_mode mode,
>>
>> Signed-off-by: Oleksij Rempel
>
> I would like to fold this patch with the asm9260 timer patch in order to
> prevent git bisecting breakage. Ok for you ?
Ok, no problem.
>> ---
>> drivers/clocksource/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 13b8152..bfaaae4 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -231,6 +231,7 @@ config CLKSRC_MIPS_GIC
>>
>> config ASM9260_TIMER
>> bool "Alphascale ASM9260 timer driver"
>> +depends on GENERIC_CLOCKEVENTS
>> select CLKSRC_MMIO
>> select CLKSRC_OF
>> default y if MACH_ASM9260
>>
>
>
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
linux-next: Tree for Jan 27
Hi all, Changes since 20150123: The arm64 tree gained a conflict against Linus' tree. The net-next tree gained conflicts against the arm-soc and net trees. The drm-panel tree gained a conflict against the drm tree. The wireless-drivers-next tree gained a build failure for which I reverted a commit. The block tree gained conflicts against the vfs and Linus' trees. The clockevents tree gained a conflict against the arm tree. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 5237 4877 files changed, 200964 insertions(+), 94565 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 (26bc420b59a3 Linux 3.19-rc6) 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 (909ba297beb5 ARM: 8292/1: mm: fix size rounding-down of arm_add_memory() function) Merging m68k-current/for-linus (f27bd5bfeda5 m68k: Wire up execveat) 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 (0eb13208aa16 powerpc/powernv: Restore LPCR with LPCR_PECE1 cleared) Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (03a605804bc4 Merge branch 's390') Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in _decode_session6.) Merging sound-current/for-linus (0767e95bb96d ALSA: seq-dummy: remove deadlock-causing events on close) Merging pci-current/for-linus (f175aa2c9f6c MAINTAINERS: Update Richard Zhu's email address) Merging wireless-drivers/master (e3f31175a3ee ath9k: fix race condition in irq processing during hardware reset) 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 (e5dff0e80463 USB: Add OTG PET device to TPL) Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in non-OF case) Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for RUGGEDCOM USB Serial Console) Merging staging.current/staging-linus (41c9e95d641a MAINTAINERS: add Android driver entries) Merging char-misc.current/char-misc-linus (26713c812313 drivers/Kconfig: remove duplicate entry for soc) Merging input-current/for-linus (1d90d6d5522b Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857)) Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module aliases) 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 (d5db139ab376 module: make module_refcount() a signed integer.) 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 (6b96d705
Re: [PATCH] ARM: clocksource: fix compile of asm9260_timer driver on ARCH=parisc
On 01/27/2015 09:51 AM, Oleksij Rempel wrote:
Am 27.01.2015 um 09:49 schrieb Daniel Lezcano:
On 01/27/2015 08:27 AM, Oleksij Rempel wrote:
make sure this driver depends on GENERIC_CLOCKEVENTS
compiler error was found by kbuild test robot:
drivers/clocksource/asm9260_timer.c:114:14: warning: its scope is
only this definition or declaration, which is probably not what you
want
drivers/clocksource/asm9260_timer.c:124:16: warning: 'struct
clock_event_device' declared inside parameter list
struct clock_event_device *evt)
drivers/clocksource/asm9260_timer.c:124:16: warning: 'enum
clock_event_mode' declared inside parameter list
drivers/clocksource/asm9260_timer.c:123:58: error: parameter 1
('mode') has incomplete type
static void asm9260_timer_set_mode(enum clock_event_mode mode,
Signed-off-by: Oleksij Rempel
I would like to fold this patch with the asm9260 timer patch in order to
prevent git bisecting breakage. Ok for you ?
Ok, no problem.
Done.
--
Facebook |
Twitter |
Re: mmc does not work in qemu n900
On Tuesday 27 January 2015 00:21:04 Aaro Koskinen wrote: > Hi, > > On Mon, Jan 26, 2015 at 10:04:59PM +0100, Pali Rohár wrote: > > problem? Why any of these two patches fix problem when mmc > > is not detected by kernel in qemu (machine n900)? Detection > > of mmc fails because function mmc_send_op_cond() without > > one of above patches fails. > > Has it ever worked? It could be just that QEMU's emulation is > broken. Since the kernel works on actual HW, you probably > should contact QEMU maintainers. > > I don't see n900 in Debian's QEMU. There's n800 and n810 but > I couldn't boot any of my kernels with those... > > A. It worked with stock Nokia kernel (2.6.28). N900 qemu support is not in upstream qemu project, but in linaro qemu version. You can find it e.g. in ubuntu: http://packages.ubuntu.com/source/precise-updates/qemu-linaro -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] arm: sunxi: input: RFC: Add sysfs voltage for sun4i-lradc driver
Hi,
On Mon, Jan 26, 2015 at 06:58:32PM +0200, Priit Laes wrote:
> ---
Like Hans was pointing out, commit log and signed-off-by please
> .../ABI/testing/sysfs-driver-input-sun4i-lradc | 4 ++
> drivers/input/keyboard/sun4i-lradc-keys.c | 49
> +-
> 2 files changed, 43 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc
> b/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc
> new file mode 100644
> index 000..e4e6448
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc
> @@ -0,0 +1,4 @@
> +What:/sys/class/input/input(x)/device/voltage
> +Date:February 2015
> +Contact: Priit Laes
> +Description: ADC output voltage in microvolts or 0 if device is not opened.
Why is it returning 0 when "device is not opened" ? What does that
even mean? You can't read that file without opening it.
> diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c
> b/drivers/input/keyboard/sun4i-lradc-keys.c
> index cc8f7dd..c0ab8ec 100644
> --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> @@ -79,10 +79,27 @@ struct sun4i_lradc_data {
> u32 vref;
> };
>
> +static u32 sun4i_lradc_read_voltage(struct sun4i_lradc_data *lradc)
> +{
> + u32 val = readl(lradc->base + LRADC_DATA0) & 0x3f;
> + return val * lradc->vref / 63;
> +};
> +
> +static ssize_t
> +sun4i_lradc_dev_voltage_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct sun4i_lradc_data *lradc = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%u\n", sun4i_lradc_read_voltage(lradc));
> +}
> +
> +static const DEVICE_ATTR(voltage, S_IRUGO, sun4i_lradc_dev_voltage_show,
> NULL);
> +
> static irqreturn_t sun4i_lradc_irq(int irq, void *dev_id)
> {
> struct sun4i_lradc_data *lradc = dev_id;
> - u32 i, ints, val, voltage, diff, keycode = 0, closest = 0x;
> + u32 i, ints, voltage, diff, keycode = 0, closest = 0x;
>
> ints = readl(lradc->base + LRADC_INTS);
>
> @@ -97,8 +114,7 @@ static irqreturn_t sun4i_lradc_irq(int irq, void *dev_id)
> }
>
> if ((ints & CHAN0_KEYDOWN_IRQ) && lradc->chan0_keycode == 0) {
> - val = readl(lradc->base + LRADC_DATA0) & 0x3f;
> - voltage = val * lradc->vref / 63;
> + voltage = sun4i_lradc_read_voltage(lradc);
>
> for (i = 0; i < lradc->chan0_map_count; i++) {
> diff = abs(lradc->chan0_map[i].voltage - voltage);
> @@ -156,7 +172,7 @@ static void sun4i_lradc_close(struct input_dev *dev)
> }
>
> static int sun4i_lradc_load_dt_keymap(struct device *dev,
> - struct sun4i_lradc_data *lradc)
> + struct sun4i_lradc_data *lradc)
> {
> struct device_node *np, *pp;
> int i;
> @@ -168,8 +184,8 @@ static int sun4i_lradc_load_dt_keymap(struct device *dev,
>
> lradc->chan0_map_count = of_get_child_count(np);
> if (lradc->chan0_map_count == 0) {
> - dev_err(dev, "keymap is missing in device tree\n");
> - return -EINVAL;
> + dev_info(dev, "keymap is missing in device tree\n");
> + return 0;
> }
>
> lradc->chan0_map = devm_kmalloc_array(dev, lradc->chan0_map_count,
> @@ -185,19 +201,19 @@ static int sun4i_lradc_load_dt_keymap(struct device
> *dev,
>
> error = of_property_read_u32(pp, "channel", &channel);
> if (error || channel != 0) {
> - dev_err(dev, "%s: Inval channel prop\n", pp->name);
> + dev_err(dev, "%s: Invalid 'channel' property\n",
> pp->name);
> return -EINVAL;
> }
>
> error = of_property_read_u32(pp, "voltage", &map->voltage);
> if (error) {
> - dev_err(dev, "%s: Inval voltage prop\n", pp->name);
> + dev_err(dev, "%s: Invalid 'voltage' property\n",
> pp->name);
> return -EINVAL;
> }
>
> error = of_property_read_u32(pp, "linux,code", &map->keycode);
> if (error) {
> - dev_err(dev, "%s: Inval linux,code prop\n", pp->name);
> + dev_err(dev, "%s: Invalid 'linux,code' property\n",
> pp->name);
> return -EINVAL;
> }
>
> @@ -257,14 +273,26 @@ static int sun4i_lradc_probe(struct platform_device
> *pdev)
> if (error)
> return error;
>
> - error = input_register_device(lradc->input);
> + error = device_create_file(dev, &dev_attr_voltage);
As I told you already, if you're going to expose this an ADC in the
end, the proper solution is to use the IIO framework, not adding
Re: [PATCH -mm 3/3] slub: make dead caches discard free slabs immediately
2015-01-27 17:23 GMT+09:00 Vladimir Davydov :
> Hi Joonsoo,
>
> On Tue, Jan 27, 2015 at 05:00:09PM +0900, Joonsoo Kim wrote:
>> On Mon, Jan 26, 2015 at 03:55:29PM +0300, Vladimir Davydov wrote:
>> > @@ -3381,6 +3390,15 @@ void __kmem_cache_shrink(struct kmem_cache *s)
>> > kmalloc(sizeof(struct list_head) * objects, GFP_KERNEL);
>> > unsigned long flags;
>> >
>> > + if (deactivate) {
>> > + /*
>> > +* Disable empty slabs caching. Used to avoid pinning offline
>> > +* memory cgroups by freeable kmem pages.
>> > +*/
>> > + s->cpu_partial = 0;
>> > + s->min_partial = 0;
>> > + }
>> > +
>>
>> Maybe, kick_all_cpus_sync() is needed here since object would
>> be freed asynchronously so they can't see this updated value.
>
> I thought flush_all() should do the trick, no?
Unfortunately, it doesn't.
flush_all() sends IPI to not all cpus. It only sends IPI to cpus where
some conditions
are met and freeing could occur on the other ones.
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/
Re: [PATCH 1/2][RFC] staging: Remove the Android alarm-dev driver
On Tue, 2015-01-20 at 13:42 -0800, John Stultz wrote:
> The functionality provided by the Android alarm-dev driver
> should now be present in the timerfd interface (thanks to
> Greg Hackmann and Todd Poynor).
>
> As of Lollipop, AOSP can make use of the timerfd if
> alarm-dev is not present (though a fixup for setting the
> rtc time if rtc0 isn't the backing for _ALARM clockids has
> been applied post-Lollipop).
>
> Thus, we should be able to remove alarm-dev from staging.
>
> Cc: Greg Hackmann
> Cc: Elliott Hughes
> Cc: Todd Poynor
> Cc: Android Kernel Team
> Cc: Greg KH
> Signed-off-by: John Stultz
This became commit 5da41e925656 ("staging: Remove the Android alarm-dev
driver") in today's linux-next (ie, next-20150127). I noticed because a
script I use to check linux-next spotted a minor problem with it.
> drivers/staging/android/Kconfig | 9 -
Here there should have been a line reading
drivers/staging/android/Makefile | 1 -
> drivers/staging/android/alarm-dev.c | 446
> ---
> drivers/staging/android/android_alarm.h | 41 ---
> drivers/staging/android/uapi/android_alarm.h | 62
> 4 files changed, 558 deletions(-)
> delete mode 100644 drivers/staging/android/alarm-dev.c
> delete mode 100644 drivers/staging/android/android_alarm.h
> delete mode 100644 drivers/staging/android/uapi/android_alarm.h
Is a trivial patch to remove that Makefile line, the one that references
CONFIG_ANDROID_INTF_ALARM_DEV and alarm-dev.o, queued already?
Thanks,
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/
[PATCH v8 0/2] Add Spreadtrum SoC bindings and serial driver support
This patch-set split the last version, and addressed the review comments from
last version on serial driver code.
Changes from v7:
* Addressed review comments from Peter:
- Initialized the stack local with zero in sprd_set_termios()
- Used dev_get_drvdata() to get sprd_uart_port
Changes from v6:
- Setted SPRD_TIMEOUT with 256 rather than 2048
- Used u32 instead of uint32_t
- Removed inline of handle_lsr_errors which is a single call site
function
- Removed unused parameter of sprd_tx & sprd_rx
- Used spin_lock_irqsave in sprd_startup() instead of spin_lock
- Added a check for port->sysrq in sprd_console_write()
- Used a global counter as a condition of calling
uart_{un}register_driver
- Added pdev->id assignment in probe()
- Setted port->flags with UPF_BOOT_AUTOCONF instead of
ASYNC_BOOT_AUTOCONF
Changes from v5:
- Used Spreadtrum instead of SPRD in menus
- Changed TTY name to 'ttyS'
- Moved uart_register_driver() to probe()
- Added spinlock as needed
- Removed register states saving and restoring in suspend() and resume()
Chunyan Zhang (2):
Documentation: DT: Add bindings for Spreadtrum SoC Platform
tty/serial: Add Spreadtrum sc9836-uart driver support
Documentation/devicetree/bindings/arm/sprd.txt | 11 +
.../devicetree/bindings/serial/sprd-uart.txt |7 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/sprd_serial.c | 797
include/uapi/linux/serial_core.h |3 +
7 files changed, 838 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/sprd.txt
create mode 100644 Documentation/devicetree/bindings/serial/sprd-uart.txt
create mode 100644 drivers/tty/serial/sprd_serial.c
--
1.7.9.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] staging: Remove the Android logger driver
On Mon, 2015-01-26 at 12:07 -0800, John Stultz wrote: > With the relase of Lollipop, Android no longer > requires the logger driver. > > There are three patches which the android dev's > still need before they drop logger on all their > devices: > > [PATCH v4 1/5] pstores: use scnprintf > [PATCH v2 2/5] pstore: remove superfluous memory size check > [PATCH 3/5] pstore: handle zero-sized prz in series > [PATCH v4 4/5] pstore: add pmsg > [PATCH 5/5] pstore: selinux: add security in-core xattr support for pstore > and debugfs > > But these seem to have been acked and are hopefully > queued for upstream. > > So this patch removes the logger driver from staging. > > Cc: Rom Lemarchand , > Cc: Mark Salyzyn > Cc: Kees Cook > Cc: Android Kernel Team > Cc: Greg KH > Signed-off-by: John Stultz > --- > drivers/staging/android/Kconfig | 17 - Please include the change that would add drivers/staging/android/Makefile | 1 - > drivers/staging/android/logger.c | 807 > --- > drivers/staging/android/logger.h | 89 - > 3 files changed, 913 deletions(-) > delete mode 100644 drivers/staging/android/logger.c > delete mode 100644 drivers/staging/android/logger.h That is also delete this line: obj-$(CONFIG_ANDROID_LOGGER) += logger.o Thanks, 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 -mm 3/3] slub: make dead caches discard free slabs immediately
On Tue, Jan 27, 2015 at 06:21:14PM +0900, Joonsoo Kim wrote:
> 2015-01-27 17:23 GMT+09:00 Vladimir Davydov :
> > Hi Joonsoo,
> >
> > On Tue, Jan 27, 2015 at 05:00:09PM +0900, Joonsoo Kim wrote:
> >> On Mon, Jan 26, 2015 at 03:55:29PM +0300, Vladimir Davydov wrote:
> >> > @@ -3381,6 +3390,15 @@ void __kmem_cache_shrink(struct kmem_cache *s)
> >> > kmalloc(sizeof(struct list_head) * objects, GFP_KERNEL);
> >> > unsigned long flags;
> >> >
> >> > + if (deactivate) {
> >> > + /*
> >> > +* Disable empty slabs caching. Used to avoid pinning offline
> >> > +* memory cgroups by freeable kmem pages.
> >> > +*/
> >> > + s->cpu_partial = 0;
> >> > + s->min_partial = 0;
> >> > + }
> >> > +
> >>
> >> Maybe, kick_all_cpus_sync() is needed here since object would
> >> be freed asynchronously so they can't see this updated value.
> >
> > I thought flush_all() should do the trick, no?
>
> Unfortunately, it doesn't.
>
> flush_all() sends IPI to not all cpus. It only sends IPI to cpus where
> some conditions
> are met and freeing could occur on the other ones.
Oh, true, missed that. Yeah, we should kick all cpus explicitly then.
Will fix in the next iteration. Thanks for catching this!
Thanks,
Vladimir
--
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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
On Mon, Jan 26, 2015 at 11:23:37AM -0800, David Cohen wrote:
> On Mon, Jan 26, 2015 at 02:55:03PM +0200, Heikki Krogerus wrote:
> > On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
> > > > +static int tusb1210_power_on(struct phy *phy)
> > > > +{
> > > > + struct tusb1210 *tusb = phy_get_drvdata(phy);
> > > > +
> > > > + gpiod_set_value_cansleep(tusb->gpio_reset, 1);
> > > > + gpiod_set_value_cansleep(tusb->gpio_cs, 1);
> > > > +
> > > > + /* Restore eye diagram optimisation value */
> > > > + ulpi_write(tusb->ulpi, TUSB1210_VENDOR_SPECIFIC2,
> > > > + tusb->eye_diagram_tuning);
> > >
> > > After you power on phy, ulpi bus may not be available right away. In
> > > intel case, phy power on happens during dwc3 power on. ULPI bus is not
> > > available until OTG controller and phy are in sync.
> > >
> > > In resume, you can't restore eye diagram from here.
> >
> > I'm sorry but I don't think I understand? Where do we power on the phy
> > before dwc3 is powered on? Or is this a Baytrail-CR specific problem?
> > I can't see any problems with the hardware I have.
>
> You can't see in single accesses. But you may see when running stability
> tests overnight.
>
> Anyway, look for dwc3_core_soft_reset() function:
> - dwc3 goes to reset state
> - phy is initialized (or at least gets ready to sync clocks)
> - dwc3 goes out or reset state
And if you look at dwc3_probe, you'll notice that it calls
phy_power_on after that, and ulpi will most definitely be accessible
at that point.
I'm only using the init and exit hooks instead of just
power_on/power_off because I'm not sure which the controllers will
use. For example, now dwc3 calls phy_init() in it's resume routine and
not phy_power_on() like I would expect. I know the problem has been
pointed out by others, so I'm expecting we'll get guidelines for it
later. But before we do, I see no harm in having both init and
power_on hooks in this driver.
> During tusb1210 phy init from dwc3, you shouldn't access ulpi bus.
We will end up executing one failed write followed by write that we
know will succeed. Ideally we didn't have to do the first one at all,
but I don't see any risk here.
> > > > + gpio = devm_gpiod_get(&ulpi->dev, "cs");
> > > > + if (!IS_ERR(gpio)) {
> > > > + ret = gpiod_direction_output(gpio, 0);
> > > > + if (ret)
> > > > + return ret;
> > > > + tusb->gpio_cs = gpio;
> > > > + }
> > > > +
> > > > + /* Store initial eye diagram optimisation value */
> > > > + ret = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
> > >
> > > It's unclear if ulpi is accessible at this point. You can't read it at
> > > this point.
> >
> > We wouldn't have reached this point if ulpi wasn't accessible.
> > Registering the ulpi interface would have already failed so no driver
> > would have been probed.
>
> You have a chicken/egg problem here:
> - dwc3 needs phy to complete soft reset during probe
> - tusb1210 needs dwc3 soft reset completed to be accessible via ULPI
>
> Can you share how tusb1210 is connected on the platform you're using as
> test for this patch? I don't think this driver would work reliably with
> this device:
> http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html
The only reason why that board doesn't work is because of very much
Baytrail-CR specific problems. These are are two issues, but the first
one is critical for getting it working. Both will be handled, but
separately from this set:
1) The firmware leaves the PHY in reset, forcing us to enable it
somehow in OS before accessing ulpi. Unless we can get a firmware fix
for that (it's starting to look like it's not going to happen; please
correct me if you know something else!), we need to add a quirk for
Baytrails (attached), which is probable still OK. But IMO this really
should be fixed in the firmware.
2) Since the gpio resources are given to the controller device in ACPI
tables and there isn't separate device object for the PHY at all, we
need to deliver the gpios somehow separately to the phy driver. There
is a thread where we are talking about how to do that:
https://lkml.org/lkml/2014/12/18/82
Thanks,
--
heikki
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..53902ea 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "platform_data.h"
@@ -35,6 +36,24 @@
static int dwc3_pci_quirks(struct pci_dev *pdev)
{
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
+ struct gpio_desc *gpio;
+
+ gpio = gpiod_get_index(&pdev->dev, "reset", 0);
+ if (!IS_ERR(gpio)) {
+ gpiod_direction_output(gpio, 0);
+ gpiod_set_value
Re: [Intel-gfx] [PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment
On Tue, Jan 27, 2015 at 09:56:49AM +0200, Jani Nikula wrote: > On Mon, 26 Jan 2015, Kumar Amit Mehta wrote: > > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent > > with the code and the rest of the comment for this routine. This patch > > fixes this typo in comment. > > > > Signed-off-by: Kumar Amit Mehta > > Reviewed-by: Jani Nikula Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] sched: Fix race between task_group and sched_task_group
On Mon, Jan 26, 2015 at 06:46:12PM -0500, Sasha Levin wrote:
> This seems to cause the following lockdep warning:
Yeah, so this one in particular seems caused by:
fadfe7be6e50 ("perf: Add queued work to remove orphaned child events")
But I'm not sure why it wasn't already true for hrtimers, we should have
the exact same problem there.
> [ 3517.958378] ==
> [ 3517.959661] [ INFO: possible circular locking dependency detected ]
> [ 3517.960172] 3.19.0-rc5-next-20150123-sasha-00063-gf82b1d7 #1824 Not tainted
> [ 3517.960172] ---
> [ 3517.960172] trinity-c7/29839 is trying to acquire lock:
> [ 3517.960172] (&(&base->lock)->rlock){-.-.-.}, at: lock_timer_base.isra.19
> (kernel/time/timer.c:751)
> [ 3517.960172]
> [ 3517.960172] but task is already holding lock:
> [ 3517.960172] (&ctx->lock){-.-.-.}, at: perf_event_context_sched_in
> (kernel/events/core.c:2600)
> [ 3517.960172]
> [ 3517.960172] which lock already depends on the new lock.
> [ 3517.960172]
> [ 3517.960172]
> [ 3517.960172] the existing dependency chain (in reverse order) is:
> [ 3517.960172]
> -> #5 (&ctx->lock){-.-.-.}:
> [ 3517.960172] lock_acquire (kernel/locking/lockdep.c:3604)
> [ 3517.960172] _raw_spin_lock (include/linux/spinlock_api_smp.h:145
> kernel/locking/spinlock.c:151)
> [ 3517.960172] __perf_event_task_sched_out (kernel/events/core.c:2434
> kernel/events/core.c:2460)
> [ 3517.960172] __schedule (include/linux/perf_event.h:730
> kernel/sched/core.c:2209 kernel/sched/core.c:2333 kernel/sched/core.c:2823)
> [ 3517.960172] schedule (kernel/sched/core.c:2853)
> [ 3517.960172] p9_client_rpc (net/9p/client.c:756 (discriminator 13))
> [ 3517.960172] p9_client_read (net/9p/client.c:1582)
> [ 3517.960172] v9fs_fid_readn (fs/9p/vfs_file.c:386)
> [ 3517.960172] v9fs_fid_readpage (fs/9p/vfs_addr.c:71)
> [ 3517.960172] v9fs_vfs_readpage (fs/9p/vfs_addr.c:105)
> [ 3517.960172] filemap_fault (mm/filemap.c:1763 mm/filemap.c:1944)
> [ 3517.960172] __do_fault (mm/memory.c:2654)
> [ 3517.960172] handle_mm_fault (mm/memory.c:2842 mm/memory.c:3143
> mm/memory.c:3267 mm/memory.c:3296)
> [ 3517.960172] __do_page_fault (arch/x86/mm/fault.c:1233)
> [ 3517.960172] trace_do_page_fault (arch/x86/mm/fault.c:1325
> include/linux/jump_label.h:114 include/linux/context_tracking_state.h:27
> include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1326)
> [ 3517.960172] do_async_page_fault (arch/x86/kernel/kvm.c:280)
> [ 3517.960172] async_page_fault (arch/x86/kernel/entry_64.S:1286)
> [ 3517.960172]
> -> #4 (&rq->lock){-.-.-.}:
> [ 3517.960172] lock_acquire (kernel/locking/lockdep.c:3604)
> [ 3517.960172] _raw_spin_lock (include/linux/spinlock_api_smp.h:145
> kernel/locking/spinlock.c:151)
> [ 3517.960172] task_rq_lock (kernel/sched/core.c:344)
> [ 3517.960172] sched_move_task (kernel/sched/core.c:7556)
> [ 3517.960172] cpu_cgroup_fork (kernel/sched/core.c:8003)
> [ 3517.960172] cgroup_post_fork (kernel/cgroup.c:5239 (discriminator 2))
> [ 3517.960172] copy_process (kernel/fork.c:1544)
> [ 3517.960172] do_fork (kernel/fork.c:1653)
> [ 3517.960172] kernel_thread (kernel/fork.c:1702)
> [ 3517.960172] rest_init (init/main.c:406)
> [ 3517.960172] start_kernel (init/main.c:503)
> [ 3517.960172] x86_64_start_reservations (arch/x86/kernel/head64.c:199)
> [ 3517.960172] x86_64_start_kernel (arch/x86/kernel/head64.c:188)
> [ 3517.960172]
> -> #3 (&p->pi_lock){-.-.-.}:
> [ 3517.960172] lock_acquire (kernel/locking/lockdep.c:3604)
> [ 3517.960172] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:119
> kernel/locking/spinlock.c:159)
> [ 3517.960172] try_to_wake_up (kernel/sched/core.c:1704)
> [ 3517.960172] default_wake_function (kernel/sched/core.c:2995)
> [ 3517.960172] autoremove_wake_function (kernel/sched/wait.c:295)
> [ 3517.960172] __wake_up_common (kernel/sched/wait.c:73)
> [ 3517.960172] __wake_up (include/linux/spinlock.h:372 kernel/sched/wait.c:96)
> [ 3517.960172] wakeup_kswapd (mm/vmscan.c:3519)
> [ 3517.960172] __alloc_pages_nodemask (mm/page_alloc.c:2530
> mm/page_alloc.c:2628 mm/page_alloc.c:2849)
> [ 3517.960172] new_page_node (mm/migrate.c:1180)
> [ 3517.960172] migrate_pages (mm/migrate.c:913 mm/migrate.c:1112)
> [ 3517.960172] SYSC_move_pages (mm/migrate.c:1265 mm/migrate.c:1340
> mm/migrate.c:1495)
> [ 3517.960172] SyS_move_pages (mm/migrate.c:1440)
> [ 3517.960172] tracesys_phase2 (arch/x86/kernel/entry_64.S:530)
> [ 3517.960172]
> -> #2 (&pgdat->kswapd_wait){..-.-.}:
> [ 3517.960172] lock_acquire (kernel/locking/lockdep.c:3604)
> [ 3517.960172] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:119
> kernel/locking/spinlock.c:159)
> [ 3517.960172] __wake_up (kernel/sched/wait.c:95)
> [ 3517.960172] wakeup_kswapd (mm/vmscan.c:3519)
> [ 3517.960172] __alloc_pages_nodemask (mm/page_alloc.c:2530
> mm/page_alloc.c:2628 mm/page_alloc.c:2849)
> [ 3517.960172] alloc_pages_current (mm/mempolicy.c:2147)
> [ 3517.960172] __get_fre
[PATCH] docs: procs -- Describe /proc//map_files entry
Signed-off-by: Cyrill Gorcunov CC: Kees Cook CC: Andrew Morton CC: "Kirill A. Shutemov" CC: Calvin Owens CC: Alexey Dobriyan CC: Oleg Nesterov CC: "Eric W. Biederman" CC: Al Viro CC: Peter Feiner CC: Pavel Emelyanov --- Gentlemen, could you please take a look once time permit. Which questions this text raises so I could add more info here (how we use it in criu, ptrace_may_access guards?) Documentation/filesystems/proc.txt | 23 +++ 1 file changed, 23 insertions(+) Index: linux-2.6.git/Documentation/filesystems/proc.txt === --- linux-2.6.git.orig/Documentation/filesystems/proc.txt +++ linux-2.6.git/Documentation/filesystems/proc.txt @@ -42,6 +42,7 @@ Table of Contents 3.6 /proc//comm & /proc//task//comm 3.7 /proc//task//children - Information about task children 3.8 /proc//fdinfo/ - Information about opened file + 3.9 /proc//map_files - Information about memory mapped files 4Configuring procfs 4.1 Mount options @@ -1763,6 +1764,28 @@ pair provide additional information part with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' still exhibits timer's remaining time. +3.9/proc//map_files - Information about memory mapped files +- +This directory consists of simbolic links which represent memory mapped files +the process is carrying. A typical output is like the following + + | lr 1 root root 64 Jan 27 11:24 333c60-333c62 -> /usr/lib64/ld-2.18.so + | lr 1 root root 64 Jan 27 11:24 333c81f000-333c82 -> /usr/lib64/ld-2.18.so + | lr 1 root root 64 Jan 27 11:24 333c82-333c821000 -> /usr/lib64/ld-2.18.so + | ... + | lr 1 root root 64 Jan 27 11:24 35d0421000-35d0422000 -> /usr/lib64/libselinux.so.1 + | lr 1 root root 64 Jan 27 11:24 40-41a000 -> /usr/bin/ls + +The name of a link is virtual memory bounds a particular map exhibits, i.e. +vm_area_struct::vm_start-vm_area_struct::vm_end. + +The main purpose of map_files directory is to be able to retrieve a set of +memory mapped files in a fast way instead of parsing /proc//maps or +/proc//smaps which contain a way more records. Same time one can open(2) +mappings from the listings of two processes and comparing inodes figure out +which anonymous memory areas are actually shared. + + -- Configuring procfs -- -- 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 v8 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
Add a full sc9836-uart driver for SC9836 SoC which is based on the spreadtrum sharkl64 platform. This driver also support earlycon. Originally-by: Lanqing Liu Signed-off-by: Orson Zhai Signed-off-by: Chunyan Zhang Acked-by: Arnd Bergmann --- drivers/tty/serial/Kconfig | 18 + drivers/tty/serial/Makefile |1 + drivers/tty/serial/sprd_serial.c | 797 ++ include/uapi/linux/serial_core.h |3 + 4 files changed, 819 insertions(+) create mode 100644 drivers/tty/serial/sprd_serial.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index c79b43c..13211f7 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1577,6 +1577,24 @@ config SERIAL_MEN_Z135 This driver can also be build as a module. If so, the module will be called men_z135_uart.ko +config SERIAL_SPRD + tristate "Support for Spreadtrum serial" + depends on ARCH_SPRD + select SERIAL_CORE + help + This enables the driver for the Spreadtrum's serial. + +config SERIAL_SPRD_CONSOLE + bool "Spreadtrum UART console support" + depends on SERIAL_SPRD=y + select SERIAL_CORE_CONSOLE + select SERIAL_EARLYCON + help + Support for early debug console using Spreadtrum's serial. This enables + the console before standard serial driver is probed. This is enabled + with "earlycon" on the kernel command line. The console is + enabled when early_param is processed. + endmenu config SERIAL_MCTRL_GPIO diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 9a548ac..4801aca 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_ARC) += arc_uart.o obj-$(CONFIG_SERIAL_RP2) += rp2.o obj-$(CONFIG_SERIAL_FSL_LPUART)+= fsl_lpuart.o obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o +obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o # GPIOLIB helpers for modem control lines obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c new file mode 100644 index 000..bbd0447 --- /dev/null +++ b/drivers/tty/serial/sprd_serial.c @@ -0,0 +1,797 @@ +/* + * Copyright (C) 2012-2015 Spreadtrum Communications Inc. + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include + +/* device name */ +#define UART_NR_MAX8 +#define SPRD_TTY_NAME "ttyS" +#define SPRD_FIFO_SIZE 128 +#define SPRD_DEF_RATE 2600 +#define SPRD_BAUD_IO_LIMIT 300 +#define SPRD_TIMEOUT 256 + +/* the offset of serial registers and BITs for them */ +/* data registers */ +#define SPRD_TXD 0x +#define SPRD_RXD 0x0004 + +/* line status register and its BITs */ +#define SPRD_LSR 0x0008 +#define SPRD_LSR_OEBIT(4) +#define SPRD_LSR_FEBIT(3) +#define SPRD_LSR_PEBIT(2) +#define SPRD_LSR_BIBIT(7) +#define SPRD_LSR_TX_OVER BIT(15) + +/* data number in TX and RX fifo */ +#define SPRD_STS1 0x000C + +/* interrupt enable register and its BITs */ +#define SPRD_IEN 0x0010 +#define SPRD_IEN_RX_FULL BIT(0) +#define SPRD_IEN_TX_EMPTY BIT(1) +#define SPRD_IEN_BREAK_DETECT BIT(7) +#define SPRD_IEN_TIMEOUT BIT(13) + +/* interrupt clear register */ +#define SPRD_ICLR 0x0014 + +/* line control register */ +#define SPRD_LCR 0x0018 +#define SPRD_LCR_STOP_1BIT 0x10 +#define SPRD_LCR_STOP_2BIT 0x30 +#define SPRD_LCR_DATA_LEN (BIT(2) | BIT(3)) +#define SPRD_LCR_DATA_LEN5 0x0 +#define SPRD_LCR_DATA_LEN6 0x4 +#define SPRD_LCR_DATA_LEN7 0x8 +#define SPRD_LCR_DATA_LEN8 0xc +#define SPRD_LCR_PARITY(BIT(0) | BIT(1)) +#define SPRD_LCR_PARITY_EN 0x2 +#define SPRD_LCR_EVEN_PAR 0x0 +#define SPRD_LCR_ODD_PAR 0x1 + +/* control register 1 */ +#define SPRD_CTL1 0x001C +#define RX_HW_FLOW_CTL_THLDBIT(6) +#define RX_HW_FLOW_CTL_EN BIT(7) +#define TX_HW_FLOW_CTL_EN BIT(8) +#define RX_TOUT_THLD_DEF 0x3E00 +#define RX_HFC_THLD_DEF0x40 + +/* fifo threshold register */ +#define SPRD_CTL2 0x0020 +#define THLD_TX_EMPTY 0x40 +#define THLD_RX_FULL 0x40 + +/* config baud rate reg
arm64: USB_ARCH_HAS_EHCI
Paul,
Your commit d035fdfa27ac ("arm64: Add Tegra132 support") is included in
today's linux-next (ie, next-20150127). I noticed because a script I use
to check linux-next spotted a minor problem with it.
It adds a select for the Kconfig symbol USB_ARCH_HAS_EHCI. That Kconfig
was obsoleted in v3.11 and removed in v3.15. See commit b797b76fb464
("usb: host: remove USB_ARCH_HAS_?HCI"). That select is now a nop.
Should I submit the trivial patch to remove that line or do you prefer
to do that yourself?
Thanks,
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/
Embedded white space in out-of-tree module full pathname
Hello, I'd like some confirmation that this is either not supported, or that I'm doing something obviously wrong. (Kernel 3.14 if it matters.) Suppose the source code for an out-of-tree kernel module is stored e.g. in "/tmp/foo bar/module" (note the embedded space in the path name) Here is the Makefile template I'm using. (Maybe it's wrong.) /tmp/foo bar/module$ cat Makefile KDIR ?= /home/mason/linux-3.14 ARCH ?= arm CROSS_COMPILE ?= arm-none-linux-gnueabi- obj-m += mytest.o all: make -C $(KDIR) M="$$PWD" clean: make -C $(KDIR) M="$$PWD" clean /tmp/foo bar/module$ make make -C /home/mason/linux-3.14 M="$PWD" make[1]: Entering directory `/home/mason/linux-3.14' scripts/Makefile.build:44: /tmp/foo/Makefile: No such file or directory make[2]: *** No rule to make target `/tmp/foo/Makefile'. Stop. make[1]: *** [_module_/tmp/foo] Error 2 make[1]: Leaving directory `/home/mason/linux-3.14' make: *** [all] Error 2 Does the kernel build system support building an out-of-tree module whose full pathname contains embedded white space, like in my example? Do I have an obvious mistake in my Makefile? Regards. -- 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/
Question on mm: propagate error from stack expansion even for guard page
在 2015/1/12 4:59, Linus Torvalds 写道: > Another week, another -rc. > > Things have remained reasonably calm, although we also had a few > last-minute MM regressions. Happily, most of them got fixed really > quickly, with one remaining arm64 issue still pending. > > So go forth and test some more. I'll be traveling for the next two > weeks due to LCA, but I should have internet, and if things continue > to be reasonably calm I don't think that my travel should be all that > noticeable. Finally the timing worked out, unlike several releases > last year. > > Anyway, the appended shortlog gives the details, but apart from the > kgdb patches showing up as some uncommon work under kernel/debug/, > things look fairly normal: mostly driver updates (gpu, pinctrl, hid, > networking), architecture updates (mainly x86 this time, some minor > arm[64] stuff), and some tooling fixes (mainly perf). > > Linus > > --- > > Aaron Plattner (1): > ALSA: hda - Add new GPU codec ID 0x10de0072 to snd-hda > > Alex Deucher (4): > drm/radeon: KV has three PPLLs (v2) > drm/radeon: fix sad_count check for dce3 > drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hw > drm/radeon: adjust default bapm settings for KV > > Alex Thorlton (1): > sched: Fix KMALLOC_MAX_SIZE overflow during cpumask allocation > > Alexandre Courbot (1): > drm/nouveau: fix missing return statement in nouveau_ttm_tt_unpopulate > > Alexey Khoroshilov (1): > drm/radeon: do not leave queue acquired if timeout happens in > kgd_hqd_destroy() > > Andi Kleen (1): > perf/x86/uncore/hsw-ep: Handle systems with only two SBOXes > > Andy Lutomirski (4): > x86_64, vdso: Fix the vdso address randomization algorithm > x86, vdso: Use asm volatile in __getcpu > perf: Move task_pt_regs sampling into arch code > perf/x86_64: Improve user regs sampling > > Andy Shevchenko (1): > qla3xxx: don't allow never end busy loop > > Anton Vorontsov (6): > kdb: Remove currently unused kdbtab_t->cmd_flags > kdb: Rename kdb_repeat_t to kdb_cmdflags_t, cmd_repeat to cmd_flags > kdb: Rename kdb_register_repeat() to kdb_register_flags() > kdb: Use KDB_REPEAT_* values as flags > kdb: Remove KDB_REPEAT_NONE flag > kdb: Add enable mask for groups of commands > > Ard Biesheuvel (1): > arm64/efi: add missing call to early_ioremap_reset() > > Ben Goz (5): > amdkfd: Fixing topology bug in building sysfs nodes > drm/amd: Fixing typos in kfd<->kgd interface > drm/amdkfd: Load mqd to hqd in non-HWS mode > drm/radeon: Assign VMID to PASID for IH in non-HWS mode > drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS) > > Ben Pfaff (1): > openvswitch: Consistently include VLAN header in flow and port stats. > > Ben Skeggs (4): > drm/nouveau/bios: fix oops on pre-nv50 chipsets > drm/nouveau: wake up the card if necessary during gem callbacks > drm/nouveau/fb/ram/mcp77: subclass nouveau_ram > drm/nouveau/fb/ram/mcp77: use carveout reg to determine size > > Benjamin Tissoires (1): > HID: logitech-hidpp: prefix the name with "Logitech" > > Bjørn Mork (1): > x86/build: Clean auto-generated processor feature files > > Bruno Prémont (2): > drm/nouveau/nouveau: Do not BUG_ON(!spin_is_locked()) on UP > qla2xxx: fix busy wait regression > > Chris Mason (2): > Btrfs: add more maintainers > Btrfs: don't delay inode ref updates during log replay > > Chris Wilson (1): > mutex: Always clear owner field upon mutex_unlock() > > Corey Minyard (1): > ipmi: Fix compile warning with tv_usec > > Dan Carpenter (3): > Btrfs, scrub: uninitialized variable in scrub_extent_for_parity() > drm/radeon: integer underflow in radeon_cp_dispatch_texture() > HID: roccat: potential out of bounds in pyra_sysfs_write_settings() > > Daniel Mack (1): > ALSA: snd-usb-caiaq: fix stream count check > > Daniel Nicoletti (1): > HID: Allow HID_BATTERY_STRENGTH to be enabled > > Daniel Thompson (3): > kdb: Categorize kdb commands (similar to SysRq categorization) > kdb: Allow access to sensitive commands to be restricted by default > kgdb: timeout if secondary CPUs ignore the roundup > > David Drysdale (1): > vfs: renumber FMODE_NONOTIFY and add to uniqueness check > > Doug Anderson (2): > pinctrl: rockchip: Handle wakeup pins > pinctrl: rockchip: Fix enable/disable/mask/unmask > > Fabian Frederick (1): > kernel/debug/debug_core.c: Logging clean-up > > Felipe Balbi (1): > net: ethernet: cpsw: fix hangs with interrupts > > Filipe Manana (1): > Btrfs: correctly get tree level in tree_backref_for_extent > > Francesco VIRLINZI (1): > pinctrl: st: avoid multiple mutex lock > > Giedrius Statkevičius (1): > HID: Add a new id 0x501a for Genius MousePen i608X > > Govindarajulu Var
Re: [linux-sunxi] Re: [PATCH] arm: sunxi: input: RFC: Add sysfs voltage for sun4i-lradc driver
On Tue, 2015-01-27 at 10:18 +0100, Maxime Ripard wrote: > Hi, > > On Mon, Jan 26, 2015 at 06:58:32PM +0200, Priit Laes wrote: > > --- > > Like Hans was pointing out, commit log and signed-off-by please > > > .../ABI/testing/sysfs-driver-input-sun4i-lradc | 4 ++ > > drivers/input/keyboard/sun4i-lradc-keys.c | 49 > > +- > > 2 files changed, 43 insertions(+), 10 deletions(-) > > create mode 100644 Documentation/ABI/testing/sysfs-driver-input- > > sun4i-lradc > > > > diff --git a/Documentation/ABI/testing/sysfs-driver-input-sun4i- > > lradc b/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc > > new file mode 100644 > > index 000..e4e6448 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc > > @@ -0,0 +1,4 @@ > > +What: /sys/class/input/input(x)/device/voltage > > +Date: February 2015 > > +Contact: Priit Laes > > +Description: ADC output voltage in microvolts or 0 if device is > > not opened. > > Why is it returning 0 when "device is not opened" ? What does that > even mean? You can't read that file without opening it. It means that something has to open the /dev/input/inputX device which sets up the ADC before the voltage can be read from the sysfs file. [...] > > As I told you already, if you're going to expose this an ADC in the > end, the proper solution is to use the IIO framework, not adding a > custom sysfs file. My intention was to expose just a simple debug output, so one can press the buttons and read the voltages for devicetree keymap. If anyone can suggest a simpler approach than current sysfs based one, I would do it. But full blown iio driver is currently out of scope. Also, Carlo's (ccaione) initially submitted (?) driver for lradc utilized iio subsystem. Päikest, Priit :) -- 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] net: Linn Ethernet Packet Sniffer driver
On 26/01/15 19:39, Joe Perches wrote: This header file is the public API for the driver. Should it not live under the 'include' directory? Several other drivers seem to follow that convention. It depends on how public is public. If it's _really_ public, it should be in uapi. If it's kinda public, then _maybe_ it should be in include/linux, but how likely is it another driver will use it? It is intended for user space code that needs to use the driver as it defines the netlink messages and attributes that the driver understands. So I guess uapi/linux would be the place for it. Thanks, Stathis -- 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 07/13] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK
Hello Wenyou,
On Tue, Jan 27, 2015 at 01:57:27PM +0800, Wenyou Yang wrote:
>
> static void __init at91_pm_init(void)
> {
> -#ifdef CONFIG_AT91_SLOW_CLOCK
> at91_pm_sram_init();
> -#endif
>
> pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
> mode)" : ""));
Details, but the ternary operation can be removed here, slow_clock now
defines whether we have PM support at all, not whether we have
slow_clock mode available.
Maybe we should not even display this message on the console if we
failed to allocate sram for slow_clock, we already fired a message
saying that PM is not available at all in at91_pm_sram_init().
Sylvain
--
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] samsung-laptop: enable better lid handling
On Tue, Jan 27, 2015 at 2:52 AM, Darren Hart wrote:
> On Thu, Dec 11, 2014 at 09:18:35PM +, Julijonas Kikutis wrote:
>
> Hi Julijonas,
>
> Please Cc the maintainer listed in the MAINTERS file for a faster response.
The easiest to do that is to use " git send-email
--cc-cmd=scripts/get_maintainer.pl"
He did cc me though, I just don't have enough time to monitor this
mailing list currently, sorry for that.
>> Some Samsung laptops with SABI3 delay the sleep for 10 seconds after
>> the lid is closed and do not wake up from sleep after the lid is opened.
>> A SABI command is needed to enable the better behavior.
>>
>> Command = 0x6e, d0 = 0x81 enables this behavior. Returns d0 = 0x01.
>> Command = 0x6e, d0 = 0x80 disables this behavior. Returns d0 = 0x00.
>>
>> Command = 0x6d and any d0 queries the state. This returns:
>> d0 = 0x0*01, d1 = 0x00, d2 = 0x00, d3 = 0x0* when it is enabled.
>> d0 = 0x0*00, d1 = 0x00, d2 = 0x00, d3 = 0x0* when it is disabled.
>> Where * is 0 - laptop has never slept or hibernated after switch on,
>>1 - laptop has hibernated just before,
>>2 - laptop has slept just before.
>>
>> Patch addresses bug https://bugzilla.kernel.org/show_bug.cgi?id=75901.
>> It adds a sysfs attribute lid_handling with description and also an
>> addition to the quirks structure to enable the mode by default.
>>
>> However, a user with another laptop in the bug report says that "power
>> button has to be pressed twice to wake the machine" in this mode.
>
> This is with this patch applied?
>
>> Therefore, it is enabled by default only for the single laptop that I
>> have tested.
>>
>> This mode is also needed in UEFI, but there samsung-laptop is
>> unfortunately disabled.
>
> I don't follow. What are you saying here?
samsung-laptop doesn't current load when the laptop boots in UEFI mode
becaue this used to brick the laptop.
I don't think this is the case anymore with new laptops, unfortunately
I don't own any of these.
> This looks pretty much ready. The only comments I have are argued against by
> staying consistent with the existing driver. So just the above questions and
> one
> comment below. Please clarify, update, and resend. Be sure to add me to Cc
> this
> time :-)
>
>>
>> Signed-off-by: Julijonas Kikutis
>> ---
>
> ...
>
>> @@ -,7 +1208,7 @@ static int __init samsung_backlight_init(struct
>> samsung_laptop *samsung)
>> }
>>
>> static umode_t samsung_sysfs_is_visible(struct kobject *kobj,
>> -struct attribute *attr, int idx)
>> + struct attribute *attr, int idx)
>> {
>> struct device *dev = container_of(kobj, struct device, kobj);
>> struct platform_device *pdev = to_platform_device(dev);
>> @@ -1124,6 +1221,8 @@ static umode_t samsung_sysfs_is_visible(struct kobject
>> *kobj,
>> ok = !!(read_battery_life_extender(samsung) >= 0);
>> if (attr == &dev_attr_usb_charge.attr)
>> ok = !!(read_usb_charge(samsung) >= 0);
>> + if (attr == &dev_attr_lid_handling.attr)
>> + ok = !!(read_lid_handling(samsung) >= 0);
>>
>> return ok ? attr->mode : 0;
>> }
>> @@ -1436,6 +1535,10 @@ static int samsung_pm_notification(struct
>> notifier_block *nb,
>> samsung->quirks->enable_kbd_backlight)
>> kbd_backlight_enable(samsung);
>>
>> + if (val == PM_POST_HIBERNATION &&
>> + samsung->quirks->lid_handling)
>
> This can be one line.
>
>
> --
> Darren Hart
> Intel Open Source Technology Center
--
Corentin Chary
http://xf.iksaif.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/
thermal: exynos: Remove CONFIG_EXYNOS_THERMAL_CORE?
Lukasz,
Your commit 1fd2273f966a ("thermal: exynos: Remove
exynos_thermal_common.[c|h] files") is included in today's linux-next
(ie, next-20150127). I noticed because a script I use to check
linux-next spotted a minor problem with it.
It removed the last users of CONFIG_EXYNOS_THERMAL_CORE. As a result
setting the Kconfig symbol EXYNOS_THERMAL_CORE has no effect anymore. Is
the trivial patch to remove that symbol's entry from
drivers/thermal/samsung/Kconfig queued somewhere?
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 v10 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device
> This patchset add new devfreq_event class to provide raw data to determine > current utilization of device which is used for devfreq governor. > > The following description explains the feature of two kind of devfreq class: > - devfreq class (existing) > : devfreq consumer device use raw data from devfreq_event device for >determining proper current system state and change voltage/frequency >dynamically using various governors. > - devfreq_event class (new) > : Provide measured raw data to devfreq device for governor Merged in my local git repo (1/7 to 3/7 as those three are in /drivers/devfreq). However, the admin requires me to setup the firewall again, so please wait another day for the merged patches to show up in external network (git.kernel.org) and to make a pull-request for Rafael. (waiting firewall execption approvals from the admin) Cheers, MyungJoo
Re: [PATCH V3 0/2] dmaengine: Support for IMG MDC
Hi Vinod, On Thu, Dec 11, 2014 at 10:59 PM, Andrew Bresticker wrote: > This series adds support for the IMG Multi-threaded DMA Controller (MDC) > which is found on IMG SoCs. Currently this driver only supports the > variant found on the MIPS-based Pistachio SoC. > > The MDC supports slave and memory-to-memory transfers on up to 32 channels. > Requests from channels are handled by MDC threads. Thread assignments are > per-channel and are specified in the device-tree. > > Tested on a platform based on the Pistachio SoC with additional patches. > Support for Pistachio will be submitted later. Slave DMA was tested > with the recently submitted IMG SPFI driver [1] and memory-to-memory > DMA was tested with the dmatest module. > > Based on Vinod's slave-dma/topic/slave_caps_device_control_fix. Any more comments on this series? I'd like to get this in for 3.20 if possible. Thanks! Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/18] spi/xilinx: Remove rx_fn and tx_fn pointer
Hello Mark
> Perhaps I'm missing something here but we only seem to be incrementing
> rx_ptr for the 32 bit case here...
The unified diff is a bit confusing this time.
This is how the function looks after the patch.
All the modes are handled in a generic way.
Which I believe it is right:
static void xilinx_spi_rx(struct xilinx_spi *xspi)
{
u32 data = xspi->read_fn(xspi->regs + XSPI_RXD_OFFSET);
if (!xspi->rx_ptr)
return;
switch (xspi->bits_per_word) {
case 8:
*(u8 *)(xspi->rx_ptr) = data;
break;
case 16:
*(u16 *)(xspi->rx_ptr) = data;
break;
case 32:
*(u32 *)(xspi->rx_ptr) = data;
break;
}
xspi->rx_ptr += xspi->bits_per_word/8;
}
>
>> + xspi->rx_ptr += xspi->bits_per_word/8;
>
> ...which looks to duplicate this which handles all cases. Also there's
> a coding style thing - spaces around the / please.
I am fixing this on the next version. (and xspi->tx_ptr +=
xspi->bits_per_word/8;)
I am also cc: the maintainers of checkpatch, because for whatever
reason, this was not found by the script
ricardo@neopili:~/curro/qtec/linux-upstream$ scripts/checkpatch.pl
xilinx-spi2/0011-spi-xilinx-Remove-rx_fn-and-tx_fn-pointer.patch
total: 0 errors, 0 warnings, 109 lines checked
xilinx-spi2/0011-spi-xilinx-Remove-rx_fn-and-tx_fn-pointer.patch has
no obvious style problems and is ready for submission.
Thanks!
--
Ricardo Ribalda
--
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: [Xen-devel] [PATCH v5 2/2] x86/xen: allow privcmd hypercalls to be preempted on 64-bit
On 27/01/15 08:35, Jan Beulich wrote: On 27.01.15 at 02:51, wrote: > Even if David told you this would be acceptable, I have to question > an abstract model of fixing issues on only 64-bit kernels - this may > be acceptable for distro purposes, but seems hardly the right > approach for upstream. If 32-bit ones are to become deliberately > broken, the XEN config option should become dependent on !X86_32. There are still legitimate reasons to prefer 32bit PV guests over 64bit ones. Previous versions of this patch had 32bit support as well. Why did you drop it? ~Andrew -- 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] perf: remove the extra validity check on nr_pages
The function is_power_of_2() also do the check on nr_pages, so the first check performed is unnecessary. On the other hand, the key point is to ensure @nr_pages is a power-of-two number and mostly @nr_pages is a nonzero value, so in the most cases, the function is_power_of_2() will be called. Signed-off-by: Kaixu Xia --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 882f835..abb57c2 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -4268,7 +4268,7 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma) * If we have rb pages ensure they're a power-of-two number, so we * can do bitmasks instead of modulo. */ - if (nr_pages != 0 && !is_power_of_2(nr_pages)) + if (!is_power_of_2(nr_pages)) return -EINVAL; if (vma_size != PAGE_SIZE * (1 + nr_pages)) -- 1.8.5.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 v7 0/4] Add support for parametrized events
On Mon, Jan 26, 2015 at 05:43:03PM -0800, Sukadev Bhattiprolu wrote:
SNIP
>
>
> Cody P Schafer (6):
> perf: provide sysfs_show for struct perf_pmu_events_attr
> perf: add PMU_EVENT_ATTR_STRING() helper
> powerpc/perf/hv-24x7: parse catalog and populate sysfs with events
> powerpc/perf/{hv-gpci, hv-common}: generate requests with counters
> annotated
> powerpc/perf/hv-gpci: add the remaining gpci requests
> powerpc/perf/hv-24x7: Document sysfs event description entries
>
> Sukadev Bhattiprolu (1):
> perf: define EVENT_DEFINE_RANGE_FORMAT_LITE helper
generic 'perf: *' patches look good to me.. cant say much about
the rest of the patchset though
jitka
--
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] mfd: Add support for COMe-cBL6 to Kontron PLD driver
This patch adds the DMI system ID of the Kontron COMe-cBL6 board to
the Kontron PLD driver. The list of supported products in the module
description is also updated.
Signed-off-by: Michael Brunner
Acked-by: Christian Rauch
---
drivers/mfd/Kconfig | 1 +
drivers/mfd/kempld-core.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..0c066b9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -352,6 +352,7 @@ config MFD_KEMPLD
* COMe-bIP#
* COMe-bPC2 (ETXexpress-PC)
* COMe-bSC# (ETXexpress-SC T#)
+ * COMe-cBL6
* COMe-cBT6
* COMe-cCT6
* COMe-cDC2 (microETXexpress-DC)
diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
index f38ec42..61a1f9b 100644
--- a/drivers/mfd/kempld-core.c
+++ b/drivers/mfd/kempld-core.c
@@ -508,8 +508,15 @@ static struct dmi_system_id kempld_dmi_table[] __initdata
= {
},
.driver_data = (void *)&kempld_platform_data_generic,
.callback = kempld_create_platform_device,
- },
- {
+ }, {
+ .ident = "CBL6",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
+ DMI_MATCH(DMI_BOARD_NAME, "COMe-cBL6"),
+ },
+ .driver_data = (void *)&kempld_platform_data_generic,
+ .callback = kempld_create_platform_device,
+ }, {
.ident = "CCR2",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
--
1.8.5.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 v5 2/2] x86/xen: allow privcmd hypercalls to be preempted on 64-bit
On 27/01/15 08:35, Jan Beulich wrote: On 27.01.15 at 02:51, wrote: > > Even if David told you this would be acceptable, I have to question > an abstract model of fixing issues on only 64-bit kernels - this may > be acceptable for distro purposes, but seems hardly the right > approach for upstream. If 32-bit ones are to become deliberately > broken, the XEN config option should become dependent on !X86_32. I'd rather have something omitted (keeping the current behaviour) than something that has not been tested at all. Obviously it would be preferable to to fix both 32-bit and 64-bit x86 (and ARM as well) but I'm not going to block an important bug fix for the majority use case (64-bit x86). David -- 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 07/13] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK
Hi,
On 27/01/2015 at 10:55:15 +0100, Sylvain Rochet wrote :
> Hello Wenyou,
>
> On Tue, Jan 27, 2015 at 01:57:27PM +0800, Wenyou Yang wrote:
> >
> > static void __init at91_pm_init(void)
> > {
> > -#ifdef CONFIG_AT91_SLOW_CLOCK
> > at91_pm_sram_init();
> > -#endif
> >
> > pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
> > mode)" : ""));
>
> Details, but the ternary operation can be removed here, slow_clock now
> defines whether we have PM support at all, not whether we have
> slow_clock mode available.
>
> Maybe we should not even display this message on the console if we
> failed to allocate sram for slow_clock, we already fired a message
> saying that PM is not available at all in at91_pm_sram_init().
>
That is done in patch 10/13.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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 v3 08/13] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
Hello Wenyou,
On Tue, Jan 27, 2015 at 01:58:20PM +0800, Wenyou Yang wrote:
>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 0377c0d..d967c31 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -71,7 +71,7 @@ static int at91_pm_begin(suspend_state_t state)
> * Verify that all the clocks are correct before entering
> * slow-clock mode.
> */
> -static int at91_pm_verify_clocks(void)
> +static int at91_pm_verify_clocks(suspend_state_t state)
> {
> unsigned long scsr;
> int i;
> @@ (...)
Unused state argument, it was added in v2, this is just a trace of a
reverted v2 change not fully cleaned.
> + if (!at91_pm_verify_clocks(state))
> + goto error;
Ditto.
Sylvain
--
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: thermal: exynos: Remove CONFIG_EXYNOS_THERMAL_CORE?
Hi Paul,
> Lukasz,
>
> Your commit 1fd2273f966a ("thermal: exynos: Remove
> exynos_thermal_common.[c|h] files") is included in today's linux-next
> (ie, next-20150127). I noticed because a script I use to check
> linux-next spotted a minor problem with it.
>
> It removed the last users of CONFIG_EXYNOS_THERMAL_CORE. As a result
> setting the Kconfig symbol EXYNOS_THERMAL_CORE has no effect anymore.
> Is the trivial patch to remove that symbol's entry from
> drivers/thermal/samsung/Kconfig queued somewhere?
I will prepare appropriate patch and send it ASAP.
Thanks for hint.
>
>
> Paul Bolle
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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 08/13] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
Hi Sylvain,
Thanks a lot.
> -Original Message-
> From: Sylvain Rochet [mailto:sylvain.roc...@finsecur.com]
> Sent: Tuesday, January 27, 2015 6:08 PM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; li...@arm.linux.org.uk;
> linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; alexandre.bell...@free-electrons.com;
> p...@axentia.se; sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v3 08/13] pm: at91: the standby mode uses the same sram
> function as the suspend to memory mode
>
> Hello Wenyou,
>
> On Tue, Jan 27, 2015 at 01:58:20PM +0800, Wenyou Yang wrote:
> >
> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> > 0377c0d..d967c31 100644
> > --- a/arch/arm/mach-at91/pm.c
> > +++ b/arch/arm/mach-at91/pm.c
> > @@ -71,7 +71,7 @@ static int at91_pm_begin(suspend_state_t state)
> > * Verify that all the clocks are correct before entering
> > * slow-clock mode.
> > */
> > -static int at91_pm_verify_clocks(void)
> > +static int at91_pm_verify_clocks(suspend_state_t state)
> > {
> > unsigned long scsr;
> > int i;
> > @@ (...)
>
> Unused state argument, it was added in v2, this is just a trace of a reverted
> v2
> change not fully cleaned.
Yes, not clear.
>
>
> > + if (!at91_pm_verify_clocks(state))
> > + goto error;
>
> Ditto.
>
>
> Sylvain
Best Regards,
Wenyou Yang
Re: [PATCH v3 07/13] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK
Hi,
On Tue, Jan 27, 2015 at 11:07:42AM +0100, Alexandre Belloni wrote:
> Hi,
>
> On 27/01/2015 at 10:55:15 +0100, Sylvain Rochet wrote :
> > Hello Wenyou,
> >
> > On Tue, Jan 27, 2015 at 01:57:27PM +0800, Wenyou Yang wrote:
> > >
> > > static void __init at91_pm_init(void)
> > > {
> > > -#ifdef CONFIG_AT91_SLOW_CLOCK
> > > at91_pm_sram_init();
> > > -#endif
> > >
> > > pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
> > > mode)" : ""));
> >
> > Details, but the ternary operation can be removed here, slow_clock now
> > defines whether we have PM support at all, not whether we have
> > slow_clock mode available.
> >
> > Maybe we should not even display this message on the console if we
> > failed to allocate sram for slow_clock, we already fired a message
> > saying that PM is not available at all in at91_pm_sram_init().
>
> That is done in patch 10/13.
Indeed… I missed that because 10/13 is a rename patch, this should be
done here IMHO :)
Sylvain
--
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: inverse mapping from a struct console to device
On Tue, Jan 27, 2015 at 03:06:35AM +, Jon Masters wrote:
> On 01/26/2015 03:50 PM, Mark Rutland wrote:
> > On Mon, Jan 26, 2015 at 07:40:58PM +, Jon Masters wrote:
> >> Hi Folks,
> >>
> >> TLDR: I need a back reference from a console struct to its device. I
> >> can't see an easy way to do this right now without adding one?
> >
> > I don't think that's quite what you need. All you need is to be able to
> > refer to the SPCR at serial probe time (more on that below), when you
> > should have the data you want.
>
> Hmm. I wanted to do it in console_register due to the existing logic for
> adding a preferred console there. But that's a silly reason.
>
> >> I've a quick question. I have prototype code that parses an ACPI table
> >> known as the SPCR (Serial Port Console Redirection - exists on both x86
> >> and ARM systems). It finds the correct serial device (but it's not a
> >> Linux specific DT-style solution so there's no "console=" parameter
> >> embedded in it or something)
> >
> > In DT we have /chosen/stdout-path which offers analagous functionality.
> > It is independent of the command line, and has a standard set of
> > parameters ({{{}}}).
>
> Hmm. I thought it was embedding a Linux specific console parameter, but
> I see when I actually check the code and the Documentation (sorry) that
> it is indeed similar in capability. Which is awesome. I'll do similar.
>
> > To make this work we check against the stdout-path when we register the
> > UART. Take a look at of_console check (called from uart_add_one_port).
>
> Great. Thanks. I looked at modifying uart_add_one_port, but I wasn't
> convinced it was called by every serial driver (for example, the
> sbsauart driver). I don't know the tty/serial code as well as I'd like.
> But I'll implement it the same way as in the OF case for the moment, and
> if we need to fix up a driver or two we can always do that.
The SBSA UART is a bit of a special case, given it cannot be
reconfigured. While Andre's SBSA UART driver [1] will call
uart_add_one_port (as the PL011 driver seems to currently), I believe
any configuration is ignored.
In the DT case, we'd expect the SBSA UART node to have a current-speed
property describing the fixed, preconfigured speed. This has no bearing
on the operation of the driver (because there's nothing to configure)
and is only used to report the speed to userspace.
I guess we don't have something on the ACPI node, and you want to use
the SPCR to determine the preconfigured rate in this case?
> > Assuming your UART probing looks similar for ACPI, you can have an
> > analagous function that goes and checks uport->dev.acpi_dev_node against
> > entires in the SPCR, configuring the UART as required at this point at
> > registration time.
>
> > This requires that you parse the SPCR earlier, but presumably the SPCR
> > is simple enough that this is possible (no AML, for instance).
>
> I already parse it as an initcall early in boot and indeed have it prior
> to the port being registered.
>
> > Is there some reason that approach is unworkable?
>
> Apparently not, just need to check a couple of drivers.
>
> Thanks Mark. I'll post a patch later for SPCR setup.
Great!
Mark.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317146.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] HID: i2c-hid: Add support for GPIO interrupts
On Mon, Jan 26, 2015 at 04:39:30PM +, Mark Rutland wrote:
> What I don't follow is why GpioInt seems to be translated as a GPIO
> rather than as an interrupt which happens to be backed by a GPIO. Were
> it not for that, the DT and ACPI cases would align better.
Because it *is* a GPIO.
In my experience we have had two kinds of interrupts that the devices
are connected to: pins connected directly to the interrupt controller
(IO-APIC or whatever), and pins connected to the GPIO controller. This
is the later.
Now, the device in question has following resources:
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x004C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer,,)
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x004C
}
})
The GpioInt() above refers to GPIO controller ("\_SB.GPO0") and its pin
number 0x4c.
Normally I would do this in the driver regardless of where it is
described (DT, ACPI, whatnot):
desc = gpiod_get(dev, NULL);
gpiod_direction_input(desc);
irq = gpiod_to_irq(desc);
Then the "irq" can be used for request_irq() and friends.
Note how both DT and ACPI cases align just fine.
If the above is not the right way to use GPIOs as interrupt, can you
please tell me how it is done then?
BTW, passing NULL to gpiod_get() implies property named "gpios" in DT
(which is why I added it to the documentation).
--
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 1/5] ARM: mediatek: Add config options for mediatek SoCs.
Joe,
On Thu, 2015-01-22 at 13:54 +0100, Matthias Brugger wrote:
> 2015-01-21 6:28 GMT+01:00 Hongzhou Yang :
> > From: Yingjoe Chen
> >
> > The upcoming MTK pinctrl driver have a big pin table for each SoC
> > and we don't want to bloat the kernel binary if we don't need it.
> > Add config options so we can build for one SoC only.
> >
> > Acked-by: Linus Walleij
> > Signed-off-by: Yingjoe Chen
> > Signed-off-by: Hongzhou Yang
>
> Applied to v3.20-next/soc
This became commit ad8a221e1f49 ("ARM: mediatek: Add config options for
mediatek SoCs.") in today's linux-next (ie, next-20150127). I noticed
because a script I use to check linux-next spotted a problem with it.
> > ---
> > arch/arm/mach-mediatek/Kconfig | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
> > index f73f588..f7e463c 100644
> > --- a/arch/arm/mach-mediatek/Kconfig
> > +++ b/arch/arm/mach-mediatek/Kconfig
> > @@ -1,6 +1,26 @@
> > -config ARCH_MEDIATEK
> > +menuconfig ARCH_MEDIATEK
> > bool "Mediatek MT65xx & MT81xx SoC" if ARCH_MULTI_V7
> > select ARM_GIC
> > select MTK_TIMER
> > help
> > Support for Mediatek MT65xx & MT81xx SoCs
> > +
> > +if ARCH_MEDIATEK
> > +
> > +config MACH_MT6589
> > + bool "MediaTek MT6589 SoCs support"
> > + default ARCH_MEDIATEK
> > +
> > +config MACH_MT6592
> > + bool "MediaTek MT6592 SoCs support"
> > + default ARCH_MEDIATEK
> > +
> > +config MACH_MT8127
> > + bool "MediaTek MT8127 SoCs support"
> > + default ARCH_MEDIATEK
> > +
> > +config MACH_MT8135
> > + bool "MediaTek MT8135 SoCs support"
> > + default ARCH_MEDIATEK
> > +
> > +endif
None of these four new MACH_MT* Kconfig symbols are currently used in
linux-next. I assume that patches that actually use them (either as a
Kconfig symbol or as a CONFIG_* macro) are still pending. Is that
correct?
Thanks,
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 v2] staging: rtl8712: fix Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ...
The subject line is too long.
> - printk(KERN_INFO "r8712u: Staging version\n");
> + pr_info("r8712u: Staging version\n");
This is a dumb thing to print. Just delete this line.
regards,
dan carpenter
--
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 00/18] spi/xilinx: Speed-up
Hello Mark On Tue, Jan 27, 2015 at 1:14 AM, Mark Brown wrote: > > In general the best way to present a series is to start off with any bug > fixes (so they can be sent to Linus and stable if needed), then move on > to mechanical and stylistic cleanups (since they tend to be easy to > review and apply) and finally move on to new functionality (since that > is most likely to run into review problems and the cleanups should help > review). Will try to follow that pattern the next time. The development of the patchset has been a bit chaotic. I opened up the code to support more modes and then I realize that I could improve the poor performance I was having with the driver > >> spi/xilinx: Support for spi mode LOOP >> spi/xilinx: Simplify data read from the Rx FIFO >> spi-xilinx: Simplify spi_fill_tx_fifo > > spi-xilinx? Thanks! Fixed on the next version. BTW what is preferred spi/xilinx: or spi: xilinx: ?I have seen both naming. Thanks! -- Ricardo Ribalda -- 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 03/13] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
Hello. On 1/27/2015 8:53 AM, Wenyou Yang wrote: From: Peter Rosin The DDRSDR controller fails miserably to put LPDDR1 memories in self-refresh. Force the controller to think it has DDR2 memories during the self-refresh period, as the DDR2 self-refresh spec is equivalent to LPDDR1, and is correctly implemented in the controller. Assume that the second controller has the same fault, but that is untested. Signed-off-by: Peter Rosin Acked-by: Nicolas Ferre --- arch/arm/mach-at91/pm_slowclock.S | 43 +++- include/soc/at91/at91sam9_ddrsdr.h |2 +- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index e2bfaf5..1155217 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S [...] @@ -108,14 +118,26 @@ ddr_sr_enable: /* figure out if we use the second ram controller */ cmp ramc1, #0 - ldrne tmp2, [ramc1, #AT91_DDRSDRC_LPR] - strne tmp2, .saved_sam9_lpr1 - bicne tmp2, #AT91_DDRSDRC_LPCB - orrne tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH + beq ddr_no_2nd_ctrl + + ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR] + str tmp2, .saved_sam9_mdr1 + bic tmp2, tmp2, #~AT91_DDRSDRC_MD + cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR + ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR] + biceq tmp2, tmp2, #AT91_DDRSDRC_MD Didn't you forget ~? Either that, or ~ above is not needed, I think. + orreq tmp2, tmp2, #AT91_DDRSDRC_MD_DDR2 + streq tmp2, [ramc1, #AT91_DDRSDRC_MDR] + + ldr tmp2, [ramc1, #AT91_DDRSDRC_LPR] + str tmp2, .saved_sam9_lpr1 + bic tmp2, #AT91_DDRSDRC_LPCB Didn't you forget ~? And isn't it 3-operand instruction (as seen in the above code)? + orr tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH Only 2 operands? [...] WBR, Sergei -- 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 1/5] ARM: mediatek: Add config options for mediatek SoCs.
Hi,
On Tue, 2015-01-27 at 11:16 +0100, Paul Bolle wrote:
> Joe,
>
> On Thu, 2015-01-22 at 13:54 +0100, Matthias Brugger wrote:
> > 2015-01-21 6:28 GMT+01:00 Hongzhou Yang :
> > > From: Yingjoe Chen
> > >
> > > The upcoming MTK pinctrl driver have a big pin table for each SoC
> > > and we don't want to bloat the kernel binary if we don't need it.
> > > Add config options so we can build for one SoC only.
> > >
> > > Acked-by: Linus Walleij
> > > Signed-off-by: Yingjoe Chen
> > > Signed-off-by: Hongzhou Yang
> >
> > Applied to v3.20-next/soc
>
> This became commit ad8a221e1f49 ("ARM: mediatek: Add config options for
> mediatek SoCs.") in today's linux-next (ie, next-20150127). I noticed
> because a script I use to check linux-next spotted a problem with it.
>
> > > ---
> > > arch/arm/mach-mediatek/Kconfig | 22 +-
> > > 1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/mach-mediatek/Kconfig
> > > b/arch/arm/mach-mediatek/Kconfig
> > > index f73f588..f7e463c 100644
> > > --- a/arch/arm/mach-mediatek/Kconfig
> > > +++ b/arch/arm/mach-mediatek/Kconfig
> > > @@ -1,6 +1,26 @@
> > > -config ARCH_MEDIATEK
> > > +menuconfig ARCH_MEDIATEK
> > > bool "Mediatek MT65xx & MT81xx SoC" if ARCH_MULTI_V7
> > > select ARM_GIC
> > > select MTK_TIMER
> > > help
> > > Support for Mediatek MT65xx & MT81xx SoCs
> > > +
> > > +if ARCH_MEDIATEK
> > > +
> > > +config MACH_MT6589
> > > + bool "MediaTek MT6589 SoCs support"
> > > + default ARCH_MEDIATEK
> > > +
> > > +config MACH_MT6592
> > > + bool "MediaTek MT6592 SoCs support"
> > > + default ARCH_MEDIATEK
> > > +
> > > +config MACH_MT8127
> > > + bool "MediaTek MT8127 SoCs support"
> > > + default ARCH_MEDIATEK
> > > +
> > > +config MACH_MT8135
> > > + bool "MediaTek MT8135 SoCs support"
> > > + default ARCH_MEDIATEK
> > > +
> > > +endif
>
> None of these four new MACH_MT* Kconfig symbols are currently used in
> linux-next. I assume that patches that actually use them (either as a
> Kconfig symbol or as a CONFIG_* macro) are still pending. Is that
> correct?
Yes, it is used in patch 3 in this series[1], and is discussed in [2].
Joe.C
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/318453.html
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315616.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CentOS 7.0, e1000e driver issue/bug - "Detected Hardware Unit Hang:" "Reset adapter unexpectedly"
Hi, I have a problem on a machine running CentOS 7.0, where the kernel/e1000e reports things like "Detected Hardware Unit Hang:" and "Reset adapter unexpectedly". The kernel version is 3.10.0-123.13.2.el7.x86_64. I had a similar issue years ago with the same machine running openSUSE 12.3 with kernel 3.7.10, and downgrading to 3.4.47 fixed it completely. At that time, I found this bug reported in fedora, marked as WONTFIX due to the fedora release hitting EoL https://bugzilla.redhat.com/show_bug.cgi?id=785806 and the dmesg output looks similar. And recently I found this old bug for CentOS 6. http://bugs.centos.org/view.php?id=6517 to which I replied but haven't seen any activity there for a week. Years ago on openSUSE 12.3 with kernel 3.7.10, this would eventually make the network fail completely requiring a reboot. So far (up 12 days) the machine with 3.10.x hasn't been disconnected long enough to be noticeable. I have seen http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=09357b00255c233705b1cf6d76a8d147340545b8 as mentioned in the fedora bug page, and it appears to already be applied to this kernel. *Here are the details for the machine with the problem: *root@machine:~ # lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.0.1406 (Core) Release: 7.0.1406 Codename: Core root@machine:~ # uname -a Linux machine.bc.local 3.10.0-123.13.2.el7.x86_64 #1 SMP Thu Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux root@machine:~ # lspci -v ... 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05) Subsystem: Super Micro Computer Inc Device 1502 Flags: bus master, fast devsel, latency 0, IRQ 42 Memory at dfd0 (32-bit, non-prefetchable) [size=128K] Memory at dfd25000 (32-bit, non-prefetchable) [size=4K] I/O ports at f020 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [e0] PCI Advanced Features Kernel driver in use: e1000e Here is dmesg right after boot and plugging in network after booted: [ 368.697841] e1000e :00:19.0 com: Detected Hardware Unit Hang: TDH <3d> TDT <67> next_to_use <67> next_to_clean <39> buffer_info[next_to_clean]: time_stamp <1000106e9> next_to_watch <3d> jiffies <100010c60> next_to_watch.status <0> MAC Status <40080083> PHY Status <796d> PHY 1000BASE-T Status <3800> PHY Extended Status <3000> PCI Status <10> [ 370.696960] e1000e :00:19.0 com: Detected Hardware Unit Hang: TDH <3d> TDT <67> next_to_use <67> next_to_clean <39> buffer_info[next_to_clean]: time_stamp <1000106e9> next_to_watch <3d> jiffies <100011430> next_to_watch.status <0> MAC Status <40080083> PHY Status <796d> PHY 1000BASE-T Status <3800> PHY Extended Status <3000> PCI Status <10> [ 372.695807] e1000e :00:19.0 com: Detected Hardware Unit Hang: TDH <3d> TDT <67> next_to_use <67> next_to_clean <39> buffer_info[next_to_clean]: time_stamp <1000106e9> next_to_watch <3d> jiffies <100011c00> next_to_watch.status <0> MAC Status <40080083> PHY Status <796d> PHY 1000BASE-T Status <3800> PHY Extended Status <3000> PCI Status <10> [ 374.694933] e1000e :00:19.0 com: Detected Hardware Unit Hang: TDH <3d> TDT <67> next_to_use <67> next_to_clean <39> buffer_info[next_to_clean]: time_stamp <1000106e9> next_to_watch <3d> jiffies <1000123d0> next_to_watch.status <0> MAC Status <40080083> PHY Status <796d> PHY 1000BASE-T Status <3800> PHY Extended Status <3000> PCI Status <10> [ 374.710096] [ cut here ] [ 374.710124] WARNING: at net/sched/sch_generic.c:259 dev_watchdog+0x270/0x280() [ 374.710128] NETDEV WATCHDOG: com (e1000e): transmit queue 0 timed out [ 374.710131] Modules linked in: binfmt_misc act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_stat istic xt_CT xt_connlimit xt_realm xt_addrtype xt_comment xt_recent xt_nat ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah xt_set ip_set ipt_ULOG xt_LOG nf_nat_tftp nf_nat_snmp_basic n f_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pro to_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 xt_TPROXY nf_defrag_ipv6 xt_time xt_TCPMSS xt_tcpmss xt_sctp [ 374.710177] xt_policy xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark xt_CLASSIFY xt_AUDIT xt_state iptable_raw iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defr
Re: [PATCH v3 0/5] Perf tool fixes for ARC + uClibc
Hi Arnaldo,
On Monday 19 January 2015 07:28 PM, Arnaldo Carvalho de Melo wrote:
> Acked-by: Jiri Olsa
>>> > > Most are already in my perf/urgent branch.
>> > Are you planning to add {4,5}/5 for next window or did u drop/miss them ?
> I will, IIRC those were not that trivial, so could wait, I'll make sure
> I review them and merge for perf/core if I find no issues.
Sorry for annoying pestering on this. I don't see the patches in ur perf/core
yet
and given that we are so close to next window, I fear that we will miss them if
we
don't add them soon.
We need them to be able to use perf on ARC - fixing build issue (5/5) as well as
run time issue (4/5)
Thx,
-Vineet
--
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] mm: vmscan: fix the page state calculation in too_many_isolated
On 01/26/2015 10:58 PM, Michal Hocko wrote: On Sat 17-01-15 13:48:34, Christoph Lameter wrote: On Sat, 17 Jan 2015, Vinayak Menon wrote: which had not updated the vmstat_diff. This CPU was in idle for around 30 secs. When I looked at the tvec base for this CPU, the timer associated with vmstat_update had its expiry time less than current jiffies. This timer had its deferrable flag set, and was tied to the next non-deferrable timer in the We can remove the deferrrable flag now since the vmstat threads are only activated as necessary with the recent changes. Looks like this could fix your issue? OK, I have checked the history and the deferrable behavior has been introduced by 39bf6270f524 (VM statistics: Make timer deferrable) which hasn't offered any numbers which would justify the change. So I think it would be a good idea to revert this one as it can clearly cause issues. Could you retest with this change? It still wouldn't help with the highly overloaded workqueues but that sounds like a bigger change and this one sounds like quite safe to me so it is a good start. Sure, I can retest. Even without highly overloaded workqueues, there can be a delay of HZ in updating the counters. This means reclaim path can be blocked for a second or more, when there aren't really any isolated pages. So we need the fix in too_many_isolated also right ? -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 1/5] ARM: mediatek: Add config options for mediatek SoCs.
Hi Joe,
On Tue, 2015-01-27 at 18:26 +0800, Yingjoe Chen wrote:
> On Tue, 2015-01-27 at 11:16 +0100, Paul Bolle wrote:
> > On Thu, 2015-01-22 at 13:54 +0100, Matthias Brugger wrote:
> > > 2015-01-21 6:28 GMT+01:00 Hongzhou Yang :
> > > > From: Yingjoe Chen
> > > >
> > > > The upcoming MTK pinctrl driver have a big pin table for each SoC
> > > > and we don't want to bloat the kernel binary if we don't need it.
> > > > Add config options so we can build for one SoC only.
> > > >
> > > > Acked-by: Linus Walleij
> > > > Signed-off-by: Yingjoe Chen
> > > > Signed-off-by: Hongzhou Yang
> > >
> > > Applied to v3.20-next/soc
> >
> > This became commit ad8a221e1f49 ("ARM: mediatek: Add config options for
> > mediatek SoCs.") in today's linux-next (ie, next-20150127). I noticed
> > because a script I use to check linux-next spotted a problem with it.
> >
> > > > ---
> > > > arch/arm/mach-mediatek/Kconfig | 22 +-
> > > > 1 file changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-mediatek/Kconfig
> > > > b/arch/arm/mach-mediatek/Kconfig
> > > > index f73f588..f7e463c 100644
> > > > --- a/arch/arm/mach-mediatek/Kconfig
> > > > +++ b/arch/arm/mach-mediatek/Kconfig
> > > > @@ -1,6 +1,26 @@
> > > > -config ARCH_MEDIATEK
> > > > +menuconfig ARCH_MEDIATEK
> > > > bool "Mediatek MT65xx & MT81xx SoC" if ARCH_MULTI_V7
> > > > select ARM_GIC
> > > > select MTK_TIMER
> > > > help
> > > > Support for Mediatek MT65xx & MT81xx SoCs
> > > > +
> > > > +if ARCH_MEDIATEK
> > > > +
> > > > +config MACH_MT6589
> > > > + bool "MediaTek MT6589 SoCs support"
> > > > + default ARCH_MEDIATEK
> > > > +
> > > > +config MACH_MT6592
> > > > + bool "MediaTek MT6592 SoCs support"
> > > > + default ARCH_MEDIATEK
> > > > +
> > > > +config MACH_MT8127
> > > > + bool "MediaTek MT8127 SoCs support"
> > > > + default ARCH_MEDIATEK
> > > > +
> > > > +config MACH_MT8135
> > > > + bool "MediaTek MT8135 SoCs support"
> > > > + default ARCH_MEDIATEK
> > > > +
> > > > +endif
> >
> > None of these four new MACH_MT* Kconfig symbols are currently used in
> > linux-next. I assume that patches that actually use them (either as a
> > Kconfig symbol or as a CONFIG_* macro) are still pending. Is that
> > correct?
>
> Yes, it is used in patch 3 in this series[1], and is discussed in [2].
>
> Joe.C
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/318453.html
That only seems to add a user for MACH_MT8135, not for the other three
symbols. The other three symbols will be used too, won't they?
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315616.html
(For the record, that is a message regarding v4 of this patch.)
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: [lm-sensors] [PATCH] hwmon: (ads7828) Make sample interval configurable
Hi Robert, Le Tuesday 27 January 2015 à 08:59 +0100, Robert Rosengren a écrit : > On 01/16/2015 07:30 PM, Guenter Roeck wrote: > > I sent a couple of patches a minute ago which should take care of the issue. > > Would be great if you can test it. > I applied the v2 versions of the patches for a quick test, but it was > not successful. Haven't done any further investigation on what the > problem might be, but when trying to read the sysfs driver I get "read > error: No such device or address". > > The sysfs path have moved with the REGMAP settings, from > /sys/bus/i2c/devices//in0_input to > /sys/bus/i2c/devices//hwmon/hwmon0/in0_input. This is expected, shouldn't be an issue if you are using a libsensors-based application with a recent enough version of libsensors. > Any ideas? Haven't had REGMAP configured in my kernel earlier, might it > be some specific configuration I miss? How are you testing/reading exactly? -- Jean Delvare SUSE L3 Support -- 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/2] HID: i2c-hid: Add support for GPIO interrupts
On Tue, Jan 27, 2015 at 10:16:10AM +, Mika Westerberg wrote:
> On Mon, Jan 26, 2015 at 04:39:30PM +, Mark Rutland wrote:
> > What I don't follow is why GpioInt seems to be translated as a GPIO
> > rather than as an interrupt which happens to be backed by a GPIO. Were
> > it not for that, the DT and ACPI cases would align better.
>
> Because it *is* a GPIO.
I don't disagree on this point.
However, this is irrelevant from the PoV of the device in question. It
doesn't care what its interrupt line is wired up to so long as it
behaves like an interrupt. Hopefully the example below will clarify what
I'm getting at here.
> In my experience we have had two kinds of interrupts that the devices
> are connected to: pins connected directly to the interrupt controller
> (IO-APIC or whatever), and pins connected to the GPIO controller. This
> is the later.
>
> Now, the device in question has following resources:
>
> Name (_CRS, ResourceTemplate () {
> I2cSerialBus (0x004C, ControllerInitiated, 0x00061A80,
> AddressingMode7Bit, "\\_SB.PCI0.I2C6",
> 0x00, ResourceConsumer,,)
> GpioInt (Level, ActiveLow, Shared, PullDefault, 0x,
> "\\_SB.GPO0", 0x00, ResourceConsumer,,)
> {
> 0x004C
> }
> })
>
> The GpioInt() above refers to GPIO controller ("\_SB.GPO0") and its pin
> number 0x4c.
>
> Normally I would do this in the driver regardless of where it is
> described (DT, ACPI, whatnot):
>
> desc = gpiod_get(dev, NULL);
> gpiod_direction_input(desc);
> irq = gpiod_to_irq(desc);
>
> Then the "irq" can be used for request_irq() and friends.
>
> Note how both DT and ACPI cases align just fine.
>
> If the above is not the right way to use GPIOs as interrupt, can you
> please tell me how it is done then?
So lets say we have a device which generates an interrupt:
device@f00 {
compatible = "some-interrupting-device";
reg = <0xf00 0x100>;
interrupts = < ... >;
};
It's intended that this is connected to an interrupt controller:
ic: interrupt-controller@b00 {
compatible = "some-interrupt-controller";
reg = <0xb00 0x100>;
#interrupt-cells = <1>;
};
device@f00 {
compatible = "some-interrupting-device";
reg = <0xf00 0x100>;
interrupt-parent = <&ic>;
interrupts = <0x3>;
};
But in some cases, this gets connected to a GPIO controller. In these
cases, the device is still logically generating an interrupt, and the
fact that the endpoint is an interrupt controller is irrelevant from the
PoV of the device. So we acknowledge that the GPIO controller is also
capable of acting as an interrupt controller, and mark it as such:
gc: gpio-controller@000 {
compatible = "some-gpio-controller";
reg = <0x000 0x100>;
#gpio-cells = <1>;
#interrupt-cells = <1>;
};
device@f00 {
compatible = "some-interrupting-device";
reg = <0xf00 0x100>;
interrupt-parent = <&gc>;
interrupts = <0x1>;
};
Thus the device binding only describes the logical interrupt, and the
driver only needs to handle interrupts.
In cases where the binding/driver actually care about the GPIO being a
GPIO (e.g. for card detect in an MMC controller), describing the GPIO as
a GPIO makes sense, and we can try gpio_to_irq as an optimisation over
polling the state of the GPIO.
> BTW, passing NULL to gpiod_get() implies property named "gpios" in DT
> (which is why I added it to the documentation).
Sure. My concern is that we should not need to deal with GPIOs in this
case were the GPIO is only there to function as an interrupt.
Given that GpioInt seems to describe an interrupt which happens to be
backed by a GPIO, I don't understand what it is necessary to translate
this as a GPIO rather than an interrupt. If it were going to be used as
a GPIO, then it would be a GpioIO object, no?
Thanks,
Mark.
--
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] mm: vmscan: fix the page state calculation in too_many_isolated
On Mon 26-01-15 14:11:59, Andrew Morton wrote: [...] > So do we drop > mm-vmscan-fix-the-page-state-calculation-in-too_many_isolated.patch? I would like to see a confirmation from Vinayak that this really helped in his test case first and only then drop the above patch. I really think that we shouldn't spread hacks around the code just workaround inefficiency in the vmstat code. We already have two places which need a special treatment and who knows how many more will show up later. Even with this patch applied we have other issues related to the overloaded workqueues as mentioned earlier but those should be fixed by a separate fixe(s). -- Michal Hocko 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/
Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated
On Tue 27-01-15 16:03:57, Vinayak Menon wrote: [...] > Sure, I can retest. Thanks! > Even without highly overloaded workqueues, there can be a delay of HZ in > updating the counters. This means reclaim path can be blocked for a second > or more, when there aren't really any isolated pages. So we need the fix in > too_many_isolated also right ? Is this a big deal though? What you are hitting is certainly a corner case. I assume your system is trashing heavily already with so few pages on the file LRU list. Anyway as mentioned in other email I would rather see vmstat data more reliable than spread hacks to the code where we see immediate issues. -- Michal Hocko 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/
Re: [PATCH] mn10300: remove redundant hex()
Arjun, On Mon, 2015-01-26 at 22:49 +0530, Arjun Sreedharan wrote: > Ping !! I wouldn't hold my breath waiting for any response, if I were you. > On 30 November 2014 at 16:29, Arjun Sreedharan wrote: > > replace rendundant hex() with kernel's hex_to_bin() > > > > Signed-off-by: Arjun Sreedharan > > --- > > arch/mn10300/kernel/gdb-stub.c | 61 > > -- > > 1 file changed, 23 insertions(+), 38 deletions(-) You can't actually build a mn10300 kernel with GDBSTUB set since v2.6.39, see https://lkml.org/lkml/2014/9/18/387 . Perhaps you still managed to build arch/mn10300/kernel/gdb-stub.o manually, bypassing kconfig. Or did you just edit out its dependency on DEPRECATED? 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] net: Linn Ethernet Packet Sniffer driver
Hi Florian, On 26/01/15 22:30, Florian Fainelli wrote: On 23/01/15 02:07, Stathis Voukelatos wrote: This patch adds support the Ethernet Packet Sniffer H/W module developed by Linn Products Ltd and found in the IMG Pistachio SoC. The module allows Ethernet packets to be parsed, matched against a user-defined pattern and timestamped. It sits between a 100M Ethernet MAC and PHY and is completely passive with respect to Ethernet frames. Is there any latency penalty involved in capturing (or not) packets as opposed to having this capture HW unused? There is no additional latency introduced by the sniffer at the H/W level, if that is what you mean. Only the S/W overhead for handling the sniffer interrupt for each match event. Matched packet bytes and timestamp values are returned through a FIFO. Timestamps are provided to the module through an externally generated Gray-encoded counter. The command pattern for packet matching is stored in module RAM and consists of a sequence of 16-bit entries. Each entry includes an 8-bit command code and and 8-bit data value. Valid command codes are: 0 - Don't care 1 - Match: packet data must match command string byte 2 - Copy: packet data will be copied to FIFO 3 - Match/Stamp: if packet data matches string byte, a timestamp is copied into the FIFO 4 - Copy/Done: packet data will be copied into the FIFO. This command terminates the command string. The driver consists of two modules: - Core: it provides an API to user space using the Generic Netlink framework. Specific backend implementations, like the Ethernet Packet Sniffer, register one or more channels with the Core. For each channel a Genl family is created. User space can access a channel by sending Genl messages to the Genl family associated with the channel. Packet matching events are multicast. Instead of having this new generic netlink family to control sniffing, could we imagine registering a netdevice which does not nothing but still allows for tools like tcpdump, af_packet and other capture tools to work transparently and just leverage the HW capture? Thanks, I will work on that change. It has been suggested by a previous reviewer too and it makes sense to go down that route. Stathis -- 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] thermal: Fix examples in DT documentation
There are various issues with the examples in this documentation, some
of the DT labels are invalid and one of the macro THERMAL_NO_LIMITS
referenced is not available as well.
As Its highly likely that people would pick some samples from the
documentation, I though fixing these would be best rather than giving
starter a challenge to figure out whats going wrong with examples.
This patch attempts to fix such errors in the documentation.
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/thermal/thermal.txt| 44 +++---
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
b/Documentation/devicetree/bindings/thermal/thermal.txt
index f5db6b7..97ed14e 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -251,24 +251,24 @@ ocp {
};
thermal-zones {
- cpu-thermal: cpu-thermal {
+ cpu_thermal: cpu-thermal {
polling-delay-passive = <250>; /* milliseconds */
polling-delay = <1000>; /* milliseconds */
thermal-sensors = <&bandgap0>;
trips {
- cpu-alert0: cpu-alert {
+ cpu_alert0: cpu-alert0 {
temperature = <9>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "active";
};
- cpu-alert1: cpu-alert {
+ cpu_alert1: cpu-alert1 {
temperature = <10>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "passive";
};
- cpu-crit: cpu-crit {
+ cpu_crit: cpu-crit {
temperature = <125000>; /* millicelsius */
hysteresis = <2000>; /* millicelsius */
type = "critical";
@@ -277,17 +277,17 @@ thermal-zones {
cooling-maps {
map0 {
- trip = <&cpu-alert0>;
- cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+ trip = <&cpu_alert0>;
+ cooling-device = <&fan0 THERMAL_NO_LIMIT 4>;
};
map1 {
- trip = <&cpu-alert1>;
- cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+ trip = <&cpu_alert1>;
+ cooling-device = <&fan0 5 THERMAL_NO_LIMIT>;
};
map2 {
- trip = <&cpu-alert1>;
+ trip = <&cpu_alert1>;
cooling-device =
- <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
};
};
@@ -298,13 +298,13 @@ used to monitor the zone 'cpu-thermal' using its sole
sensor. A fan
device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
different cooling states 0-9. It is used to remove the heat out of
the thermal zone 'cpu-thermal' using its cooling states
-from its minimum to 4, when it reaches trip point 'cpu-alert0'
+from its minimum to 4, when it reaches trip point 'cpu_alert0'
at 90C, as an example of active cooling. The same cooling device is used at
-'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+'cpu_alert1', but from 5 to its maximum state. The cpu@0 device is also
linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
-using all its cooling states at trip point 'cpu-alert1',
+using all its cooling states at trip point 'cpu_alert1',
which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
-temperature of 125C, represented by the trip point 'cpu-crit', the silicon
+temperature of 125C, represented by the trip point 'cpu_crit', the silicon
is not reliable anymore.
(b) - IC with several internal sensors
@@ -329,7 +329,7 @@ ocp {
};
thermal-zones {
- cpu-thermal: cpu-thermal {
+ cpu_thermal: cpu-thermal {
polling-delay-passive = <250>; /* milliseconds */
polling-delay = <1000>; /* milliseconds */
@@ -338,12 +338,12 @@ thermal-zones {
trips {
/* each zone within the SoC may have its own trips */
- cpu-alert: cpu-alert {
+ cpu_alert: cpu-alert {
temperature = <10>; /* millicelsius */
hysteresis = <2000>; /* mi
Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated
On Mon 26-01-15 12:35:00, Christoph Lameter wrote: > On Mon, 26 Jan 2015, Michal Hocko wrote: > > > > Please do not run the vmstat_updates concurrently. They update shared > > > cachelines and therefore can cause bouncing cachelines if run concurrently > > > on multiple cpus. > > > > Would you preffer to call smp_call_function_single on each CPU > > which needs an update? That would make vmstat_shepherd slower but that > > is not a big deal, is it? > > Run it from the timer interrupt as usual from a work request? Those are > staggered. I am not following. The idea was to run vmstat_shepherd in a kernel thread and waking up as per defined timeout and then check need_update for each CPU and call smp_call_function_single to refresh the timer rather than building a mask and then calling sm_call_function_many to reduce paralel contention on the shared counters. > > Anyway I am wondering whether the cache line bouncing between > > vmstat_update instances is a big deal in the real life. Updating shared > > counters whould bounce with many CPUs but this is an operation which is > > not done often. Also all the CPUs would have update the same counters > > all the time and I am not sure this happens that often. Do you have a > > load where this would be measurable? > > Concurrent page faults update lots of counters concurrently. True > But will those trigger the smp_call_function? The smp_call_function was meant to be called only from the vmstat_shepherd context which does happen "rarely". Or am I missing your point here? -- Michal Hocko 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/
[PATCH 4/7] spi: spi-fsl-dspi: avoid preparing the clock two times
regmap_read/regmap_write will expect the peripheral clock
to be enabled before accessing the registers of the peripheral.
Since the peripheral clock is enabled separatly, avoid redundant clock
prepare (with devm_regmap_init_mmio_clk) and use devm_regmap_init_mmio instead.
Acked-by: Stefan Agner
Signed-off-by: Bhuvanchandra DV
---
drivers/spi/spi-fsl-dspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 9b80d54..5378148 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -502,7 +502,7 @@ static int dspi_probe(struct platform_device *pdev)
goto out_master_put;
}
- dspi->regmap = devm_regmap_init_mmio_clk(&pdev->dev, "dspi", base,
+ dspi->regmap = devm_regmap_init_mmio(&pdev->dev, base,
&dspi_regmap_config);
if (IS_ERR(dspi->regmap)) {
dev_err(&pdev->dev, "failed to init regmap: %ld\n",
--
2.2.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 1/7] ARM: vf610: add second DSPI instance
Acked-by: Stefan Agner
Signed-off-by: Bhuvanchandra DV
---
arch/arm/boot/dts/vf500.dtsi | 4
arch/arm/boot/dts/vfxxx.dtsi | 11 +++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index 1dbf8d2..f5f807c 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -66,6 +66,10 @@
interrupts = ;
};
+&dspi1 {
+ interrupts = ;
+};
+
&edma0 {
interrupts = ,
;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a29c7ce..789744b 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -139,6 +139,17 @@
status = "disabled";
};
+ dspi1: dspi1@4002d000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-dspi";
+ reg = <0x4002d000 0x1000>;
+ clocks = <&clks VF610_CLK_DSPI1>;
+ clock-names = "dspi";
+ spi-num-chipselects = <5>;
+ status = "disabled";
+ };
+
sai2: sai@40031000 {
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
--
2.2.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 2/7] ARM: vf-colibri: add SPI support and enable MCP2515 CAN
MCP2515 CAN controller is available on Colibri Evaluation board.
Hence enable MCP2515 CAN.
Signed-off-by: Bhuvanchandra DV
---
arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 31 +++
arch/arm/boot/dts/vf-colibri.dtsi | 15 +++
2 files changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index 36cafbf..69364b0 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -12,6 +12,12 @@
bootargs = "console=ttyLP0,115200";
};
+ clk16m: clk16m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1600>;
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -47,6 +53,21 @@
status = "okay";
};
+&dspi1 {
+ status = "okay";
+
+ can2: mcp2515@0 {
+ compatible = "microchip,mcp2515";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can_int>;
+ reg = <0>;
+ clocks = <&clk16m>;
+ spi-max-frequency = <1000>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 GPIO_ACTIVE_LOW>;
+ };
+};
+
&esdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_esdhc1>;
@@ -94,3 +115,13 @@
&usbh1 {
vbus-supply = <&usbh_vbus_reg>;
};
+
+&iomuxc {
+ vf610-colibri {
+ pinctrl_can_int: can_int {
+ fsl,pins = <
+ VF610_PAD_PTB21__GPIO_430x22ed
+ >;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 5c2b732..fbef082 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -23,6 +23,12 @@
status = "okay";
};
+&dspi1 {
+ bus-num = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dspi1>;
+};
+
&edma0 {
status = "okay";
};
@@ -107,6 +113,15 @@
>;
};
+ pinctrl_dspi1: dspi1grp {
+ fsl,pins = <
+ VF610_PAD_PTD5__DSPI1_CS0 0x33e2
+ VF610_PAD_PTD6__DSPI1_SIN 0x33e1
+ VF610_PAD_PTD7__DSPI1_SOUT 0x33e2
+ VF610_PAD_PTD8__DSPI1_SCK 0x33e2
+ >;
+ };
+
pinctrl_esdhc1: esdhc1grp {
fsl,pins = <
VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
--
2.2.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 3/7] spi: spi-fsl-dspi: Remove usage of devm_kzalloc
devm_* API was supposed to be used only in probe function call. Memory is allocated at 'probe' and free automatically at 'remove'. Usage of devm_* functions outside probe sometimes leads to memory leak. Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead. Also add the dspi_cleanup function to free the controller data upon cleanup. [1.027945] fsl-dspi 4002d000.dspi1: registered master spi1 [1.028664] spi spi1.0: setup mode 0, 8 bits/w, 5000 Hz max --> 0 [1.028877] [ cut here ] [1.036953] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:286 driver_probe_device+0x1d8/0x244() [1.052136] Modules linked in: [1.058525] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc1-104479-g702bebc #202 [1.072777] Backtrace: [1.078437] [<80011a04>] (dump_backtrace) from [<80011ce0>] (show_stack+0x18/0x1c) [1.092393] r6:011e r5:0009 r4: r3: [1.101639] [<80011cc8>] (show_stack) from [<805a2d18>] (dump_stack+0x24/0x28) [1.115701] [<805a2cf4>] (dump_stack) from [<80021564>] (warn_slowpath_common+0x74/0x8c) [1.130905] [<800214f0>] (warn_slowpath_common) from [<80021620>] (warn_slowpath_null+0x24/0x2c) [1.147289] r8: r7:807d5dd0 r6:802e2f54 r5:8ea1a200 r4:808444d4 [1.158272] [<800215fc>] (warn_slowpath_null) from [<802e2ee8>] (driver_probe_device+0x1d8/0x244) [1.175532] [<802e2d10>] (driver_probe_device) from [<802e2f9c>] (__device_attach+0x48/0x4c) [1.192583] r8: r7:8ea4 r6:802e2f54 r5:8ea1a200 r4:807d5dd0 r3:8035a150 [1.209718] [<802e2f54>] (__device_attach) from [<802e14ac>] (bus_for_each_drv+0x60/0x94) [1.227619] r5:8ea1a200 r4: [1.236097] [<802e144c>] (bus_for_each_drv) from [<802e2cd4>] (device_attach+0x7c/0x90) [1.253809] r6:807d5cc0 r5:8ea1a234 r4:8ea1a200 [1.263442] [<802e2c58>] (device_attach) from [<802e2338>] (bus_probe_device+0x8c/0xb0) [1.281269] r6:807d5cc0 r5:8ea1a200 r4:8ea1a208 r3:8e881cc0 [1.292124] [<802e22ac>] (bus_probe_device) from [<802e06c8>] (device_add+0x448/0x528) [1.309972] r6:8ea1a200 r5: r4:8ea1a208 r3:0001 [1.320830] [<802e0280>] (device_add) from [<8035a8c8>] (spi_add_device+0x9c/0x15c) [1.338382] r9:8e8ab210 r8: r7:8e8ab210 r6: r5:8ea4 r4:8ea1a200 [1.356236] [<8035a82c>] (spi_add_device) from [<8035c0a8>] (spi_register_master+0x4d8/0x73c) [1.374695] r7:8ea1a368 r6:8ea1a200 r5:8fde7f7c r4:8ea4 [1.385537] [<8035bbd0>] (spi_register_master) from [<8035d930>] (spi_bitbang_start+0x9c/0x108) [1.404100] r10:8088 r9:8e816f80 r8:8fde7c50 r7:8e8ab210 r6:8e8ab200 r5:8ea4 [1.421967] r4:8ea4 [1.429305] [<8035d894>] (spi_bitbang_start) from [<8035e334>] (dspi_probe+0x1d4/0x2bc) [1.446821] r4:8ea40210 r3:80845a10 [1.455241] [<8035e160>] (dspi_probe) from [<802e4854>] (platform_drv_probe+0x4c/0xac) [1.472666] r10: r9:8ea1c2c0 r8: r7:807d5e20 r6:807d5e20 r5:fdfb [1.490365] r4:8e8ab210 [1.497638] [<802e4808>] (platform_drv_probe) from [<802e2e20>] (driver_probe_device+0x110/0x244) [1.516021] r7:807d5e20 r6: r5:8e8ab210 r4:808444d4 [1.526612] [<802e2d10>] (driver_probe_device) from [<802e3034>] (__driver_attach+0x94/0x98) [1.544556] r8:807735e8 r7: r6:8e8ab244 r5:807d5e20 r4:8e8ab210 r3: [1.562013] [<802e2fa0>] (__driver_attach) from [<802e13f4>] (bus_for_each_dev+0x68/0x9c) [1.579714] r6:802e2fa0 r5:807d5e20 r4: r3:8e8ad03c [1.590310] [<802e138c>] (bus_for_each_dev) from [<802e2914>] (driver_attach+0x24/0x28) [1.607804] r6:807ca840 r5:8ea25700 r4:807d5e20 [1.617252] [<802e28f0>] (driver_attach) from [<802e25bc>] (bus_add_driver+0x150/0x1f8) [1.634584] [<802e246c>] (bus_add_driver) from [<802e3670>] (driver_register+0x80/0x100) [1.652292] r7:8e842038 r6:8078e0f8 r5:807b3460 r4:807d5e20 [1.662953] [<802e35f0>] (driver_register) from [<802e4798>] (__platform_driver_register+0x5c/0x64) [1.681772] r5:807b3460 r4:807b3460 [1.690234] [<802e473c>] (__platform_driver_register) from [<8078e114>] (fsl_dspi_driver_init+0x1c/0x20) [1.709306] [<8078e0f8>] (fsl_dspi_driver_init) from [<80008770>] (do_one_initcall+0x94/0x1d4) [1.727791] [<800086dc>] (do_one_initcall) from [<80773e38>] (kernel_init_freeable+0x130/0x1d0) [1.746412] r10:8079eef0 r9:8079eee4 r8:807735e8 r7:807f1c80 r6:807f1c80 r5:0006 [1.764399] r4:807a7bc8 [1.771813] [<80773d08>] (kernel_init_freeable) from [<8059f864>] (kernel_init+0x10/0xf0) [1.789660] r10: r9: r8: r7: r6: r5:8059f854 [1.807381] r4: [1.814668] [<8059f854>] (kernel_init) from [<8000e638>] (ret_from_fork+0x14/0x3c) [1.831772] r4: r3:8e842000 [1.840212] ---[ end trace f7f1c89f62e53de9 ]--- Acked-by: Stefan Agner Signed-off-by: Bhuvanchandra DV --- drive
Re: [linux-sunxi] Re: [PATCH] arm: sunxi: input: RFC: Add sysfs voltage for sun4i-lradc driver
Hi, On 27-01-15 10:49, Priit Laes wrote: On Tue, 2015-01-27 at 10:18 +0100, Maxime Ripard wrote: Hi, On Mon, Jan 26, 2015 at 06:58:32PM +0200, Priit Laes wrote: --- Like Hans was pointing out, commit log and signed-off-by please .../ABI/testing/sysfs-driver-input-sun4i-lradc | 4 ++ drivers/input/keyboard/sun4i-lradc-keys.c | 49 +- 2 files changed, 43 insertions(+), 10 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-driver-input- sun4i-lradc diff --git a/Documentation/ABI/testing/sysfs-driver-input-sun4i- lradc b/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc new file mode 100644 index 000..e4e6448 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-input-sun4i-lradc @@ -0,0 +1,4 @@ +What: /sys/class/input/input(x)/device/voltage +Date: February 2015 +Contact: Priit Laes +Description: ADC output voltage in microvolts or 0 if device is not opened. Why is it returning 0 when "device is not opened" ? What does that even mean? You can't read that file without opening it. It means that something has to open the /dev/input/inputX device which sets up the ADC before the voltage can be read from the sysfs file. [...] As I told you already, if you're going to expose this an ADC in the end, the proper solution is to use the IIO framework, not adding a custom sysfs file. My intention was to expose just a simple debug output, so one can press the buttons and read the voltages for devicetree keymap. If anyone can suggest a simpler approach than current sysfs based one, I would do it. The android driver always uses 0.2V / 200mV steps, so what I do is simply create a mapping with 200mV mapped to KEY_VOLUMEUP, 400mV mapped to KEY_VOLUMEDOWN, etc. following the hardcoded android driver mapping: https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/input/keyboard/sun4i-keyboard.c#L136 Usually this will be correct in one go, after testing one can shuffle key codes as needed (usually not needed) and/or remove unused entries. With that said I do think that a sysfs file to see the actual voltages, or a kernel parameter to printk them on keypress interrupt would be useful. I guess the printk option would be better as it would show the actual keypress value read, not some semi-random sample. Regards, Hans -- 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] net: Linn Ethernet Packet Sniffer driver
On Mon, Jan 26, 2015 at 10:16:18AM +, Stathis Voukelatos wrote:
>
> On 23/01/15 10:51, Mark Rutland wrote:
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> > b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> > new file mode 100644
> > index 000..6b6e105
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> > @@ -0,0 +1,27 @@
> > +* Linn Products Ethernet Packet Sniffer
> > +
> > +Required properties:
> > +- compatible : must be "linn,eth-sniffer"
> > +- reg : physical addresses and sizes of registers. Must contain 3 entries:
> > + first entry: registers memory space
> > + second entry: TX command memory
> > + third entry: RX command memory
> > Just to check: are those memories are part of the packet sniffer device,
> > or are carveouts from other memory?
> Yes, the 3 memory areas are part of the packet sniffer module.
> >> +- fifo-block-words : number of words in one data FIFO entry
> >> +
> >> +Example:
> >> +
> >> +sniffer@1814a000 {
> >> +compatible = "linn,eth-sniffer";
> >> +reg = <0x1814a000 0x100>, <0x1814a400 0x400>, <0x1814a800 0x400>;
> >> +reg-names = "regs", "tx-ram", "rx-ram";
> >> +interrupts = ;
> >> +interrupt-names = "eth-sniffer-irq";
> >> +clocks = <&system_clk>;
> >> +clock-names = "sys";
> >> +fifo-block-words = <4>;
> >> +};
> > Surely the relationship between the sniffer, MAC, and PHY should be
> > described, so we know which interface the sniffer is related to?
> >
> The packet sniffer sits between the MAC and the PHY and monitors TX or RX
> packets, or both. Will add a description in the binding doc.
I understood that. However the binding does not explicitly refer to
either of those, so I don't see how you'd associate this sniffer
instance with the relevant PHY+MAC instances.
That should be made explicit in the binding.
Mark.
--
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 5/7] spi: spi-fsl-dspi: Remove spi-bitbang
From: Chao Fu
DSPI module need cs change information in
a spi transfer. According to cs change, DSPI
will give last data the right flag. Bitbang
provide cs change behind the last data in
a transfer. So DSPI can not deal the last
data in every transfer properly, so remove
the bitbang in the driver.
Signed-off-by: Bhuvanchandra DV
---
drivers/spi/Kconfig| 1 -
drivers/spi/spi-fsl-dspi.c | 144 ++---
2 files changed, 71 insertions(+), 74 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9982998..6316d6d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -292,7 +292,6 @@ config SPI_FSL_SPI
config SPI_FSL_DSPI
tristate "Freescale DSPI controller"
- select SPI_BITBANG
select REGMAP_MMIO
depends on SOC_VF610 || COMPILE_TEST
help
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 5378148..b20dbb5 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -106,7 +106,7 @@ struct chip_data {
};
struct fsl_dspi {
- struct spi_bitbang bitbang;
+ struct spi_master *master;
struct platform_device *pdev;
struct regmap *regmap;
@@ -114,6 +114,7 @@ struct fsl_dspi {
struct clk *clk;
struct spi_transfer *cur_transfer;
+ struct spi_message *cur_msg;
struct chip_data*cur_chip;
size_t len;
void*tx;
@@ -123,6 +124,7 @@ struct fsl_dspi {
chardataflags;
u8 cs;
u16 void_write_data;
+ u32 cs_change;
wait_queue_head_t waitq;
u32 waitflags;
@@ -225,6 +227,8 @@ static int dspi_transfer_write(struct fsl_dspi *dspi)
if (dspi->len == 0 || tx_count == DSPI_FIFO_SIZE - 1) {
/* last transfer in the transfer */
dspi_pushr |= SPI_PUSHR_EOQ;
+ if ((dspi->cs_change) && (!dspi->len))
+ dspi_pushr &= ~SPI_PUSHR_CONT;
} else if (tx_word && (dspi->len == 1))
dspi_pushr |= SPI_PUSHR_EOQ;
@@ -246,6 +250,7 @@ static int dspi_transfer_read(struct fsl_dspi *dspi)
int rx_count = 0;
int rx_word = is_double_byte_mode(dspi);
u16 d;
+
while ((dspi->rx < dspi->rx_end)
&& (rx_count < DSPI_FIFO_SIZE)) {
if (rx_word) {
@@ -276,64 +281,67 @@ static int dspi_transfer_read(struct fsl_dspi *dspi)
return rx_count;
}
-static int dspi_txrx_transfer(struct spi_device *spi, struct spi_transfer *t)
+static int dspi_transfer_one_message(struct spi_master *master,
+ struct spi_message *message)
{
- struct fsl_dspi *dspi = spi_master_get_devdata(spi->master);
- dspi->cur_transfer = t;
- dspi->cur_chip = spi_get_ctldata(spi);
- dspi->cs = spi->chip_select;
- dspi->void_write_data = dspi->cur_chip->void_write_data;
-
- dspi->dataflags = 0;
- dspi->tx = (void *)t->tx_buf;
- dspi->tx_end = dspi->tx + t->len;
- dspi->rx = t->rx_buf;
- dspi->rx_end = dspi->rx + t->len;
- dspi->len = t->len;
-
- if (!dspi->rx)
- dspi->dataflags |= TRAN_STATE_RX_VOID;
-
- if (!dspi->tx)
- dspi->dataflags |= TRAN_STATE_TX_VOID;
-
- regmap_write(dspi->regmap, SPI_MCR, dspi->cur_chip->mcr_val);
- regmap_write(dspi->regmap, SPI_CTAR(dspi->cs),
dspi->cur_chip->ctar_val);
- regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE);
-
- if (t->speed_hz)
+ struct fsl_dspi *dspi = spi_master_get_devdata(master);
+ struct spi_device *spi = message->spi;
+ struct spi_transfer *transfer;
+ int status = 0;
+ message->actual_length = 0;
+
+ list_for_each_entry(transfer, &message->transfers, transfer_list) {
+ dspi->cur_transfer = transfer;
+ dspi->cur_msg = message;
+ dspi->cur_chip = spi_get_ctldata(spi);
+ dspi->cs = spi->chip_select;
+ if (dspi->cur_transfer->transfer_list.next
+ == &dspi->cur_msg->transfers)
+ transfer->cs_change = 1;
+ dspi->cs_change = transfer->cs_change;
+ dspi->void_write_data = dspi->cur_chip->void_write_data;
+
+ dspi->dataflags = 0;
+ dspi->tx = (void *)transfer->tx_buf;
+ dspi->tx_end = dspi->tx + transfer->len;
+ dspi->rx = transfer->rx_buf;
+ dspi->rx_end = dspi->rx + transfer->len;
+ dspi->len = transfer->len;
+
+ if (!dspi->rx)
+ dspi->dataflags |= TRAN_STATE_RX_VOID;
+
+ if (!dspi->tx)
+
[PATCH v2] kvm: iommu: Add cond_resched to legacy device assignment code
From: Joerg Roedel When assigning devices to large memory guests (>=128GB guest memory in the failure case) the functions to create the IOMMU page-tables for the whole guest might run for a very long time. On non-preemptible kernels this might cause Soft-Lockup warnings. Fix these by adding a cond_resched() to the mapping and unmapping loops. Signed-off-by: Joerg Roedel --- arch/x86/kvm/iommu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/iommu.c b/arch/x86/kvm/iommu.c index 17b73ee..7dbced3 100644 --- a/arch/x86/kvm/iommu.c +++ b/arch/x86/kvm/iommu.c @@ -138,7 +138,7 @@ int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot) gfn += page_size >> PAGE_SHIFT; - + cond_resched(); } return 0; @@ -306,6 +306,8 @@ static void kvm_iommu_put_pages(struct kvm *kvm, kvm_unpin_pages(kvm, pfn, unmap_pages); gfn += unmap_pages; + + cond_resched(); } } -- 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 6/7] spi: spi-fsl-dspi: split the resuable code
From: Chao Fu
Add two functions:
- dspi_data_from_popr
- dspi_data_to_pushr
Signed-off-by: Bhuvanchandra DV
---
drivers/spi/spi-fsl-dspi.c | 118 +++--
1 file changed, 60 insertions(+), 58 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index b20dbb5..e0ce906 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -167,12 +167,68 @@ static void hz_to_spi_baud(char *pbr, char *br, int
speed_hz,
*br = ARRAY_SIZE(brs) - 1;
}
+static u32 dspi_data_to_pushr(struct fsl_dspi *dspi, int tx_word)
+{
+ u16 d16;
+ u8 d8;
+
+ if (tx_word) {
+ if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
+ d16 = *(u16 *)dspi->tx;
+ dspi->tx += 2;
+ } else {
+ d16 = dspi->void_write_data;
+ }
+
+ dspi->len -= 2;
+
+ return SPI_PUSHR_TXDATA(d16) |
+ SPI_PUSHR_PCS(dspi->cs) |
+ SPI_PUSHR_CTAS(dspi->cs) |
+ SPI_PUSHR_CONT;
+ } else {
+ if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
+
+ d8 = *(u8 *)dspi->tx;
+ dspi->tx++;
+ } else {
+ d8 = (u8)dspi->void_write_data;
+ }
+
+ dspi->len--;
+
+ return SPI_PUSHR_TXDATA(d8) |
+ SPI_PUSHR_PCS(dspi->cs) |
+ SPI_PUSHR_CTAS(dspi->cs) |
+ SPI_PUSHR_CONT;
+ }
+}
+
+static void dspi_data_from_popr(struct fsl_dspi *dspi, int rx_word)
+{
+ u16 d;
+ unsigned int val;
+
+ if (rx_word) {
+ regmap_read(dspi->regmap, SPI_POPR, &val);
+ d = SPI_POPR_RXDATA(val);
+
+ if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
+ *(u16 *)dspi->rx = d;
+ dspi->rx += 2;
+ } else {
+ regmap_read(dspi->regmap, SPI_POPR, &val);
+ d = SPI_POPR_RXDATA(val);
+ if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
+ *(u8 *)dspi->rx = d;
+ dspi->rx++;
+ }
+}
+
static int dspi_transfer_write(struct fsl_dspi *dspi)
{
int tx_count = 0;
int tx_word;
- u16 d16;
- u8 d8;
u32 dspi_pushr = 0;
int first = 1;
@@ -190,39 +246,7 @@ static int dspi_transfer_write(struct fsl_dspi *dspi)
}
while (dspi->len && (tx_count < DSPI_FIFO_SIZE)) {
- if (tx_word) {
- if (dspi->len == 1)
- break;
-
- if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
- d16 = *(u16 *)dspi->tx;
- dspi->tx += 2;
- } else {
- d16 = dspi->void_write_data;
- }
-
- dspi_pushr = SPI_PUSHR_TXDATA(d16) |
- SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(dspi->cs) |
- SPI_PUSHR_CONT;
-
- dspi->len -= 2;
- } else {
- if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
-
- d8 = *(u8 *)dspi->tx;
- dspi->tx++;
- } else {
- d8 = (u8)dspi->void_write_data;
- }
-
- dspi_pushr = SPI_PUSHR_TXDATA(d8) |
- SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(dspi->cs) |
- SPI_PUSHR_CONT;
-
- dspi->len--;
- }
+ dspi_pushr = dspi_data_to_pushr(dspi, tx_word);
if (dspi->len == 0 || tx_count == DSPI_FIFO_SIZE - 1) {
/* last transfer in the transfer */
@@ -249,32 +273,10 @@ static int dspi_transfer_read(struct fsl_dspi *dspi)
{
int rx_count = 0;
int rx_word = is_double_byte_mode(dspi);
- u16 d;
while ((dspi->rx < dspi->rx_end)
&& (rx_count < DSPI_FIFO_SIZE)) {
- if (rx_word) {
- unsigned int val;
-
- if ((dspi->rx_end - dspi->rx) == 1)
- break;
-
- regmap_read(dspi->regmap, SPI_POPR, &val);
- d = SPI_POPR_RXDATA(val);
-
- if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
- *(u16 *)dspi->rx = d;
- dspi->rx += 2;
-
- } else {
- unsigned int val;
-
- regmap_read(dspi->regmap, SPI_POPR, &val);
- d = SPI_POPR
[PATCH 7/7] spi: spi-fsl-dspi: Add support for TCFQ transfer mode
From: Chao Fu
TCFQ is interrupt of Transfer Complete Flag in DSPI module.
EOQ is interrupt of End of Queue Flag in DSPI module.
For adopting of different platform, either of them is a way of DSPI
transfer data. This patch add TCF support for DSPI module in other platform.
Signed-off-by: Bhuvanchandra DV
---
.../devicetree/bindings/spi/spi-fsl-dspi.txt | 2 +
drivers/spi/spi-fsl-dspi.c | 74 +++---
2 files changed, 68 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index cbbe16e..b50439f 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -15,6 +15,8 @@ Optional property:
- big-endian: If present the dspi device's registers are implemented
in big endian mode, otherwise in native mode(same with CPU), for more
detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
+- tcfq-mode: If present, the data transfer will be done at TCFQ interrupt.
+ By default, driver chooses EOQ interrupt if 'tcfq-mode' property was not set.
Example:
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index e0ce906..feca2fd 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -63,9 +63,11 @@
#define SPI_CTAR0_SLAVE0x0c
#define SPI_SR 0x2c
+#define SPI_SR_TCFQF 0x8000
#define SPI_SR_EOQF0x1000
#define SPI_RSER 0x30
+#define SPI_RSER_TCFQE 0x8000
#define SPI_RSER_EOQFE 0x1000
#define SPI_PUSHR 0x34
@@ -105,6 +107,12 @@ struct chip_data {
u16 void_write_data;
};
+enum dspi_trans_mode {
+ DSPI_EOQ_MODE = 0,
+ DSPI_TCFQ_MODE,
+ DSPI_DMA_MODE, /*TODO*/
+};
+
struct fsl_dspi {
struct spi_master *master;
struct platform_device *pdev;
@@ -125,6 +133,7 @@ struct fsl_dspi {
u8 cs;
u16 void_write_data;
u32 cs_change;
+ enum dspi_trans_modetrans_mode;
wait_queue_head_t waitq;
u32 waitflags;
@@ -225,7 +234,7 @@ static void dspi_data_from_popr(struct fsl_dspi *dspi, int
rx_word)
}
}
-static int dspi_transfer_write(struct fsl_dspi *dspi)
+static int dspi_eoq_write(struct fsl_dspi *dspi)
{
int tx_count = 0;
int tx_word;
@@ -269,7 +278,7 @@ static int dspi_transfer_write(struct fsl_dspi *dspi)
return tx_count * (tx_word + 1);
}
-static int dspi_transfer_read(struct fsl_dspi *dspi)
+static int dspi_eoq_read(struct fsl_dspi *dspi)
{
int rx_count = 0;
int rx_word = is_double_byte_mode(dspi);
@@ -283,6 +292,37 @@ static int dspi_transfer_read(struct fsl_dspi *dspi)
return rx_count;
}
+static int dspi_tcfq_write(struct fsl_dspi *dspi)
+{
+ int tx_word;
+ u32 dspi_pushr = 0;
+
+ tx_word = is_double_byte_mode(dspi);
+
+ if (tx_word && (dspi->len == 1)) {
+ dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM;
+ regmap_update_bits(dspi->regmap, SPI_CTAR(dspi->cs),
+ SPI_FRAME_BITS_MASK, SPI_FRAME_BITS(8));
+ tx_word = 0;
+ }
+
+ dspi_pushr = dspi_data_to_pushr(dspi, tx_word);
+
+ if ((dspi->cs_change) && (!dspi->len))
+ dspi_pushr &= ~SPI_PUSHR_CONT;
+
+ regmap_write(dspi->regmap, SPI_PUSHR, dspi_pushr);
+
+ return tx_word + 1;
+}
+
+static void dspi_tcfq_read(struct fsl_dspi *dspi)
+{
+ int rx_word = is_double_byte_mode(dspi);
+
+ dspi_data_from_popr(dspi, rx_word);
+}
+
static int dspi_transfer_one_message(struct spi_master *master,
struct spi_message *message)
{
@@ -326,8 +366,13 @@ static int dspi_transfer_one_message(struct spi_master
*master,
regmap_write(dspi->regmap, SPI_CTAR(dspi->cs),
dspi->cur_chip->ctar_val);
- regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE);
- message->actual_length += dspi_transfer_write(dspi);
+ if (dspi->trans_mode == DSPI_EOQ_MODE) {
+ regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE);
+ message->actual_length += dspi_eoq_write(dspi);
+ } else if (dspi->trans_mode == DSPI_TCFQ_MODE) {
+ regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_TCFQE);
+ message->actual_length += dspi_tcfq_write(dspi);
+ }
if (wait_event_interruptible(dspi->waitq, dspi->waitflags))
dev_err(&dspi->pdev->dev, "wait transfer complete
fail!\n");
@@ -399,8 +444,13 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
struct spi_message *msg
Re: [PATCH 2/2] HID: i2c-hid: Add support for GPIO interrupts
On Tue, Jan 27, 2015 at 10:39:25AM +, Mark Rutland wrote:
> > If the above is not the right way to use GPIOs as interrupt, can you
> > please tell me how it is done then?
>
>
> So lets say we have a device which generates an interrupt:
>
> device@f00 {
> compatible = "some-interrupting-device";
> reg = <0xf00 0x100>;
> interrupts = < ... >;
> };
>
> It's intended that this is connected to an interrupt controller:
>
> ic: interrupt-controller@b00 {
> compatible = "some-interrupt-controller";
> reg = <0xb00 0x100>;
> #interrupt-cells = <1>;
> };
>
> device@f00 {
> compatible = "some-interrupting-device";
> reg = <0xf00 0x100>;
> interrupt-parent = <&ic>;
> interrupts = <0x3>;
> };
>
> But in some cases, this gets connected to a GPIO controller. In these
> cases, the device is still logically generating an interrupt, and the
> fact that the endpoint is an interrupt controller is irrelevant from the
> PoV of the device. So we acknowledge that the GPIO controller is also
> capable of acting as an interrupt controller, and mark it as such:
>
> gc: gpio-controller@000 {
> compatible = "some-gpio-controller";
> reg = <0x000 0x100>;
> #gpio-cells = <1>;
> #interrupt-cells = <1>;
> };
>
> device@f00 {
> compatible = "some-interrupting-device";
> reg = <0xf00 0x100>;
> interrupt-parent = <&gc>;
> interrupts = <0x1>;
> };
>
> Thus the device binding only describes the logical interrupt, and the
> driver only needs to handle interrupts.
OK.
> In cases where the binding/driver actually care about the GPIO being a
> GPIO (e.g. for card detect in an MMC controller), describing the GPIO as
> a GPIO makes sense, and we can try gpio_to_irq as an optimisation over
> polling the state of the GPIO.
Well, I've seen touch panels where you actually need to switch the GPIO
to be output and do some magic before you can use the same GPIO as an
interrupt.
> > BTW, passing NULL to gpiod_get() implies property named "gpios" in DT
> > (which is why I added it to the documentation).
>
> Sure. My concern is that we should not need to deal with GPIOs in this
> case were the GPIO is only there to function as an interrupt.
>
> Given that GpioInt seems to describe an interrupt which happens to be
> backed by a GPIO, I don't understand what it is necessary to translate
> this as a GPIO rather than an interrupt. If it were going to be used as
> a GPIO, then it would be a GpioIO object, no?
OK, so where do you propose we handle the translation if not in the
driver? Also keep in mind that some of the devices may have multiple
GpioInt()s.
--
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] tpm: fix suspend/resume paths for TPM 2.0
Fixed suspend/resume paths for TPM 2.0 and consolidated all the
associated code to the tpm_pm_suspend() and tpm_pm_resume()
functions. Resume path should be handled by the firmware, i.e.
Startup(CLEAR) for hibernate and Startup(STATE) for suspend.
There might be some non-PC embedded devices in the future where
Startup() is not the handled by the FW but fixing the code for
those IMHO should be postponed until there is hardware available
to test the fixes although extra Startup in the driver code is
essentially a NOP.
Reported-by: Peter Hüwe
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 10 --
drivers/char/tpm/tpm_crb.c | 16 +---
drivers/char/tpm/tpm_tis.c | 22 ++
3 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index bf53a37..93c8b90fd 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -901,8 +901,13 @@ int tpm_pm_suspend(struct device *dev)
if (chip == NULL)
return -ENODEV;
- if (chip->flags & TPM_CHIP_FLAG_TPM2)
- return tpm2_shutdown(chip, TPM2_SU_CLEAR);
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ rc = tpm2_shutdown(chip, TPM2_SU_STATE);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+ }
/* for buggy tpm, flush pcrs with extend to selected dummy */
if (tpm_suspend_pcr) {
@@ -952,6 +957,7 @@ EXPORT_SYMBOL_GPL(tpm_pm_suspend);
int tpm_pm_resume(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
+ int ret;
if (chip == NULL)
return -ENODEV;
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 3dd23cf..3e080f5 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -95,21 +95,7 @@ struct crb_priv {
u8 __iomem *rsp;
};
-#ifdef CONFIG_PM_SLEEP
-static int crb_resume(struct device *dev)
-{
- int rc;
- struct tpm_chip *chip = dev_get_drvdata(dev);
-
- rc = tpm2_shutdown(chip, TPM2_SU_STATE);
- if (!rc)
- rc = tpm2_do_selftest(chip);
-
- return rc;
-}
-#endif
-
-static SIMPLE_DEV_PM_OPS(crb_pm, tpm_pm_suspend, crb_resume);
+static SIMPLE_DEV_PM_OPS(crb_pm, tpm_pm_suspend, tpm_pm_resume);
static u8 crb_status(struct tpm_chip *chip)
{
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 6725bef..c105eb7 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -865,25 +865,23 @@ static void tpm_tis_reenable_interrupts(struct tpm_chip
*chip)
static int tpm_tis_resume(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
- int ret = 0;
+ int ret;
if (chip->vendor.irq)
tpm_tis_reenable_interrupts(chip);
- if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- /* NOP if firmware properly does this. */
- tpm2_startup(chip, TPM2_SU_STATE);
+ ret = tpm_pm_resume(dev);
+ if (ret)
+ return ret;
- ret = tpm2_shutdown(chip, TPM2_SU_STATE);
- if (!ret)
- ret = tpm2_do_selftest(chip);
- } else {
- ret = tpm_pm_resume(dev);
- if (!ret)
- tpm_do_selftest(chip);
+ /* TPM 1.2 requires self-test on resume. */
+ if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
+ ret = tpm_do_selftest(chip);
+ if (ret < 0)
+ return ret;
}
- return ret;
+ return 0;
}
#endif
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOM at low page cache?
CC linux-mm in case somebody has a good answer but missed this in lkml traffic On 01/23/2015 11:18 PM, John Moser wrote: > Why is there no tunable to OOM at low page cache? > > I have no swap configured. I have 16GB RAM. If Chrome or Gimp or some > other stupid program goes off the deep end and eats up my RAM, I hit > some 15.5GB or 15.75GB usage and stay there for about 40 minutes. Every > time the program tries to do something to eat more RAM, it cranks disk > hard; the disk starts thrashing, the mouse pointer stops moving, and > nothing goes on. It's like swapping like crazy, except you're reading > library files instead of paged anonymous RAM. > > If only I could tell the system to OOM kill at 512MB or 1GB or 95% > non-evictable RAM, it would recover on its own. As-is, I need to wait > or trigger the OOM killer by sysrq. > > Am I just the only person in the world who's ever had that problem? Or > is it a matter of questions fast popping up when you try to do this > *and* enable paging to disk? (In my experience, that's a matter of too > much swap space: if you have 16GB RAM and your computer dies at 15.25GB > usage, your swap space should be no larger than 750MB plus inactive > working RAM; obviously, your computer can't handle paging 750MB back and > forth. If you make it 8GB wide and you start swap thrashing at 2GB > usage, you have too much swap available). > > I guess you could try to detect excessive swap and page cache thrashing, > but that's complex; if anyone really wanted to do that, it would be done > by now. A low-barrier OOM is much simpler. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] usb: dwc3: add ULPI interface support
> look at your patch again. In case DWC3_ULPI isn't enabled, this file > won't be linked at all. You're using stubs, so taht's fine. > > In case it _is_ enabled, you're breaking out early if you can't register > ulpi interface, meaning you're exitting probe() (which, in fact, seems > wrong as I want to be able to run dwc3 with ULPI enabled on a platform > that was configured with ULPI+UTMI, but uses UTMI PHY). > > I still think this patch won't work in all cases. OK. So in case of ULPI+UTMI we'll try the ulpi interface, and if it fails, fall back to UTMI. Or can we use some other method to determine to which interface the PHY is really attached to in that case? Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] Add SPI support for Colibri modules and DSPI driver fixes
- Add second dspi instance. - Enable MCP2515 CAN controller which is avaialble on Colibri evaluation board. - Respin the stalled patches of dspi fixes. Previous discussion at: http://comments.gmane.org/gmane.linux.ports.arm.kernel/359542 Bhuvanchandra DV (4): ARM: vf610: add second DSPI instance ARM: vf-colibri: add SPI support and enable MCP2515 CAN spi: spi-fsl-dspi: Remove usage of devm_kalloc spi: spi-fsl-dspi: avoid preparing the clocks two times Chao Fu (3): spi: spi-fsl-dspi: Remove spi-bitbang spi: spi-fsl-dspi: split the resuable code spi: spi-fsl-dspi: Add support for TCFQ transfer mode .../devicetree/bindings/spi/spi-fsl-dspi.txt | 2 + arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 31 ++ arch/arm/boot/dts/vf-colibri.dtsi | 15 + arch/arm/boot/dts/vf500.dtsi | 4 + arch/arm/boot/dts/vfxxx.dtsi | 11 + drivers/spi/Kconfig| 1 - drivers/spi/spi-fsl-dspi.c | 314 + 7 files changed, 254 insertions(+), 124 deletions(-) -- 2.2.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: [PATCH v4 6/6] arm: dma-mapping: updates to limit dma_mask and iommu mapping size
Hi Murali,
On 23/01/15 22:32, Murali Karicheri wrote:
Limit the dma_mask to minimum of dma_mask and dma_base + size - 1.
Also arm_iommu_create_mapping() has size parameter of size_t and
arm_setup_iommu_dma_ops() can take a value higher than that. So
limit the size to SIZE_MAX.
Signed-off-by: Murali Karicheri
---
arch/arm/mm/dma-mapping.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7864797..a1f9030 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2004,6 +2004,13 @@ static bool arm_setup_iommu_dma_ops(struct device *dev,
u64 dma_base, u64 size,
if (!iommu)
return false;
+ /*
+* currently arm_iommu_create_mapping() takes a max of size_t
+* for size param. So check this limit for now.
+*/
+ if (size > SIZE_MAX)
+ return false;
+
mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
if (IS_ERR(mapping)) {
pr_warn("Failed to create %llu-byte IOMMU mapping for device
%s\n",
@@ -2053,6 +2060,9 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
{
struct dma_map_ops *dma_ops;
+ /* limit dma_mask to the lower of the two values */
+ *dev->dma_mask = min((*dev->dma_mask), (dma_base + size - 1));
+
Is there any reason not to do this in of_dma_configure? It seems like
something everyone could benefit from - I'd cooked up a dodgy workaround
for the same issue in my arm64 IOMMU code, but handling it generically
in common code would be much nicer.
Robin.
dev->archdata.dma_coherent = coherent;
if (arm_setup_iommu_dma_ops(dev, dma_base, size, iommu))
dma_ops = arm_get_iommu_dma_map_ops(coherent);
--
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/
