Re: [PATCH] x86/asm/entry/64: pack interrupt dispatch table tighter
* H. Peter Anvin wrote: > On 04/03/2015 11:37 AM, Linus Torvalds wrote: > > On Fri, Apr 3, 2015 at 11:35 AM, H. Peter Anvin wrote: > >> > >> For the record, I actually measured the impact of the jump-to-jump when > >> I wrote it. It has a small, *but measurable*, positive impact. > > > > What did you compare against, and how did you measure that? I don't > > see how it could *possibly* be faster than just a simple aligned "push > > + jmp". > > > > I wish I remembered the exact details; it took a fair bit of gathering > numbers as the spread was quite a bit wider than the delta, but in the > end there were two distribution peaks clearly offset. > > I seem to remember it involving a loop running RDTSC continuously and > another RDTSC in the interrupt path. So the thing is, while I don't know how you've loaded the machine, if user-space is doing nothing but looping in RDTSC, the kernel I$ might become cache hot easily not just in L2 but in L1 cache as well. But 'when the machine is not doing anything' is not what we optimize for, we (try to) optimize for the case when there's a lot of work going on and the async context (irq, fault, etc.) I$ is likely cache-cold. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 8:32 PM, Peter Hurley wrote:
> On 04/03/2015 11:24 PM, Yinghai Lu wrote:
>> On Fri, Apr 3, 2015 at 8:15 PM, Peter Hurley
>> wrote:
>>> On 04/03/2015 11:09 PM, Yinghai Lu wrote:
On Fri, Apr 3, 2015 at 7:19 PM, Yinghai Lu wrote:
> On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley
> wrote:
>> Restore undocumented behavior of kernel command line parameters of
>> the forms:
>> console=uart[8250],io|mmio|mmio32,[,options]
>> console=uart[8250],[,options]
>> where 'options' have not been specified; in this case, the hardware
>> is assumed to be initialized.
>
>
> This patch fix regression for the hand over. Thanks.
Just now noticed, this patch only fix partial problem. Kernel console is
ok.
But later initrd/init scripts revert back to 9600 again.
>>>
I updated my fix a little bit. please check attached.
Thanks
Yinghai
Subject: [PATCH -v2] earlycon: Fix earlycon/console handover without options
commit c7cef0a84912 ("console: Add extensible console matching")
broke the earlycon/handover when booting
console=uart8250,io,0x3f8
the bootloader is using 115200, and the earlycon continue
use 115200, but console revert back to 9600.
Before the commit, probed baud rate is passed via console_cmdline
from earlycon to normal console.
That commit remove that and only check boot command line.
This patch use port match to get hold earlycon, and use earlycon
device options to update options for console.
Fixes: commit c7cef0a84912 ("console: Add extensible console matching")
Signed-off-by: Yinghai Lu
---
-v2: simplify serial8250_get_earlycon_options and don't update
console_cmdline.
---
drivers/tty/serial/8250/8250_core.c |4
drivers/tty/serial/8250/8250_early.c | 17 +
include/linux/serial_8250.h |1 +
3 files changed, 22 insertions(+)
Index: linux-2.6/drivers/tty/serial/8250/8250_core.c
===
--- linux-2.6.orig/drivers/tty/serial/8250/8250_core.c
+++ linux-2.6/drivers/tty/serial/8250/8250_core.c
@@ -3491,6 +3491,10 @@ static int univ8250_console_match(struct
continue;
co->index = i;
+
+ if (!options)
+ options = serial8250_get_earlycon_options(port);
+
return univ8250_console_setup(co, options);
}
Index: linux-2.6/drivers/tty/serial/8250/8250_early.c
===
--- linux-2.6.orig/drivers/tty/serial/8250/8250_early.c
+++ linux-2.6/drivers/tty/serial/8250/8250_early.c
@@ -105,6 +105,22 @@ static void __init early_serial8250_writ
serial8250_early_out(port, UART_IER, ier);
}
+static struct earlycon_device *early_device;
+
+char *serial8250_get_earlycon_options(struct uart_port *up)
+{
+ struct earlycon_device *device = early_device;
+ struct uart_port *port = device ? &device->port : NULL;
+
+ if (!port || (!port->membase && !port->iobase))
+ return NULL;
+
+ if (!uart_match_port(up, port))
+ return NULL;
+
+ return device->options;
+}
+
static unsigned int __init probe_baud(struct uart_port *port)
{
unsigned char lcr, dll, dlm;
@@ -161,6 +177,7 @@ static int __init early_serial8250_setup
} else
init_port(device);
+ early_device = device;
device->con->write = early_serial8250_write;
return 0;
}
Index: linux-2.6/include/linux/serial_8250.h
===
--- linux-2.6.orig/include/linux/serial_8250.h
+++ linux-2.6/include/linux/serial_8250.h
@@ -135,6 +135,7 @@ void serial8250_resume_port(int line);
extern int early_serial_setup(struct uart_port *port);
+extern char *serial8250_get_earlycon_options(struct uart_port *up);
extern unsigned int serial8250_early_in(struct uart_port *port, int offset);
extern void serial8250_early_out(struct uart_port *port, int offset, int value);
extern void serial8250_do_set_termios(struct uart_port *port,
Re: [PATCH 0/3] block: loop: switch to VFS ITER_BVEC
On Wed, Mar 25, 2015 at 04:27:48PM +0100, Christoph Hellwig wrote: > On Wed, Mar 25, 2015 at 03:23:48PM +0800, Ming Lei wrote: > > > - mm_segment_t old_fs = get_fs(); > > > + > > > + iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len); > > > > > > file_start_write(file); > > > - set_fs(get_ds()); > > > - bw = file->f_op->write(file, buf, len, &pos); > > > - set_fs(old_fs); > > > + bw = vfs_iter_write(file, &i, ppos); > > > > This patch moves to support ->read_iter/->write_iter only, which > > might cause regression for backing file without defining read/write > > iter callback. > > ->read_iter/->write_iter is the main fs I/O path - by the time this is > ready ->aio_read/->aio_write should be gone. So they are. Folks, could you base /dev/loop stuff on current vfs.git#for-next? And yes, everything that might serve as backing file for /dev/loop has ->write_iter() now. -- 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] nohz: make nohz_full imply isolcpus
On Sat, 2015-04-04 at 04:03 +0200, Mike Galbraith wrote:
> On Fri, 2015-04-03 at 15:21 -0400, Chris Metcalf wrote:
> > On 04/03/2015 02:08 PM, Mike Galbraith wrote:
> > > On Fri, 2015-04-03 at 12:24 -0400, cmetcalf@ezchip.comwrote:
> > > > From: Chris Metcalf
> > > >
> > > > It's not clear that nohz_full is useful without isolcpus also
> > > > set, since otherwise the scheduler has to run periodically to
> > > > try to determine whether to steal work from other cores.
> > > >
> > > > Signed-off-by: Chris Metcalf
> > > Ack! nohz_full= as currently defined makes zero sense when the
> > > cpu
> > > set (which should be spelled cpuset) remains connected to the
> > > scheduler. Perturbation of tasks to PREVENT cpu domination is
> > > what
> > > the scheduler does for a living. Sprinkling microsecond savers
> > > all
> > > over the kernel is pretty silly if you don't shut down the
> > > mother
> > > lode
> > > of perturbation.
> >
> > Sounds like a thumbs up for this patch, then? :-)
>
> Yup. The other thumb turns in the up direction when folks start
> spelling cpuset properly ;-) Static isolcpus was supposed to go
> away.
Speaking of microsecond savers, the (ick) deferment experiment below
cut 60 core jitter in half. Shooting the clocksource watchdog fixes
alternating ~15us/~5us tick on my desktop box.
With workqueue twiddles and whatnot floating around, the thing is
starting to look viable.
---
kernel/sched/core.c |5 +++--
kernel/time/clocksource.c |5 +
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2604,12 +2604,13 @@ u64 scheduler_tick_max_deferment(void)
struct rq *rq = this_rq();
unsigned long next, now = ACCESS_ONCE(jiffies);
- next = rq->last_sched_tick + HZ;
+ next = (rq->last_sched_tick + HZ) | (rq->clock & 0x3f);
if (time_before_eq(next, now))
return 0;
- return jiffies_to_nsecs(next - now);
+ /* Add noise to avoid CPUs colliding at tick boundaries */
+ return jiffies_to_nsecs(next - now) | (rq->clock & 0xf);
}
#endif
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -267,8 +267,13 @@ static void clocksource_watchdog(unsigne
* to each other.
*/
next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);
+skip_nohz_full:
if (next_cpu >= nr_cpu_ids)
next_cpu = cpumask_first(cpu_online_mask);
+ if (next_cpu && tick_nohz_full_cpu(next_cpu)) {
+ next_cpu = cpumask_next(next_cpu, cpu_online_mask);
+ goto skip_nohz_full;
+ }
watchdog_timer.expires += WATCHDOG_INTERVAL;
add_timer_on(&watchdog_timer, next_cpu);
out:
--
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] PCI: Introduce pci_bus_addr_t
On Fri, Apr 3, 2015 at 11:59 AM, Bjorn Helgaas wrote:
> On Tue, Mar 31, 2015 at 07:57:47PM -0700, Yinghai Lu wrote:
>> David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
>> to fit in upstream windows") broke booting on sparc/T5-8.
>>
>> In the boot log, there is
>> pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
>> 0x110204000)
>> but that only could happen when dma_addr_t is 32-bit.
>>
>> According to David Miller, all DMA occurs behind an IOMMU and these
>> IOMMUs only support 32-bit addressing, therefore dma_addr_t is
>> 32-bit on sparc64.
>>
>> Let's introduce pci_bus_addr_t instead of using dma_addr_t,
>> and pci_bus_addr_t will be 64-bit on 64-bit platform or X86_PAE.
>
> I propose the following doc updates (I can just fold them into this patch
> if you approve):
>
>
> commit 13fca18e2f1d9dd078b8dfea965718cf13a4b600
> Author: Bjorn Helgaas
> Date: Fri Apr 3 12:39:35 2015 -0500
>
> pci-bus-addr-fixups
>
> diff --git a/include/linux/types.h b/include/linux/types.h
> index 6747247e3f9f..00a127e89752 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -139,12 +139,20 @@ typedef unsigned long blkcnt_t;
> */
> #define pgoff_t unsigned long
>
> -/* A dma_addr_t can hold any valid DMA or bus address for the platform */
> +/*
> + * A dma_addr_t can hold any valid DMA address, i.e., any address returned
> + * by the DMA API.
> + *
> + * If the DMA API only uses 32-bit addresses, dma_addr_t need only be 32
> + * bits wide. Bus addresses, e.g., PCI BARs, may be wider than 32 bits,
> + * but drivers do memory-mapped I/O to ioremapped kernel virtual addresses,
> + * so they don't care about the size of the actual bus addresses.
> + */
Good to me.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On 04/03/2015 11:37 PM, Yinghai Lu wrote: > What is NVM here? nvm == nevermind -- 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/5] vfs: Non-blockling buffered fs read (page cache only)
On Mon, 30 Mar 2015 13:26:25 -0700 Andrew Morton
wrote:
> d) fincore() is more expensive
Actually, I kinda take that back. fincore() will be faster than
preadv2() in the case of a pagecache miss, and slower in the case of a
pagecache hit.
The breakpoint appears to be a hit rate of 30% - if fewer than 30% of
queries find the page in pagecache, fincore() will be faster than
preadv2().
This is because for a pagecache miss, fincore() will be about twice as
fast as preadv2(). For a pagecache hit, fincore()+pread() is 55%
slower than preadv2(). If there are lots of misses, fincore() is
faster overall.
Minimal fincore() implementation is below. It doesn't implement the
page_map!=NULL mode at all and will be slow for large areas - it needs
to be taught about radix_tree_for_each_*(). But it's good enough for
testing.
On a slow machine, in nanoseconds:
null syscall: 528
fincore (miss): 674
fincore (hit): 729
single byte pread: 1026
single byte preadv: 1134
pread() is a bit faster than preadv() and samba uses pread(), so the
implementations are:
if (fincore(fd, NULL, offset, len) == len)
pread();
else
punt();
if (preadv2(fd, ..., offset, len) == len)
...
else
punt();
fincore+pread, pagecache-hit: 1755ns
fincore+pread, pagecache-miss: 674ns
preadv(): 1134ns (preadv2() will be a little faster for
misses)
Now, a pagecache hit rate of 30% sounds high so one would think that
fincore+pread is clearly ahead. But the pagecache hit rate in this
code will actually be quite high, because of readahead.
For a large linear read of a file which is perfectly laid out on disk
and is fully *uncached*, the hit rates will be as good as 99.8%,
because readahead is bringing in data in 2MB blobs.
In practice I expect that fincore()+pread() will be slower for linear
reads of medium to large files and faster for small files and seeky
accesses.
How much does all this matter? Not much. On a fast machine a
single-byte pread() takes 240ns. So if your server thread is handling
25000 requests/sec, we're only talking 0.6% overhead.
Note that we can trivially monitor the hit rate with either preadv2()
or fincore()+pread(): just count how many times all the data is there
versus how many times it isn't.
Also, note that we can use *both* fincore() and preadv2() to detect the
problematic page-just-disappeared race:
if (fincore(fd, NULL, offset, len) == len) {
if (preadv2(fd, offset, len) != len)
printf("race just happened");
It would be great if someone could apply the below, modify the
preadv2() callsite as above and determine under what conditions (if
any) the page-stealing race occurs.
arch/x86/syscalls/syscall_64.tbl |1
include/linux/syscalls.h |2
mm/Makefile |2
mm/fincore.c | 65 +
4 files changed, 69 insertions(+), 1 deletion(-)
diff -puN arch/x86/syscalls/syscall_64.tbl~fincore
arch/x86/syscalls/syscall_64.tbl
--- a/arch/x86/syscalls/syscall_64.tbl~fincore
+++ a/arch/x86/syscalls/syscall_64.tbl
@@ -331,6 +331,7 @@
32264 execveatstub_execveat
32364 preadv2 sys_preadv2
32464 pwritev2sys_pwritev2
+325common fincore sys_fincore
#
# x32-specific system call numbers start at 512 to avoid cache impact
diff -puN include/linux/syscalls.h~fincore include/linux/syscalls.h
--- a/include/linux/syscalls.h~fincore
+++ a/include/linux/syscalls.h
@@ -880,6 +880,8 @@ asmlinkage long sys_process_vm_writev(pi
asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
unsigned long idx1, unsigned long idx2);
asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags);
+asmlinkage long sys_fincore(int fd, unsigned char __user *page_map,
+ loff_t offset, size_t len);
asmlinkage long sys_seccomp(unsigned int op, unsigned int flags,
const char __user *uargs);
asmlinkage long sys_getrandom(char __user *buf, size_t count,
diff -puN mm/Makefile~fincore mm/Makefile
--- a/mm/Makefile~fincore
+++ a/mm/Makefile
@@ -19,7 +19,7 @@ obj-y := filemap.o mempool.o oom_kill.
readahead.o swap.o truncate.o vmscan.o shmem.o \
util.o mmzone.o vmstat.o backing-dev.o \
mm_init.o mmu_context.o percpu.o slab_common.o \
- compaction.o vmacache.o \
+ compaction.o vmacache.o fincore.o \
interval_tree.o list_lru.o workingset.o \
debug.o $(mmu-y)
diff -puN /dev/null mm/fincore.c
--- /dev/null
+++ a/mm/fincore.c
@@ -0,0 +1,65 @@
+#include
+#include
+#includ
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 8:32 PM, Peter Hurley wrote: Just now noticed, this patch only fix partial problem. Kernel console is ok. But later initrd/init scripts revert back to 9600 again. >>> >>> Please share the init scripts. >> >> I am using opensuse 13.1 rescue disk as ramdisk. > > NVM, I know what the problem is. > What is NVM here? -- 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] PCI: Introduce pci_bus_addr_t
On Fri, Apr 3, 2015 at 1:52 PM, Bjorn Helgaas wrote:
> [+cc Sam (commented on previous versions), Russell, linux-arm-kernel, Ralf,
> linux-mips, Ben, linuxppc-dev, x86]
>
> On Fri, Apr 03, 2015 at 02:32:34PM -0500, Bjorn Helgaas wrote:
>> On Tue, Mar 31, 2015 at 07:57:47PM -0700, Yinghai Lu wrote:
>> > David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
>> > to fit in upstream windows") broke booting on sparc/T5-8.
>> >
>> > In the boot log, there is
>> > pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
>> > 0x110204000)
>> > but that only could happen when dma_addr_t is 32-bit.
>> >
>> > According to David Miller, all DMA occurs behind an IOMMU and these
>> > IOMMUs only support 32-bit addressing, therefore dma_addr_t is
>> > 32-bit on sparc64.
>> >
>> > Let's introduce pci_bus_addr_t instead of using dma_addr_t,
>> > and pci_bus_addr_t will be 64-bit on 64-bit platform or X86_PAE.
>> >
>> > Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in
>> > upstream windows")
>> > Fixes: commit 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs
>> > larger than 4GB")
>> > Link:
>> > http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
>> > Reported-by: David Ahern
>> > Tested-by: David Ahern
>> > Signed-off-by: Yinghai Lu
>> > Cc: #3.19
>> > ---
>> > drivers/pci/Kconfig | 4
>> > drivers/pci/bus.c | 10 +-
>> > drivers/pci/probe.c | 12 ++--
>> > include/linux/pci.h | 12 +---
>> > 4 files changed, 24 insertions(+), 14 deletions(-)
>> >
>> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> > index 7a8f1c5..6a5a269 100644
>> > --- a/drivers/pci/Kconfig
>> > +++ b/drivers/pci/Kconfig
>> > @@ -1,6 +1,10 @@
>> > #
>> > # PCI configuration
>> > #
>> > +config PCI_BUS_ADDR_T_64BIT
>> > + def_bool y if (64BIT || X86_PAE)
>> > + depends on PCI
>>
>> We're going to use pci_bus_addr_t in some places where we previously used
>> dma_addr_t, which means pci_bus_addr_t should be at least as large as
>> dma_addr_t. Can you enforce that directly, e.g., with something like this?
>>
>> def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT || X86_PAE)
then should use
def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On 04/03/2015 11:24 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 8:15 PM, Peter Hurley wrote: >> On 04/03/2015 11:09 PM, Yinghai Lu wrote: >>> On Fri, Apr 3, 2015 at 7:19 PM, Yinghai Lu wrote: On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley wrote: > Restore undocumented behavior of kernel command line parameters of > the forms: > console=uart[8250],io|mmio|mmio32,[,options] > console=uart[8250],[,options] > where 'options' have not been specified; in this case, the hardware > is assumed to be initialized. This patch fix regression for the hand over. Thanks. >>> >>> Just now noticed, this patch only fix partial problem. Kernel console is ok. >>> >>> But later initrd/init scripts revert back to 9600 again. >> >> Please share the init scripts. > > I am using opensuse 13.1 rescue disk as ramdisk. NVM, I know what the problem is. -- 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] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 8:24 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 8:15 PM, Peter Hurley wrote: >> On 04/03/2015 11:09 PM, Yinghai Lu wrote: >>> On Fri, Apr 3, 2015 at 7:19 PM, Yinghai Lu wrote: On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley wrote: > Restore undocumented behavior of kernel command line parameters of > the forms: > console=uart[8250],io|mmio|mmio32,[,options] > console=uart[8250],[,options] > where 'options' have not been specified; in this case, the hardware > is assumed to be initialized. This patch fix regression for the hand over. Thanks. >>> >>> Just now noticed, this patch only fix partial problem. Kernel console is ok. >>> >>> But later initrd/init scripts revert back to 9600 again. >> >> Please share the init scripts. > > I am using opensuse 13.1 rescue disk as ramdisk. or opensuse 12.3 rescue disk. -- 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] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 8:09 PM, Peter Hurley wrote: > > All this automatic behavior and aliases for the same things just > adds unnecessary complexity and maintenance burden, without measurable > gain. > > The real tragedy is that all this was totally unnecessary; what was > wrong with "earlycon=uart,io,0x3f8 console=ttyS0"? When I worked on the patch | commit 18a8bd949d6adb311ea816125ff65050df1f3f6e | Date: Sun Jul 15 23:37:59 2007 -0700 | |serial: convert early_uart to earlycon for 8250 Andrew requested that. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 8:15 PM, Peter Hurley wrote: > On 04/03/2015 11:09 PM, Yinghai Lu wrote: >> On Fri, Apr 3, 2015 at 7:19 PM, Yinghai Lu wrote: >>> On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley >>> wrote: Restore undocumented behavior of kernel command line parameters of the forms: console=uart[8250],io|mmio|mmio32,[,options] console=uart[8250],[,options] where 'options' have not been specified; in this case, the hardware is assumed to be initialized. >>> >>> >>> This patch fix regression for the hand over. Thanks. >> >> Just now noticed, this patch only fix partial problem. Kernel console is ok. >> >> But later initrd/init scripts revert back to 9600 again. > > Please share the init scripts. I am using opensuse 13.1 rescue disk as ramdisk. -- 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] earlycon: 8250: Fix command line regression
On 04/03/2015 11:09 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 7:19 PM, Yinghai Lu wrote: >> On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley >> wrote: >>> Restore undocumented behavior of kernel command line parameters of >>> the forms: >>> console=uart[8250],io|mmio|mmio32,[,options] >>> console=uart[8250],[,options] >>> where 'options' have not been specified; in this case, the hardware >>> is assumed to be initialized. >> >> >> This patch fix regression for the hand over. Thanks. > > Just now noticed, this patch only fix partial problem. Kernel console is ok. > > But later initrd/init scripts revert back to 9600 again. Please share the init scripts. -- 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] earlycon: 8250: Fix command line regression
On 04/03/2015 10:56 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 7:29 PM, Peter Hurley wrote: >> On 04/03/2015 10:19 PM, Yinghai Lu wrote: >>> On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley >>> wrote: Restore undocumented behavior of kernel command line parameters of the forms: console=uart[8250],io|mmio|mmio32,[,options] console=uart[8250],[,options] where 'options' have not been specified; in this case, the hardware is assumed to be initialized. >>> >>> >>> Please separated bug fix and other documentation change to different >>> patches. >> >> No. The documentation reflects exactly what the bug fix is for. > > what is > > + uart[],mmio,[,options] > + uart[],mmio32,[,options] Wrong patch version; that's v1. >>> also fix the patch title to make it clear and you need to mention which >>> commit >>> cause the regression. >> >> Please bisect and send bisect log so I know which commit broke >> your setup. > > I already gave your the patch "title". Here it is again: > > commit c7cef0a84912cab3c9df8949b034e4aa62982ec9 > Author: Peter Hurley > Date: Mon Mar 9 16:27:12 2015 -0400 > > console: Add extensible console matching Ok. >>> This patch fix regression for the hand over. Thanks. >>> >>> Another regression. >>> when user have >>> console=uart8250,io,0x3f8 console=uart8250,io,0x2f8 >>> >>> before your patchset: >>> port_0x3f8 is early console, and will be console later. >>> and port_0x2f8 is ignored, because only ONE early console is allowed. >>>and old console setup, only handle ttyS0. >>> >>> after your patchset: >>> port_0x3f8 is early console, and will be console later. >>> port_0x2f8 will become default console, as new console with match method >>>treat all uart8250 as ttyS0. >>> >>> Please fix that too. >> >> That's a new feature, not a regression. > > ok, think that more. > > with this patch: > > [PATCH] earlycon: 8250: Fix command line regression > > When you have console=uart8250,io,0x3f8 console=uart,io,0x2f8 > > you will skip the setup to 0x2f8, as the options is null. > then if the bios or bootloader only setup baud rate for 0x3f8. > the user could get nothing from 0x2f8. > > Do you need to call univ8250_console_setup(co, options) > to set the default baud rate ? No. The user specified that the console had already been initialized by leaving out the option string. Isn't that what this whole email thread has been about? All this automatic behavior and aliases for the same things just adds unnecessary complexity and maintenance burden, without measurable gain. The real tragedy is that all this was totally unnecessary; what was wrong with "earlycon=uart,io,0x3f8 console=ttyS0"? Regards, Peter Hurley -- 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] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 7:19 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley wrote: >> Restore undocumented behavior of kernel command line parameters of >> the forms: >> console=uart[8250],io|mmio|mmio32,[,options] >> console=uart[8250],[,options] >> where 'options' have not been specified; in this case, the hardware >> is assumed to be initialized. > > > This patch fix regression for the hand over. Thanks. Just now noticed, this patch only fix partial problem. Kernel console is ok. But later initrd/init scripts revert back to 9600 again. So the patch does not fix the regression from commit c7cef0a84912cab3c9df8949b034e4aa62982ec9 Author: Peter Hurley Date: Mon Mar 9 16:27:12 2015 -0400 console: Add extensible console matching -- 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: [Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716
Hi Jiang,
Sorry for my delayed response. I've been on vacation for a week and am
still trying to catch up.
On Mon, Mar 30, 2015 at 10:40:43AM +0800, Jiang Liu wrote:
> Before commit 593669c2ac0f("Use common ACPI resource interfaces to
> simplify implementation"), arch/x86/pci/acpi.c applies following
> rules when parsing ACPI resources for PCI host bridge:
> 1) Ignore IO port resources defined by acpi_resource_io and
>acpi_resource_fixed_io, which should be used to define resource
>for PCI device instead of PCI bridge.
> 2) Accept IOMEM resource defined by acpi_resource_memory24,
>acpi_resource_memory32 and acpi_resource_fixed_memory32.
>These IOMEM resources are accepted to workaround some BIOS issue,
>though they should be ignored. For example, PC Engines APU.1C
>platform defines PCI host bridge IOMEM resources as:
> Memory32Fixed (ReadOnly,
> 0x000A, // Address Base
> 0x0002, // Address Length
> )
> Memory32Fixed (ReadOnly,
> 0x, // Address Base
> 0x, // Address Length
> _Y00)
> 3) Accept all IO port and IOMEM resources defined by
>acpi_resource_address{16,32,64,extended64}, no matter it's marked as
>ACPI_CONSUMER or ACPI_PRODUCER.
>
> Commit 593669c2ac0f("Use common ACPI resource interfaces to
> simplify implementation") accept all IO port and IOMEM resources
> defined by acpi_resource_io, acpi_resource_fixed_io,
> acpi_resource_memory24, acpi_resource_memory32,
> acpi_resource_fixed_memory32 and
> acpi_resource_address{16,32,64,extended64}, which causes IO port
> resources consumed by host bridge itself are listed in to host bridge
> resource list.
>
> Then commit 63f1789ec716("Ignore resources consumed by host bridge
> itself") ignores resources consumed by host bridge itself by checking
> IORESOURCE_WINDOW flag, which accidently removed the workaround in 2)
> above for BIOS bug .
This is probably partly my fault.
I think the ACPI spec intention is that every _CRS resource descriptor
should be interpreted as "Consumer," i.e., as resources consumed by the
device itself, unless it's marked otherwise. Only the following types can
be marked as "Producer":
- Word/DWord/QWord/Extended address space descriptors,
- Extended interrupt descriptors,
- GPIO interrupt and I/O connections,
- I2C/SPI/UART serial bus resource descriptors
With 66528fdd45b0 ("x86/PCI: parse additional host bridge window resource
types"), I made Linux treat Memory24, Memory32, and Memory32Fixed
descriptors in PCI host bridge _CRS as Producers. I did it because Windows
apparently does that (there are details in
https://bugzilla.kernel.org/show_bug.cgi?id=15817), but I wasn't aware of
any machines that required it. That was probably a mistake because it
didn't fix anything and it covered up ASL usage errors like what PC Engines
did.
> It's really costed us much time to figure out this whole picture.
> So we refine interface acpi_dev_filter_resource_type as below,
> which should be easier for maintence:
> 1) Caller specifies IORESOURCE_WINDOW flag to explicitly query resource
>for bridge(PRODUCER), otherwise it's querying resource for
>device(CONSUMER).
Sounds good to me.
> 2) Ignore IO port resources defined by acpi_resource_io and
>acpi_resource_fixed_io if IORESOURCE_WINDOW is specified.
Sounds good to me.
> 3) Accpet IOMEM resource defined by acpi_resource_memory24,
>acpi_resource_memory32 and acpi_resource_fixed_memory32 for BIOS
>bugs, with comment to state it's workaround for BIOS bug.
I don't like the fact that this is the behavior for all ACPI devices.
Prior to 593669c2ac0f, we had this behavior for PCI host bridges only.
I don't think this is what the spec envisioned, so I don't really like
doing it for all devices.
> 4) Accept IO port and IOMEM defined by acpi_resource_addressxx if
>a) IORESOURCE_WINDOW is specified and ACPI_PRODUCER is true
>b) IORESOURCE_WINDOW is not specified and ACPI_PRODUCER is false
Sounds good to me.
> Currently acpi_dev_filter_resource_type() is only used by ACPI pci
> host bridge and IOAPIC driver, so it shouldn't affect other drivers.
We should assume it will eventually be used for all ACPI devices,
shouldn't we?
> Another possible fix is to only ignore IO resource consumed by host
> bridge and keep IOMEM resource consumed by host bridge, please refer to:
> http://www.spinics.net/lists/linux-pci/msg39706.html
>
> Sample ACPI table are archived at:
> https://bugzilla.kernel.org/show_bug.cgi?id=94221
>
> V2->V3:
> Refine function acpi_dev_match_producer_consumer() as suggested by Rafael
>
> Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
> Reported-and-Tested-by: Bernhard Thaler
> Signed-off-by: Jiang Liu
> ---
> arch/x86/pci/acpi.c |5 ++---
> drivers/acpi/resource.c |
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 7:50 PM, Peter Hurley wrote: > On 04/03/2015 10:29 PM, Peter Hurley wrote: >> On 04/03/2015 10:19 PM, Yinghai Lu wrote: >>> Another regression. >>> when user have >>> console=uart8250,io,0x3f8 console=uart8250,io,0x2f8 >>> >>> before your patchset: >>> port_0x3f8 is early console, and will be console later. >>> and port_0x2f8 is ignored, because only ONE early console is allowed. >>>and old console setup, only handle ttyS0. >>> >>> after your patchset: >>> port_0x3f8 is early console, and will be console later. >>> port_0x2f8 will become default console, as new console with match method >>>treat all uart8250 as ttyS0. >>> >>> Please fix that too. >> >> That's a new feature, not a regression. > > So, in all seriousness, you actually have this setup and want me to > fix this? No. Just add one count in the console match for it. > > IOW, to support more than 1 earlycon in the future will require > using a totally different command line parameter. Awesome. > That is future, right? Show me patch. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 7:29 PM, Peter Hurley wrote: > On 04/03/2015 10:19 PM, Yinghai Lu wrote: >> On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley >> wrote: >>> Restore undocumented behavior of kernel command line parameters of >>> the forms: >>> console=uart[8250],io|mmio|mmio32,[,options] >>> console=uart[8250],[,options] >>> where 'options' have not been specified; in this case, the hardware >>> is assumed to be initialized. >> >> >> Please separated bug fix and other documentation change to different patches. > > No. The documentation reflects exactly what the bug fix is for. what is + uart[],mmio,[,options] + uart[],mmio32,[,options] > >> also fix the patch title to make it clear and you need to mention which >> commit >> cause the regression. > > Please bisect and send bisect log so I know which commit broke > your setup. I already gave your the patch "title". Here it is again: commit c7cef0a84912cab3c9df8949b034e4aa62982ec9 Author: Peter Hurley Date: Mon Mar 9 16:27:12 2015 -0400 console: Add extensible console matching > >> This patch fix regression for the hand over. Thanks. >> >> Another regression. >> when user have >> console=uart8250,io,0x3f8 console=uart8250,io,0x2f8 >> >> before your patchset: >> port_0x3f8 is early console, and will be console later. >> and port_0x2f8 is ignored, because only ONE early console is allowed. >>and old console setup, only handle ttyS0. >> >> after your patchset: >> port_0x3f8 is early console, and will be console later. >> port_0x2f8 will become default console, as new console with match method >>treat all uart8250 as ttyS0. >> >> Please fix that too. > > That's a new feature, not a regression. ok, think that more. with this patch: [PATCH] earlycon: 8250: Fix command line regression When you have console=uart8250,io,0x3f8 console=uart,io,0x2f8 you will skip the setup to 0x2f8, as the options is null. then if the bios or bootloader only setup baud rate for 0x3f8. the user could get nothing from 0x2f8. Do you need to call univ8250_console_setup(co, options) to set the default baud rate ? -- 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] earlycon: 8250: Fix command line regression
On 04/03/2015 10:29 PM, Peter Hurley wrote: > On 04/03/2015 10:19 PM, Yinghai Lu wrote: >> Another regression. >> when user have >> console=uart8250,io,0x3f8 console=uart8250,io,0x2f8 >> >> before your patchset: >> port_0x3f8 is early console, and will be console later. >> and port_0x2f8 is ignored, because only ONE early console is allowed. >>and old console setup, only handle ttyS0. >> >> after your patchset: >> port_0x3f8 is early console, and will be console later. >> port_0x2f8 will become default console, as new console with match method >>treat all uart8250 as ttyS0. >> >> Please fix that too. > > That's a new feature, not a regression. So, in all seriousness, you actually have this setup and want me to fix this? IOW, to support more than 1 earlycon in the future will require using a totally different command line parameter. Awesome. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] drm/msm: fixup wait_for_completion_timeout handling
wait_for_completion_timeout return >= 0 but never negative so the check
logic looks inconsistent. Further the return value of
wait_for_completion_timeout was being passed up the call chain but the
x call sites as drm_dp_i2c_do_msg()/drm_dp_dpcd_access() check for < 0
thus timeout was being treated as success case.
drivers/gpu/drm/drm_dp_helper.c:drm_dp_i2c_do_msg()
mutex_lock(&aux->hw_mutex);
ret = aux->transfer(aux, msg);
mutex_unlock(&aux->hw_mutex);
if (ret < 0) {
logic in edp_aux_transfer() seems incorrect as it could return 0 (timeout)
but checks of <= 0 to indicate error so the return probably should be
-ETIMEDOUT in case wait_for_completion_timeout returns 0 (timeout
occurred).
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc6 (localversion-next is -next-20150402)
drivers/gpu/drm/msm/edp/edp_aux.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index 5f5a84f..1d2ccdf 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -119,6 +119,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
{
struct edp_aux *aux = to_edp_aux(drm_aux);
ssize_t ret;
+ unsigned long time_left;
bool native = msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATIVE_READ);
bool read = msg->request & (DP_AUX_I2C_READ & DP_AUX_NATIVE_READ);
@@ -147,15 +148,16 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux,
struct drm_dp_aux_msg *msg)
goto unlock_exit;
DBG("wait_for_completion");
- ret = wait_for_completion_timeout(&aux->msg_comp, 300);
- if (ret <= 0) {
+ time_left = wait_for_completion_timeout(&aux->msg_comp, 300);
+ if (!time_left) {
/*
* Clear GO and reset AUX channel
* to cancel the current transaction.
*/
edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
msm_edp_aux_ctrl(aux, 1);
- pr_err("%s: aux timeout, %d\n", __func__, ret);
+ pr_err("%s: aux timeout, %lu\n", __func__, time_left);
+ ret = -ETIMEDOUT;
goto unlock_exit;
}
DBG("completion");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/msm: fix build warning - missing prototype
fix build warning when building edp/edp_aux.o due to missing prototype for edp_aux_transfer. Signed-off-by: Nicholas Mc Guire --- building drivers/gpu/drm/msm/msm.ko gives the following warning: drivers/gpu/drm/msm/edp/edp_aux.c:118:9: warning: no previous prototype for 'edp_aux_transfer' [-Wmissing-prototypes] ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct drm_dp_aux_msg *msg) ^ the fix is to simply add the missing prototype to drivers/gpu/drm/msm/edp/edp.h This was compile tested with qcom_defconfig + CONFIG_DRM=m (implies CONFIG_DRM_MSM=m) Patch is against 4.0-rc6 (localversion-next is -next-20150402) drivers/gpu/drm/msm/edp/edp.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h index ba5bedd..93d819c 100644 --- a/drivers/gpu/drm/msm/edp/edp.h +++ b/drivers/gpu/drm/msm/edp/edp.h @@ -58,6 +58,8 @@ void *msm_edp_aux_init(struct device *dev, void __iomem *regbase, void msm_edp_aux_destroy(struct device *dev, struct edp_aux *aux); irqreturn_t msm_edp_aux_irq(struct edp_aux *aux, u32 isr); void msm_edp_aux_ctrl(struct edp_aux *aux, int enable); +ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, +struct drm_dp_aux_msg *msg); /* Phy */ bool msm_edp_phy_ready(struct edp_phy *phy); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drm/msm: fix HZ dependency of timeout
The timeout is passed as a constant which makes it HZ dependent because
jiffies are expected so it should be converted to jiffies. The actual
value is not clear from the code - my best guess is that this should be
300 milliseconds given that other timeouts are in milliseconds based on
looking at other drm drivers (e.g. exynos_drm_dsi.c:356 300ms,
tegra/dpaux.c:188 250ms) - this needs to be confirmed by someone who
knows the details of the driver.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc6 (localversion-next is -next-20150402)
drivers/gpu/drm/msm/edp/edp_aux.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index 91a1a67..d1b6833 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -148,7 +148,8 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
goto unlock_exit;
DBG("wait_for_completion");
- time_left = wait_for_completion_timeout(&aux->msg_comp, 300);
+ time_left = wait_for_completion_timeout(&aux->msg_comp,
+ msecs_to_jiffies(300));
if (!time_left) {
/*
* Clear GO and reset AUX channel
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drm/msm: drop redundant output in debug message
wait_for_completion_timeout returns 0 in case of timeout so printing the
return value here will always yield 0 and is therefor redundant - dropped.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc6 (localversion-next is -next-20150402)
drivers/gpu/drm/msm/edp/edp_aux.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index d1b6833..645ea07 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -157,7 +157,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
*/
edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
msm_edp_aux_ctrl(aux, 1);
- pr_err("%s: aux timeout, %lu\n", __func__, time_left);
+ pr_err("%s: aux timeout,\n", __func__);
ret = -ETIMEDOUT;
goto unlock_exit;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] earlycon: 8250: Fix command line regression
On 04/03/2015 10:19 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley wrote: >> Restore undocumented behavior of kernel command line parameters of >> the forms: >> console=uart[8250],io|mmio|mmio32,[,options] >> console=uart[8250],[,options] >> where 'options' have not been specified; in this case, the hardware >> is assumed to be initialized. > > > Please separated bug fix and other documentation change to different patches. No. The documentation reflects exactly what the bug fix is for. > also fix the patch title to make it clear and you need to mention which commit > cause the regression. Please bisect and send bisect log so I know which commit broke your setup. > This patch fix regression for the hand over. Thanks. > > Another regression. > when user have > console=uart8250,io,0x3f8 console=uart8250,io,0x2f8 > > before your patchset: > port_0x3f8 is early console, and will be console later. > and port_0x2f8 is ignored, because only ONE early console is allowed. >and old console setup, only handle ttyS0. > > after your patchset: > port_0x3f8 is early console, and will be console later. > port_0x2f8 will become default console, as new console with match method >treat all uart8250 as ttyS0. > > Please fix that too. That's a new feature, not a regression. -- 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] earlycon: 8250: Fix command line regression
On Fri, Apr 3, 2015 at 5:04 PM, Peter Hurley wrote: > Restore undocumented behavior of kernel command line parameters of > the forms: > console=uart[8250],io|mmio|mmio32,[,options] > console=uart[8250],[,options] > where 'options' have not been specified; in this case, the hardware > is assumed to be initialized. Please separated bug fix and other documentation change to different patches. also fix the patch title to make it clear and you need to mention which commit cause the regression. This patch fix regression for the hand over. Thanks. Another regression. when user have console=uart8250,io,0x3f8 console=uart8250,io,0x2f8 before your patchset: port_0x3f8 is early console, and will be console later. and port_0x2f8 is ignored, because only ONE early console is allowed. and old console setup, only handle ttyS0. after your patchset: port_0x3f8 is early console, and will be console later. port_0x2f8 will become default console, as new console with match method treat all uart8250 as ttyS0. Please fix that too. -- 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, mempool: kasan: poison mempool elements
On Fri, 3 Apr 2015, Andrey Ryabinin wrote: > Mempools keep allocated objects in reserved for situations > when ordinary allocation may not be possible to satisfy. > These objects shouldn't be accessed before they leave > the pool. > This patch poison elements when get into the pool > and unpoison when they leave it. This will let KASan > to detect use-after-free of mempool's elements. > > Signed-off-by: Andrey Ryabinin Tested-by: David Rientjes -- 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] nohz: make nohz_full imply isolcpus
On Fri, 2015-04-03 at 15:21 -0400, Chris Metcalf wrote: > On 04/03/2015 02:08 PM, Mike Galbraith wrote: > > On Fri, 2015-04-03 at 12:24 -0400, cmetcalf@ezchip.comwrote: > > > From: Chris Metcalf > > > > > > It's not clear that nohz_full is useful without isolcpus also > > > set, since otherwise the scheduler has to run periodically to > > > try to determine whether to steal work from other cores. > > > > > > Signed-off-by: Chris Metcalf > > Ack! nohz_full= as currently defined makes zero sense when the cpu > > set (which should be spelled cpuset) remains connected to the > > scheduler. Perturbation of tasks to PREVENT cpu domination is what > > the scheduler does for a living. Sprinkling microsecond savers all > > over the kernel is pretty silly if you don't shut down the mother > > lode > > of perturbation. > > Sounds like a thumbs up for this patch, then? :-) Yup. The other thumb turns in the up direction when folks start spelling cpuset properly ;-) Static isolcpus was supposed to go away. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2] mm, memcg: sync allocation and memcg charge gfp flags for THP
On Wed, 18 Mar 2015, Michal Hocko wrote:
> memcg currently uses hardcoded GFP_TRANSHUGE gfp flags for all THP
> charges. THP allocations, however, might be using different flags
> depending on /sys/kernel/mm/transparent_hugepage/{,khugepaged/}defrag
> and the current allocation context.
>
> The primary difference is that defrag configured to "madvise" value will
> clear __GFP_WAIT flag from the core gfp mask to make the allocation
> lighter for all mappings which are not backed by VM_HUGEPAGE vmas.
> If memcg charge path ignores this fact we will get light allocation but
> the a potential memcg reclaim would kill the whole point of the
> configuration.
>
> Fix the mismatch by providing the same gfp mask used for the
> allocation to the charge functions. This is quite easy for all
> paths except for hugepaged kernel thread with !CONFIG_NUMA which is
> doing a pre-allocation long before the allocated page is used in
> collapse_huge_page via khugepaged_alloc_page. To prevent from cluttering
> the whole code path from khugepaged_do_scan we simply return the current
> flags as per khugepaged_defrag() value which might have changed since
> the preallocation. If somebody changed the value of the knob we would
> charge differently but this shouldn't happen often and it is definitely
> not critical because it would only lead to a reduced success rate of
> one-off THP promotion.
>
> Acked-by: Vlastimil Babka
> Signed-off-by: Michal Hocko
Acked-by: David Rientjes
I'm slightly surprised that this issue never got reported before.
--
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/memory: print also a_ops->readpage in print_bad_pte
On Sat, 4 Apr 2015 03:47:12 +0300 Konstantin Khlebnikov wrote: > On Sat, Apr 4, 2015 at 1:10 AM, Andrew Morton > wrote: > > On Fri, 03 Apr 2015 20:18:18 +0300 Konstantin Khlebnikov > > wrote: > > > >> A lot of filesystems use generic_file_mmap() and filemap_fault(), > >> f_op->mmap and vm_ops->fault aren't enough to identify filesystem. > >> > >> This prints file name, vm_ops->fault, f_op->mmap and a_ops->readpage > >> (which is almost always implemented and filesystem-specific). > >> > >> Example: > >> > >> [ 23.676410] BUG: Bad page map in process sh pte:1b7e6025 pmd:19bbd067 > >> [ 23.676887] page:ea6df980 count:4 mapcount:1 > >> mapping:8800196426c0 index:0x97 > >> [ 23.677481] flags: 0x10c(referenced|uptodate) > >> [ 23.677896] page dumped because: bad pte > >> [ 23.678205] addr:7f52fcb17000 vm_flags:0075 anon_vma: > >> (null) mapping:8800196426c0 index:97 > >> [ 23.678922] file:libc-2.19.so fault:filemap_fault > >> mmap:generic_file_readonly_mmap readpage:v9fs_vfs_readpage > > > > Is that why we print these out? Just to identify the fs type? > > > > There's always vma->vm_file->f_inode->i_sb->s_magic ;) > > Yes, but that also might be anon inode/file mapped by some driver, so > s_magic isn't enough. Well, we could ensure that every file_system_type has a valid ->name. Do an audit, put a debug check in register_filesystem()? -- 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 -next 11/11] serial: 8250_early: Remove setup_early_serial8250_console()
On 04/03/2015 08:52 PM, Yinghai Lu wrote: > On Fri, Apr 3, 2015 at 11:27 AM, Peter Hurley > wrote: >> On 04/03/2015 01:44 PM, Yinghai Lu wrote: >>> On Fri, Apr 3, 2015 at 10:38 AM, Peter Hurley >>> wrote: On 04/03/2015 12:57 PM, Yinghai Lu wrote: Wait -- you have earlycon in a product?? >>> >>> What do you mean? >> >> I mean, what will happen if I put in a big debug banner like Steven >> did for ftrace? >> >> Kernel developers need earlycon for debugging arch code; often the earlycon >> is just hacked together especially when it requires fixmap support. >> >> Putting it in a product and _relying on undocumented behavior_ is a bad idea. > > let me repeat again: > when you have "console=uart8250,io,0x3f8", you will have earlycon and > then console. > > That is just for kernel developer for debugging. > > When you have x86 with bunch of dimms and cpus, user will have to wait couple > of minutes to output from console=ttyS0and if it hang early, no > one would know what happen. > > Also it is only boot time only The fix is sitting in your inbox. Pointless to discuss it now. -- 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: fbtft: 80 characters per line in fb_ili9163.c
On Sat, 4 Apr 2015, Andreas Theodosiou wrote: > This is a patch to the fb_ili9163.c file that inserts a line break in > line #92 to make the line fit into the 80 character limit. > > Signed-off-by: Andreas Theodosiou > --- > drivers/staging/fbtft/fb_ili9163.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/fbtft/fb_ili9163.c > b/drivers/staging/fbtft/fb_ili9163.c > index ed92a64..fc7568b 100644 > --- a/drivers/staging/fbtft/fb_ili9163.c > +++ b/drivers/staging/fbtft/fb_ili9163.c > @@ -89,7 +89,8 @@ > > /* > This display: > -http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI-Color-TFT-LCD-Display-Module-/271422122271 > +http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI- > +Color-TFT-LCD-Display-Module-/271422122271 With this change the user won't be able to just simply click on the url and have it open for him. Thus I don't think this is a good change. Sometimes in the kernel people leave lines over 80 characters to make the code more grep-able, sometimes it's just more clear when it's over 80 characters or, probably, in cases like this. Su pagarba / Regards, Giedrius -- 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 -next 11/11] serial: 8250_early: Remove setup_early_serial8250_console()
On Fri, Apr 3, 2015 at 11:27 AM, Peter Hurley wrote: > On 04/03/2015 01:44 PM, Yinghai Lu wrote: > > which means you have to have CONFIG_SERIAL_EARLYCON to get a serial console > at all. what do you mean? Now in drivers/tty/serial/8250/Kconfig we have config SERIAL_8250_CONSOLE bool "Console on 8250/16550 and compatible serial port" depends on SERIAL_8250=y select SERIAL_CORE_CONSOLE select SERIAL_EARLYCON do you mean, we should not have that "select SERIAL_EARLYCON" ? -- 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 -next 11/11] serial: 8250_early: Remove setup_early_serial8250_console()
On Fri, Apr 3, 2015 at 11:27 AM, Peter Hurley wrote: > On 04/03/2015 01:44 PM, Yinghai Lu wrote: >> On Fri, Apr 3, 2015 at 10:38 AM, Peter Hurley >> wrote: >>> On 04/03/2015 12:57 PM, Yinghai Lu wrote: >>> >>> Wait -- you have earlycon in a product?? >> >> What do you mean? > > I mean, what will happen if I put in a big debug banner like Steven > did for ftrace? > > Kernel developers need earlycon for debugging arch code; often the earlycon > is just hacked together especially when it requires fixmap support. > > Putting it in a product and _relying on undocumented behavior_ is a bad idea. let me repeat again: when you have "console=uart8250,io,0x3f8", you will have earlycon and then console. That is just for kernel developer for debugging. When you have x86 with bunch of dimms and cpus, user will have to wait couple of minutes to output from console=ttyS0and if it hang early, no one would know what happen. Also it is only boot time only -- 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/memory: print also a_ops->readpage in print_bad_pte
On Sat, Apr 4, 2015 at 1:10 AM, Andrew Morton wrote: > On Fri, 03 Apr 2015 20:18:18 +0300 Konstantin Khlebnikov > wrote: > >> A lot of filesystems use generic_file_mmap() and filemap_fault(), >> f_op->mmap and vm_ops->fault aren't enough to identify filesystem. >> >> This prints file name, vm_ops->fault, f_op->mmap and a_ops->readpage >> (which is almost always implemented and filesystem-specific). >> >> Example: >> >> [ 23.676410] BUG: Bad page map in process sh pte:1b7e6025 pmd:19bbd067 >> [ 23.676887] page:ea6df980 count:4 mapcount:1 >> mapping:8800196426c0 index:0x97 >> [ 23.677481] flags: 0x10c(referenced|uptodate) >> [ 23.677896] page dumped because: bad pte >> [ 23.678205] addr:7f52fcb17000 vm_flags:0075 anon_vma: >> (null) mapping:8800196426c0 index:97 >> [ 23.678922] file:libc-2.19.so fault:filemap_fault >> mmap:generic_file_readonly_mmap readpage:v9fs_vfs_readpage > > Is that why we print these out? Just to identify the fs type? > > There's always vma->vm_file->f_inode->i_sb->s_magic ;) Yes, but that also might be anon inode/file mapped by some driver, so s_magic isn't enough. > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org -- 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: fbtft: 80 characters per line in fb_ili9163.c
On Sat, 2015-04-04 at 03:23 +0300, Andreas Theodosiou wrote: > This is a patch to the fb_ili9163.c file that inserts a line break in > line #92 to make the line fit into the 80 character limit. [] > diff --git a/drivers/staging/fbtft/fb_ili9163.c > b/drivers/staging/fbtft/fb_ili9163.c [] > @@ -89,7 +89,8 @@ > > /* > This display: > -http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI-Color-TFT-LCD-Display-Module-/271422122271 > +http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI- > +Color-TFT-LCD-Display-Module-/271422122271 Please don't do this to links. There are many real defects to fix and other code to improve. This isn't one of those. I doubt though that an ebay link is very long lasting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Enhancements to twl4030 phy to support better charging - V2
On Fri, 3 Apr 2015 19:08:22 +0530 Kishon Vijay Abraham I wrote: > +Extcon MAINTAINERS > > Hi, > > On Wednesday 01 April 2015 10:11 AM, NeilBrown wrote: > > On Thu, 26 Mar 2015 05:29:42 +0530 Kishon Vijay Abraham I > > wrote: > > > >> Hi NeilBrown, > >> > >> On Thursday 26 March 2015 02:52 AM, NeilBrown wrote: > >>> On Thu, 26 Mar 2015 02:46:32 +0530 Kishon Vijay Abraham I > >>> wrote: > >>> > Hi, > > On Monday 23 March 2015 04:05 AM, NeilBrown wrote: > > Hi Kishon, > > I wonder if you could queue the following for the next merge window. > > They allow the twl4030 phy to provide more information to the > > twl4030 battery charger. > > There are only minimal changes since the first version, particularly > > documentation has been improved. > > There are quite a few things in this series which use the USB PHY library > interface which is kindof deprecated. We should try and use the Generic > PHY > library for all of them. It would also be better to add features to the > PHY framework if the we can't achieve something with the existing PHY > framework. > >>> > >>> Hi, > >>> are you able to more specific at all? What is the "USB PHY library"? > >>> Where exactly is the "PHY framework"? > >> > >> There is a USB PHY library that exists in drivers/usb/phy/phy.c and there > >> is > >> a Generic PHY framework that is present in drivers/phy/phy-core.c. twl4030 > >> actually supports both the framework. > >> > >> In your patch whatever uses struct usb_phy uses the old USB PHY library and > >> whatever uses struct phy uses the generic PHY framework. (Actually your > >> patch > >> does not use the PHY framework at all). We want to deprecate using the USB > >> PHY > >> library and make everyone use the generic PHY framework. Adding features > >> to a driver using the USB PHY library will make the transition to generic > >> PHY > >> framework a bit more difficult. > >> > >> Now all the features that is supported in the USB PHY library may not be > >> supported by the PHY framework. So we should start extending the PHY > >> framework > >> instead of using the USB PHY library. > >> > >> One think I noticed in your driver is using atomic notifier chain. IMO > >> extcon > >> framework should be used in twl4030 USB driver to notify the controller > >> driver > >> instead of using USB PHY notifier. For all other things we have to see if > >> it > >> can be added in the PHY framework. > > > > I've had a look at the code with these issues in mind, and there is one > > issue > > that I'm not sure about. > > > > In phy-twl4030-usb, the usb_phy is used to hold a reference to the > > 'struct otg', and for passing cable state changes to the notifier. > > right now we directly call omap_musb_mailbox no? we don't use notifiers right? Correct, and omap_musb_set_mailbox uses the notifier chain. phy-twl4030-usb does ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier); That is the only place the current phy code interacts with the notifier chain. > > > > The former probably has to stay until musb can keep a reference to the otg, > > separate form the usb_phy. The latter can be changed to use extcon - to > > some extent. I actually have patches to do that from a couple of years > > back, > > but I never proceeded with them. > > > > The problem is that one thing that needs to be communicated to the charger > > is > > the max current that was negotiated by a "Standard Downstream Port". > > This could be 500mA from a powered hum, or much less from an unpowered hub. > > (Currently the usb gadget code does negotiated between different > > possibilities, but it could and hopefully will one day). > > > > With the notifier chain there is an easy way to communicate the allowed > > current once it is negotiated. e.g. ab8500_usb_set_power() does this. > > > > 'struct phy' has no equivalent of the 'set_power' callback which 'struct > > usb_phy' provides, and extcon has no mechanism (that I can see) for > > communicating a number - just binary cable states. > > Chanwoo Choi, Can this be modified so that we can communicate numbers like in > the case of EXTCON_CHARGE_DOWNSTREAM? > > > > Presumably a 'set_power' method could be added to 'struct phy' so the > > usb-core can communicate the number to the phy, but it is not clear to me > > how > > the 'phy' can communicate it to the charger. > > Should the PHY be involved in all this? We can make the gadget driver > directly communicate the value to the charger no? > > The 'phy' could provide an API to request the current negotiated max > > current, > > but there still needs to be a way to let the charger know that this has > > changed. > > That could in theory be done via extcon, by having a secondary > > 'USB_connected' cable type, but it isn't really a cable type and pretending > > that it is seems wrong. > > I think EXTCON_CHARGE_DOWNSTREAM was created for that purpose. Chanwoo? > EXTC
[PATCH] staging: fbtft: 80 characters per line in fb_ili9163.c
This is a patch to the fb_ili9163.c file that inserts a line break in line #92 to make the line fit into the 80 character limit. Signed-off-by: Andreas Theodosiou --- drivers/staging/fbtft/fb_ili9163.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fb_ili9163.c b/drivers/staging/fbtft/fb_ili9163.c index ed92a64..fc7568b 100644 --- a/drivers/staging/fbtft/fb_ili9163.c +++ b/drivers/staging/fbtft/fb_ili9163.c @@ -89,7 +89,8 @@ /* This display: -http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI-Color-TFT-LCD-Display-Module-/271422122271 +http://www.ebay.com/itm/Replace-Nokia-5110-LCD-1-44-Red-Serial-128X128-SPI- +Color-TFT-LCD-Display-Module-/271422122271 This particular display has a design error! The controller has 3 pins to configure to constrain the memory and resolution to a fixed dimension (in that case 128x128) but they leaved those pins configured for 128x160 so -- 2.3.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 0/3] tty: eliminate 64 byte stack buffers passed to tty_name
On 03/31/2015 09:55 AM, Rasmus Villemoes wrote: > All users of tty_name pass the return value directly to a printf > function, so we might as well use tty->name directly instead of > copying it to a user-supplied (stack) buffer. Reviewed-by: Peter Hurley -- 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] [media] marvell-ccic: fix memory leak on failure path in cafe_smbus_setup()
If i2c_add_adapter() fails, adap is not deallocated.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/platform/marvell-ccic/cafe-driver.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/cafe-driver.c
b/drivers/media/platform/marvell-ccic/cafe-driver.c
index 562845361246..9d45505370cd 100644
--- a/drivers/media/platform/marvell-ccic/cafe-driver.c
+++ b/drivers/media/platform/marvell-ccic/cafe-driver.c
@@ -339,17 +339,21 @@ static int cafe_smbus_setup(struct cafe_camera *cam)
adap = kzalloc(sizeof(*adap), GFP_KERNEL);
if (adap == NULL)
return -ENOMEM;
- cam->mcam.i2c_adapter = adap;
- cafe_smbus_enable_irq(cam);
adap->owner = THIS_MODULE;
adap->algo = &cafe_smbus_algo;
strcpy(adap->name, "cafe_ccic");
adap->dev.parent = &cam->pdev->dev;
i2c_set_adapdata(adap, cam);
ret = i2c_add_adapter(adap);
- if (ret)
+ if (ret) {
printk(KERN_ERR "Unable to register cafe i2c adapter\n");
- return ret;
+ kfree(adap);
+ return ret;
+ }
+
+ cam->mcam.i2c_adapter = adap;
+ cafe_smbus_enable_irq(cam);
+ return 0;
}
static void cafe_smbus_shutdown(struct cafe_camera *cam)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irq: revert non-working patch to affinity defaults
On Fri, 3 Apr 2015 08:55:57 +0200 Ingo Molnar wrote: > So the original commit also has the problem that it unnecessary > drops/retakes the descriptor lock: > > > irq_put_desc_unlock(desc, flags); > > - /* set the initial affinity to prevent every interrupt being on CPU0 */ > > - if (m) > > - __irq_set_affinity(irq, m, false); > > > i.e. why not just call into irq_set_affinity_locked() while we still > have the descriptor locked? I had tried that but it didn't help much. I also tried kzalloc a new descriptor like the proc functionality does, and that changes the behavior a little, but doesn't fix it AFAICS. > Now this is just a small annoyance that should not really matter - it > would be nice to figure out the real reason for why the irqs move back > to CPU#0. > > In theory the same could happen to 'irqbalanced' as well, if it calls > shortly after an irq was registered - so this is not a bug we want to > ignore. Let me know if I can do something to help, the IRQ code is a bit of a steep learning curve, so the chances of me fixing it are small. > Also, worst case we are back to where v3.19 was, right? So could we > try to analyze this a bit more? Yes, 3.19 shipped with this issue. Again, let me know if I can help. Thanks, Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] earlycon: 8250: Fix command line regression
Restore undocumented behavior of kernel command line parameters of
the forms:
console=uart[8250],io|mmio|mmio32,[,options]
console=uart[8250],[,options]
where 'options' have not been specified; in this case, the hardware
is assumed to be initialized.
Document the required behavior of the original implementation.
Reported-by: Yinghai Lu
Signed-off-by: Peter Hurley
---
v2: Fixed regression which allowed "console=uart1337,..." to start a
console (but not an earlycon)
+ fixed earlycon= documentation related required behavior fixed by
this patch
Documentation/kernel-parameters.txt | 18 +++---
drivers/tty/serial/8250/8250_core.c | 20 ++--
drivers/tty/serial/8250/8250_early.c | 19 ---
3 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index bfcb1a6..1facf0b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -713,10 +713,18 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
+ uart[8250],mmio32,[,options]
+ uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
- switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ switching to the matching ttyS device later.
+ MMIO inter-register address stride is either 8-bit
+ (mmio) or 32-bit (mmio32).
+ If none of [io|mmio|mmio32], is assumed to be
+ equivalent to 'mmio'. 'options' are specified in the
+ same format described for ttyS above; if unspecified,
+ the h/w is not re-initialized.
+
hvc Use the hypervisor console device . This is for
both Xen and PowerPC hypervisors.
@@ -944,11 +952,15 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
uart[8250],mmio32,[,options]
+ uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
MMIO inter-register address stride is either 8-bit
(mmio) or 32-bit (mmio32).
- The options are the same as for ttyS, above.
+ If none of [io|mmio|mmio32], is assumed to be
+ equivalent to 'mmio'. 'options' are specified in the
+ same format described for "console=ttyS"; if
+ unspecified, the h/w is not initialized.
pl011,
Start an early, polled-mode console on a pl011 serial
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index e0fb5f0..bda2a57 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3455,13 +3455,18 @@ static int univ8250_console_setup(struct console *co,
char *options)
* @options: ptr to option string from console command line
*
* Only attempts to match console command lines of the form:
- * console=uart<>,io|mmio|mmio32,,
- * console=uart<>,,options
+ * console=uart[8250],io|mmio|mmio32,[,]
+ * console=uart[8250],0x[,]
* This form is used to register an initial earlycon boot console and
* replace it with the serial8250_console at 8250 driver init.
*
* Performs console setup for a match (as required by interface)
*
+ * ** HACK ALERT **
+ * If no are specified, then assume the h/w is already setup.
+ * This was the undocumented behavior of the original implementation so
+ * it is cast in stone forever.
+ *
* Returns 0 if console matches; otherwise non-zero to use default matching
*/
static int univ8250_console_match(struct console *co, char *name, int idx,
@@ -3475,6 +3480,9 @@ static int univ8250_console_match(struct console *co,
char *name, int idx,
if (strncmp(name, match, 4) != 0)
return -ENODEV;
+ if (idx && idx != 8250)
+ return -ENODEV;
+
if (uart_parse_earlycon(options, &iotype, &addr, &options))
return -ENODEV;
@@ -3491,6 +3499,14 @@ static int univ8250_console_match(struct console *co,
char *name, int idx,
continue;
co->index = i;
+
+ /* if no line settings, then assume h/w was setup */
+ if (!options) {
+ /*
Re: [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU
On 2015-04-03 22:09, Russell King - ARM Linux wrote: > On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote: >> In order to support SoC with heterogenous CPU architectures (such >> as Freescale Vybrid/i.MXSX) it is preferable to use the same >> architecture (ARCH_MXC in this case) for the MMU enabled and !MMU >> CPU. Hence allow to select MULTIPLATFORM even without MMU. >> >> Signed-off-by: Stefan Agner >> --- >> arch/arm/Kconfig | 21 ++--- >> 1 file changed, 10 insertions(+), 11 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 9f1f09a..636cb3f 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -230,7 +230,7 @@ config VECTORS_BASE >>in size. >> >> config ARM_PATCH_PHYS_VIRT >> -bool "Patch physical to virtual translations at runtime" if EMBEDDED >> +bool "Patch physical to virtual translations at runtime" if EMBEDDED || >> (ARCH_MULTIPLATFORM && MMU) >> default y > > This makes no sense. Multiplatform MMU _requires_ this feature, so why > offer it to the user when multiplatform is enabled _and_ MMU is enabled? I see, this is plain wrong. Will replace that with a select ... if MMU in multiplatform. > Patch 7817/1 in the patch system tried doing something like you're trying > to do here - I wonder whether you've reviewed the mailing list for > previous discussions. I did some research at RFC/v1 time and mainly looked into Arnd's git trees. Most patches just open up !MMU for multiplatform. What I'm trying to do here is to enable !MMU with multiplatform while keeping the impact as little as possible, e.g. by making all other platforms in multiplatform dependent on MMU. See also https://www.marc.info/?l=linux-kernel&m=141997848124399&w=2 > Given that it's Easter, I'm not going to re-state what I said last time > this came up, but instead leave you to do some research. For example, > reading message id <20130819232411.gx23...@n2100.arm.linux.org.uk>... Also looked at some other messages about this topic, but I guess quotes from the message above will do to discuss this further: > Now, here's the question: can multiplatform ever work properly on nommu? > > We get multiplatform working on MMU by using the MMU to provide a more > consistent view of the system. On noMMU, we don't have that. So if > your kernel is built to run assuming that it will be located in ram at > location X on platform Y, that isn't going to work if platform Z doesn't > have RAM there. The platforms I primarily have in mind (heterogeneous multi-processing SoC's with MMU/!MMU processors) would actually allow such a multiplatform kernel: i.MX6 SoloX as well as Vybrid have the main memory in the same location, hence one could build a multiplatform !MMU kernel for this two devices. Of course, this is possible more by chance. I also did not tried it yet. I don't have a i.MX6 SoloX device. > My feeling is that the motivation behind this patch is to avoid an > amount of yuckyness associated with trying to enable Versatile Express > support outside of the multiplatform container - it's not really about > being able to build a single zImage which works on all noMMU platforms. > So, I don't think this is the right solution to this problem. I must admit that this was the main motivation for me too. My first approach was to create a set of completely independent config symbols: http://marc.info/?l=linux-arm-kernel&m=141756604900611&w=2 However, I'm sure this could be done better and with less config symbols. So, if you think it would be worth enabling multiplatform for these devices (Vybrid/i.MX6 SoloX), I would prepare a patchset which does it while not converting EFM32 to multiplatform (as patch 08/11 currently does). If you think it's also not worth for those devices, I will try to enable ARCH_MXC/SOC_VF610 with !MMU and !MULTIPLATFORM... -- Stefan -- 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] earlycon: 8250: Fix command line regression
Restore undocumented behavior of kernel command line parameters of
the forms:
console=uart[],io|mmio|mmio32,[,options]
console=uart[],[,options]
where 'options' have not been specified; in this case, the hardware
is assumed to be initialized.
Document the required behavior of the original implementation.
Reported-by: Yinghai Lu
Signed-off-by: Peter Hurley
---
Documentation/kernel-parameters.txt | 15 +++
drivers/tty/serial/8250/8250_core.c | 15 ++-
drivers/tty/serial/8250/8250_early.c | 19 ---
3 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index bfcb1a6..59c9832 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -711,12 +711,19 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,[,options]
- uart[8250],mmio,[,options]
+ uart[],io,[,options]
+ uart[],mmio,[,options]
+ uart[],mmio32,[,options]
+ uart[],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
- switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ switching to the matching ttyS device later.
+ Any optional number is accepted and ignored.
+ If none of [io|mmio|mmio32], is assumed to be
+ equivalent to 'mmio'. 'options' are specified in the
+ same format described for ttyS above; if unspecified,
+ the h/w is not re-initialized.
+
hvc Use the hypervisor console device . This is for
both Xen and PowerPC hypervisors.
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index e0fb5f0..5f41a9c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3456,12 +3456,17 @@ static int univ8250_console_setup(struct console *co,
char *options)
*
* Only attempts to match console command lines of the form:
* console=uart<>,io|mmio|mmio32,,
- * console=uart<>,,options
+ * console=uart<>,0x,
* This form is used to register an initial earlycon boot console and
* replace it with the serial8250_console at 8250 driver init.
*
* Performs console setup for a match (as required by interface)
*
+ * ** HACK ALERT **
+ * If no are specified, then assume the h/w is already setup.
+ * This was the undocumented behavior of the original implementation so
+ * it is cast in stone forever.
+ *
* Returns 0 if console matches; otherwise non-zero to use default matching
*/
static int univ8250_console_match(struct console *co, char *name, int idx,
@@ -3491,6 +3496,14 @@ static int univ8250_console_match(struct console *co,
char *name, int idx,
continue;
co->index = i;
+
+ /* if no line settings, then assume h/w was setup */
+ if (!options) {
+ /* link port to console */
+ port->cons = co;
+ return 0;
+ }
+
return univ8250_console_setup(co, options);
}
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index e95ebfe..8e11968 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -105,21 +105,6 @@ static void __init early_serial8250_write(struct console
*console,
serial8250_early_out(port, UART_IER, ier);
}
-static unsigned int __init probe_baud(struct uart_port *port)
-{
- unsigned char lcr, dll, dlm;
- unsigned int quot;
-
- lcr = serial8250_early_in(port, UART_LCR);
- serial8250_early_out(port, UART_LCR, lcr | UART_LCR_DLAB);
- dll = serial8250_early_in(port, UART_DLL);
- dlm = serial8250_early_in(port, UART_DLM);
- serial8250_early_out(port, UART_LCR, lcr);
-
- quot = (dlm << 8) | dll;
- return (port->uartclk / 16) / quot;
-}
-
static void __init init_port(struct earlycon_device *device)
{
struct uart_port *port = &device->port;
@@ -151,10 +136,6 @@ static int __init early_serial8250_setup(struct
earlycon_device *device,
struct uart_port *port = &device->port;
unsigned int ier;
- device->baud = probe_baud(&device->port);
- snprintf(device->options, sizeof(device->options), "%u",
-device->baud);
-
/* assu
[PATCH 2/2] soc: qcom: Add Shared Memory Manager driver
The Shared Memory Manager driver implements an interface for allocating
and accessing items in the memory area shared among all of the
processors in a Qualcomm platform.
Signed-off-by: Bjorn Andersson
---
Note that this depends on the hwspinlock device tree patches by Suman Anna [1]
and my qcom-hwspinlock driver [2].
[1] https://patchwork.kernel.org/patch/5942431/
[2] https://patchwork.kernel.org/patch/6083681/
drivers/soc/qcom/Kconfig | 7 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smem.c | 763 ++
include/linux/soc/qcom/smem.h | 14 +
4 files changed, 785 insertions(+)
create mode 100644 drivers/soc/qcom/smem.c
create mode 100644 include/linux/soc/qcom/smem.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7bd2c94..b5783a4 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -9,3 +9,10 @@ config QCOM_GSBI
functions for connecting the underlying serial UART, SPI, and I2C
devices to the output pins.
+config QCOM_SMEM
+ tristate "Qualcomm Shared Memory Manager (SMEM)"
+ depends on ARCH_QCOM
+ help
+ Say y here to enable support for the Qualcomm Shared Memory Manager.
+ The driver provides an interface to items in a heap shared among all
+ processors in a Qualcomm platform.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 4389012..91a61fb 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
+obj-$(CONFIG_QCOM_SMEM) += smem.o
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
new file mode 100644
index 000..6ac6fe5b
--- /dev/null
+++ b/drivers/soc/qcom/smem.c
@@ -0,0 +1,763 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * The Qualcomm shared memory system is a allocate only heap structure that
+ * consists of one of more memory areas that can be accessed by the processors
+ * in the SoC.
+ *
+ * All systems contains a global heap, accessible by all processors in the SoC,
+ * with a table of contents data structure (@smem_header) at the beginning of
+ * the main shared memory block.
+ *
+ * The global header contains metadata for allocations as well as a fixed list
+ * of 512 entries (@smem_global_entry) that can be initialized to reference
+ * parts of the shared memory space.
+ *
+ *
+ * In addition to this global heap a set of "private" heaps can be set up at
+ * boot time with access restrictions so that only certain processor pairs can
+ * access the data.
+ *
+ * These partitions are referenced from an optional partition table
+ * (@smem_ptable), that is found 4kB from the end of the main smem region. The
+ * partition table entries (@smem_ptable_entry) lists the involved processors
+ * (or hosts) and their location in the main shared memory region.
+ *
+ * Each partition starts with a header (@smem_partition_header) that identifies
+ * the partition and holds properties for the two internal memory regions. The
+ * two regions are cached and non-cached memory respectively. Each region
+ * contain a link list of allocation headers (@smem_private_entry) followed by
+ * their data.
+ *
+ *
+ * To synchronize allocations in the shared memory heaps a remote spinlock must
+ * be held - currently lock number 3 of the sfpb or tcsr is used for this on
all
+ * platforms.
+ *
+ */
+
+/**
+ * struct smem_proc_comm - proc_comm communication struct (legacy)
+ * @command: current command to be executed
+ * @status: status of the currently requested command
+ * @params: parameters to the command
+ */
+struct smem_proc_comm {
+ u32 command;
+ u32 status;
+ u32 params[2];
+};
+
+/**
+ * struct smem_global_entry - entry to reference smem items on the heap
+ * @allocated: boolean to indicate if this entry is used
+ * @offset:offset to the allocated space
+ * @size: size of the allocated space, 8 byte aligned
+ * @aux_base: base address for the memory region used by this unit, or 0 for
+ * the default region. bits 0,1 are reserved
+ */
+struct smem_global_entry {
+ u32 allocated;
+ u32 offset;
+ u32 size;
+ u32 aux_base; /* bits 1:0 reserved */
+};
+#define AUX_BASE_MASK 0xfffc
+
+/**
+
[PATCH 1/2] soc: qcom: Add device tree binding for SMEM
Add device tree binding documentation for the Qualcom Shared Memory
manager.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/soc/qcom/qcom,smem.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
new file mode 100644
index 000..d90f839
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
@@ -0,0 +1,49 @@
+Qualcomm Shared Memory binding
+
+This binding describes the Qualcomm Shared Memory, used to share data between
+various subsystems and OSes in Qualcomm platforms.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be:
+ "qcom,smem"
+
+- memory-region:
+ Usage: required
+ Value type:
+ Definition: handle to memory reservation for main smem memory region.
+
+- reg:
+ Usage: optional
+ Value type:
+ Definition: base address and size pair for any additional memory areas
+ of the shared memory.
+
+- hwspinlocks:
+ Usage: required
+ Value type:
+ Definition: reference to a hwspinlock used to protect allocations from
+ the shared memory
+
+= EXAMPLE
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ smem_region: smem@fa0 {
+ reg = <0xfa0 0x20>;
+ no-map;
+ };
+ };
+
+ smem@fa0 {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_region>;
+ reg = <0xfc428000 0x4000>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
--
1.8.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] blackfin: Kconfig: Let PLL_BYPASS and MPU depend on some BF_REV of BF533
On Thu, Apr 2, 2015 at 11:25 PM, Chen Gang wrote: > For allmodconfig, it uses BF533 which will cause 3 issues for common > checking: > > - The first 2 issues are about PLL_BYPASS, it needs BF_REV_0_6 (which >just match the compiler's output for __SILICON_REVISION__). > > - The last issue is about MPU, it needs BF_REV_0_5 or BF_REV_0_6 (which >just match the compiler's output for __SILICON_REVISION__). > > The related error with allmodconfig: > > CC arch/blackfin/mach-common/arch_checks.o > arch/blackfin/mach-common/arch_checks.c:24:3: error: #error "Sclk value > selected is less than minimum. Please select a proper value for SCLK > multiplier" ># error "Sclk value selected is less than minimum. Please select a proper > value for SCLK multiplier" > ^ > arch/blackfin/mach-common/arch_checks.c:28:3: error: #error "ANOMALY > 05000273, please make sure CCLK is at least 2x SCLK" ># error "ANOMALY 05000273, please make sure CCLK is at least 2x SCLK" > ^ > arch/blackfin/mach-common/arch_checks.c:51:3: error: #error the MPU will > not function safely while Anomaly 05000263 applies ># error the MPU will not function safely while Anomaly 05000263 applies > ^ > > config PLL_BYPASS > bool "Bypass PLL" > - depends on BFIN_KERNEL_CLOCK && (!BF60x) > + depends on BFIN_KERNEL_CLOCK && (!BF60x) && ((!BF533) || BF_REV_0_6) > default n > > config CLKIN_HALF > @@ -1112,6 +1112,7 @@ endchoice > comment "Memory Protection Unit" > config MPU > bool "Enable the memory protection unit" > + depends on (!BF533) || BF_REV_0_6 || BF_REV_0_5 > default n > help > Use the processor's MPU to protect applications from accessing This answers my question wrt. allmodconfig. ;) I'm not sure if this is the correct way. Isn't this the reason why we have COMPILE_TEST? -- Thanks, //richard -- 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] blackfin: Makefile: Add -D__linux__ flag for KBUILD_CFLAGS
On Fri, Apr 3, 2015 at 10:19 PM, Chen Gang wrote: > The related error with allmodconfig: BTW: How do you generate this allmodconfig? "make allmodconfig ARCH=blackfin" cannot work as you need to specify a board... > CC [M] fs/coda/psdev.o > In file included from include/linux/coda.h:64:0, >from fs/coda/psdev.c:45: > include/uapi/linux/coda.h:221:2: error: unknown type name 'u_quad_t' > u_quad_t va_size; /* file size in bytes */ > ^ > include/uapi/linux/coda.h:229:2: error: unknown type name 'u_quad_t' > u_quad_t va_bytes; /* bytes of disk space held by file */ > ^ > include/uapi/linux/coda.h:230:2: error: unknown type name 'u_quad_t' > u_quad_t va_filerev; /* file modification number */ > ^ > > Signed-off-by: Chen Gang > --- > arch/blackfin/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/blackfin/Makefile b/arch/blackfin/Makefile > index 1fce086..2ece4e3 100644 > --- a/arch/blackfin/Makefile > +++ b/arch/blackfin/Makefile > @@ -13,7 +13,7 @@ LDFLAGS_vmlinux := -X > OBJCOPYFLAGS := -O binary -R .note -R .comment -S > GZFLAGS := -9 > > -KBUILD_CFLAGS += $(call cc-option,-mno-fdpic) > +KBUILD_CFLAGS += $(call cc-option,-mno-fdpic) -D__linux__ Hmm, what compiler are you using? It's odd that __linux__ is not defined... -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, paravirt, xen: Remove the 64-bit irq_enable_sysexit pvop
[cc: Boris and Konrad. Whoops]
On Fri, Apr 3, 2015 at 3:51 PM, Andy Lutomirski wrote:
> We don't use irq_enable_sysexit on 64-bit kernels any more. Remove
> all the paravirt and Xen machinery to support it on 64-bit kernels.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> I haven't actually tested this on Xen, but it builds for me.
>
> arch/x86/ia32/ia32entry.S | 6 --
> arch/x86/include/asm/paravirt_types.h | 7 ---
> arch/x86/kernel/asm-offsets.c | 2 ++
> arch/x86/kernel/paravirt.c| 4 +++-
> arch/x86/kernel/paravirt_patch_64.c | 1 -
> arch/x86/xen/enlighten.c | 3 ++-
> arch/x86/xen/xen-asm_64.S | 16
> arch/x86/xen/xen-ops.h| 2 ++
> 8 files changed, 13 insertions(+), 28 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 5d8f987a340d..eb1eb7b70f4b 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -77,12 +77,6 @@ ENTRY(native_usergs_sysret32)
> swapgs
> sysretl
> ENDPROC(native_usergs_sysret32)
> -
> -ENTRY(native_irq_enable_sysexit)
> - swapgs
> - sti
> - sysexit
> -ENDPROC(native_irq_enable_sysexit)
> #endif
>
> /*
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index 7549b8b369e4..38a0ff9ef06e 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -160,13 +160,14 @@ struct pv_cpu_ops {
> u64 (*read_pmc)(int counter);
> unsigned long long (*read_tscp)(unsigned int *aux);
>
> +#ifdef CONFIG_X86_32
> /*
> * Atomically enable interrupts and return to userspace. This
> -* is only ever used to return to 32-bit processes; in a
> -* 64-bit kernel, it's used for 32-on-64 compat processes, but
> -* never native 64-bit processes. (Jump, not call.)
> +* is only used in 32-bit kernels. 64-bit kernels use
> +* usergs_sysret32 instead.
> */
> void (*irq_enable_sysexit)(void);
> +#endif
>
> /*
> * Switch to usermode gs and return to 64-bit usermode using
> diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
> index 9f6b9341950f..2d27ebf0aed8 100644
> --- a/arch/x86/kernel/asm-offsets.c
> +++ b/arch/x86/kernel/asm-offsets.c
> @@ -49,7 +49,9 @@ void common(void) {
> OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable);
> OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
> OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
> +#ifdef CONFIG_X86_32
> OFFSET(PV_CPU_irq_enable_sysexit, pv_cpu_ops, irq_enable_sysexit);
> +#endif
> OFFSET(PV_CPU_read_cr0, pv_cpu_ops, read_cr0);
> OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2);
> #endif
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 548d25f00c90..7563114d9c3a 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -154,7 +154,9 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers,
> void *insnbuf,
> ret = paravirt_patch_ident_64(insnbuf, len);
>
> else if (type == PARAVIRT_PATCH(pv_cpu_ops.iret) ||
> +#ifdef CONFIG_X86_32
> type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit) ||
> +#endif
> type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret32) ||
> type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret64))
> /* If operation requires a jmp, then jmp */
> @@ -371,7 +373,7 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
>
> .load_sp0 = native_load_sp0,
>
> -#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
> +#if defined(CONFIG_X86_32)
> .irq_enable_sysexit = native_irq_enable_sysexit,
> #endif
> #ifdef CONFIG_X86_64
> diff --git a/arch/x86/kernel/paravirt_patch_64.c
> b/arch/x86/kernel/paravirt_patch_64.c
> index a1da6737ba5b..0de21c62c348 100644
> --- a/arch/x86/kernel/paravirt_patch_64.c
> +++ b/arch/x86/kernel/paravirt_patch_64.c
> @@ -49,7 +49,6 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
> PATCH_SITE(pv_irq_ops, save_fl);
> PATCH_SITE(pv_irq_ops, irq_enable);
> PATCH_SITE(pv_irq_ops, irq_disable);
> - PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
> PATCH_SITE(pv_cpu_ops, usergs_sysret32);
> PATCH_SITE(pv_cpu_ops, usergs_sysret64);
> PATCH_SITE(pv_cpu_ops, swapgs);
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 81665c9f2132..3797b6b31f95 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1267,10 +1267,11 @@ static const struct pv_cpu_ops xen_cpu_ops
> __initconst = {
> .read_tscp = native_read_tscp,
>
> .iret = xen_iret,
> - .irq_enable_sysexit = xen_sysexit,
> #ifdef CONFIG_X86_64
> .usergs_sysret32 = xen_sysret32,
>
[PATCH] x86, paravirt, xen: Remove the 64-bit irq_enable_sysexit pvop
We don't use irq_enable_sysexit on 64-bit kernels any more. Remove
all the paravirt and Xen machinery to support it on 64-bit kernels.
Signed-off-by: Andy Lutomirski
---
I haven't actually tested this on Xen, but it builds for me.
arch/x86/ia32/ia32entry.S | 6 --
arch/x86/include/asm/paravirt_types.h | 7 ---
arch/x86/kernel/asm-offsets.c | 2 ++
arch/x86/kernel/paravirt.c| 4 +++-
arch/x86/kernel/paravirt_patch_64.c | 1 -
arch/x86/xen/enlighten.c | 3 ++-
arch/x86/xen/xen-asm_64.S | 16
arch/x86/xen/xen-ops.h| 2 ++
8 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 5d8f987a340d..eb1eb7b70f4b 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -77,12 +77,6 @@ ENTRY(native_usergs_sysret32)
swapgs
sysretl
ENDPROC(native_usergs_sysret32)
-
-ENTRY(native_irq_enable_sysexit)
- swapgs
- sti
- sysexit
-ENDPROC(native_irq_enable_sysexit)
#endif
/*
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 7549b8b369e4..38a0ff9ef06e 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -160,13 +160,14 @@ struct pv_cpu_ops {
u64 (*read_pmc)(int counter);
unsigned long long (*read_tscp)(unsigned int *aux);
+#ifdef CONFIG_X86_32
/*
* Atomically enable interrupts and return to userspace. This
-* is only ever used to return to 32-bit processes; in a
-* 64-bit kernel, it's used for 32-on-64 compat processes, but
-* never native 64-bit processes. (Jump, not call.)
+* is only used in 32-bit kernels. 64-bit kernels use
+* usergs_sysret32 instead.
*/
void (*irq_enable_sysexit)(void);
+#endif
/*
* Switch to usermode gs and return to 64-bit usermode using
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 9f6b9341950f..2d27ebf0aed8 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -49,7 +49,9 @@ void common(void) {
OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable);
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
+#ifdef CONFIG_X86_32
OFFSET(PV_CPU_irq_enable_sysexit, pv_cpu_ops, irq_enable_sysexit);
+#endif
OFFSET(PV_CPU_read_cr0, pv_cpu_ops, read_cr0);
OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2);
#endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 548d25f00c90..7563114d9c3a 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -154,7 +154,9 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers, void
*insnbuf,
ret = paravirt_patch_ident_64(insnbuf, len);
else if (type == PARAVIRT_PATCH(pv_cpu_ops.iret) ||
+#ifdef CONFIG_X86_32
type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit) ||
+#endif
type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret32) ||
type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret64))
/* If operation requires a jmp, then jmp */
@@ -371,7 +373,7 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
.load_sp0 = native_load_sp0,
-#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
+#if defined(CONFIG_X86_32)
.irq_enable_sysexit = native_irq_enable_sysexit,
#endif
#ifdef CONFIG_X86_64
diff --git a/arch/x86/kernel/paravirt_patch_64.c
b/arch/x86/kernel/paravirt_patch_64.c
index a1da6737ba5b..0de21c62c348 100644
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -49,7 +49,6 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
PATCH_SITE(pv_irq_ops, save_fl);
PATCH_SITE(pv_irq_ops, irq_enable);
PATCH_SITE(pv_irq_ops, irq_disable);
- PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
PATCH_SITE(pv_cpu_ops, usergs_sysret32);
PATCH_SITE(pv_cpu_ops, usergs_sysret64);
PATCH_SITE(pv_cpu_ops, swapgs);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 81665c9f2132..3797b6b31f95 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1267,10 +1267,11 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst
= {
.read_tscp = native_read_tscp,
.iret = xen_iret,
- .irq_enable_sysexit = xen_sysexit,
#ifdef CONFIG_X86_64
.usergs_sysret32 = xen_sysret32,
.usergs_sysret64 = xen_sysret64,
+#else
+ .irq_enable_sysexit = xen_sysexit,
#endif
.load_tr_desc = paravirt_nop,
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 985fc3ee0973..a2cabb8bd6bf 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -
Re: [PATCH] blackfin: include: asm: pgtable: Define dummy pgprot_writecombine
On Fri, Apr 3, 2015 at 10:36 PM, Chen Gang wrote:
> It is copied from asm-generic, the related error with allmodconfig:
>
> CC [M] sound/core/pcm_native.o
> sound/core/pcm_native.c: In function 'snd_pcm_lib_default_mmap':
> sound/core/pcm_native.c:3387:24: error: implicit declaration of function
> 'pgprot_writecombine' [-Werror=implicit-function-declaration]
> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
> ^
> sound/core/pcm_native.c:3387:22: error: incompatible types when assigning
> to type 'pgprot_t {aka struct }' from type 'int'
> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
> ^
>
> Signed-off-by: Chen Gang
> ---
> arch/blackfin/include/asm/pgtable.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/blackfin/include/asm/pgtable.h
> b/arch/blackfin/include/asm/pgtable.h
> index b88a155..3e730d9 100644
> --- a/arch/blackfin/include/asm/pgtable.h
> +++ b/arch/blackfin/include/asm/pgtable.h
> @@ -36,6 +36,7 @@ typedef pte_t *pte_addr_t;
> #define PAGE_READONLY __pgprot(0) /* these mean nothing to
> NO_MM */
> #define PAGE_KERNEL__pgprot(0) /* these mean nothing to
> NO_MM */
> #define pgprot_noncached(prot) (prot)
> +#define pgprot_writecombinepgprot_noncached
This looks fishy as blackfin's pgtable.h already includes asm-generic/pgtable.h.
So, copy&pasting pgprot_writecombine shouldn't be needed.
--
Thanks,
//richard
--
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: samples: kdbus: kdbus-workers: Define dummy prime_new()
On Sat, Apr 4, 2015 at 12:17 AM, Chen Gang wrote: > Quite a few of architures (e.g. blackfin, cris, frv ...) do not support > memfd_create system call which is used in prime_new(). So define a dummy > one. Don't paper over the issue, just wire up the system call on blackfin. For an example see: commit f3240c1f6d18591b2c1ef33ed18d5ca91e62c104 Author: Hans-Christian Egtvedt Date: Thu Dec 25 19:58:50 2014 +0100 avr32: wire up missing syscalls -- Thanks, //richard -- 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: sched: Improve load balancing in the presence of idle CPUs
On Wed, 2015-04-01 at 22:59 -0700, Jason Low wrote:
> On Wed, 2015-04-01 at 18:04 +0100, Morten Rasmussen wrote:
> > On Wed, Apr 01, 2015 at 07:49:56AM +0100, Preeti U Murthy wrote:
>
> > > I am sorry I don't quite get this. Can you please elaborate?
> >
> > I think the scenario is that we are in nohz_idle_balance() and decide to
> > bail out because we have pulled some tasks, but before leaving
> > nohz_idle_balance() we want to check if more balancing is necessary
> > using nohz_kick_needed() and potentially kick somebody to continue.
>
> Also, below is an example patch.
>
> (Without the conversion to idle_cpu(), the check for rq->idle_balance
> would not be accurate anymore)
>
> ---
> kernel/sched/fair.c | 17 ++---
> 1 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fdae26e..7749a14 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7620,6 +7620,8 @@ out:
> }
>
> #ifdef CONFIG_NO_HZ_COMMON
> +static inline bool nohz_kick_needed(struct rq *rq);
> +
> /*
> * In CONFIG_NO_HZ_COMMON case, the idle balance kickee will do the
> * rebalancing for all the cpus for whom scheduler ticks are stopped.
> @@ -7629,6 +7631,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum
> cpu_idle_type idle)
> int this_cpu = this_rq->cpu;
> struct rq *rq;
> int balance_cpu;
> + bool done_balancing = false;
>
> if (idle != CPU_IDLE ||
> !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu)))
> @@ -7644,7 +7647,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum
> cpu_idle_type idle)
>* balancing owner will pick it up.
>*/
> if (need_resched())
> - break;
> + goto end;
>
> rq = cpu_rq(balance_cpu);
>
> @@ -7663,9 +7666,12 @@ static void nohz_idle_balance(struct rq *this_rq, enum
> cpu_idle_type idle)
> if (time_after(this_rq->next_balance, rq->next_balance))
> this_rq->next_balance = rq->next_balance;
> }
> + done_balancing = true;
> nohz.next_balance = this_rq->next_balance;
> end:
> clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
> + if (!done_balancing && nohz_kick_needed(this_rq))
> + nohz_balancer_kick();
> }
>
>
I think we can get rid of the done_balancing boolean
and make it a bit easier to read if we change the above code to
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bcfe320..08317dc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7557,8 +7557,13 @@ static void nohz_idle_balance(struct rq *this_rq, enum
cpu_idle_type idle)
* work being done for other cpus. Next load
* balancing owner will pick it up.
*/
- if (need_resched())
- break;
+ if (need_resched()) {
+ /* preparing to bail, kicking other cpu to continue */
+ clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
+ if (nohz_kick_needed(this_rq))
+ nohz_balance_kick();
+ return;
+ }
rq = cpu_rq(balance_cpu);
Thanks.
Tim
--
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] usb: musb: Kconfig: Depend on some machines under blackfin
On 4/4/15 06:03, Richard Weinberger wrote: > On Fri, Apr 3, 2015 at 11:51 PM, Chen Gang > wrote: >> Under blackfin, only bf527, bf548 and bf609 may use musb. The related >> error with allmodconfig: >> >> CC [M] drivers/usb/misc/trancevibrator.o >> In file included from drivers/usb/musb/musb_core.h:70:0, >>from drivers/usb/musb/musb_core.c:103: >> drivers/usb/musb/musb_core.c: In function 'musb_indexed_ep_select': >> drivers/usb/musb/musb_regs.h:458:32: error: 'USB_INDEX' undeclared (first >> use in this function) >>#define MUSB_INDEX USB_OFFSET(USB_INDEX) /* 8 bit */ >> ^ >> >> Signed-off-by: Chen Gang >> --- >> drivers/usb/musb/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig >> index 39db8b6..5fca898 100644 >> --- a/drivers/usb/musb/Kconfig >> +++ b/drivers/usb/musb/Kconfig >> @@ -6,7 +6,7 @@ >> # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller >> config USB_MUSB_HDRC >> tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' >> - depends on (USB || USB_GADGET) >> + depends on (USB || USB_GADGET) && (!BLACKFIN || (BLACKFIN && (BF527 >> || BF548 || BF609))) > > This is ugly. > Can't you add a new Kconfig symbol in arch/blackfin and change the > #ifndef CONFIG_BLACKFIN > in drivers/usb/musb/musb_regs.h to it? > For me, for configuration, we need to try to finish them in Kconfig and keep the .c or .h source code no touch. But it is really not quite well to let machine details (e.g. BF527, BF548, BF609) in the outside of "arch/blackfin". So, I guess, we need to add new config value HAVE_MUSB for it in patch v2. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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/
Please respond!!!
Please respond!!! Hello friend! I would like to contact you personally for an important proposal that could of interest to you. I send this email only to know if this email address is functional. I have something very important to discuss with you. Contact me for details by: Email: fernrodyu...@aol.jp with your direct contacts. Kind regards. Antonio Vinal. -- 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/
samples: kdbus: kdbus-workers: Define dummy prime_new()
Quite a few of architures (e.g. blackfin, cris, frv ...) do not support
memfd_create system call which is used in prime_new(). So define a dummy
one.
The related error (with allmodconfig under blackfin):
CC [M] samples/kfifo/inttype-example.o
samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ undeclared
(first use in this function)
p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
^
samples/kdbus/kdbus-workers.c:930:18: note: each undeclared identifier is
reported only once for each function it appears in
make[2]: *** [samples/kdbus/kdbus-workers] Error 1
Signed-off-by: Chen Gang
---
samples/kdbus/kdbus-workers.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/samples/kdbus/kdbus-workers.c b/samples/kdbus/kdbus-workers.c
index d331e01..0affd23 100644
--- a/samples/kdbus/kdbus-workers.c
+++ b/samples/kdbus/kdbus-workers.c
@@ -910,6 +910,8 @@ exit:
*
*/
+#ifdef __NR_memfd_create
+
static int prime_new(struct prime **out)
{
struct prime *p;
@@ -954,6 +956,15 @@ error:
return r;
}
+#else
+
+static int prime_new(struct prime **out)
+{
+ return err("the architecture does not support memfd_create");
+}
+
+#endif
+
static void prime_free(struct prime *p)
{
if (!p)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 08/15] clockevents/drivers: Add STM32 Timer driver
On Sat, Apr 4, 2015 at 1:09 AM, Andy Shevchenko
wrote:
> On Fri, Apr 3, 2015 at 8:01 PM, Maxime Coquelin
> wrote:
>> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
>> The drivers detects whether the time is 16 or 32 bits, and applies a
>> 1024 prescaler value if it is 16 bits.
[]
>> + pr_err("failed to get clock for clockevent (%d)\n", ret);
>
> Why not dev_err(); ?
Understood, because it's device tree with lack of something like of_err();
--
With Best Regards,
Andy Shevchenko
--
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/memory: print also a_ops->readpage in print_bad_pte
On Fri, 03 Apr 2015 20:18:18 +0300 Konstantin Khlebnikov wrote: > A lot of filesystems use generic_file_mmap() and filemap_fault(), > f_op->mmap and vm_ops->fault aren't enough to identify filesystem. > > This prints file name, vm_ops->fault, f_op->mmap and a_ops->readpage > (which is almost always implemented and filesystem-specific). > > Example: > > [ 23.676410] BUG: Bad page map in process sh pte:1b7e6025 pmd:19bbd067 > [ 23.676887] page:ea6df980 count:4 mapcount:1 > mapping:8800196426c0 index:0x97 > [ 23.677481] flags: 0x10c(referenced|uptodate) > [ 23.677896] page dumped because: bad pte > [ 23.678205] addr:7f52fcb17000 vm_flags:0075 anon_vma: > (null) mapping:8800196426c0 index:97 > [ 23.678922] file:libc-2.19.so fault:filemap_fault > mmap:generic_file_readonly_mmap readpage:v9fs_vfs_readpage Is that why we print these out? Just to identify the fs type? There's always vma->vm_file->f_inode->i_sb->s_magic ;) -- 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 08/15] clockevents/drivers: Add STM32 Timer driver
On Fri, Apr 3, 2015 at 8:01 PM, Maxime Coquelin
wrote:
> STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
> The drivers detects whether the time is 16 or 32 bits, and applies a
> 1024 prescaler value if it is 16 bits.
>
Few comments below.
> Reviewed-by: Linus Walleij
> Tested-by: Chanwoo Choi
> Signed-off-by: Maxime Coquelin
> ---
> drivers/clocksource/Kconfig | 8 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-stm32.c | 184
> ++
> 3 files changed, 193 insertions(+)
> create mode 100644 drivers/clocksource/timer-stm32.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index b82e58b..519304b 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -101,6 +101,14 @@ config CLKSRC_EFM32
> Support to use the timers of EFM32 SoCs as clock source and clock
> event device.
>
> +config CLKSRC_STM32
> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
> + select CLKSRC_MMIO
> + default ARCH_STM32
> + help
> + Support to use the timers of STM32 SoCs as clock event device.
> +
> config ARM_ARCH_TIMER
> bool
> select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 1c9a643..525dafe 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_ARCH_NSPIRE) += zevio-timer.o
> obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm_kona_timer.o
> obj-$(CONFIG_CADENCE_TTC_TIMER)+= cadence_ttc_timer.o
> obj-$(CONFIG_CLKSRC_EFM32) += time-efm32.o
> +obj-$(CONFIG_CLKSRC_STM32) += timer-stm32.o
> obj-$(CONFIG_CLKSRC_EXYNOS_MCT)+= exynos_mct.o
> obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
> obj-$(CONFIG_FSL_FTM_TIMER)+= fsl_ftm_timer.o
> diff --git a/drivers/clocksource/timer-stm32.c
> b/drivers/clocksource/timer-stm32.c
> new file mode 100644
> index 000..fad2e2e
> --- /dev/null
> +++ b/drivers/clocksource/timer-stm32.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author: Maxime Coquelin
> + * License terms: GNU General Public License (GPL), version 2
> + *
> + * Inspired by time-efm32.c from Uwe Kleine-Koenig
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define TIM_CR10x00
> +#define TIM_DIER 0x0c
> +#define TIM_SR 0x10
> +#define TIM_EGR0x14
> +#define TIM_PSC0x28
> +#define TIM_ARR0x2c
> +
> +#define TIM_CR1_CENBIT(0)
> +#define TIM_CR1_OPMBIT(3)
> +#define TIM_CR1_ARPE BIT(7)
> +
> +#define TIM_DIER_UIE BIT(0)
> +
> +#define TIM_SR_UIF BIT(0)
> +
> +#define TIM_EGR_UG BIT(0)
> +
> +struct stm32_clock_event_ddata {
> + struct clock_event_device evtdev;
> + unsigned periodic_top;
> + void __iomem *base;
> +};
> +
> +static void stm32_clock_event_set_mode(enum clock_event_mode mode,
> + struct clock_event_device *evtdev)
> +{
> + struct stm32_clock_event_ddata *data =
> + container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> + void *base = data->base;
> +
> + switch (mode) {
> + case CLOCK_EVT_MODE_PERIODIC:
> + writel_relaxed(data->periodic_top, base + TIM_ARR);
> + writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
> + break;
> +
> + case CLOCK_EVT_MODE_ONESHOT:
> + default:
> + writel_relaxed(0, base + TIM_CR1);
> + break;
> + }
> +}
> +
> +static int stm32_clock_event_set_next_event(unsigned long evt,
> + struct clock_event_device *evtdev)
> +{
> + struct stm32_clock_event_ddata *data =
> + container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
> +
> + writel_relaxed(evt, data->base + TIM_ARR);
> + writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
> + data->base + TIM_CR1);
> +
> + return 0;
> +}
> +
> +static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
> +{
> + struct stm32_clock_event_ddata *data = dev_id;
> +
> + writel_relaxed(0, data->base + TIM_SR);
> +
> + data->evtdev.event_handler(&data->evtdev);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static struct stm32_clock_event_ddata clock_event_ddata = {
> + .evtdev = {
> + .name = "stm32 clockevent",
> + .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> + .set_mode = stm32_clock_event_set_mode,
> + .set_next_event = stm32_clock_event_set_next_event,
> + .rating = 200,
> +
Re: [PATCH] mm, mempool: kasan: poison mempool elements
On Fri, 03 Apr 2015 17:47:47 +0300 Andrey Ryabinin
wrote:
> Mempools keep allocated objects in reserved for situations
> when ordinary allocation may not be possible to satisfy.
> These objects shouldn't be accessed before they leave
> the pool.
> This patch poison elements when get into the pool
> and unpoison when they leave it. This will let KASan
> to detect use-after-free of mempool's elements.
>
> ...
>
> +static void kasan_poison_element(mempool_t *pool, void *element)
> +{
> + if (pool->alloc == mempool_alloc_slab)
> + kasan_slab_free(pool->pool_data, element);
> + if (pool->alloc == mempool_kmalloc)
> + kasan_kfree(element);
> + if (pool->alloc == mempool_alloc_pages)
> + kasan_free_pages(element, (unsigned long)pool->pool_data);
> +}
We recently discovered that mempool pages (from alloc_pages, not slab)
can be in highmem. But kasan apepars to handle highmem pages (by
baling out) so we should be OK with that.
Can kasan be taught to use kmap_atomic() or is it more complicated than
that? It probably isn't worthwhile - highmem pages don'[t get used by the
kernel much and most bugs will be found using 64-bit testing anyway.
--
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 10/15] serial: stm32-usart: Add STM32 USART Driver
On Fri, Apr 3, 2015 at 8:01 PM, Maxime Coquelin wrote: > This drivers adds support to the STM32 USART controller, which is a > standard serial driver. > Few minor comments. > Tested-by: Chanwoo Choi > Signed-off-by: Maxime Coquelin > --- > drivers/tty/serial/Kconfig | 17 + > drivers/tty/serial/Makefile | 1 + > drivers/tty/serial/stm32-usart.c | 736 > +++ > include/uapi/linux/serial_core.h | 3 + > 4 files changed, 757 insertions(+) > create mode 100644 drivers/tty/serial/stm32-usart.c > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index d2501f0..880cb4f 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1611,6 +1611,23 @@ config SERIAL_SPRD_CONSOLE > with "earlycon" on the kernel command line. The console is > enabled when early_param is processed. > > +config SERIAL_STM32 > + tristate "STMicroelectronics STM32 serial port support" > + select SERIAL_CORE > + depends on ARM || COMPILE_TEST > + help > + This driver is for the on-chip Serial Controller on > + STMicroelectronics STM32 MCUs. > + USART supports Rx & Tx functionality. > + It support all industry standard baud rates. > + > + If unsure, say N. > + > +config SERIAL_STM32_CONSOLE > + bool "Support for console on STM32" > + depends on SERIAL_STM32=y > + select SERIAL_CORE_CONSOLE > + > endmenu > > config SERIAL_MCTRL_GPIO > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > index 599be4b..67c5023 100644 > --- a/drivers/tty/serial/Makefile > +++ b/drivers/tty/serial/Makefile > @@ -95,6 +95,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART) += fsl_lpuart.o > obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)+= digicolor-usart.o > obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o > obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o > +obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o > > # GPIOLIB helpers for modem control lines > obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o > diff --git a/drivers/tty/serial/stm32-usart.c > b/drivers/tty/serial/stm32-usart.c > new file mode 100644 > index 000..61e0e19 > --- /dev/null > +++ b/drivers/tty/serial/stm32-usart.c > @@ -0,0 +1,736 @@ > +/* > + * Copyright (C) Maxime Coquelin 2015 > + * Author: Maxime Coquelin > + * License terms: GNU General Public License (GPL), version 2 > + * > + * Inspired by st-asc.c from STMicroelectronics (c) > + */ > + > +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) > +#define SUPPORT_SYSRQ > +#endif > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRIVER_NAME "stm32-usart" > + > +/* Register offsets */ > +#define USART_SR 0x00 > +#define USART_DR 0x04 > +#define USART_BRR 0x08 > +#define USART_CR1 0x0c > +#define USART_CR2 0x10 > +#define USART_CR3 0x14 > +#define USART_GTPR 0x18 > + > +/* USART_SR */ > +#define USART_SR_PEBIT(0) > +#define USART_SR_FEBIT(1) > +#define USART_SR_NFBIT(2) > +#define USART_SR_ORE BIT(3) > +#define USART_SR_IDLE BIT(4) > +#define USART_SR_RXNE BIT(5) > +#define USART_SR_TCBIT(6) > +#define USART_SR_TXE BIT(7) > +#define USART_SR_LBD BIT(8) > +#define USART_SR_CTS BIT(9) > +#define USART_SR_ERR_MASK (USART_SR_LBD | USART_SR_ORE | \ > +USART_SR_FE | USART_SR_PE) > +/* Dummy bits */ > +#define USART_SR_DUMMY_RX BIT(16) > + > +/* USART_DR */ > +#define USART_DR_MASK GENMASK(8, 0) > + > +/* USART_BRR */ > +#define USART_BRR_DIV_F_MASK GENMASK(3, 0) > +#define USART_BRR_DIV_M_MASK GENMASK(15, 4) > +#define USART_BRR_DIV_M_SHIFT 4 > + > +/* USART_CR1 */ > +#define USART_CR1_SBK BIT(0) > +#define USART_CR1_RWU BIT(1) > +#define USART_CR1_RE BIT(2) > +#define USART_CR1_TE BIT(3) > +#define USART_CR1_IDLEIE BIT(4) > +#define USART_CR1_RXNEIE BIT(5) > +#define USART_CR1_TCIE BIT(6) > +#define USART_CR1_TXEIEBIT(7) > +#define USART_CR1_PEIE BIT(8) > +#define USART_CR1_PS BIT(9) > +#define USART_CR1_PCE BIT(10) > +#define USART_CR1_WAKE BIT(11) > +#define USART_CR1_MBIT(12) > +#define USART_CR1_UE BIT(13) > +#define USART_CR1_OVER8BIT(15) > +#define USART_CR1_IE_MASK GENMASK(8, 4) > + > +/* USART_CR2 */ > +#define USART_CR2_ADD_MASK GENMASK(3, 0) > +#define USART_CR2_LBDL BIT(5) > +#define USART_CR2_LBDIEBIT(6) > +#define USART_CR2_LBCL BIT(8) > +#define USART_CR2_CPHA
Re: [PATCH] usb: musb: Kconfig: Depend on some machines under blackfin
On Fri, Apr 3, 2015 at 11:51 PM, Chen Gang wrote: > Under blackfin, only bf527, bf548 and bf609 may use musb. The related > error with allmodconfig: > > CC [M] drivers/usb/misc/trancevibrator.o > In file included from drivers/usb/musb/musb_core.h:70:0, >from drivers/usb/musb/musb_core.c:103: > drivers/usb/musb/musb_core.c: In function 'musb_indexed_ep_select': > drivers/usb/musb/musb_regs.h:458:32: error: 'USB_INDEX' undeclared (first > use in this function) >#define MUSB_INDEX USB_OFFSET(USB_INDEX) /* 8 bit */ > ^ > > Signed-off-by: Chen Gang > --- > drivers/usb/musb/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index 39db8b6..5fca898 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -6,7 +6,7 @@ > # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller > config USB_MUSB_HDRC > tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' > - depends on (USB || USB_GADGET) > + depends on (USB || USB_GADGET) && (!BLACKFIN || (BLACKFIN && (BF527 > || BF548 || BF609))) This is ugly. Can't you add a new Kconfig symbol in arch/blackfin and change the #ifndef CONFIG_BLACKFIN in drivers/usb/musb/musb_regs.h to it? -- Thanks, //richard -- 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: cma: add functions to get region pages counters
On Fri, 03 Apr 2015 15:42:40 +0300 Stefan Strogin
wrote:
> From: Dmitry Safonov
>
> Here are two functions that provide interface to compute/get used size
> and size of biggest free chunk in cma region. Add that information to debugfs.
>
> ...
>
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -53,6 +53,36 @@ unsigned long cma_get_size(const struct cma *cma)
> return cma->count << PAGE_SHIFT;
> }
>
> +unsigned long cma_get_used(struct cma *cma)
> +{
> + unsigned long ret = 0;
> +
> + mutex_lock(&cma->lock);
> + /* pages counter is smaller than sizeof(int) */
> + ret = bitmap_weight(cma->bitmap, (int)cma->count);
> + mutex_unlock(&cma->lock);
> +
> + return ret << cma->order_per_bit;
> +}
> +
> +unsigned long cma_get_maxchunk(struct cma *cma)
> +{
> + unsigned long maxchunk = 0;
> + unsigned long start, end = 0;
> +
> + mutex_lock(&cma->lock);
> + for (;;) {
> + start = find_next_zero_bit(cma->bitmap, cma->count, end);
> + if (start >= cma->count)
> + break;
> + end = find_next_bit(cma->bitmap, cma->count, start);
> + maxchunk = max(end - start, maxchunk);
> + }
> + mutex_unlock(&cma->lock);
> +
> + return maxchunk << cma->order_per_bit;
> +}
This will cause unused code to be included in cma.o when
CONFIG_CMA_DEBUGFS=n. Please review the below patch which moves it all
into cma_debug.c
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -33,6 +33,28 @@ static int cma_debugfs_get(void *data, u64 *val)
>
> DEFINE_SIMPLE_ATTRIBUTE(cma_debugfs_fops, cma_debugfs_get, NULL, "%llu\n");
>
> +static int cma_used_get(void *data, u64 *val)
> +{
> + struct cma *cma = data;
> +
> + *val = cma_get_used(cma);
> +
> + return 0;
> +}
We have cma_used_get() and cma_get_used(). Confusing! Can we think of
better names for one or both of them?
From: Andrew Morton
Subject: mm-cma-add-functions-to-get-region-pages-counters-fix
move debug code from cma.c into cma_debug.c so it doesn't get included in
CONFIG_CMA_DEBUGFS=n builds
Cc: Dmitry Safonov
Cc: Michal Nazarewicz
Cc: Stefan Strogin
Cc: Marek Szyprowski
Cc: Joonsoo Kim
Cc: Pintu Kumar
Cc: Weijie Yang
Cc: Laurent Pinchart
Cc: Vyacheslav Tyrtov
Cc: Aleksei Mateosian
Signed-off-by: Andrew Morton
---
include/linux/cma.h |2 --
mm/cma.c| 30 --
mm/cma_debug.c | 31 +++
3 files changed, 31 insertions(+), 32 deletions(-)
diff -puN
include/linux/cma.h~mm-cma-add-functions-to-get-region-pages-counters-fix
include/linux/cma.h
--- a/include/linux/cma.h~mm-cma-add-functions-to-get-region-pages-counters-fix
+++ a/include/linux/cma.h
@@ -18,8 +18,6 @@ struct cma;
extern unsigned long totalcma_pages;
extern phys_addr_t cma_get_base(const struct cma *cma);
extern unsigned long cma_get_size(const struct cma *cma);
-extern unsigned long cma_get_used(struct cma *cma);
-extern unsigned long cma_get_maxchunk(struct cma *cma);
extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
diff -puN mm/cma.c~mm-cma-add-functions-to-get-region-pages-counters-fix
mm/cma.c
--- a/mm/cma.c~mm-cma-add-functions-to-get-region-pages-counters-fix
+++ a/mm/cma.c
@@ -53,36 +53,6 @@ unsigned long cma_get_size(const struct
return cma->count << PAGE_SHIFT;
}
-unsigned long cma_get_used(struct cma *cma)
-{
- unsigned long ret = 0;
-
- mutex_lock(&cma->lock);
- /* pages counter is smaller than sizeof(int) */
- ret = bitmap_weight(cma->bitmap, (int)cma->count);
- mutex_unlock(&cma->lock);
-
- return ret << cma->order_per_bit;
-}
-
-unsigned long cma_get_maxchunk(struct cma *cma)
-{
- unsigned long maxchunk = 0;
- unsigned long start, end = 0;
-
- mutex_lock(&cma->lock);
- for (;;) {
- start = find_next_zero_bit(cma->bitmap, cma->count, end);
- if (start >= cma->count)
- break;
- end = find_next_bit(cma->bitmap, cma->count, start);
- maxchunk = max(end - start, maxchunk);
- }
- mutex_unlock(&cma->lock);
-
- return maxchunk << cma->order_per_bit;
-}
-
static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
int align_order)
{
diff -puN mm/cma_debug.c~mm-cma-add-functions-to-get-region-pages-counters-fix
mm/cma_debug.c
--- a/mm/cma_debug.c~mm-cma-add-functions-to-get-region-pages-counters-fix
+++ a/mm/cma_debug.c
@@ -22,6 +22,37 @@ struct cma_mem {
static struct dentry *cma_debugfs_root;
+static unsigned long cma_get_used(struct cma *cma)
+{
+ unsigned long ret = 0;
+
+ mutex_lock(&cma->lock);
+ /* pages counter is smaller than sizeof(int) */
+ ret = bitmap_weight(cma->bitmap, (int)cma->count);
+ mutex_unlock(&cma->lock);
+
+ return ret << cma->order_
Re: [PATCH] ARM: at91/dt: sama5d3 xplained: add phy address for macb1
On Fri, Apr 03, 2015 at 01:55:07PM -0700, Olof Johansson wrote: > On Fri, Apr 03, 2015 at 10:43:40AM +0200, Nicolas Ferre wrote: > > Le 31/03/2015 10:56, Nicolas Ferre a écrit : > > > After 57a38effa598 (net: phy: micrel: disable broadcast for > > > KSZ8081/KSZ8091) > > > the macb1 interface refuses to work properly because it tries > > > to cling to address 0 which isn't able to communicate in broadcast with > > > the mac anymore. The micrel phy on the board is actually configured > > > to show up at address 1. > > > Adding the phy node and its real address fixes the issue. > > > > > > Signed-off-by: Nicolas Ferre > > > Cc: Johan Hovold > > > Cc: #3.19 > > > --- > > > > Arnd, Olof, Kevin, > > > > It seems late but, is it possible to queue this patch as a 4.0 fixes? > > > > Without it, the 10/100 Ethernet on sama5d3 doesn't work if it's not used > > by u-boot previously. > > Sure, resend it to a...@kernel.org. Nevermind, I ended up picking it up from the list. Applied. -Olof -- 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] usb: musb: Kconfig: Depend on some machines under blackfin
Under blackfin, only bf527, bf548 and bf609 may use musb. The related error with allmodconfig: CC [M] drivers/usb/misc/trancevibrator.o In file included from drivers/usb/musb/musb_core.h:70:0, from drivers/usb/musb/musb_core.c:103: drivers/usb/musb/musb_core.c: In function 'musb_indexed_ep_select': drivers/usb/musb/musb_regs.h:458:32: error: 'USB_INDEX' undeclared (first use in this function) #define MUSB_INDEX USB_OFFSET(USB_INDEX) /* 8 bit */ ^ Signed-off-by: Chen Gang --- drivers/usb/musb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 39db8b6..5fca898 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -6,7 +6,7 @@ # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' - depends on (USB || USB_GADGET) + depends on (USB || USB_GADGET) && (!BLACKFIN || (BLACKFIN && (BF527 || BF548 || BF609))) help Say Y here if your system has a dual role high speed USB controller based on the Mentor Graphics silicon IP. Then -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/Kconfig: Fix allnoconfig without explicitly specified ARCH
On Fri, 2015-04-03 at 19:23 +0200, Borislav Petkov wrote: > On Fri, Apr 03, 2015 at 05:33:03PM +0200, Paul Bolle wrote: > > Well, "when building on 32 bits" it currently suffices to do: > > make allnoconfig > > > > and the patch changes that. > > Hmm, so this would need more staring. The fact that 64-bit needs to set > CONFIG_64BIT, we would need a way to say: > > option allnoconfig_y if ARCH = "x86" > > And Kconfig doesn't support that yet... The fact that "make allnoconfig" and "make allyesconfig" can give you a .config for another subarchitecture is annoying. I think it would be nice if we teach those make targets (through tweaks in Kconfig files and/or Makefiles) to avoid doing that. Not sure, yet, how a clean way to do that might look like, sorry. 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: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
On Fri, Apr 03, 2015 at 10:26:24PM +0200, Pavel Machek wrote:
> > > + - power-gpios: Reference to the GPIO that controls the power for the
> > > chip.
> >
> > You're using power-gpios in documentation only.
>
> Which is ok, because generic code adds "-gpios" itself.
Do you think you need this part:
+ if (!of_find_property(node, "gpios", NULL)) {
+ dev_err(&client->dev, "No gpio node\n");
+ return -EINVAL;
+ }
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi Pavel,
On Fri, Apr 03, 2015 at 10:26:24PM +0200, Pavel Machek wrote:
>
> Documentation for adp1653 binding.
>
> ---
>
> > Please split this as Javier suggested. I'd think both could go through
> > the media-tree unless someone objects.
>
> Please apply.
>
> > > + - power-gpios: Reference to the GPIO that controls the power for the
> > > chip.
> >
> > You're using power-gpios in documentation only.
>
> Which is ok, because generic code adds "-gpios" itself.
>
> > The spec refers to this by "EN". How about "en-gpios" instead? This
> > definitely isn't about power, but about resetting the chip. It gets the
> > power through another pin.
>
> It controls power of the chip. Noone gets _power_ through gpios,
> hopefully. Yes, I can rename it. "en-gpios" is too ugly to
> live. Sebastian suggested "enable". Hope that's okay with you.
"enable-gpios" sounds fine for me.
>
> Pavel
>
> new file mode 100644
> index 000..da9934a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> @@ -0,0 +1,37 @@
> +* Analog Devices ADP1653 flash LED driver
> +
> +Required Properties:
> +
> + - compatible: Must contain be "adi,adp1653"
> +
> + - reg: I2C slave address
> +
> + - power-gpios: Reference to the GPIO that controls the power for the chip.
> +
> +There are two LED outputs available - flash and indicator. One LED is
> +represented by one child node, nodes need to be named "flash" and
> "indicator".
> +
> +Required properties of the LED child node:
> +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Required properties of the flash LED child node:
> +
> +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> + adp1653: led-controller@30 {
> + compatible = "adi,adp1653";
> + reg = <0x30>;
> + power-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> +
> + flash {
> + flash-timeout-us = <50>;
> + flash-max-microamp = <32>;
> + max-microamp = <5>;
> + };
> + indicator {
> + max-microamp = <17500>;
> + };
> + };
>
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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/
pmem and i_dio_count overhead
Jens, one of your patches from October 2013 never made it
to the kernel, but would be beneficial for pmem. It helps
IOPS about 15%.
Original patch: https://lkml.org/lkml/2013/10/24/130
> From Jens Axboe
> Subject [PATCH 05/11] direct-io: only inc/dec inode->i_dio_count for file
> systems
> Date Thu, 24 Oct 2013 10:25:58 +0100
>
> We don't need truncate protection for block devices, so add a flag
> bypassing this cache line dirtying twice for every IO. This easily
> contributes to 5-10% of the CPU time on high IOPS O_DIRECT testing.
Here are perf top results while running fio to pmem devices
using memcpy with non-temporal load and store instructions:
20.54% [pmem] [k] pmem_do_bvec.isra.6
10.13% [kernel] [k] do_blockdev_direct_IO
5.93% [kernel] [k] inode_dio_done
4.46% [kernel] [k] bio_endio
3.07% fio [.] get_io_u
2.08% fio [.] do_io
Inside do_blockdev_direct_io (10%), 60% of the time is spent
atomically incrementing i_dio_count:
│ static inline void atomic_inc(atomic_t *v)
│ {
│ asm volatile(LOCK_PREFIX "incl %0"
0.06 │ 225: lock incl 0x134(%r14)
│ atomic_inc(&inode->i_dio_count);
│
│ retval = 0;
│ sdio.blkbits = blkbits;
│ sdio.blkfactor = i_blkbits - blkbits;
│ sdio.block_in_file = offset >> blkbits;
60.31 │mov-0x1d0(%rbp),%rdx
0.16 │mov%r12d,%ecx
│ */
│ atomic_inc(&inode->i_dio_count);
│
│ retval = 0;
│ sdio.blkbits = blkbits;
│ sdio.blkfactor = i_blkbits - blkbits;
0.00 │sub%r12d,%ebx
│ * Will be decremented at I/O completion time.
│ */
│ atomic_inc(&inode->i_dio_count);
inode_dio_done is taking all of its 5.8% time doing the
corresponding atomic_dec.
So, they're combining for 11.8% of the overall CPU time.
The problem is more atomic contention than cache line dirtying.
Applying your patch (changing the bitmask from 0x04 to
0x08, since 0x04 is taken now) eliminates those
instructions from perf top and improves the high IOPS
results by 5 to 15%.
AttrCopyRead IOPS Write IOPS
= ==
UC NT rd,wr513 K 326 K
with the patch: 510 K 325 K
WB NT rd,wr3.3 M 3.5 M
with the patch: 3.8 M 3.9 M
WC NT rd,wr3.0 M 3.9 M
with the patch: 3.1 M 4.1 M
WT NT rd,wr3.3 M 2.1 M
with the patch: 3.7 M 3.7 M
(there is some other test environment inconsistency
with WT writes - I don't think this change really
helped by 76%)
---
Robert Elliott, HP Server Storage
--
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: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
On Fri, Apr 03, 2015 at 10:29:53PM +0200, Pavel Machek wrote: > On Fri 2015-04-03 14:23:56, Sakari Ailus wrote: > > Hi Pavel, > > > > On Fri, Apr 03, 2015 at 10:23:44AM +0200, Pavel Machek wrote: > > > Hi! > > > > > > > Hi Pawel, > > > > > > I'm still Pavel. v, not w. > > > > I know too many Pawels. Sorry about that. :-) > > > > > > I guess it uses adp1653_id_table. I'd hade to add redundand > > > information, because if it would just mask the errors if the code > > > changed... > > > > Indeed, that's true. This is comparing "adp1653" vs. comparing > > "adi,adp1653". I think I still prefer the latter since it's got also the > > vendor prefix included. > > > > Suppose we change this later and someone misspelled the vendor prefix --- > > their board would break. > > Suppose we do what you suggest. That does not fix the problem, since > code will still match the "adp1653" in case someone misspells it. > > If you want to change how i2c device matching works, well, you can do > it, but my patch is not right place to do that. Good point. Let's leave it as-is. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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] powerpc/83xx: add support for mpc8306
On Fri, 2015-04-03 at 14:45 +0200, Filip Brozović wrote: > The idea was that boards in the Kconfig file would select these symbols > in order to enable support for the 8306. I mainly wanted to get this > patch into mainline in order to make kernel maintenance for a couple of > custom in-house developed boards easier. The trouble with this patch is that, without some follow up patch, it adds Kconfig symbols and preprocessor checks that are pointless for mainline. I think we should not do that. (I'm also not sure how having those bits in mainline substantially benefits out of tree development.) But if you would put this in a series that also adds the code using these bits, than I'd have no reason to object (and neither would, I guess, the bots checking the tree for issues like that). 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 0/2] powerpc/kvm: Enable running guests on RT Linux
On Fri, 2015-04-03 at 11:07 +0300, Purcareata Bogdan wrote: > On 03.04.2015 02:11, Scott Wood wrote: > > On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote: > >> On 27.02.2015 03:05, Scott Wood wrote: > >>> On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote: > On 02/26/2015 02:02 PM, Paolo Bonzini wrote: > > > > > > On 24/02/2015 00:27, Scott Wood wrote: > >> This isn't a host PIC driver. It's guest PIC emulation, some of which > >> is indeed not suitable for a rawlock (in particular, openpic_update_irq > >> which loops on the number of vcpus, with a loop body that calls > >> IRQ_check() which loops over all pending IRQs). > > > > The question is what behavior is wanted of code that isn't quite > > RT-ready. What is preferred, bugs or bad latency? > > > > If the answer is bad latency (which can be avoided simply by not running > > KVM on a RT kernel in production), patch 1 can be applied. If the > can be applied *but* makes no difference if applied or not. > > > answer is bugs, patch 1 is not upstream material. > > > > I myself prefer to have bad latency; if something takes a spinlock in > > atomic context, that spinlock should be raw. If it hurts (latency), > > don't do it (use the affected code). > > The problem, that is fixed by this s/spin_lock/raw_spin_lock/, exists > only in -RT. There is no change upstream. In general we fix such things > in -RT first and forward the patches upstream if possible. This convert > thingy would be possible. > Bug fixing comes before latency no matter if RT or not. Converting > every lock into a rawlock is not always the answer. > Last thing I read from Scott is that he is not entirely sure if this is > the right approach or not and patch #1 was not acked-by him either. > > So for now I wait for Scott's feedback and maybe a backtrace :) > >>> > >>> Obviously leaving it in a buggy state is not what we want -- but I lean > >>> towards a short term "fix" of putting "depends on !PREEMPT_RT" on the > >>> in-kernel MPIC emulation (which is itself just an optimization -- you > >>> can still use KVM without it). This way people don't enable it with RT > >>> without being aware of the issue, and there's more of an incentive to > >>> fix it properly. > >>> > >>> I'll let Bogdan supply the backtrace. > >> > >> So about the backtrace. Wasn't really sure how to "catch" this, so what > >> I did was to start a 24 VCPUs guest on a 24 CPU board, and in the guest > >> run 24 netperf flows with an external back to back board of the same > >> kind. I assumed this would provide the sufficient VCPUs and external > >> interrupt to expose an alleged culprit. > >> > >> With regards to measuring the latency, I thought of using ftrace, > >> specifically the preemptirqsoff latency histogram. Unfortunately, I > >> wasn't able to capture any major differences between running a guest > >> with in-kernel MPIC emulation (with the openpic raw_spinlock_conversion > >> applied) vs. no in-kernel MPIC emulation. Function profiling > >> (trace_stat) shows that in the second case there's a far greater time > >> spent in kvm_handle_exit (100x), but overall, the maximum latencies for > >> preemptirqsoff don't look that much different. > >> > >> Here are the max numbers (preemptirqsoff) for the 24 CPUs, on the host > >> RT Linux, sorted in descending order, expressed in microseconds: > >> > >> In-kernel MPIC QEMU MPIC > >> 3975 5105 > > > > What are you measuring? Latency in the host, or in the guest? > > This is in the host kernel. Those are terrible numbers in both cases. Can you use those tracing tools to find out what the code path is for QEMU MPIC? -Scott -- 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] add fixed_phy_update_state() - update state of fixed_phy
03.04.2015 22:25, Florian Fainelli пишет: On 01/04/15 10:30, Stas Sergeev wrote: - The callback needs to be registered before of_phy_connect() to avoid running with outdated state, but of_phy_connect() returns the phy_device pointer, which is needed to register the callback. Registering it before of_phy_connect() will therefore require a hack to get the pointer earlier. In fact, this can't even be done: registering it before of_phy_connect() is an asking for troubles with NULL deref. Overall, this addition makes the subsequent patch that implements SGMII link status for mvneta, much cleaner. Agreed, now that we have that, we should probably just remove the ability to have a fixed link update callback since it suffers from all the deficiencies you outlined above, and is creating some overhead by polling the hardware. In fact, there is still a bit of a problem. You certainly want to set the initial state, so that on of_phy_connect() time it is already valid. For this I still use of_phy_find_device()... This, however, differs from registering the callback: - initial state is set only once; callback should be registered before _every_ of_phy_connect() (but it can't be registered before because of the NULL, so only after) - initial state can be set anywhere anytime, not necessary any near of_phy_connect(). So the problem is mostly solved, but of_phy_find_device() is still there. To get rid of this, I guess some addition to of_mdio may be needed as well. Maybe optionally passing the status directly to of_phy_connect()? Not sure. -- 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: Unreliable hibernation on Lenovo x230 (regression)
On Friday, April 03, 2015 05:58:25 PM rhn wrote: > On Thu, 2 Apr 2015 17:28:05 +0200 > Pavel Machek wrote: > > > On Wed 2015-04-01 21:47:43, rhn wrote: > > > Hello, > > > > > > Between kernel 3.16 and 3.17, a regression has been introduced where the > > > first hibernation after regular shutdown always fails to resume. > > > Subsequent hibernations succeed. > > > > > > The system is a Lenovo x230 with Intel i5, booting with EFI, with the > > > hibernate partition located on a secondary SSD drive. Installed system is > > > Fedora 20, hibernation and reboots were issued using the KDE shutdown > > > dialog. > > > > > > I have tracked the problem to first appear in the commit > > > e67ee10190e69332f929bdd6594a312363321a66 Merge branches 'pm-sleep', > > > 'pm-cpufreq' and 'pm-cpuidle' > > > > > > The problem itself manifests in dmesg as follows (system was first > > > restarted, then hibernated - this log is from the subsequent > > resume): > > > > Ok, can you try to disable cpufreq and cpuidle, and then try if it > > reproduces? > > > > At that point, this is the candidate: > > > > commit e67ee10190e69332f929bdd6594a312363321a66 > > Merge: 21c806d 84c91b7 39c8bba 372ba8c > > Author: Rafael J. Wysocki > > Date: Mon Aug 11 23:19:48 2014 +0200 > > > > Merge branches 'pm-sleep', 'pm-cpufreq' and 'pm-cpuidle' > > > > * pm-sleep: > > PM / hibernate: avoid unsafe pages in e820 reserved regions > > > > ... > > Alternatively, you can just try to revert > > > > commit 84c91b7ae07c62cf6dee7fde3277f4be21331f85 > > Author: Lee, Chun-Yi > > Date: Mon Aug 4 23:23:21 2014 +0800 > > > > PM / hibernate: avoid unsafe pages in e820 reserved regions > > > > When the machine doesn't well handle the e820 persistent when > > hibernate > > resuming, then it may cause page fault when writing image to > > snapshot > > buffer: > > > > > > ... > > > > Thanks, > > Pavel > > I tried to disable CONFIG_CPU_IDLE and CONFIG_CPU_FREQ, however for some > reason I could only disable CONFIG_CPU_FREQ. > > The bug persisted. > > Reverting the commit 84c91b7 on top of e67ee10 fixes the problem. > > I created a copy of the bug report here: > https://bugzilla.kernel.org/show_bug.cgi?id=96111 Please check if 4.0-rc6 still has the problem and if reverting the commit in question on top of it fixes the problem too. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 1/2] x86: add support for the non-standard protected e820 type
On Fri, 2015-04-03 at 10:12 -0700, Yinghai Lu wrote:
> On Fri, Apr 3, 2015 at 9:14 AM, Toshi Kani wrote:
> > On Wed, 2015-04-01 at 09:12 +0200, Christoph Hellwig wrote:
> > :
> >> @@ -748,7 +758,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
> >> /*
> >> * Find the highest page frame number we have available
> >> */
> >> -static unsigned long __init e820_end_pfn(unsigned long limit_pfn,
> >> unsigned type)
> >> +static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
> >> {
> >> int i;
> >> unsigned long last_pfn = 0;
> >> @@ -759,7 +769,11 @@ static unsigned long __init e820_end_pfn(unsigned
> >> long limit_pfn, unsigned type)
> >> unsigned long start_pfn;
> >> unsigned long end_pfn;
> >>
> >> - if (ei->type != type)
> >> + /*
> >> + * Persistent memory is accounted as ram for purposes of
> >> + * establishing max_pfn and mem_map.
> >> + */
> >> + if (ei->type != E820_RAM && ei->type != E820_PRAM)
> >> continue;
> >
> > Should we also delete this code, accounting E820_PRAM as ram, along with
> > the deletion of reserve_pmem() in this version?
>
> should revert those end_of_ram change as attached.
I confirmed that the pmem driver works with the change, and last_pfn is
updated as expected.
Thanks,
-Toshi
--
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] Btrfs: prevent deletion of mounted subvolumes
On Thu, Apr 02, 2015 at 05:02:25PM +0200, David Sterba wrote: > On Wed, Apr 01, 2015 at 08:49:54PM -0700, Omar Sandoval wrote: > > Hm, yeah, that's unfortunate, thanks for pointing that out. It looks > > like we can get the subvolume ID reliably: > > > > > > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > > index 05fef19..a74ddb3 100644 > > --- a/fs/btrfs/super.c > > +++ b/fs/btrfs/super.c > > @@ -1024,6 +1024,8 @@ static int btrfs_show_options(struct seq_file *seq, > > struct dentry *dentry) > > struct btrfs_root *root = info->tree_root; > > char *compress_type; > > > > + seq_printf(seq, ",subvolid=%llu", > > + BTRFS_I(d_inode(dentry))->root->root_key.objectid); > > yes, subvolid is reliable, but not very friendly from users' POV. I'd > like to see subvol=/path there. Possibly we can have both. So are you saying that we should try to fix the bug in userspace by first getting subvol/subvolid in /proc/mounts, or do you want to keep that a separate issue? Just asking because you didn't comment on the kernel-side fix. Here's a concrete implementation of what I'm talking about: https://github.com/osandov/linux/tree/btrfs-delete-mounted-subvol. -- Omar -- 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: rtl8188eu: Remove zero testing pointer typed value
On Fri, Apr 03, 2015 at 10:01:10AM -0700, Joe Perches wrote: > On Fri, 2015-04-03 at 19:51 +0300, Dan Carpenter wrote: > > Also strcmp() and similar should always be done as == 0, < 0 or != 0 > > because that is the idiom: > > Less true. > > When testing for equality, !strcmp is very common. > > There are ~2500 uses of !strcmp in the kernel tree vs > ~1500 uses of strcmp() == or != Bugs with reversed strcmp() tests are almost always caught in testing so it's not an issue. But == 0 is more correct. ;) 1) It's more clear when read in English. "if not strcmp then" or "if strcmp NOT EQUAL zero". In the second one I've emphasized the NOT EQUAL because the strings are not eqaul. 2) Also if works for the other compares too. if (strcmp(x, y) < 0) <-- means x is less than y. if (strcmp(x, y) == 0) <-- means x == y. 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: [PATCHv5] media: i2c/adp1653: devicetree support for adp1653
Hi! > > + pd->max_flash_intensity = val/1000; > > + > > + if (of_property_read_u32(child, "max-microamp", &val)) > > + return -EINVAL; > > + pd->max_torch_intensity = val/1000; > > I think you need to do of_node_put(child) here and after you're done with > indicator below. ...and in most of the error paths. Ok. Will submit the updated patch when the documentation one is accepted. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v2 7/7] USB / PM: Allow USB devices to remain runtime-suspended when sleeping
On Friday, April 03, 2015 01:44:36 PM Dmitry Torokhov wrote: > Hi Tomeu, > > On Fri, Apr 03, 2015 at 02:57:56PM +0200, Tomeu Vizoso wrote: > > Have dev_pm_ops.prepare return 1 for USB devices, interfaces, endpoints > > and ports so that USB devices can remain runtime-suspended when the > > system goes to a sleep state, if their wakeup state is correct. > > > > Also enable runtime PM for endpoints, which is another requirement for > > the above to work. > > After patching I think the 4th unrelated subsystem with stubs for > prepare() I think it is pretty clear that this approach is not the right > one. > > If your driver does not care about any children hanging off it there is > dev->ignore_children flag that either already does what you want, or > maybe needs adjusted to support your use case. I wouldn't overload ignore_children with that meaning. That said adding a "return 1 from device_prepare() if this is set" flag might be a good idea. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: at91/dt: sama5d3 xplained: add phy address for macb1
On Fri, Apr 03, 2015 at 10:43:40AM +0200, Nicolas Ferre wrote: > Le 31/03/2015 10:56, Nicolas Ferre a écrit : > > After 57a38effa598 (net: phy: micrel: disable broadcast for KSZ8081/KSZ8091) > > the macb1 interface refuses to work properly because it tries > > to cling to address 0 which isn't able to communicate in broadcast with > > the mac anymore. The micrel phy on the board is actually configured > > to show up at address 1. > > Adding the phy node and its real address fixes the issue. > > > > Signed-off-by: Nicolas Ferre > > Cc: Johan Hovold > > Cc: #3.19 > > --- > > Arnd, Olof, Kevin, > > It seems late but, is it possible to queue this patch as a 4.0 fixes? > > Without it, the 10/100 Ethernet on sama5d3 doesn't work if it's not used > by u-boot previously. Sure, resend it to a...@kernel.org. -Olof -- 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/4] ARM: multi_v7_defconfig: Enable Tegra ACTMON support
On Mon, Mar 30, 2015 at 04:40:13PM +0200, Tomeu Vizoso wrote: > This brings the DevFreq framework in and builds the ACTMON driver that > on Tegra124 will scale the external memory clock based on current load. > > Signed-off-by: Tomeu Vizoso > --- Thanks, applied 1-4. In the future you can squash into one commit if you want. -Olof -- 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] kbuild: Create directory for target DTB
On Mon, Mar 30, 2015 at 02:39:08PM +0200, Michal Simek wrote: > From: Nathan Rossi > > When building specific DTBs out of the kernel tree the vendor subdirs > (boot/dts/) are not created, ensure that they are before > building the DTB. > > Signed-off-by: Nathan Rossi > Signed-off-by: Michal Simek > Acked-by: Will Deacon > --- Thanks, applied. -Olof -- 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] PCI: Introduce pci_bus_addr_t
[+cc Sam (commented on previous versions), Russell, linux-arm-kernel, Ralf,
linux-mips, Ben, linuxppc-dev, x86]
On Fri, Apr 03, 2015 at 02:32:34PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 31, 2015 at 07:57:47PM -0700, Yinghai Lu wrote:
> > David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
> > to fit in upstream windows") broke booting on sparc/T5-8.
> >
> > In the boot log, there is
> > pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
> > 0x110204000)
> > but that only could happen when dma_addr_t is 32-bit.
> >
> > According to David Miller, all DMA occurs behind an IOMMU and these
> > IOMMUs only support 32-bit addressing, therefore dma_addr_t is
> > 32-bit on sparc64.
> >
> > Let's introduce pci_bus_addr_t instead of using dma_addr_t,
> > and pci_bus_addr_t will be 64-bit on 64-bit platform or X86_PAE.
> >
> > Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in
> > upstream windows")
> > Fixes: commit 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs
> > larger than 4GB")
> > Link:
> > http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
> > Reported-by: David Ahern
> > Tested-by: David Ahern
> > Signed-off-by: Yinghai Lu
> > Cc: #3.19
> > ---
> > drivers/pci/Kconfig | 4
> > drivers/pci/bus.c | 10 +-
> > drivers/pci/probe.c | 12 ++--
> > include/linux/pci.h | 12 +---
> > 4 files changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> > index 7a8f1c5..6a5a269 100644
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -1,6 +1,10 @@
> > #
> > # PCI configuration
> > #
> > +config PCI_BUS_ADDR_T_64BIT
> > + def_bool y if (64BIT || X86_PAE)
> > + depends on PCI
>
> We're going to use pci_bus_addr_t in some places where we previously used
> dma_addr_t, which means pci_bus_addr_t should be at least as large as
> dma_addr_t. Can you enforce that directly, e.g., with something like this?
>
> def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT || X86_PAE)
>
> Unless we do something like that, I think this may break these arches by
> changing the addresses in struct pci_bus_region from 64 bits to 32:
>
> arch/arm/Kconfig:
> XEN selects ARCH_DMA_ADDR_T_64BIT but not 64BIT, so it would not
> set PCI_BUS_ADDR_T_64BIT
>
> arch/arm/mach-axxia/Kconfig:
> ARCH_AXXIA selects ARCH_DMA_ADDR_T_64BIT but not 64BIT, so it
> would not set PCI_BUS_ADDR_T_64BIT
>
> arch/arm/mach-exynos/Kconfig:
> SOC_EXYNOS5440 selects ARCH_DMA_ADDR_T_64BIT if ARM_LPAE, but not
> 64BIT, so it would not set PCI_BUS_ADDR_T_64BIT
>
> arch/arm/mach-highbank/Kconfig:
> ARCH_HIGHBANK selects ARCH_DMA_ADDR_T_64BIT if ARM_LPAE, but not
> 64BIT, so it would not set PCI_BUS_ADDR_T_64BIT
>
> arch/arm/mach-shmobile/Kconfig:
> ARCH_SHMOBILE_MULTI selects ARCH_DMA_ADDR_T_64BIT if ARM_LPAE, but
> not 64BIT, so it would not set PCI_BUS_ADDR_T_64BIT
>
> arch/mips/Kconfig:
> sets ARCH_DMA_ADDR_T_64BIT if (HIGHMEM && ARCH_PHYS_ADDR_T_64BIT)
> || 64BIT, so if we have (HIGHMEM && ARCH_PHYS_ADDR_T_64BIT) but not
> 64BIT, it would not set PCI_BUS_ADDR_T_64BIT
>
> arch/powerpc/Kconfig:
> sets ARCH_DMA_ADDR_T_64BIT if ARCH_PHYS_ADDR_T_64BIT, which isn't
> trivially identical to (64BIT || X86_PAE), so we may not set
> PCI_BUS_ADDR_T_64BIT in all cases where we set
> ARCH_DMA_ADDR_T_64BIT
>
> arch/x86/Kconfig:
> sets ARCH_DMA_ADDR_T_64BIT if X86_64 || HIGHMEM64G, which isn't
> trivially identical to (64BIT || X86_PAE), so we may not set
> PCI_BUS_ADDR_T_64BIT in all cases where we set
> ARCH_DMA_ADDR_T_64BIT
>
> > config PCI_MSI
> > bool "Message Signaled Interrupts (MSI and MSI-X)"
> > depends on PCI
> > diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> > index 90fa3a7..6fbd3f2 100644
> > --- a/drivers/pci/bus.c
> > +++ b/drivers/pci/bus.c
> > @@ -92,11 +92,11 @@ void pci_bus_remove_resources(struct pci_bus *bus)
> > }
> >
> > static struct pci_bus_region pci_32_bit = {0, 0xULL};
> > -#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> > +#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
> > static struct pci_bus_region pci_64_bit = {0,
> > - (dma_addr_t) 0xULL};
> > -static struct pci_bus_region pci_high = {(dma_addr_t) 0x1ULL,
> > - (dma_addr_t) 0xULL};
> > + (pci_bus_addr_t) 0xULL};
> > +static struct pci_bus_region pci_high = {(pci_bus_addr_t) 0x1ULL,
> > + (pci_bus_addr_t) 0xULL};
> > #endif
> >
> > /*
> > @@ -200,7 +200,7 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct
> > resource *res,
> > resource_size_t),
> > void *alignf
Re: [PATCH 2/3] sparc/PCI: Add mem64 resource parsing for root bus
[+cc Ben, linuxppc-dev, Grant, Rob, devicetree]
On Tue, Mar 31, 2015 at 07:57:48PM -0700, Yinghai Lu wrote:
> Found "no compatible bridge window" warning in boot log from T5-8.
>
> pci :00:01.0: can't claim BAR 15 [mem 0x1-0x4afff pref]: no
> compatible bridge window
>
> That resource is above 4G, but does not get offset correctly as
> root bus only report io and mem32.
>
> pci_sun4v f02dbcfc: PCI host bridge to bus :00
> pci_bus :00: root bus resource [io 0x8040-0x80400fff] (bus
> address [0x-0xfff])
> pci_bus :00: root bus resource [mem 0x8000-0x80007eff] (bus
> address [0x-0x7eff])
> pci_bus :00: root bus resource [bus 00-77]
>
> Add mem64 handling in pci_common for sparc, so we can have 64bit resource
> registered for root bus at first.
>
> After patch, will have:
> pci_sun4v f02dbcfc: PCI host bridge to bus :00
> pci_bus :00: root bus resource [io 0x8040-0x80400fff] (bus
> address [0x-0xfff])
> pci_bus :00: root bus resource [mem 0x8000-0x80007eff] (bus
> address [0x-0x7eff])
> pci_bus :00: root bus resource [mem 0x8001-0x8007] (bus
> address [0x1-0x7])
> pci_bus :00: root bus resource [bus 00-77]
>
> Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in
> upstream windows")
> Link:
> http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
> Reported-by: David Ahern
> Tested-by: David Ahern
> Signed-off-by: Yinghai Lu
> Cc: #3.19
> ---
> arch/sparc/kernel/pci.c| 7 ++-
> arch/sparc/kernel/pci_common.c | 15 +--
> arch/sparc/kernel/pci_impl.h | 1 +
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
> index 9ce5afe..04ce3ac 100644
> --- a/arch/sparc/kernel/pci.c
> +++ b/arch/sparc/kernel/pci.c
> @@ -185,8 +185,10 @@ static unsigned long pci_parse_of_flags(u32 addr0)
>
> if (addr0 & 0x0200) {
> flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
> - flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
> flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
> + if (addr0 & 0x0100)
> + flags |= IORESOURCE_MEM_64
> + | PCI_BASE_ADDRESS_MEM_TYPE_64;
> if (addr0 & 0x4000)
> flags |= IORESOURCE_PREFETCH
>| PCI_BASE_ADDRESS_MEM_PREFETCH;
This function is very similar to these:
drivers/of/address.c of_bus_pci_get_flags()
arch/powerpc/kernel/pci_of_scan.c pci_parse_of_flags()
arch/sparc/kernel/of_device_32.c of_bus_pci_get_flags()
arch/sparc/kernel/of_device_64.c of_bus_pci_get_flags()
Should they get a similar change? They're all so similar that it would be
nice to consolidate them, but I think that would be out of scope for this
patch.
> @@ -663,6 +665,9 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
> pbm->io_space.start);
> pci_add_resource_offset(&resources, &pbm->mem_space,
> pbm->mem_space.start);
> + if (pbm->mem64_space.flags)
> + pci_add_resource_offset(&resources, &pbm->mem64_space,
> + pbm->mem_space.start);
> pbm->busn.start = pbm->pci_first_busno;
> pbm->busn.end = pbm->pci_last_busno;
> pbm->busn.flags = IORESOURCE_BUS;
> diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
> index 944a065..a859a86 100644
> --- a/arch/sparc/kernel/pci_common.c
> +++ b/arch/sparc/kernel/pci_common.c
> @@ -406,6 +406,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
> }
>
> num_pbm_ranges = i / sizeof(*pbm_ranges);
> + memset(&pbm->mem64_space, 0, sizeof(struct resource));
>
> for (i = 0; i < num_pbm_ranges; i++) {
> const struct linux_prom_pci_ranges *pr = &pbm_ranges[i];
> @@ -451,7 +452,11 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
> break;
>
> case 3:
> - /* XXX 64-bit MEM handling XXX */
> + /* 64-bit MEM handling */
> + pbm->mem64_space.start = a;
> + pbm->mem64_space.end = a + size - 1UL;
> + pbm->mem64_space.flags = IORESOURCE_MEM;
> + break;
>
> default:
> break;
> @@ -465,15 +470,21 @@ void pci_determine_mem_io_space(struct pci_pbm_info
> *pbm)
> prom_halt();
> }
>
> - printk("%s: PCI IO[%llx] MEM[%llx]\n",
> + printk("%s: PCI IO[%llx] MEM[%llx]",
> pbm->name,
> pbm->io_space.start,
> pbm->mem_space.start);
> + if (pbm->mem64_
Re: [PATCH v2 7/7] USB / PM: Allow USB devices to remain runtime-suspended when sleeping
Hi Tomeu,
On Fri, Apr 03, 2015 at 02:57:56PM +0200, Tomeu Vizoso wrote:
> Have dev_pm_ops.prepare return 1 for USB devices, interfaces, endpoints
> and ports so that USB devices can remain runtime-suspended when the
> system goes to a sleep state, if their wakeup state is correct.
>
> Also enable runtime PM for endpoints, which is another requirement for
> the above to work.
After patching I think the 4th unrelated subsystem with stubs for
prepare() I think it is pretty clear that this approach is not the right
one.
If your driver does not care about any children hanging off it there is
dev->ignore_children flag that either already does what you want, or
maybe needs adjusted to support your use case.
Thanks.
>
> Signed-off-by: Tomeu Vizoso
> ---
> drivers/usb/core/endpoint.c | 17 +
> drivers/usb/core/message.c | 16
> drivers/usb/core/port.c | 6 ++
> drivers/usb/core/usb.c | 8 +++-
> 4 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/endpoint.c b/drivers/usb/core/endpoint.c
> index 39a2402..7c82bb7 100644
> --- a/drivers/usb/core/endpoint.c
> +++ b/drivers/usb/core/endpoint.c
> @@ -160,6 +160,19 @@ static const struct attribute_group *ep_dev_groups[] = {
> NULL
> };
>
> +#ifdef CONFIG_PM
> +
> +static int usb_ep_device_prepare(struct device *dev)
> +{
> + return 1;
> +}
> +
> +static const struct dev_pm_ops usb_ep_device_pm_ops = {
> + .prepare = usb_ep_device_prepare,
> +};
> +
> +#endif /* CONFIG_PM */
> +
> static void ep_device_release(struct device *dev)
> {
> struct ep_device *ep_dev = to_ep_device(dev);
> @@ -170,6 +183,9 @@ static void ep_device_release(struct device *dev)
> struct device_type usb_ep_device_type = {
> .name = "usb_endpoint",
> .release = ep_device_release,
> +#ifdef CONFIG_PM
> + .pm = &usb_ep_device_pm_ops,
> +#endif
> };
>
> int usb_create_ep_devs(struct device *parent,
> @@ -197,6 +213,7 @@ int usb_create_ep_devs(struct device *parent,
> goto error_register;
>
> device_enable_async_suspend(&ep_dev->dev);
> + pm_runtime_enable(&ep_dev->dev);
> endpoint->ep_dev = ep_dev;
> return retval;
>
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index f368d20..9041aee 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -1589,10 +1589,26 @@ static int usb_if_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> return 0;
> }
>
> +#ifdef CONFIG_PM
> +
> +static int usb_if_prepare(struct device *dev)
> +{
> + return 1;
> +}
> +
> +static const struct dev_pm_ops usb_if_pm_ops = {
> + .prepare = usb_if_prepare,
> +};
> +
> +#endif /* CONFIG_PM */
> +
> struct device_type usb_if_device_type = {
> .name = "usb_interface",
> .release = usb_release_interface,
> .uevent = usb_if_uevent,
> +#ifdef CONFIG_PM
> + .pm = &usb_if_pm_ops,
> +#endif
> };
>
> static struct usb_interface_assoc_descriptor *find_iad(struct usb_device
> *dev,
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index 2106183..f49707d 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
>
> return retval;
> }
> +
> +static int usb_port_prepare(struct device *dev)
> +{
> + return 1;
> +}
> #endif
>
> static const struct dev_pm_ops usb_port_pm_ops = {
> #ifdef CONFIG_PM
> .runtime_suspend = usb_port_runtime_suspend,
> .runtime_resume = usb_port_runtime_resume,
> + .prepare = usb_port_prepare,
> #endif
> };
>
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index 8d5b2f4..3a55c91 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -316,7 +316,13 @@ static int usb_dev_uevent(struct device *dev, struct
> kobj_uevent_env *env)
>
> static int usb_dev_prepare(struct device *dev)
> {
> - return 0; /* Implement eventually? */
> + struct usb_device *udev = to_usb_device(dev);
> +
> + /* Return 0 if the current wakeup setting is wrong, otherwise 1 */
> + if (udev->do_remote_wakeup != device_may_wakeup(dev))
> + return 0;
> +
> + return 1;
> }
>
> static void usb_dev_complete(struct device *dev)
> --
> 2.3.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] spi: fsl-dspi: Add ~50ns delay between cs and sck
Add delay between chip select and clock signals, before clock starts and
after clock stops.
Signed-off-by: Aaron Brice
---
drivers/spi/spi-fsl-dspi.c | 64 +++---
1 file changed, 60 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 8213358..5fe54cd 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,7 @@
#include
#include
#include
+#include
#define DRIVER_NAME "fsl-dspi"
@@ -51,7 +53,7 @@
#define SPI_CTAR_CPOL(x) ((x) << 26)
#define SPI_CTAR_CPHA(x) ((x) << 25)
#define SPI_CTAR_LSBFE(x) ((x) << 24)
-#define SPI_CTAR_PCSSCR(x) (((x) & 0x0003) << 22)
+#define SPI_CTAR_PCSSCK(x) (((x) & 0x0003) << 22)
#define SPI_CTAR_PASC(x) (((x) & 0x0003) << 20)
#define SPI_CTAR_PDT(x)(((x) & 0x0003) << 18)
#define SPI_CTAR_PBR(x)(((x) & 0x0003) << 16)
@@ -59,6 +61,7 @@
#define SPI_CTAR_ASC(x)(((x) & 0x000f) << 8)
#define SPI_CTAR_DT(x) (((x) & 0x000f) << 4)
#define SPI_CTAR_BR(x) ((x) & 0x000f)
+#define SPI_CTAR_SCALE_BITS0xf
#define SPI_CTAR0_SLAVE0x0c
@@ -176,6 +179,40 @@ static void hz_to_spi_baud(char *pbr, char *br, int
speed_hz,
}
}
+static void ns_delay_scale(char *psc, char *sc, int delay_ns,
+ unsigned long clkrate)
+{
+ int pscale_tbl[4] = {1, 3, 5, 7};
+ int scale_needed, scale, minscale = INT_MAX;
+ int i, j;
+ u32 remainder;
+
+ scale_needed = div_u64_rem((u64)delay_ns * clkrate, NSEC_PER_SEC,
+ &remainder);
+ if (remainder)
+ scale_needed++;
+
+ for (i = 0; i < ARRAY_SIZE(pscale_tbl); i++)
+ for (j = 0; j <= SPI_CTAR_SCALE_BITS; j++) {
+ scale = pscale_tbl[i] * (2 << j);
+ if (scale >= scale_needed) {
+ if (scale < minscale) {
+ minscale = scale;
+ *psc = i;
+ *sc = j;
+ }
+ break;
+ }
+ }
+
+ if (minscale == INT_MAX) {
+ pr_warn("Cannot find correct scale values for %dns delay at
clkrate %ld, using max prescaler value",
+ delay_ns, clkrate);
+ *psc = ARRAY_SIZE(pscale_tbl) - 1;
+ *sc = SPI_CTAR_SCALE_BITS;
+ }
+}
+
static int dspi_transfer_write(struct fsl_dspi *dspi)
{
int tx_count = 0;
@@ -354,7 +391,10 @@ static int dspi_setup(struct spi_device *spi)
{
struct chip_data *chip;
struct fsl_dspi *dspi = spi_master_get_devdata(spi->master);
- unsigned char br = 0, pbr = 0, fmsz = 0;
+ u32 cs_sck_delay = 0, sck_cs_delay = 0;
+ unsigned char br = 0, pbr = 0, pcssck = 0, cssck = 0;
+ unsigned char pasc = 0, asc = 0, fmsz = 0;
+ unsigned long clkrate;
if ((spi->bits_per_word >= 4) && (spi->bits_per_word <= 16)) {
fmsz = spi->bits_per_word - 1;
@@ -371,18 +411,34 @@ static int dspi_setup(struct spi_device *spi)
return -ENOMEM;
}
+ of_property_read_u32(spi->dev.of_node, "fsl,spi-cs-sck-delay",
+ &cs_sck_delay);
+
+ of_property_read_u32(spi->dev.of_node, "fsl,spi-sck-cs-delay",
+ &sck_cs_delay);
+
chip->mcr_val = SPI_MCR_MASTER | SPI_MCR_PCSIS |
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF;
chip->void_write_data = 0;
- hz_to_spi_baud(&pbr, &br,
- spi->max_speed_hz, clk_get_rate(dspi->clk));
+ clkrate = clk_get_rate(dspi->clk);
+ hz_to_spi_baud(&pbr, &br, spi->max_speed_hz, clkrate);
+
+ /* Set PCS to SCK delay scale values */
+ ns_delay_scale(&pcssck, &cssck, cs_sck_delay, clkrate);
+
+ /* Set After SCK delay scale values */
+ ns_delay_scale(&pasc, &asc, sck_cs_delay, clkrate);
chip->ctar_val = SPI_CTAR_FMSZ(fmsz)
| SPI_CTAR_CPOL(spi->mode & SPI_CPOL ? 1 : 0)
| SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0)
| SPI_CTAR_LSBFE(spi->mode & SPI_LSB_FIRST ? 1 : 0)
+ | SPI_CTAR_PCSSCK(pcssck)
+ | SPI_CTAR_CSSCK(cssck)
+ | SPI_CTAR_PASC(pasc)
+ | SPI_CTAR_ASC(asc)
| SPI_CTAR_PBR(pbr)
| SPI_CTAR_BR(br);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/xsave: Robustify and merge macros
On Fri, Apr 03, 2015 at 07:48:24PM +0200, Borislav Petkov wrote: > On Fri, Apr 03, 2015 at 07:33:06PM +0200, Quentin Casasnovas wrote: > > > Basically, the idea was: > > > > > > .skip len(repl1) - len(orig), 0x90 > > > .skip len(repl2) - len(repl1), 0x90 > > > > > > BUT!, for some reason I changed it to what's there now and I can't > > > remember why anymore. > > > > I think it would not work in the case where repl1 is smaller or equal than > > orig_insn (i.e. no padding in the first .skip) but orig_insn is strictly > > smaller than repl2 (since we're never comparing repl2 with insn in this > > new-old code). > > orig_insn=4 > repl1=3 > repl2=5 > > .skip 0, 0x90 > .skip 2, 0x90 > > I think that still works, only the padding is larger than it needs to > be. And it is so many bytes larger as len(abs(repl1 - orig_insn)) is. > > In the example above, we'll get two bytes padding while only 1 suffices. > Right. > > Anything wrong with the two different approaches I've suggested in my > > original mail? > > Right now, I want to have a minimal fix for obvious reasons. We can > always improve stuff later when there's more time. > If you're happy with the extra padding in such cases then your second approach looks okay to me. But IMO, even if taking the '.if' directive approach is certainly bigger LOC-wise, it should be much easier to review in a rush than some other .skip trickery. It all depends on your definition of minimal change really, and whether that extra padding is acceptable or not for you :) Quentin -- 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 v3 1/3] spi: fsl-dspi: Fix clock rate scale values
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice
---
drivers/spi/spi-fsl-dspi.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index d1a3924..8213358 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -148,23 +148,32 @@ static void hz_to_spi_baud(char *pbr, char *br, int
speed_hz,
16, 32, 64, 128,
256,512,1024, 2048,
4096, 8192, 16384, 32768 };
- int temp, i = 0, j = 0;
-
- temp = clkrate / 2 / speed_hz;
-
- for (i = 0; i < ARRAY_SIZE(pbr_tbl); i++)
- for (j = 0; j < ARRAY_SIZE(brs); j++) {
- if (pbr_tbl[i] * brs[j] >= temp) {
- *pbr = i;
- *br = j;
- return;
+ int scale_needed, scale, minscale = INT_MAX;
+ int i, j;
+
+ scale_needed = clkrate / speed_hz;
+ if (clkrate % speed_hz)
+ scale_needed++;
+
+ for (i = 0; i < ARRAY_SIZE(brs); i++)
+ for (j = 0; j < ARRAY_SIZE(pbr_tbl); j++) {
+ scale = brs[i] * pbr_tbl[j];
+ if (scale >= scale_needed) {
+ if (scale < minscale) {
+ minscale = scale;
+ *br = i;
+ *pbr = j;
+ }
+ break;
}
}
- pr_warn("Can not find valid baud rate,speed_hz is %d,clkrate is %ld\
- ,we use the max prescaler value.\n", speed_hz, clkrate);
- *pbr = ARRAY_SIZE(pbr_tbl) - 1;
- *br = ARRAY_SIZE(brs) - 1;
+ if (minscale == INT_MAX) {
+ pr_warn("Can not find valid baud rate,speed_hz is %d,clkrate is
%ld, we use the max prescaler value.\n",
+ speed_hz, clkrate);
+ *pbr = ARRAY_SIZE(pbr_tbl) - 1;
+ *br = ARRAY_SIZE(brs) - 1;
+ }
}
static int dspi_transfer_write(struct fsl_dspi *dspi)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] devicetree: spi: fsl-dspi: Add cs-sck delays
Adding fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay properties to
support delays before and after starting the clock in a transfer.
Signed-off-by: Aaron Brice
---
Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index cbbe16e..70af78a 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -16,6 +16,12 @@ Optional property:
in big endian mode, otherwise in native mode(same with CPU), for more
detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
+Optional SPI slave node properties:
+- fsl,spi-cs-sck-delay: a delay in nanoseconds between activating chip
+ select and the start of clock signal, at the start of a transfer.
+- fsl,spi-sck-cs-delay: a delay in nanoseconds between stopping the clock
+ signal and deactivating chip select, at the end of a transfer.
+
Example:
dspi0@4002c000 {
@@ -43,6 +49,8 @@ dspi0@4002c000 {
reg = <0>;
linux,modalias = "m25p80";
modal = "at26df081a";
+ fsl,spi-cs-sck-delay = <100>;
+ fsl,spi-sck-cs-delay = <50>;
};
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] spi: fsl-dspi (vf610) clock fixes
We were having intermittent problems writing to SRAM chip on SPI bus on vf610 SoM. Added support for CS setup and hold times to meet the SRAM spec. In the process noticed that the baud rate was a little high. Changes since v2: * Incorporate fixes per Stefen Agner review, namely moved hard-coded 50ns delays to device tree properties * Fix for baud rate scale value remainders, reported by Andy Shevchenko Changes since v1: * More detail in commit message for clock rate fix Aaron Brice (3): spi: fsl-dspi: Fix clock rate scale values devicetree: spi: fsl-dspi: Add cs-sck delays spi: fsl-dspi: Add ~50ns delay between cs and sck .../devicetree/bindings/spi/spi-fsl-dspi.txt | 8 ++ drivers/spi/spi-fsl-dspi.c | 97 ++ 2 files changed, 89 insertions(+), 16 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blackfin: include: asm: pgtable: Define dummy pgprot_writecombine
It is copied from asm-generic, the related error with allmodconfig:
CC [M] sound/core/pcm_native.o
sound/core/pcm_native.c: In function 'snd_pcm_lib_default_mmap':
sound/core/pcm_native.c:3387:24: error: implicit declaration of function
'pgprot_writecombine' [-Werror=implicit-function-declaration]
area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
^
sound/core/pcm_native.c:3387:22: error: incompatible types when assigning to
type 'pgprot_t {aka struct }' from type 'int'
area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
^
Signed-off-by: Chen Gang
---
arch/blackfin/include/asm/pgtable.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/blackfin/include/asm/pgtable.h
b/arch/blackfin/include/asm/pgtable.h
index b88a155..3e730d9 100644
--- a/arch/blackfin/include/asm/pgtable.h
+++ b/arch/blackfin/include/asm/pgtable.h
@@ -36,6 +36,7 @@ typedef pte_t *pte_addr_t;
#define PAGE_READONLY __pgprot(0) /* these mean nothing to NO_MM
*/
#define PAGE_KERNEL__pgprot(0) /* these mean nothing to NO_MM
*/
#define pgprot_noncached(prot) (prot)
+#define pgprot_writecombinepgprot_noncached
extern void paging_init(void);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom dt changes for 4.1
Hi, On Fri, Mar 27, 2015 at 11:49:26AM -0500, Kumar Gala wrote: > The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: > > Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git > tags/qcom-dt-for-4.1 > > for you to fetch changes up to 1be95ed01c190ca74677798348306a50ad0d46c1: > > ARM: dts: qcom: Add idle state device nodes for 8064 (2015-03-25 16:38:16 > -0500) > > > Qualcomm ARM Based Device Tree Updates for v4.1 > > * Updated GIC binding to include Qualcomm GIC compatible > * Added binding and updated dts for TCSR (Top Control and Status Register) > * Added LCC clocks to IPQ8064/APQ8064/MSM8960 device trees > * Added LPASS support to IPQ8064 device tree > * Added SPMI PMIC & device support to APQ8084 and MSM8974 > * Added support for MSM8916/APQ8016 SoC (64-bit) and MTP8916/SBC8016 boards > * Added support for qcom,saw2 & qcom,idle-states on MSM8974/APQ8084/APQ8064 > > > Andy Gross (5): > mfd: qcom,tcsr: Add device tree binding for TCSR > arm: dts: qcom: Add TCSR support for APQ8064 > arm: dts: qcom: Add TCSR support for IPQ8064 > arm: dts: qcom: Add TCSR support for MSM8660 > arm: dts: qcom: Add TCSR support for MSM8960 > > Georgi Djakov (1): > dt-bindings: Add #defines for MSM8916 clocks and resets > > Ivan T. Ivanov (3): > arm: dts: qcom: Add SPMI PMIC Arbiter nodes for APQ8084 and MSM8974 > arm: dts: qcom: Add 8x74 chipset SPMI PMIC's nodes > arm: dts: qcom: Add APQ8084 chipset SPMI PMIC's nodes > > Kenneth Westfield (1): > arm: dts: qcom: Add LPASS Audio HW to IPQ8064 device tree > > Kumar Gala (4): > arm: qcom: dts: gic: add compatible string for Qualcomm MSM GICs > arm: dts: qcom: Add LCC nodes > arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts > arm64: dts: Add Qualcomm APQ8016 SBC evaluation board dts We are still merging 64-bit material in a separate branch. Since you're mixing contents here it means that conflicts between the two percolate all the way up to our pull requests to Linus. I've cherry-picked the branch contents here instead, so I've picked up the contents but spread across next/dt and next/arm64. Please keep them separate in the future so we can merge branches instead. Thanks, -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 4.0-rc4
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem: there is a fix for ALPS driver for issue introduced in the latest update and a tweak for yet another Lenovo box in Synaptics. There will be more ALPS tweaks coming... Changelog: - Charlie Mooney (1): Input: add MT_TOOL_PALM Dmitry Torokhov (1): Input: ALPS - fix max coordinates for v5 and v7 protocols Filip Ayazi (1): Input: synaptics - fix min-max quirk value for E440 Peter Hutterer (1): Input: define INPUT_PROP_ACCELEROMETER behavior Ramiro Morales (1): Input: synaptics - add quirk for Thinkpad E440 Diffstat: Documentation/input/event-codes.txt | 6 ++ Documentation/input/multi-touch-protocol.txt | 9 ++--- drivers/input/mouse/alps.c | 11 ++- drivers/input/mouse/synaptics.c | 7 ++- include/uapi/linux/input.h | 3 ++- 5 files changed, 26 insertions(+), 10 deletions(-) -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
On Fri 2015-04-03 14:23:56, Sakari Ailus wrote: > Hi Pavel, > > On Fri, Apr 03, 2015 at 10:23:44AM +0200, Pavel Machek wrote: > > Hi! > > > > > Hi Pawel, > > > > I'm still Pavel. v, not w. > > I know too many Pawels. Sorry about that. :-) > > > I guess it uses adp1653_id_table. I'd hade to add redundand > > information, because if it would just mask the errors if the code > > changed... > > Indeed, that's true. This is comparing "adp1653" vs. comparing > "adi,adp1653". I think I still prefer the latter since it's got also the > vendor prefix included. > > Suppose we change this later and someone misspelled the vendor prefix --- > their board would break. Suppose we do what you suggest. That does not fix the problem, since code will still match the "adp1653" in case someone misspells it. If you want to change how i2c device matching works, well, you can do it, but my patch is not right place to do that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Documentation for adp1653 binding.
---
> Please split this as Javier suggested. I'd think both could go through
> the media-tree unless someone objects.
Please apply.
> > + - power-gpios: Reference to the GPIO that controls the power for the
> > chip.
>
> You're using power-gpios in documentation only.
Which is ok, because generic code adds "-gpios" itself.
> The spec refers to this by "EN". How about "en-gpios" instead? This
> definitely isn't about power, but about resetting the chip. It gets the
> power through another pin.
It controls power of the chip. Noone gets _power_ through gpios,
hopefully. Yes, I can rename it. "en-gpios" is too ugly to
live. Sebastian suggested "enable". Hope that's okay with you.
Pavel
new file mode 100644
index 000..da9934a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be "adi,adp1653"
+
+ - reg: I2C slave address
+
+ - power-gpios: Reference to the GPIO that controls the power for the chip.
+
+There are two LED outputs available - flash and indicator. One LED is
+represented by one child node, nodes need to be named "flash" and "indicator".
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ power-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ max-microamp = <5>;
+ };
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [GIT PULL] qcom defconfig changes for 4.1-1
On Fri, Mar 27, 2015 at 11:38:49AM -0500, Kumar Gala wrote: > The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: > > Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git > tags/qcom-defconfig-for-4.1-1 > > for you to fetch changes up to dc344b62121c4e2ba5bd9d5bf7a2b4ce5f0487ce: > > ARM: qcom: Increase MMC_BLOCK_MINORS in defconfig (2015-03-25 16:16:59 > -0500) > > > Qualcomm ARM Based defconfig Updates for v4.1-1 > > * Increase MMC_BLOCK_MINORS to 32 since qcom platforms have more than > 16 partitions > > > Georgi Djakov (1): > ARM: qcom: Increase MMC_BLOCK_MINORS in defconfig > > Rajendra Nayak (1): > arm: qcom: Enable lpass clock driver in defconfig > > Stephen Boyd (1): > arm: qcom: Update defconfig > > arch/arm/configs/qcom_defconfig | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) I only see one new patch here, the mmc minors one. The others have already been merged through another pull request. Please send incremental requests in those cases so that the diffstats are correct. Anyway, merged. -Olof -- 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] powerpc/83xx: add support for mpc8306
On Fri, 2015-04-03 at 14:45 +0200, Filip Brozović wrote: > On 4/3/2015 2:01 PM, Paul Bolle wrote: > > On Fri, 2015-04-03 at 12:44 +0200, Filip Brozovic wrote: > >> --- a/arch/powerpc/platforms/83xx/Kconfig > >> +++ b/arch/powerpc/platforms/83xx/Kconfig > > > >> +# used for gpio > >> +config PPC_MPC830x > >> + bool > >> + select ARCH_WANT_OPTIONAL_GPIOLIB > >> + > >> +config PPC_MPC8306 > >> + bool > > > > To me these two new Kconfig symbols look pointless: > > - they have no prompt, so one cannot set them manually; > > - no other Kconfig symbol selects them; > > - they do not default to 'y'. > > > > I'm not aware of a way to set these symbols to 'y' outside of those > > three. Is there perhaps a way for kconfig to set these symbols to 'y' > > that I have missed? > > > > Or do you expect to do one of these three things in a separate patch? > > > > The idea was that boards in the Kconfig file would select these symbols > in order to enable support for the 8306. I mainly wanted to get this > patch into mainline in order to make kernel maintenance for a couple of > custom in-house developed boards easier. Since these boards are not > widely available and our customers are unlikely to want to change and > recompile the kernel, I have so far leaned towards not including support > for them in mainline. As far as I can see, boards which are included in > mainline right now are mostly evaluation boards which are easily > available at most electronics distributors. > > That being said, I don't know what the "official" stance on this is; is > adding custom boards encouraged regardless of their availability (e.g. > if I develop a custom board with the intention of only ever actually > making a single prototype for personal use, should I go and submit > patches so that support makes it into the mainline kernel?), or should > there be a minimum level of public interest before incorporating custom > boards into mainline? If it's the latter, I suppose a solution would be > to include support for the Freescale MPC8306SOM in mainline. Of course, > this has its own problems, since someone would have to write and > maintain it (and I don't have an MPC8306SOM nor the time needed to do > maintenance). Custom boards are fine as long as someone will maintain them. What are you using PPC_MPC8306 for in your custom board code? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] qcom cleanup changes for 4.1
On Fri, Mar 27, 2015 at 11:34:51AM -0500, Kumar Gala wrote: > The following changes since commit 9eccca0843205f87c00404b663188b88eb248051: > > Linux 4.0-rc3 (2015-03-08 16:09:09 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git > tags/qcom-cleanup-for-4.1 > > for you to fetch changes up to 27842bb18b004a2802f4b3221c79ce638c4bf6ee: > > mmc: Remove msm_sdcc driver (2015-03-27 11:31:02 -0500) > > > General cleanups for MSM/QCOM for 4.1 > > * Removal of mach-msm and associated drivers cleanups that have been > ack'd by associated maintainers > > > Stephen Boyd (3): > ARM: Remove mach-msm and associated ARM architecture code > gpio: Remove gpio-msm-v1 driver > mmc: Remove msm_sdcc driver Merged. -Olof -- 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] blackfin: Makefile: Add -D__linux__ flag for KBUILD_CFLAGS
The related error with allmodconfig: CC [M] fs/coda/psdev.o In file included from include/linux/coda.h:64:0, from fs/coda/psdev.c:45: include/uapi/linux/coda.h:221:2: error: unknown type name 'u_quad_t' u_quad_t va_size; /* file size in bytes */ ^ include/uapi/linux/coda.h:229:2: error: unknown type name 'u_quad_t' u_quad_t va_bytes; /* bytes of disk space held by file */ ^ include/uapi/linux/coda.h:230:2: error: unknown type name 'u_quad_t' u_quad_t va_filerev; /* file modification number */ ^ Signed-off-by: Chen Gang --- arch/blackfin/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/blackfin/Makefile b/arch/blackfin/Makefile index 1fce086..2ece4e3 100644 --- a/arch/blackfin/Makefile +++ b/arch/blackfin/Makefile @@ -13,7 +13,7 @@ LDFLAGS_vmlinux := -X OBJCOPYFLAGS := -O binary -R .note -R .comment -S GZFLAGS := -9 -KBUILD_CFLAGS += $(call cc-option,-mno-fdpic) +KBUILD_CFLAGS += $(call cc-option,-mno-fdpic) -D__linux__ ifeq ($(CONFIG_ROMKERNEL),y) KBUILD_CFLAGS += -mlong-calls endif -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] i2c: davinci: use bus recovery infrastructure
> > The I2C specs say in 3.1.16 that the recovery procedure should be used > > when SDA is stuck low. So, I do wonder if we should apply the recovery > > after a timeout. Stuck SDA might be one reason for timeout, but there > > may be others... > > This is ancient code. And regarding your question - > Might be it would be reasonable to add call of > i2c_davinci_wait_bus_not_busy() at the end of i2c_davinci_xfer()? > This way we will wait for Bus Free before performing recovery. That might be an improvement, but the generic question still remains: Is a timeout a reason for recovery? SDA stuck low is one reason for a timeout. I have problems making up my mind here between being pragmatic and being in accordance with the specs. > Of course, i2c_davinci_wait_bus_not_busy() has to be fixed first > as proposed by Alexander Sverdlin here: > https://patchwork.ozlabs.org/patch/448994/. Okay, good that you said it. So I'll give his patch series priority over this one. signature.asc Description: Digital signature
