Re: [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing
On Thu, Nov 17, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
Thanks, this works for me in 4.4:
Tested-by: Olaf Hering
Olaf
signature.asc
Description: PGP signature
Re: [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format
Hello Stefan,
On 16-11-17 17:07:24, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> >
> > Signed-off-by: Sanchayan Maity
> > ---
> > drivers/spi/spi-fsl-dspi.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index aee8c88..164e2e1 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi
> > *dspi)
> > }
> >
> > val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > - dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > - SPI_PUSHR_PCS(dspi->cs) |
> > - SPI_PUSHR_CTAS(0);
> > + if (dspi->cs_change) {
> > + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > + SPI_PUSHR_PCS(dspi->cs) |
> > + SPI_PUSHR_CTAS(0);
> > + } else {
> > + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > + SPI_PUSHR_PCS(dspi->cs) |
> > + SPI_PUSHR_CTAS(0) |
> > + SPI_PUSHR_CONT;
> > + }
>
> How about:
>
>
> dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> SPI_PUSHR_PCS(dspi->cs) |
> SPI_PUSHR_CTAS(0);
>
> + if (dspi->cs_change)
> + dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
>
>
> Avoids code duplication...
Agreed. It's much better. Should be !dspi->cs_change though.
Will include it in next iteration.
Thanks & Regards,
Sanchayan.
>
> --
> Stefan
>
>
>
> > dspi->tx += tx_word + 1;
> >
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
Re: [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
On 16-11-17 17:03:19, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Currently dmaengine_prep_slave_single was being called with length
> > set to the complete DMA buffer size. This resulted in unwanted bytes
> > being transferred to the SPI register leading to clock and MOSI lines
> > having unwanted data even after chip select got deasserted and the
> > required bytes having been transferred.
> >
> > Signed-off-by: Sanchayan Maity
> > ---
> > drivers/spi/spi-fsl-dspi.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..aee8c88 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi
> > *dspi)
> >
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> > dma->tx_dma_phys,
> > - DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> > + dma->curr_xfer_len *
> > + DMA_SLAVE_BUSWIDTH_4_BYTES /
> > + (tx_word ? 2 : 1),
> > + DMA_MEM_TO_DEV,
>
> Hm, this is getting ridiculous, I think we convert curr_xfer_len from
> bytes to DMA transfers in almost every use.
>
> Can we make it be transfer length in actual 4 byte transfers? We then
> probably have to convert it to bytes once to subtract from
> curr_remaining_bytes, but I think it would simplify code overall...
Will the below be acceptable fix?
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 41422cd..db7f091 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -217,15 +217,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
- int i, len;
+ int i;
u16 d;
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
- for (i = 0; i < len; i++) {
+ for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +240,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi
*dspi)
struct device *dev = &dspi->pdev->dev;
int time_left;
int tx_word;
- int i, len;
+ int i;
u16 val;
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
- for (i = 0; i < len - 1; i++) {
+ for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -267,7 +263,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -283,7 +281,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -330,17 +330,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
- int tx_word;
+ int tx_word = 1;
int ret = 0;
- tx_word = is_double_byte_mode(dspi);
+ if (is_double_byte_mode(dspi))
+ tx_word = 2;
curr_remaining_bytes = dspi->len;
+ bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer */
-
Re: [PATCH 6/9] lib: radix-tree: add entry deletion support to __radix_tree_replace()
On Thu 17-11-16 14:30:58, Johannes Weiner wrote:
> Page cache shadow entry handling will be a lot simpler when it can use
> a single generic replacement function for pages, shadow entries, and
> emptying slots.
>
> Make __radix_tree_replace() properly account insertions and deletions
> in node->count and garbage collect nodes as they become empty. Then
> re-implement radix_tree_delete() on top of it.
>
> Signed-off-by: Johannes Weiner
Seeing this patch, just ignore my nit to the previous patch. Also it would
have been easier to review this patch if you split out the move of those
two functions into a separate patch and state it's just a code move...
Anyway, the result looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> lib/radix-tree.c | 227
> ---
> 1 file changed, 116 insertions(+), 111 deletions(-)
>
> diff --git a/lib/radix-tree.c b/lib/radix-tree.c
> index f91d5b0af654..5d8930f3b3d8 100644
> --- a/lib/radix-tree.c
> +++ b/lib/radix-tree.c
> @@ -539,6 +539,107 @@ static int radix_tree_extend(struct radix_tree_root
> *root,
> }
>
> /**
> + * radix_tree_shrink-shrink radix tree to minimum height
> + * @root radix tree root
> + */
> +static inline bool radix_tree_shrink(struct radix_tree_root *root)
> +{
> + bool shrunk = false;
> +
> + for (;;) {
> + struct radix_tree_node *node = root->rnode;
> + struct radix_tree_node *child;
> +
> + if (!radix_tree_is_internal_node(node))
> + break;
> + node = entry_to_node(node);
> +
> + /*
> + * The candidate node has more than one child, or its child
> + * is not at the leftmost slot, or the child is a multiorder
> + * entry, we cannot shrink.
> + */
> + if (node->count != 1)
> + break;
> + child = node->slots[0];
> + if (!child)
> + break;
> + if (!radix_tree_is_internal_node(child) && node->shift)
> + break;
> +
> + if (radix_tree_is_internal_node(child))
> + entry_to_node(child)->parent = NULL;
> +
> + /*
> + * We don't need rcu_assign_pointer(), since we are simply
> + * moving the node from one part of the tree to another: if it
> + * was safe to dereference the old pointer to it
> + * (node->slots[0]), it will be safe to dereference the new
> + * one (root->rnode) as far as dependent read barriers go.
> + */
> + root->rnode = child;
> +
> + /*
> + * We have a dilemma here. The node's slot[0] must not be
> + * NULLed in case there are concurrent lookups expecting to
> + * find the item. However if this was a bottom-level node,
> + * then it may be subject to the slot pointer being visible
> + * to callers dereferencing it. If item corresponding to
> + * slot[0] is subsequently deleted, these callers would expect
> + * their slot to become empty sooner or later.
> + *
> + * For example, lockless pagecache will look up a slot, deref
> + * the page pointer, and if the page has 0 refcount it means it
> + * was concurrently deleted from pagecache so try the deref
> + * again. Fortunately there is already a requirement for logic
> + * to retry the entire slot lookup -- the indirect pointer
> + * problem (replacing direct root node with an indirect pointer
> + * also results in a stale slot). So tag the slot as indirect
> + * to force callers to retry.
> + */
> + if (!radix_tree_is_internal_node(child))
> + node->slots[0] = RADIX_TREE_RETRY;
> +
> + radix_tree_node_free(node);
> + shrunk = true;
> + }
> +
> + return shrunk;
> +}
> +
> +static bool delete_node(struct radix_tree_root *root,
> + struct radix_tree_node *node)
> +{
> + bool deleted = false;
> +
> + do {
> + struct radix_tree_node *parent;
> +
> + if (node->count) {
> + if (node == entry_to_node(root->rnode))
> + deleted |= radix_tree_shrink(root);
> + return deleted;
> + }
> +
> + parent = node->parent;
> + if (parent) {
> + parent->slots[node->offset] = NULL;
> + parent->count--;
> + } else {
> + root_tag_clear_all(root);
> + root->rnode = NULL;
> + }
> +
> + radix_tree_node_free(node);
> + deleted
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
* Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. Exposing this feature to userspace will allow a
> ptracer to trap and emulate the CPUID instruction.
>
> When supported, this feature is controlled by toggling bit 0 of
> MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
> https://bugzilla.kernel.org/attachment.cgi?id=243991
>
> Implement a new pair of arch_prctls, available on both x86-32 and x86-64.
>
> ARCH_GET_CPUID: Returns the current CPUID faulting state, either
> ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. arg2 must be 0.
>
> ARCH_SET_CPUID: Set the CPUID faulting state to arg2, which must be either
> ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. Returns EINVAL if arg2 is
> another value or CPUID faulting is not supported on this system.
So the interface is:
> +#define ARCH_GET_CPUID 0x1005
> +#define ARCH_SET_CPUID 0x1006
> +#define ARCH_CPUID_ENABLE 1
> +#define ARCH_CPUID_SIGSEGV 2
Which maps to:
prctl(ARCH_SET_CPUID, 0); /* -EINVAL */
prctl(ARCH_SET_CPUID, 1); /* enable CPUID [i.e. make it work without
faulting] */
prctl(ARCH_SET_CPUID, 2); /* disable CPUID [i.e. make it fault] */
ret = prctl(ARCH_GET_CPUID, 0); /* return current state: 1==on, 2==off */
This is a very broken interface that makes very little sense.
It would be much better to use a more natural interface where 1/0 means on/off
and
where ARCH_GET_CPUID returns the current natural state:
prctl(ARCH_SET_CPUID, 0); /* disable CPUID [i.e. make it fault] */
prctl(ARCH_SET_CPUID, 1); /* enable CPUID [i.e. make it work without
faulting] */
ret = prctl(ARCH_GET_CPUID); /* 1==enabled, 0==disabled */
See how natural it is? The use of the ARCH_CPUID_SIGSEGV/ENABLED symbols can be
avoided altogether. This will cut down on some of the ugliness in the kernel
code
as well - and clean up the argument name as well: instead of naming it 'int
arg2'
it can be named the more natural 'int cpuid_enabled'.
> The state of the CPUID faulting flag is propagated across forks, but reset
> upon exec.
I don't think this is the natural API for propagating settings across exec().
We should reset the flag on exec() only if security considerations require it -
i.e. like perf events are cleared.
If binaries that assume a working CPUID are exec()-ed then CPUID can be enabled
explicitly.
Clearing it automatically loses the ability of a pure no-CPUID environment to
exec() a CPUID-safe binary.
> Signed-off-by: Kyle Huey
> ---
> arch/x86/include/asm/msr-index.h | 3 +
> arch/x86/include/asm/processor.h | 2 +
> arch/x86/include/asm/thread_info.h| 6 +-
> arch/x86/include/uapi/asm/prctl.h | 6 +
> arch/x86/kernel/cpu/intel.c | 7 +
> arch/x86/kernel/process.c | 84 ++
> fs/exec.c | 1 +
> include/linux/thread_info.h | 4 +
> tools/testing/selftests/x86/Makefile | 2 +-
> tools/testing/selftests/x86/cpuid-fault.c | 254
> ++
> 10 files changed, 367 insertions(+), 2 deletions(-)
> create mode 100644 tools/testing/selftests/x86/cpuid-fault.c
Please put the self-test into a separate patch.
> static void init_intel_misc_features_enables(struct cpuinfo_x86 *c)
> {
> u64 msr;
>
> + if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, &msr))
> + return;
> +
> + msr = 0;
> + wrmsrl(MSR_MISC_FEATURES_ENABLES, msr);
> + this_cpu_write(msr_misc_features_enables_shadow, msr);
> +
> if (!rdmsrl_safe(MSR_PLATFORM_INFO, &msr)) {
> if (msr & MSR_PLATFORM_INFO_CPUID_FAULT)
> set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
> }
> }
Sigh, so the Intel MSR index itself is grossly misnamed:
MSR_MISC_FEATURES_ENABLES
- plain reading of 'enables' suggests it's a verb, but in wants to be a noun. A
better name would be MSR_MISC_FEATURES or so.
So while for the MSR index we want to keep the Intel name, please drop that
_enables() postfix from the kernel C function names such as this one - and from
the shadow value name as well.
> +DEFINE_PER_CPU(u64, msr_misc_features_enables_shadow);
> +
> +static void set_cpuid_faulting(bool on)
> +{
> + u64 msrval;
> +
> + DEBUG_LOCKS_WARN_ON(!irqs_disabled());
> +
> + msrval = this_cpu_read(msr_misc_features_enables_shadow);
> + msrval &= ~MSR_MISC_FEATURES_ENABLES_CPUID_FAULT;
> + msrval |= (on << MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT);
> + this_cpu_write(msr_misc_features_enables_shadow, msrval);
> + wrmsrl(MSR_MISC_FEATURES_ENABLES, msrval);
This gets called from the context switch path and this looks pretty suboptimal,
especially when combined with the TIF flag check:
> void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
>
Re: [PATCH] sound: Add dependency on DMA
On Thu, 17 Nov 2016 20:42:38 +0100, Florian Fainelli wrote: > > On 11/17/2016 11:14 AM, Florian Fainelli wrote: > > On 11/17/2016 11:03 AM, Takashi Iwai wrote: > >> On Thu, 17 Nov 2016 19:52:37 +0100, > >> Florian Fainelli wrote: > >>> > >>> Architectures like m32r do not have a proper DMA-API implementation, > >>> fixes COMPILE_TEST linking failures for the sounds subsystem. > >> > >> What error did you get exactly? > >> There are already CONFIG_HAS_DMA dependency in a few places, so I > >> wonder what's missing. > > > > They looked like these: > > > > sound/built-in.o: In function `snd_pcm_lib_default_mmap': > > (.text+0xbb14): undefined reference to `bad_dma_ops' > > sound/built-in.o: In function `snd_pcm_lib_default_mmap': > > (.text+0xbb1c): undefined reference to `bad_dma_ops' > > sound/built-in.o: In function `snd_pcm_lib_default_mmap': > > (.text+0xbb34): undefined reference to `dma_common_mmap' > > sound/built-in.o: In function `snd_pcm_lib_default_mmap': > > (.text+0xbb34): relocation truncated to fit: R_M32R_26_PCREL_RELA > > against undefined symbol `dma_common_mmap' > > Makefile:961: recipe for target 'vmlinux' failed > > > > I could probably add an ifdef CONFIG_HAS_DMA just surrounding these > > snd_pcm_lib if you think this is more appropriate? > > I can't reproduce this build failure reliably anyway now, it was due to > switching between x86/m32r configurations, the only offender was the > Broadcom Cygnus driver, and this has been fixed as well. OK, good to hear. Meanwhile, we can put a patch like below just to be sure, too. But you can't check whether it works now ;) thanks, Takashi --- diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 9d33c1e85c79..8d7a61078b9f 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3403,6 +3403,7 @@ int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream, area->vm_end - area->vm_start, area->vm_page_prot); } #endif /* CONFIG_GENERIC_ALLOCATOR */ +#ifdef CONFIG_HAS_DMA #ifndef CONFIG_X86 /* for avoiding warnings arch/x86/mm/pat.c */ if (!substream->ops->page && substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV) @@ -3412,6 +3413,7 @@ int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream, substream->runtime->dma_addr, area->vm_end - area->vm_start); #endif /* CONFIG_X86 */ +#endif /* CONFIG_HAS_DMA */ /* mmap with fault handler */ area->vm_ops = &snd_pcm_vm_ops_data_fault; return 0;
Re: [PATCH v12 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64
* Thomas Gleixner wrote: > On Fri, 18 Nov 2016, Ingo Molnar wrote: > > > > > * Kyle Huey wrote: > > > > > In order to introduce new arch_prctls that are not 64 bit only, rename the > > > existing 64 bit implementation to do_arch_prctl_64(). Also rename the > > > second > > > argument to arch_prctl(), which will no longer always be an address. > > > > > #ifdef CONFIG_X86_64 > > > void entry_SYSCALL_64(void); > > > +long do_arch_prctl_64(struct task_struct *task, int code, unsigned long > > > arg2); > > > #endif > > > > Could you please also rename the weirdly named 'code' argument to 'option', > > to be in line with the existing sys_prctl() interface nomenclature? > > I'll fix that up when picking up the series. No need for another iteration, > ok? I think the main patch needs a bit of conceptual work still: - simpler ABI - better exec() behavior - simpler, better, faster implementation for the MSR writes ... see the mail I just wrote. Thanks, Ingo
Re: kvm: GPF in irqfd_shutdown/eventfd_ctx_remove_wait_queue
On Sat, Nov 12, 2016 at 10:48 PM, Dmitry Vyukov wrote: > On Sat, Nov 12, 2016 at 1:27 PM, Dmitry Vyukov wrote: >> Hello, >> >> I've got the following crash while running syzkaller fuzzer. >> On commit 015ed9433be2b476ec7e2e6a9a411a56e3b5b035 (Nov 11). >> Unfortunately it is not reproducible. >> May be related to: >> https://groups.google.com/forum/#!topic/syzkaller/NKlClJzOOww >> https://groups.google.com/forum/#!topic/syzkaller/Dz__GySpVr8 >> >> general protection fault: [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 17194 Comm: kworker/0:2 Not tainted 4.9.0-rc4+ #49 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> Workqueue: kvm-irqfd-cleanup irqfd_shutdown >> task: 88003b2bdb40 task.stack: 88003bcd8000 >> RIP: 0010:[] [< inline >] __list_del >> include/linux/list.h:89 >> RIP: 0010:[] [< inline >] list_del >> include/linux/list.h:107 >> RIP: 0010:[] [< inline >] >> __remove_wait_queue include/linux/wait.h:196 >> RIP: 0010:[] [] >> eventfd_ctx_remove_wait_queue+0x139/0x2d0 fs/eventfd.c:201 >> RSP: 0018:88003bcdfb50 EFLAGS: 00010002 >> RAX: RBX: 88003cefbd40 RCX: dc00 >> RDX: RSI: 0001 RDI: 0008 >> RBP: 88003bcdfb90 R08: 90a58b45 R09: 0001 >> R10: 84da2600 R11: 11000779bf36 R12: 88003b986b88 >> R13: 88003bcdfbc8 R14: 88003cefbd48 R15: 0081 >> FS: () GS:88003ec0() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 00813000 CR3: 65fd4000 CR4: 26f0 >> Stack: >> 88003bcdfb60 88003cefbd90 0296 88003b986b80 >> 88003b986ca8 11000779bf75 88003b986c80 dc00 >> 88003bcdfc30 8106dd86 41b58ab3 >> Call Trace: >> [] irqfd_shutdown+0x96/0x1a0 >> arch/x86/kvm/../../../virt/kvm/eventfd.c:128 >> [] process_one_work+0x9fc/0x1900 kernel/workqueue.c:2096 >> [] worker_thread+0xef/0x1480 kernel/workqueue.c:2230 >> [] kthread+0x244/0x2d0 kernel/kthread.c:209 >> [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433 >> Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 83 01 00 00 48 8d 7a 08 >> 48 b9 00 00 00 00 00 fc ff df 49 8b 44 24 20 48 89 fe 48 c1 ee 03 <80> >> 3c 0e 00 0f 85 45 01 00 00 48 89 c6 48 b9 00 00 00 00 00 fc >> RIP [< inline >] __list_del include/linux/list.h:89 >> RIP [< inline >] list_del include/linux/list.h:107 >> RIP [< inline >] __remove_wait_queue include/linux/wait.h:196 >> RIP [] eventfd_ctx_remove_wait_queue+0x139/0x2d0 >> fs/eventfd.c:201 >> RSP >> ---[ end trace 9772f974e210aab6 ]--- >> Kernel panic - not syncing: Fatal exception >> Shutting down cpus with NMI >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Kernel Offset: disabled >> reboot: cpu_has_vmx: ecx=80a02021 1 > > > Another use-after-free that looks relevant: > > BUG: KASAN: use-after-free in insert_work+0x24a/0x2e0 at addr 88003d87bcd8 > Read of size 8 by task syz-executor/28580 > CPU: 0 PID: 28580 Comm: syz-executor Not tainted 4.9.0-rc4+ #49 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > 88003c60f920 81c2e46b 88003e80ccc0 88003d87bc38 > 88003d87bf70 88003c60f948 8165ab9c > ed0007b0f79b ed0007b0f79b 88003e80ccc0 88003c60f9c8 > Call Trace: > [< inline >] __dump_stack lib/dump_stack.c:15 > [] dump_stack+0xb3/0x118 lib/dump_stack.c:51 > [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 > [< inline >] print_address_description mm/kasan/report.c:194 > [< inline >] kasan_report_error mm/kasan/report.c:283 > [] kasan_report+0x231/0x500 mm/kasan/report.c:303 > [] __asan_report_load8_noabort+0x14/0x20 > mm/kasan/report.c:329 > [< inline >] constant_test_bit arch/x86/include/asm/bitops.h:311 > [< inline >] set_work_data kernel/workqueue.c:614 > [< inline >] set_work_pwq kernel/workqueue.c:621 > [] insert_work+0x24a/0x2e0 kernel/workqueue.c:1297 > [] __queue_work+0x4f1/0xed0 kernel/workqueue.c:1459 > [] queue_work_on+0x97/0xa0 kernel/workqueue.c:1484 > [< inline >] queue_work include/linux/workqueue.h:474 > [< inline >] schedule_work include/linux/workqueue.h:532 > [< inline >] kvm_irqfd_assign > arch/x86/kvm/../../../virt/kvm/eventfd.c:403 > [] kvm_irqfd+0x117f/0x18a0 > arch/x86/kvm/../../../virt/kvm/eventfd.c:572 > [] kvm_vm_ioctl+0x2e7/0x1670 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:2996 > [< inline >] vfs_ioctl fs/ioctl.c:43 > [] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679 > [< inline >] SYSC_ioctl fs/ioctl.c:694 > [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685 > [] entry_SYSCALL_64_fastpath+0x1f/0xc2 > Object at 88003d87bc38, in cache kmalloc-51
Re: [PATCH 0/5] x86: remove idle notifier
* Len Brown wrote: > The return from idle path is latency sensitive, > so the less code and fewer data accesses, the better. > > Remove the un-maintained i7300_idle driver, > the only user of the x86 idle-notifier, > and then remove the notifier itself. Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH v2 1/3] hwmon: ltc2990: refactor value conversion
Hi Guenter,
On Thu, 17 Nov 2016, Guenter Roeck wrote:
On 11/17/2016 08:23 AM, Tom Levens wrote:
Hi Guenter,
Thanks for taking the time to review the patch.
On Thu, 17 Nov 2016, Guenter Roeck wrote:
> Hi Tom,
>
> On 11/17/2016 04:10 AM, Tom Levens wrote:
> > Conversion from raw values to signed integers has been refactored
> > using
> > the macros in bitops.h.
> >
> Please also mention that this fixes a bug in negative temperature
> conversions.
Yes, of course, I will include the information in v3.
>
> > Signed-off-by: Tom Levens
> > ---
> >drivers/hwmon/ltc2990.c | 27 ++-
> >1 files changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
> > index 8f8fe05..0ec4102 100644
> > --- a/drivers/hwmon/ltc2990.c
> > +++ b/drivers/hwmon/ltc2990.c
> > @@ -9,8 +9,12 @@
> > * This driver assumes the chip is wired as a dual current monitor,
> > and
> > * reports the voltage drop across two series resistors. It also
> > reports
> > * the chip's internal temperature and Vcc power supply voltage.
> > + *
> > + * Value conversion refactored
> > + * by Tom Levens
>
> Kind of unusual to do that for minor changes like this. Imagine if
> everyone would do that.
> The commit log is what gives you credit.
Good point, thanks for the hint. I will remove it from v3.
> > */
> >
> > +#include
> >#include
> >#include
> >#include
> > @@ -34,19 +38,10 @@
> >#define LTC2990_CONTROL_MODE_CURRENT0x06
> >#define LTC2990_CONTROL_MODE_VOLTAGE0x07
> >
> > -/* convert raw register value to sign-extended integer in 16-bit
> > range */
> > -static int ltc2990_voltage_to_int(int raw)
> > -{
> > -if (raw & BIT(14))
> > -return -(0x4000 - (raw & 0x3FFF)) << 2;
> > -else
> > -return (raw & 0x3FFF) << 2;
> > -}
> > -
> > /* Return the converted value from the given register in uV or mC */
> > -static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, int
> > *result)
> > +static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, s32
> > *result)
> > {
> > -int val;
> > +s32 val;
>
> Please just leave the variable type alone. it is also used for the
> return value
> from i2c_smbus_read_word_swapped(), which is an int, and changing it to
> s32 doesn't really make the code better.
According to i2c.h the return type for i2c_smbus_read_word_swapped() is
s32, which is why I modified it here. But it could be changed back if you
think it is better to leave it as an int.
Ah, ok. Good to know. Please leave it anyway, reason being that there is no
real
reason to change it. Effectively those are just whitespace changes (unlike
the rest,
which is part bug fix, part cleanup).
> Can you send me a register map for the chip ? I would like to write a
> module test.
Here is an example register dump:
I meant the output of i2cdump (something like "i2cdump -y -f
w").
The register map wraps at 0x0F, so I only sent you the first 16 bytes. But
the fully expanded form is:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
10: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
20: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
30: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
40: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
50: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
60: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
70: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
80: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
90: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
a0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
b0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
c0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
d0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
e0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
f0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
Cheers,
Thanks,
Guenter
00 00 00 00
01 90 07 d0
2c cd 7d 80
7c 29 20 00
The expected values in this case are:
in0_input 5000
in1_input610
in2_input3500
in3_input-195
in4_input-299
temp1_input 25000
temp2_input 125000
temp3_input-4
curr1_input38840
curr2_input-12428
Testing with lltc,mode set to <5>, <6> and <7> should give you all
measurements.
> Thanks,
> Guenter
Cheers,
RE: [PATCH] net: fec: Detect and recover receive queue hangs
From: Chris Lesiak Sent: Friday, November 18, 2016
5:15 AM
>To: Andy Duan
>Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Jaccon
>Bastiaansen ; chris.les...@licor.com
>Subject: [PATCH] net: fec: Detect and recover receive queue hangs
>
>This corrects a problem that appears to be similar to ERR006358. But while
>ERR006358 is a race when the tx queue transitions from empty to not empty,
>this problem is a race when the rx queue transitions from full to not full.
>
>The symptom is a receive queue that is stuck. The ENET_RDAR register will
>read 0, indicating that there are no empty receive descriptors in the receive
>ring. Since no additional frames can be queued, no RXF interrupts occur.
>
>This problem can be triggered with a 1 Gb link and about 400 Mbps of traffic.
>
>This patch detects this condition, sets the work_rx bit, and reschedules the
>poll method.
>
>Signed-off-by: Chris Lesiak
>---
> drivers/net/ethernet/freescale/fec_main.c | 31
>+++
> 1 file changed, 31 insertions(+)
>
Firstly, how to reproduce the issue, pls list the reproduce steps. Thanks.
Secondly, pls check below comments.
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index fea0f33..8a87037 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -1588,6 +1588,34 @@ fec_enet_interrupt(int irq, void *dev_id)
> return ret;
> }
>
>+static inline bool
>+fec_enet_recover_rxq(struct fec_enet_private *fep, u16 queue_id) {
>+ int work_bit = (queue_id == 0) ? 2 : ((queue_id == 1) ? 0 : 1);
>+
>+ if (readl(fep->rx_queue[queue_id]->bd.reg_desc_active))
If rx ring is really empty in slight throughput cases, rdar is always cleared,
then there always do napi reschedule.
>+ return false;
>+
>+ dev_notice_once(&fep->pdev->dev, "Recovered rx queue\n");
>+
>+ fep->work_rx |= 1 << work_bit;
>+
>+ return true;
>+}
>+
>+static inline bool fec_enet_recover_rxqs(struct fec_enet_private *fep)
>+{
>+ unsigned int q;
>+ bool ret = false;
>+
>+ for (q = 0; q < fep->num_rx_queues; q++) {
>+ if (fec_enet_recover_rxq(fep, q))
>+ ret = true;
>+ }
>+
>+ return ret;
>+}
>+
> static int fec_enet_rx_napi(struct napi_struct *napi, int budget) {
> struct net_device *ndev = napi->dev;
>@@ -1601,6 +1629,9 @@ static int fec_enet_rx_napi(struct napi_struct *napi,
>int budget)
> if (pkts < budget) {
> napi_complete(napi);
> writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
>+
>+ if (fec_enet_recover_rxqs(fep) && napi_reschedule(napi))
>+ writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
> }
> return pkts;
> }
>--
>2.5.5
Re: [PATCH 4/4] x86/tsc: set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs
* Bin Gao wrote: > TSC on Intel Atom SoCs capable of determining TSC frequency by MSR is > reliable and the frequency is known (because it's provided by HW). > On these platforms PIT/HPET is generally not available so > calibration won't work at all and also TSC is the only reliable > clocksource. So we set both X86_FEATURE_TSC_KNOWN_FREQ and > X86_FEATURE_TSC_RELIABLE flags to make sure the calibration is > skipped and no watchdog on TSC. > + /* > + * TSC frequency determined by MSR is always considered "known" > + * because it is reported by HW. > + * Another fact is that on MSR capable platforms, PIT/HPET is > + * generally not available so calibration won't work at all. > + */ > + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); > + > + /* > + * Unfortunately there is no a HW way to report TSC is reliable. > + * We were told by silicon design team that TSC on Atom SoCs are > + * always "reliable". TSC is also the only reliable clocksource > + * on these SoCs (HPET is either not present or not functional) > + * so marke TSC reliable to avoid watchdog on it. minor nit: s/there is no a HW way/ there is no HW way Thanks, Ingo
[PATCH 0/2] Thunderbolt Kbuild fixes
Dear Ingo,
please consider applying the following two patches to efi/core for 4.10,
based on the discussion with Arnd:
The first one fixes a build breakage for certain configs on arm and arm64,
the second one excludes thunderbolt from the build on non-x86 except for
compile tests.
Feel free to squash the first one with the existing commit 79f9cd35b05e
("thunderbolt, efi: Fix Kconfig dependencies") on this branch, or squash
both with c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from EFI")
if you want.
Thank you!
Lukas
Lukas Wunner (2):
thunderbolt, efi: Fix Kconfig dependencies harder
thunderbolt: Compile on x86 only
drivers/thunderbolt/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.10.1
[PATCH 2/2] thunderbolt: Compile on x86 only
So far Thunderbolt is (unfortunately) an Intel proprietary technology that is only available on x86, so compiling on other arches is pointless except for testing purposes. Amend Kconfig accordingly. Suggested-by: Arnd Bergmann Cc: Andreas Noever Cc: Matt Fleming Signed-off-by: Lukas Wunner --- drivers/thunderbolt/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig index de5d27e..d35db16 100644 --- a/drivers/thunderbolt/Kconfig +++ b/drivers/thunderbolt/Kconfig @@ -1,6 +1,7 @@ menuconfig THUNDERBOLT tristate "Thunderbolt support for Apple devices" depends on PCI + depends on X86 || COMPILE_TEST select APPLE_PROPERTIES if EFI_STUB && X86 select CRC32 help -- 2.10.1
[PATCH 1/2] thunderbolt, efi: Fix Kconfig dependencies harder
Since commit c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from
EFI"), the THUNDERBOLT config option selects APPLE_PROPERTIES.
This broke the build for certain configs because APPLE_PROPERTIES is
located in a menu which depends on EFI: If EFI is not enabled, the
prerequisites needed for APPLE_PROPERTIES are not selected: Those are
EFI_DEV_PATH_PARSER and UCS2_STRING. Additionally EFI_DEV_PATH_PARSER
won't compile unless ACPI is enabled.
Commit 79f9cd35b05e ("thunderbolt, efi: Fix Kconfig dependencies")
sought to fix the breakage by making THUNDERBOLT select APPLE_PROPERTIES
only if EFI_STUB is enabled. On x86, EFI_STUB depends on EFI and EFI
depends on ACPI, so this fixed the build at least on this architecture.
However on arm and arm64, EFI_STUB does not depend on EFI, so once again
the prerequisites needed for APPLE_PROPERTIES are not selected.
Additionally ACPI is not available on arm and optional on arm64,
therefore EFI_DEV_PATH_PARSER won't compile.
Fix by selecting APPLE_PROPERTIES only on x86.
Suggested-by: Arnd Bergmann
Cc: Andreas Noever
Cc: Matt Fleming
Signed-off-by: Lukas Wunner
---
drivers/thunderbolt/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
index bb0318c..de5d27e 100644
--- a/drivers/thunderbolt/Kconfig
+++ b/drivers/thunderbolt/Kconfig
@@ -1,7 +1,7 @@
menuconfig THUNDERBOLT
tristate "Thunderbolt support for Apple devices"
depends on PCI
- select APPLE_PROPERTIES if EFI_STUB
+ select APPLE_PROPERTIES if EFI_STUB && X86
select CRC32
help
Cactus Ridge Thunderbolt Controller driver
--
2.10.1
Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes
On Nov 17, 2016, at 6:35 AM, David Howells wrote:
>
> Return enhanced file attributes from the AFS filesystem. This includes the
> following:
>
> (1) The data version number as st_version, setting STATX_VERSION.
>
> (2) STATX_ATTR_AUTOMOUNT will be set on automount directories by virtue of
> S_AUTOMOUNT being set on the inode. These are referrals to other
> volumes or other cells.
>
> (3) STATX_ATTR_UNLISTED_DENTS on a directory that does cell lookup for
> non-existent names and mounts them (typically mounted on /afs with -o
> autocell). The resulting directories are marked STATX_ATTR_FABRICATED
> as they do not actually exist in the mounted AFS directory.
>
> (4) Files, directories and symlinks accessed over AFS are marked
> STATX_ATTR_REMOTE.
>
> STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not
> support them.
Rather than clearing specific flags, wouldn't it be better to explicitly
set the flags that are actually being returned? Otherwise, this would
have the problem that Dave pointed out on the 0/4 patch, that there may
be flags still set from userspace that do not mean anything to AFS.
Cheers, Andreas
>
> Example output:
>
> [root@andromeda ~]# ./samples/statx/test-statx /afs
> statx(/afs) = 0
> results=7ef
> Size: 2048Blocks: 0 IO Block: 4096directory
> Device: 00:25 Inode: 1 Links: 2
> Access: (0777/drwxrwxrwx) Uid: 0 Gid: 0
> Access: 2006-05-07 00:21:15.0+0100
> Modify: 2006-05-07 00:21:15.0+0100
> Change: 2006-05-07 00:21:15.0+0100
> IO-blocksize: blksize=4096
>
> Signed-off-by: David Howells
> ---
>
> fs/afs/inode.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/fs/afs/inode.c b/fs/afs/inode.c
> index 86cc7264c21c..b08c405a7e1b 100644
> --- a/fs/afs/inode.c
> +++ b/fs/afs/inode.c
> @@ -72,9 +72,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode,
> struct key *key)
> inode->i_uid= vnode->status.owner;
> inode->i_gid= GLOBAL_ROOT_GID;
> inode->i_size = vnode->status.size;
> - inode->i_ctime.tv_sec = vnode->status.mtime_server;
> - inode->i_ctime.tv_nsec = 0;
> - inode->i_atime = inode->i_mtime = inode->i_ctime;
> + inode->i_mtime.tv_sec = vnode->status.mtime_server;
> + inode->i_mtime.tv_nsec = 0;
> + inode->i_atime = inode->i_ctime = inode->i_mtime;
> inode->i_blocks = 0;
> inode->i_generation = vnode->fid.unique;
> inode->i_version= vnode->status.data_version;
> @@ -375,8 +375,7 @@ int afs_validate(struct afs_vnode *vnode, struct key *key)
> /*
> * read the attributes of an inode
> */
> -int afs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> - struct kstat *stat)
> +int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat
> *stat)
> {
> struct inode *inode;
>
> @@ -385,6 +384,18 @@ int afs_getattr(struct vfsmount *mnt, struct dentry
> *dentry,
> _enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation);
>
> generic_fillattr(inode, stat);
> +
> + stat->result_mask &= ~(STATX_ATIME | STATX_CTIME | STATX_BLOCKS);
> + stat->result_mask |= STATX_VERSION;
> + stat->version = inode->i_version;
> +
> + if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags))
> + stat->attributes |= STATX_ATTR_UNLISTED_DENTS;
> +
> + if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags))
> + stat->attributes |= STATX_ATTR_FABRICATED;
> + else
> + stat->attributes |= STATX_ATTR_REMOTE;
> return 0;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token
* Vince Weaver wrote: > On Thu, 17 Nov 2016, Vince Weaver wrote: > > > On Thu, 17 Nov 2016, Vince Weaver wrote: > > > > > > > > [ 911.507365] > > > > == > > > > [ 911.514824] BUG: KASAN: global-out-of-bounds in > > > > match_token+0x268/0x310 at addr b14ad058 > > > > [ 911.523912] Read of size 8 by task perf_fuzzer/20662 > > > > [ 911.528945] Address belongs to variable if_tokens+0x78/0xa0 > > I managed to create a short reproducer that reliably causes the issue on > my skylake test machine. Awesome, thanks a lot Vince! Ingo
Re: [PATCHv3 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
* Laura Abbott wrote: > > DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting > the same support. Rather than add a list of architectures, switch this > to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as > appropriate. > > Suggested-by: Mark Rutland > Signed-off-by: Laura Abbott > --- > v3: No change, x86 maintainers please ack if you are okay with this. > --- > arch/x86/Kconfig | 1 + > lib/Kconfig.debug | 5 - > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index bada636..f533321 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -23,6 +23,7 @@ config X86 > select ARCH_CLOCKSOURCE_DATA > select ARCH_DISCARD_MEMBLOCK > select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI > + select ARCH_HAS_DEBUG_VIRTUAL > select ARCH_HAS_DEVMEM_IS_ALLOWED > select ARCH_HAS_ELF_RANDOMIZE > select ARCH_HAS_FAST_MULTIPLIER Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH 7/9] lib: radix-tree: update callback for changing leaf nodes
On Thu 17-11-16 14:31:34, Johannes Weiner wrote:
> Support handing __radix_tree_replace() a callback that gets invoked
> for all leaf nodes that change or get freed as a result of the slot
> replacement, to assist users tracking nodes with node->private_list.
>
> This prepares for putting page cache shadow entries into the radix
> tree root again and drastically simplifying the shadow tracking.
>
> Suggested-by: Jan Kara
> Signed-off-by: Johannes Weiner
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/dax.c | 3 ++-
> include/linux/radix-tree.h | 4 +++-
> lib/radix-tree.c | 42 +-
> mm/shmem.c | 3 ++-
> 4 files changed, 36 insertions(+), 16 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 85930c2a2749..6916ed37d463 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -649,7 +649,8 @@ static void *dax_insert_mapping_entry(struct
> address_space *mapping,
>
> ret = __radix_tree_lookup(page_tree, index, &node, &slot);
> WARN_ON_ONCE(ret != entry);
> - __radix_tree_replace(page_tree, node, slot, new_entry);
> + __radix_tree_replace(page_tree, node, slot,
> + new_entry, NULL, NULL);
> }
> if (vmf->flags & FAULT_FLAG_WRITE)
> radix_tree_tag_set(page_tree, index, PAGECACHE_TAG_DIRTY);
> diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
> index 2d1b9b8be983..15c972ea9510 100644
> --- a/include/linux/radix-tree.h
> +++ b/include/linux/radix-tree.h
> @@ -263,9 +263,11 @@ void *__radix_tree_lookup(struct radix_tree_root *root,
> unsigned long index,
> struct radix_tree_node **nodep, void ***slotp);
> void *radix_tree_lookup(struct radix_tree_root *, unsigned long);
> void **radix_tree_lookup_slot(struct radix_tree_root *, unsigned long);
> +typedef void (*radix_tree_update_node_t)(struct radix_tree_node *, void *);
> void __radix_tree_replace(struct radix_tree_root *root,
> struct radix_tree_node *node,
> - void **slot, void *item);
> + void **slot, void *item,
> + radix_tree_update_node_t update_node, void *private);
> void radix_tree_replace_slot(struct radix_tree_root *root,
>void **slot, void *item);
> bool __radix_tree_delete_node(struct radix_tree_root *root,
> diff --git a/lib/radix-tree.c b/lib/radix-tree.c
> index 5d8930f3b3d8..df4ff18dd63c 100644
> --- a/lib/radix-tree.c
> +++ b/lib/radix-tree.c
> @@ -325,7 +325,6 @@ static void radix_tree_node_rcu_free(struct rcu_head
> *head)
> tag_clear(node, i, 0);
>
> node->slots[0] = NULL;
> - node->count = 0;
>
> kmem_cache_free(radix_tree_node_cachep, node);
> }
> @@ -542,7 +541,9 @@ static int radix_tree_extend(struct radix_tree_root *root,
> * radix_tree_shrink-shrink radix tree to minimum height
> * @root radix tree root
> */
> -static inline bool radix_tree_shrink(struct radix_tree_root *root)
> +static inline bool radix_tree_shrink(struct radix_tree_root *root,
> + radix_tree_update_node_t update_node,
> + void *private)
> {
> bool shrunk = false;
>
> @@ -597,8 +598,12 @@ static inline bool radix_tree_shrink(struct
> radix_tree_root *root)
>* also results in a stale slot). So tag the slot as indirect
>* to force callers to retry.
>*/
> - if (!radix_tree_is_internal_node(child))
> + node->count = 0;
> + if (!radix_tree_is_internal_node(child)) {
> node->slots[0] = RADIX_TREE_RETRY;
> + if (update_node)
> + update_node(node, private);
> + }
>
> radix_tree_node_free(node);
> shrunk = true;
> @@ -608,7 +613,8 @@ static inline bool radix_tree_shrink(struct
> radix_tree_root *root)
> }
>
> static bool delete_node(struct radix_tree_root *root,
> - struct radix_tree_node *node)
> + struct radix_tree_node *node,
> + radix_tree_update_node_t update_node, void *private)
> {
> bool deleted = false;
>
> @@ -617,7 +623,8 @@ static bool delete_node(struct radix_tree_root *root,
>
> if (node->count) {
> if (node == entry_to_node(root->rnode))
> - deleted |= radix_tree_shrink(root);
> + deleted |= radix_tree_shrink(root, update_node,
> + private);
> return deleted;
> }
>
> @@ -880,17 +887,20 @@ static void replace_slot(struct radix_tree_
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Thu, Nov 17, 2016 at 04:36:24PM +, Will Deacon wrote:
> On Thu, Nov 17, 2016 at 05:11:10PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 17, 2016 at 12:08:36PM +, Will Deacon wrote:
> > > All sounds reasonable to me. It's worth pointing out that you can't create
> > > order using a control dependency hanging off the status flag of a
> > > store-conditional, but the code in question here has the dependency from
> > > the loaded value, which is sufficient.
> >
> > Yeah, I'm always surprised by that 'feature'. Is that ARM specific? Or
> > so more LL/SC archs have this?
>
> In general, I'm not sure, but I think PPC does allow for the control
> dependency.
>
You guys mean the "control dependency" from a sc to subsequent WRITE,
like in the following litmus?
PPC sc-control
""
{
0:r11=x;0:r12=y;0:r3=1;0:r10=0;
1:r11=x;1:r12=y;
}
P0 | P1 ;
lwarx r2, r10, r11 | lwz r2, 0(r12) ;
stwcx. r3, r10, r11 | lwsync ;
bne Fail |;
stw r3, 0(r12) | lwz r1, 0(r11) ;
Fail:|;
exists
(1:r2 = 1 /\ x = 1 /\ 1:r1 = 0)
PPCMEM and herd both said the exists-clause could be triggered
"Sometimes".
And ISA said:
"""
Because a Store Conditional instruction may complete before its store
has been performed, a conditional Branch instruction that depends on the
CR0 value set by a Store Conditional instruction does not order the
Store Conditional's store with respect to storage accesses caused by
instructions that follow the Branch.
"""
So ppc doesn't honor this "control dependency". ;-)
Regards,
Boqun
> Will
signature.asc
Description: PGP signature
Re: [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute
Hi Russell, On 03/11/16 05:28, Juri Lelli wrote: > Hi, > > apologies for the delay in replying, but I'm attending Linux Plumbers > this week. > > On 30/10/16 20:45, Russell King - ARM Linux wrote: > > On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote: [...] > > I should have addressed your comments with the updated version below. If > it looks good to you I'll superseed the old version with this new one. > The two updated patches are still listed as incoming in your system. Do you think we will be able to queue them for 4.10? IMHO, it would be good to have all pieces in together at once (Catalin and Sudeep already queued their respective bits). Thanks a lot. Best, - Juri
Re: [PATCH 8/9] mm: workingset: move shadow entry tracking to radix tree exceptional tracking
On Thu 17-11-16 14:32:11, Johannes Weiner wrote:
> Currently, we track the shadow entries in the page cache in the upper
> bits of the radix_tree_node->count, behind the back of the radix tree
> implementation. Because the radix tree code has no awareness of them,
> we rely on random subtleties throughout the implementation (such as
> the node->count != 1 check in the shrinking code, which is meant to
> exclude multi-entry nodes but also happens to skip nodes with only one
> shadow entry, as that's accounted in the upper bits). This is error
> prone and has, in fact, caused the bug fixed in d3798ae8c6f3 ("mm:
> filemap: don't plant shadow entries without radix tree node").
>
> To remove these subtleties, this patch moves shadow entry tracking
> from the upper bits of node->count to the existing counter for
> exceptional entries. node->count goes back to being a simple counter
> of valid entries in the tree node and can be shrunk to a single byte.
>
> This vastly simplifies the page cache code. All accounting happens
> natively inside the radix tree implementation, and maintaining the LRU
> linkage of shadow nodes is consolidated into a single function in the
> workingset code that is called for leaf nodes affected by a change in
> the page cache tree.
>
> This also removes the last user of the __radix_delete_node() return
> value. Eliminate it.
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
>
> Signed-off-by: Johannes Weiner
> ---
> include/linux/radix-tree.h | 8 ++-
> include/linux/swap.h | 34 +---
> lib/radix-tree.c | 25 +
> mm/filemap.c | 54 +---
> mm/truncate.c | 21 +++--
> mm/workingset.c| 56
> +++---
> 6 files changed, 60 insertions(+), 138 deletions(-)
>
> diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
> index 15c972ea9510..744486057e9e 100644
> --- a/include/linux/radix-tree.h
> +++ b/include/linux/radix-tree.h
> @@ -80,14 +80,10 @@ static inline bool radix_tree_is_internal_node(void *ptr)
> #define RADIX_TREE_MAX_PATH (DIV_ROUND_UP(RADIX_TREE_INDEX_BITS, \
> RADIX_TREE_MAP_SHIFT))
>
> -/* Internally used bits of node->count */
> -#define RADIX_TREE_COUNT_SHIFT (RADIX_TREE_MAP_SHIFT + 1)
> -#define RADIX_TREE_COUNT_MASK((1UL << RADIX_TREE_COUNT_SHIFT) - 1)
> -
> struct radix_tree_node {
> unsigned char shift; /* Bits remaining in each slot */
> unsigned char offset; /* Slot offset in parent */
> - unsigned intcount; /* Total entry count */
> + unsigned char count; /* Total entry count */
> unsigned char exceptional;/* Exceptional entry count */
> union {
> struct {
> @@ -270,7 +266,7 @@ void __radix_tree_replace(struct radix_tree_root *root,
> radix_tree_update_node_t update_node, void *private);
> void radix_tree_replace_slot(struct radix_tree_root *root,
>void **slot, void *item);
> -bool __radix_tree_delete_node(struct radix_tree_root *root,
> +void __radix_tree_delete_node(struct radix_tree_root *root,
> struct radix_tree_node *node);
> void *radix_tree_delete_item(struct radix_tree_root *, unsigned long, void
> *);
> void *radix_tree_delete(struct radix_tree_root *, unsigned long);
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index a56523cefb9b..09b212d37f1d 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -246,39 +246,7 @@ struct swap_info_struct {
> void *workingset_eviction(struct address_space *mapping, struct page *page);
> bool workingset_refault(void *shadow);
> void workingset_activation(struct page *page);
> -extern struct list_lru workingset_shadow_nodes;
> -
> -static inline unsigned int workingset_node_pages(struct radix_tree_node
> *node)
> -{
> - return node->count & RADIX_TREE_COUNT_MASK;
> -}
> -
> -static inline void workingset_node_pages_inc(struct radix_tree_node *node)
> -{
> - node->count++;
> -}
> -
> -static inline void workingset_node_pages_dec(struct radix_tree_node *node)
> -{
> - VM_WARN_ON_ONCE(!workingset_node_pages(node));
> - node->count--;
> -}
> -
> -static inline unsigned int workingset_node_shadows(struct radix_tree_node
> *node)
> -{
> - return node->count >> RADIX_TREE_COUNT_SHIFT;
> -}
> -
> -static inline void workingset_node_shadows_inc(struct radix_tree_node *node)
> -{
> - node->count += 1U << RADIX_TREE_COUNT_SHIFT;
> -}
> -
> -static inline void workingset_node_shadows_dec(struct radix_tree_node *node)
> -{
> - VM_WARN_ON_ONCE(!workingset_node_shadows(node));
> - node->count -= 1U << RADIX_TREE_COUNT_SHIFT;
> -}
> +void workingset_update_node
Re: [PATCH 0/2] Thunderbolt Kbuild fixes
On Friday, November 18, 2016 9:22:59 AM CET Lukas Wunner wrote:
> Dear Ingo,
>
> please consider applying the following two patches to efi/core for 4.10,
> based on the discussion with Arnd:
>
> The first one fixes a build breakage for certain configs on arm and arm64,
> the second one excludes thunderbolt from the build on non-x86 except for
> compile tests.
>
> Feel free to squash the first one with the existing commit 79f9cd35b05e
> ("thunderbolt, efi: Fix Kconfig dependencies") on this branch, or squash
> both with c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from EFI")
> if you want.
Both patches
Acked-by: Arnd Bergmann
Thanks for following up,
Arnd
Re: [PATCH 9/9] mm: workingset: restore refault tracking for single-page files
On Thu 17-11-16 14:32:44, Johannes Weiner wrote:
> Shadow entries in the page cache used to be accounted behind the radix
> tree implementation's back in the upper bits of node->count, and the
> radix tree code extending a single-entry tree with a shadow entry in
> root->rnode would corrupt that counter. As a result, we could not put
> shadow entries at index 0 if the tree didn't have any other entries,
> and that means no refault detection for any single-page file.
>
> Now that the shadow entries are tracked natively in the radix tree's
> exceptional counter, this is no longer necessary. Extending and
> shrinking the tree from and to single entries in root->rnode now does
> the right thing when the entry is exceptional, remove that limitation.
>
> Signed-off-by: Johannes Weiner
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/filemap.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 7d92032277ff..ae7b6992aded 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -164,14 +164,7 @@ static void page_cache_tree_delete(struct address_space
> *mapping,
> __radix_tree_lookup(&mapping->page_tree, page->index + i,
> &node, &slot);
>
> - if (!node) {
> - VM_BUG_ON_PAGE(nr != 1, page);
> - /*
> - * We need a node to properly account shadow
> - * entries. Don't plant any without. XXX
> - */
> - shadow = NULL;
> - }
> + VM_BUG_ON_PAGE(!node && nr != 1, page);
>
> radix_tree_clear_tags(&mapping->page_tree, node, slot);
> __radix_tree_replace(&mapping->page_tree, node, slot, shadow,
> --
> 2.10.2
>
--
Jan Kara
SUSE Labs, CR
Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
Hi Bharat, On 18/11/2016 06:34, Bharat Bhushan wrote: > Hi Eric, > > Have you sent out QEMU side patches based on this new approach? In case I > missed please point me the patches? Upstream QEMU works fine for PCIe/MSI passthrough on ARM since mach virt address space does not collide with fixed MSI region. Thanks Eric > > Thanks > -Bharat > >> -Original Message- >> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- >> boun...@lists.linux-foundation.org] On Behalf Of Eric Auger >> Sent: Tuesday, November 15, 2016 6:39 PM >> To: eric.au...@redhat.com; eric.auger@gmail.com; >> christoffer.d...@linaro.org; marc.zyng...@arm.com; >> robin.mur...@arm.com; alex.william...@redhat.com; >> will.dea...@arm.com; j...@8bytes.org; t...@linutronix.de; >> ja...@lakedaemon.net; linux-arm-ker...@lists.infradead.org >> Cc: drjo...@redhat.com; k...@vger.kernel.org; punit.agra...@arm.com; >> linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org; >> pranav.sawargaon...@gmail.com >> Subject: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and >> IOVA reserved regions >> >> Following LPC discussions, we now report reserved regions through iommu- >> group sysfs reserved_regions attribute file. >> >> Reserved regions are populated through the IOMMU get_resv_region >> callback (former get_dm_regions), now implemented by amd-iommu, intel- >> iommu and arm-smmu. >> >> The intel-iommu reports the [FEE0_h - FEF0_000h] MSI window as an >> IOMMU_RESV_NOMAP reserved region. >> >> arm-smmu reports the MSI window (arbitrarily located at 0x800 and 1MB >> large) and the PCI host bridge windows. >> >> The series integrates a not officially posted patch from Robin: >> "iommu/dma: Allow MSI-only cookies". >> >> This series currently does not address IRQ safety assessment. >> >> Best Regards >> >> Eric >> >> Git: complete series available at >> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3 >> >> History: >> RFC v2 -> v3: >> - switch to an iommu-group sysfs API >> - use new dummy allocator provided by Robin >> - dummy allocator initialized by vfio-iommu-type1 after enumerating >> the reserved regions >> - at the moment ARM MSI base address/size is left unchanged compared >> to v2 >> - we currently report reserved regions and not usable IOVA regions as >> requested by Alex >> >> RFC v1 -> v2: >> - fix intel_add_reserved_regions >> - add mutex lock/unlock in vfio_iommu_type1 >> >> >> Eric Auger (10): >> iommu/dma: Allow MSI-only cookies >> iommu: Rename iommu_dm_regions into iommu_resv_regions >> iommu: Add new reserved IOMMU attributes >> iommu: iommu_alloc_resv_region >> iommu: Do not map reserved regions >> iommu: iommu_get_group_resv_regions >> iommu: Implement reserved_regions iommu-group sysfs file >> iommu/vt-d: Implement reserved region get/put callbacks >> iommu/arm-smmu: Implement reserved region get/put callbacks >> vfio/type1: Get MSI cookie >> >> drivers/iommu/amd_iommu.c | 20 +++--- >> drivers/iommu/arm-smmu.c| 52 +++ >> drivers/iommu/dma-iommu.c | 116 ++ >> --- >> drivers/iommu/intel-iommu.c | 50 ++ >> drivers/iommu/iommu.c | 141 >> >> drivers/vfio/vfio_iommu_type1.c | 26 >> include/linux/dma-iommu.h | 7 ++ >> include/linux/iommu.h | 49 ++ >> 8 files changed, 391 insertions(+), 70 deletions(-) >> >> -- >> 1.9.1 >> >> ___ >> iommu mailing list >> io...@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/iommu > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Re: [PATCH 1/2] unwind: prevent KASAN false positive warnings in guess unwinder
* Josh Poimboeuf wrote: > On Thu, Nov 17, 2016 at 09:57:23AM -0600, Josh Poimboeuf wrote: > > The guess unwinder scans the entire stack, which can cause KASAN > > "stack-out-of-bounds" false positive warnings. Tell KASAN to ignore it. > > > > Reported-by: Peter Zijlstra > > Signed-off-by: Josh Poimboeuf > > Whoops, forgot to prefix the patch subjects with "x86/". No problem, fixed it up. Thanks, Ingo
RE: [PATCH] Input: elan_i2c - Add new ic and modify some functions for new IC infomation Signed-off-by: KT Liao
Hi Dmitry
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Friday, November 18, 2016 1:15 AM
To: KT Liao
Cc: linux-kernel@vger.kernel.org; linux-in...@vger.kernel.org;
phoe...@emc.com.tw; kt.l...@emc.com.tw
Subject: Re: [PATCH] Input: elan_i2c - Add new ic and modify some functions for
new IC infomation Signed-off-by: KT Liao
Hi KT,
On Thu, Nov 17, 2016 at 07:47:43PM +0800, KT Liao wrote:
> ---
> drivers/input/mouse/elan_i2c.h | 6 ++--
> drivers/input/mouse/elan_i2c_core.c | 46 ++
> drivers/input/mouse/elan_i2c_i2c.c | 63
> ++--
> drivers/input/mouse/elan_i2c_smbus.c | 11 +--
> 4 files changed, 99 insertions(+), 27 deletions(-) mode change
> 100644 => 100755 drivers/input/mouse/elan_i2c.h mode change 100644 =>
> 100755 drivers/input/mouse/elan_i2c_core.c
> mode change 100644 => 100755 drivers/input/mouse/elan_i2c_i2c.c
> mode change 100644 => 100755 drivers/input/mouse/elan_i2c_smbus.c
Why are you changing mode on the files?
[KT]:Sorry, it's my fault to change file mode. I will fix it in next upstream.
>
> diff --git a/drivers/input/mouse/elan_i2c.h
> b/drivers/input/mouse/elan_i2c.h old mode 100644 new mode 100755 index
> c0ec261..a90df14
> --- a/drivers/input/mouse/elan_i2c.h
> +++ b/drivers/input/mouse/elan_i2c.h
> @@ -56,9 +56,10 @@ struct elan_transport_ops {
> int (*get_baseline_data)(struct i2c_client *client,
>bool max_baseliune, u8 *value);
>
> - int (*get_version)(struct i2c_client *client, bool iap, u8 *version);
> + int (*get_version)(struct i2c_client *client,
> +bool iap, u8 *version, u8 pattern);
> int (*get_sm_version)(struct i2c_client *client,
> - u8* ic_type, u8 *version);
> + u16 *ic_type, u8 *version, u8 pattern);
> int (*get_checksum)(struct i2c_client *client, bool iap, u16 *csum);
> int (*get_product_id)(struct i2c_client *client, u16 *id);
>
> @@ -82,6 +83,7 @@ struct elan_transport_ops {
> int (*get_report)(struct i2c_client *client, u8 *report);
> int (*get_pressure_adjustment)(struct i2c_client *client,
> int *adjustment);
> + int (*get_pattern)(struct i2c_client *client, u8 *pattern);
> };
>
> extern const struct elan_transport_ops elan_smbus_ops, elan_i2c_ops;
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> old mode 100644
> new mode 100755
> index d15b338..bb0c832
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -5,7 +5,7 @@
> *
> * Author: 林政維 (Duson Lin)
> * Author: KT Liao
> - * Version: 1.6.2
> + * Version: 1.6.3
> *
> * Based on cyapa driver:
> * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
> @@ -41,7 +41,7 @@
> #include "elan_i2c.h"
>
> #define DRIVER_NAME "elan_i2c"
> -#define ELAN_DRIVER_VERSION "1.6.2"
> +#define ELAN_DRIVER_VERSION "1.6.3"
> #define ELAN_VENDOR_ID 0x04f3
> #define ETP_MAX_PRESSURE 255
> #define ETP_FWIDTH_REDUCE90
> @@ -78,6 +78,7 @@ struct elan_tp_data {
> unsigned intx_res;
> unsigned inty_res;
>
> + u8 pattern;
> u16 product_id;
> u8 fw_version;
> u8 sm_version;
> @@ -85,7 +86,7 @@ struct elan_tp_data {
> u16 fw_checksum;
> int pressure_adjustment;
> u8 mode;
> - u8 ic_type;
> + u16 ic_type;
> u16 fw_validpage_count;
> u16 fw_signature_address;
>
> @@ -96,10 +97,10 @@ struct elan_tp_data {
> boolbaseline_ready;
> };
>
> -static int elan_get_fwinfo(u8 iap_version, u16 *validpage_count,
> +static int elan_get_fwinfo(u16 ic_type, u16 *validpage_count,
> u16 *signature_address)
> {
> - switch (iap_version) {
> + switch (ic_type) {
> case 0x00:
> case 0x06:
> case 0x08:
> @@ -119,6 +120,9 @@ static int elan_get_fwinfo(u8 iap_version, u16
> *validpage_count,
> case 0x0E:
> *validpage_count = 640;
> break;
> + case 0x10:
> + *validpage_count = 1024;
> + break;
> default:
> /* unknown ic type clear value */
> *validpage_count = 0;
> @@ -204,12 +208,17 @@ static int elan_query_product(struct
> elan_tp_data *data) {
> int error;
>
> + error = data->ops->get_pattern(data->client, &data->pattern);
> + if (error)
> + return error;
> +
> error = data->ops->get_product_id(data->client, &data->product_id);
> if (error)
> return error;
Re: [PATCH 05/11] mtd: nand: denali: remove "Spectra:" prefix from printk strings
Hi Marek,
2016-11-13 6:35 GMT+09:00 Marek Vasut :
> On 11/09/2016 05:35 AM, Masahiro Yamada wrote:
>> As far as I understood from the Kconfig menu deleted by commit
>> be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
>> specific to Intel Moorestown Platform.
>>
>> The Denali NAND controller IP is used for various SoCs such as
>> Altera SOCFPGA, Socionext UniPhier, etc. The platform specific
>> strings are not preferred in this driver.
>>
>> Signed-off-by: Masahiro Yamada
>
> Reviewed-by: Marek Vasut
>
>> ---
>>
>> As an ARM-SoC developer, I only need denali.c and denali_dt.c.
>>
>> I see some "Spectra:" in drivers/mtd/nand/denali_pci.c as well.
>> I was not quite sure if they are needed or not.
>> If desired, I can update this patch to remove them too.
>
> Is anyone even using Denali on Intel now ?
>
>> drivers/mtd/nand/denali.c | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> index 80d3e26..78d795b 100644
>> --- a/drivers/mtd/nand/denali.c
>> +++ b/drivers/mtd/nand/denali.c
>> @@ -402,7 +402,7 @@ static void get_hynix_nand_para(struct denali_nand_info
>> *denali,
>> break;
>> default:
>> dev_warn(denali->dev,
>> - "Spectra: Unknown Hynix NAND (Device ID: 0x%x).\n"
>> + "Unknown Hynix NAND (Device ID: 0x%x).\n"
>>"Will use default parameter values instead.\n",
>>device_id);
>> }
>> @@ -1458,7 +1458,7 @@ int denali_init(struct denali_nand_info *denali)
>>*/
>> if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
>> DENALI_NAND_NAME, denali)) {
>> - pr_err("Spectra: Unable to allocate IRQ\n");
>> + dev_err(denali->dev, "Unable to request IRQ\n");
>> return -ENODEV;
>> }
>>
>> @@ -1495,7 +1495,7 @@ int denali_init(struct denali_nand_info *denali)
>> /* Is 32-bit DMA supported? */
>> ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
>> if (ret) {
>> - pr_err("Spectra: no usable DMA configuration\n");
>> + dev_err(denali->dev, "no usable DMA configuration\n");
>> goto failed_req_irq;
>> }
>>
>> @@ -1503,7 +1503,7 @@ int denali_init(struct denali_nand_info *denali)
>>mtd->writesize + mtd->oobsize,
>>DMA_BIDIRECTIONAL);
>> if (dma_mapping_error(denali->dev, denali->buf.dma_buf)) {
>> - dev_err(denali->dev, "Spectra: failed to map DMA buffer\n");
>> + dev_err(denali->dev, "failed to map DMA buffer\n");
>
> Nit: For consistency's sake, use Failed with capital F . Fix the "No
> usable DMA ..." too.
Even if we fix those two, we still have some more printk strings
that start with a lower case.
line 177: dev_err(denali->dev, "reset bank failed.\n");
line 699: pr_err("timeout occurred, status = 0x%x, mask = 0x%x\n",
line 863: dev_err(denali->dev, "unable to send pipeline command\n");
line 1074: dev_err(denali->dev, "timeout on write_page (type = %d)\n",
line 1309: pr_err(": unsupported command received 0x%x\n", cmd);
If you say "consistency's sake" and
you are a big fan of capital letters instead of lower cases,
will you send a patch that touches those globally?
Your comments against this series are just about
"upper cases vs lower cases".
If I get more useful comments, I am happy to send v2.
But, at this moment, I see no good reason for v2
because changing those two lines does not give us any consistency.
--
Best Regards
Masahiro Yamada
[GIT PULL] GPIO fixes for v4.9 nocheinmal
Hi Linus, these are hopefully the last GPIO fixes for v4.9. The most important is that it fixes the UML randconfig builds that have been nagging me for some time and me being confused about where the problem was really sitting, now this fix give this nice feeling that everything is solid and builds fine. Please pull it in! Yours, Linus Walleij The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911: Linux 4.9-rc4 (2016-11-05 16:23:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v4.9-4 for you to fetch changes up to f9c22ec6c1c511285dc539b83aabdabdb6baf245: gpio: Remove GPIO_DEVRES option (2016-11-16 20:46:32 +0100) GPIO fixes for the v4.9 series: - Finally, after being puzzled by a bunch of recurrent UML build failures on randconfigs from the build robot, Keno Fischer nailed it: GPIO_DEVRES is optional and depends on HAS_IOMEM even though many users just unconditionally rely on it to be available. And it *should* be available: garbage collection is nice for this and it *certainly* has nothing to do with having IOMEM. So we got rid of it, and now the UML builds should JustWork(TM). - Do not call .get_direction() on sleeping GPIO chips on the fastpath when locking GPIOs for interrupts: it is done from atomic context, no way. - Some driver fixes. Keno Fischer (1): gpio: Remove GPIO_DEVRES option Linus Walleij (2): gpio: do not double-check direction on sleeping chips gpio: tc3589x: fix up .get_direction() Phil Reid (2): gpio: pca953x: Fix corruption of other gpios in set_multiple. gpio: pca953x: Move memcpy into mutex lock for set multiple drivers/gpio/Kconfig| 4 drivers/gpio/Makefile | 2 +- drivers/gpio/gpio-pca953x.c | 4 ++-- drivers/gpio/gpio-tc3589x.c | 2 +- drivers/gpio/gpiolib.c | 7 +-- 5 files changed, 9 insertions(+), 10 deletions(-)
Re: [PATCH 4/4] statx: AFS: Return enhanced file attributes
Andreas Dilger wrote: > > STATX_ATIME, STATX_CTIME and STATX_BLOCKS are cleared as AFS does not > > support them. > > Rather than clearing specific flags, wouldn't it be better to explicitly > set the flags that are actually being returned? Otherwise, this would > have the problem that Dave pointed out on the 0/4 patch, that there may > be flags still set from userspace that do not mean anything to AFS. I'm not sure it make a difference. generic_fillattr() has to initialise result_mask to STATX_BASIC_STATS for the support of any unmodified filesystem. We can then either clear the bits we don't want or just overwrite the mask entirely with the bits we do want. Bits in request_mask that are beyond STATX_BASIC_STATS are not automatically propagated to result_mask. Possibly vfs_xgetattr_nosec() should preset the result_mask rather than doing this in generic_fillattr(). David
Re: [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
On Friday, November 18, 2016 9:16:58 AM CET Krzysztof Kozlowski wrote:
> All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
> 200 Hz. Unfortunately in case of multiplatform image this affects also
> other platforms when Exynos is enabled.
>
> This looks like an very old legacy code, dating back to initial
> upstreaming of S3C24xx. Probably it was required for s3c24xx timer
> driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
> unused plat-samsung/time.c").
>
> Since then, this fixed 200 Hz spread everywhere, including out-of-tree
> Samsung kernels (SoC vendor's and Tizen's). I believe this choice
> was rather an effect of coincidence instead of conscious choice.
>
> Exynos uses its own MCT or arch timer and can work with all HZ values.
> Older platforms use newer Samsung PWM timer driver which should handle
> down to 100 Hz.
>
> Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
> A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
> other values.
>
> Reported-by: Lee Jones
> [Dropping 200_HZ from S3C/S5P suggested by Arnd]
> Reported-by: Arnd Bergmann
> Signed-off-by: Krzysztof Kozlowski
> Cc: Kukjin Kim
> Tested-by: Javier Martinez Canillas
>
Acked-by: Arnd Bergmann
Maybe add a paragraph about the specific problem:
"On s3c24xx, the PWM counter is only 16 bit wide, and with the
typical 12MHz input clock that overflows every 5.5ms. This works
with HZ=200 or higher but not with HZ=100 which needs a 10ms
interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
the counter is 32 bits and does not have this problem.
The new samsung_pwm_timer driver solves the problem by scaling
the input clock by a factor of 50 on s3c24xx, which makes it
less accurate but allows HZ=100 as well as CONFIG_NO_HZ with
fewer wakeups".
Arnd
RE: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Tue, Nov 15 2016, 12:59 PM, Simon Guinot wrote: > On Wed, Nov 09, 2016 at 03:42:53PM +, Levy, Amir (Jer) wrote: > > On Wed, Nov 9 2016, 04:36 PM, Simon Guinot wrote: > > > Hi Amir, > > > > > > I have an ASUS "All Series/Z87-DELUXE/QUAD" motherboard with a > > > Thunderbolt 2 "Falcon Ridge" chipset (device ID 156d). > > > > > > Is the thunderbolt-icm driver supposed to work with this chipset ? > > > > > > > Yes, the thunderbolt-icm supports Falcon Ridge, device ID 156c. > > 156d is the bridge - > > http://lxr.free-electrons.com/source/include/linux/pci_ids.h#L2619 > > > > > I have installed both a 4.8.6 Linux kernel (patched with your v9 > > > series) and the thunderbolt-software-daemon (27 october release) > > > inside a Debian system (Jessie). > > > > > > If I connect the ASUS motherboard with a MacBook Pro (Thunderbolt > > > 2, device ID 156c), I can see that the thunderbolt-icm driver is > > > loaded and that the thunderbolt-software-daemon is well started. > > > But the Ethernet interface is not created. > > > > > > I have attached to this email the syslog file. There is the logs > > > from both the kernel and the daemon inside. Note that the daemon > > > logs are everything but clear about what could be the issue. Maybe > > > I missed some kind of configuration ? But I failed to find any > > > valuable information about configuring the driver and/or the > > > daemon in > the various documentation files. > > > > > > Please, can you provide some guidance ? I'd really like to test > > > your patch series. > > > > First, thank you very much for willing to test it. > > Thunderbolt Networking support was added during Falcon Ridge, in the > latest FR images. > > Do you know which Thunderbolt image version you have on your system? > > Currently I submitted only Thunderbolt Networking feature in Linux, > > and we plan to add more features like reading the image version and > updating the image. > > If you don't know the image version, the only thing I can suggest is > > to load windows, install thunderbolt SW and check in the Thunderbolt > application the image version. > > To know if image update is needed, you can check - > > https://thunderbolttechnology.net/updates > > Hi Amir, > > From the Windows Thunderbolt software, I can read 13.00 for the > firmware version. And from https://thunderbolttechnology.net/updates, > I can see that there is no update available for my ASUS motherboard. > > Am I good to go ? > Thunderbolt Networking is supported on both Thunderbolt(tm) 2 and Thunderbolt(tm) 3 systems. Thunderbolt 2 systems must have updated NVM (version 25 or later) in order for the functionality to work properly. If the system does not have the update, please contact the OEM directly for an updated NVM. For best functionality and support, Intel recommends using Thunderbolt 3 systems for all validation and testing. > BTW, it is quite a shame that the Thunderbolt firmware version can't > be read from Linux. > This is WIP, once this patch will be upstream, we will be able to focus more on aligning Linux with the Thunderbolt features that we have for windows. Regards, Amir
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Jeff Layton wrote: > > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > > stat() on that filesystem. > > > > We also need to specify here what happens if both bits are set. Should > that be -EINVAL? Makes sense. This leads to another thought: should fstatat() be allowed to take AT_STATX_* flags? David
Re: [PATCH 05/11] mtd: nand: denali: remove "Spectra:" prefix from printk strings
On 11/18/2016 09:42 AM, Masahiro Yamada wrote:
> Hi Marek,
>
>
> 2016-11-13 6:35 GMT+09:00 Marek Vasut :
>> On 11/09/2016 05:35 AM, Masahiro Yamada wrote:
>>> As far as I understood from the Kconfig menu deleted by commit
>>> be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
>>> specific to Intel Moorestown Platform.
>>>
>>> The Denali NAND controller IP is used for various SoCs such as
>>> Altera SOCFPGA, Socionext UniPhier, etc. The platform specific
>>> strings are not preferred in this driver.
>>>
>>> Signed-off-by: Masahiro Yamada
>>
>> Reviewed-by: Marek Vasut
>>
>>> ---
>>>
>>> As an ARM-SoC developer, I only need denali.c and denali_dt.c.
>>>
>>> I see some "Spectra:" in drivers/mtd/nand/denali_pci.c as well.
>>> I was not quite sure if they are needed or not.
>>> If desired, I can update this patch to remove them too.
>>
>> Is anyone even using Denali on Intel now ?
>>
>>> drivers/mtd/nand/denali.c | 11 +--
>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>>> index 80d3e26..78d795b 100644
>>> --- a/drivers/mtd/nand/denali.c
>>> +++ b/drivers/mtd/nand/denali.c
>>> @@ -402,7 +402,7 @@ static void get_hynix_nand_para(struct denali_nand_info
>>> *denali,
>>> break;
>>> default:
>>> dev_warn(denali->dev,
>>> - "Spectra: Unknown Hynix NAND (Device ID: 0x%x).\n"
>>> + "Unknown Hynix NAND (Device ID: 0x%x).\n"
>>>"Will use default parameter values instead.\n",
>>>device_id);
>>> }
>>> @@ -1458,7 +1458,7 @@ int denali_init(struct denali_nand_info *denali)
>>>*/
>>> if (request_irq(denali->irq, denali_isr, IRQF_SHARED,
>>> DENALI_NAND_NAME, denali)) {
>>> - pr_err("Spectra: Unable to allocate IRQ\n");
>>> + dev_err(denali->dev, "Unable to request IRQ\n");
>>> return -ENODEV;
>>> }
>>>
>>> @@ -1495,7 +1495,7 @@ int denali_init(struct denali_nand_info *denali)
>>> /* Is 32-bit DMA supported? */
>>> ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
>>> if (ret) {
>>> - pr_err("Spectra: no usable DMA configuration\n");
>>> + dev_err(denali->dev, "no usable DMA configuration\n");
>>> goto failed_req_irq;
>>> }
>>>
>>> @@ -1503,7 +1503,7 @@ int denali_init(struct denali_nand_info *denali)
>>>mtd->writesize + mtd->oobsize,
>>>DMA_BIDIRECTIONAL);
>>> if (dma_mapping_error(denali->dev, denali->buf.dma_buf)) {
>>> - dev_err(denali->dev, "Spectra: failed to map DMA buffer\n");
>>> + dev_err(denali->dev, "failed to map DMA buffer\n");
>>
>> Nit: For consistency's sake, use Failed with capital F . Fix the "No
>> usable DMA ..." too.
>
>
> Even if we fix those two, we still have some more printk strings
> that start with a lower case.
>
>
> line 177: dev_err(denali->dev, "reset bank failed.\n");
>
> line 699: pr_err("timeout occurred, status = 0x%x, mask = 0x%x\n",
>
> line 863: dev_err(denali->dev, "unable to send pipeline command\n");
>
> line 1074: dev_err(denali->dev, "timeout on write_page (type = %d)\n",
>
> line 1309: pr_err(": unsupported command received 0x%x\n", cmd);
>
>
>
> If you say "consistency's sake" and
> you are a big fan of capital letters instead of lower cases,
> will you send a patch that touches those globally?
It's not really _that_ important.
> Your comments against this series are just about
> "upper cases vs lower cases".
>
> If I get more useful comments, I am happy to send v2.
>
> But, at this moment, I see no good reason for v2
> because changing those two lines does not give us any consistency.
Well we have to start somewhere, but I can fix those two when applying.
--
Best regards,
Marek Vasut
Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
On Fri, 18 Nov 2016, Ingo Molnar wrote:
> * Kyle Huey wrote:
> > + if (test_tsk_thread_flag(prev_p, TIF_NOCPUID) ^
> > + test_tsk_thread_flag(next_p, TIF_NOCPUID)) {
> > + set_cpuid_faulting(test_tsk_thread_flag(next_p, TIF_NOCPUID));
> > + }
> > +
>
> Why not cache the required MSR value in the task struct instead?
>
> That would allow something much more obvious and much faster, like:
>
> if (prev_p->thread.misc_features_val !=
> next_p->thread.misc_features_val)
> wrmsrl(MSR_MISC_FEATURES_ENABLES,
> next_p->thread.misc_features_val);
>
> (The TIF flag maintenance is still required to get into __switch_to_xtra().)
>
> It would also be easy to extend without extra overhead, should any other
> feature
> bit be added to the MSR in the future.
I doubt that. There are feature enable bits coming up which are not related
to tasks. So if we have switches enabling/disabling global features, then
we would be forced to chase all threads in order to update all misc_features
thread variables. Surely not what we want to do.
Thanks,
tglx
RE: [v7,1/1] i2c: add master driver for mellanox systems
Hi Wolfram,
Thank you for review.
> -Original Message-
> From: Wolfram Sang [mailto:wsa-...@sang-engineering.com]
> Sent: Friday, November 18, 2016 12:15 AM
> To: Vadim Pasternak
> Cc: w...@the-dreams.de; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; j...@resnulli.us; Michael Shych
>
> Subject: Re: [v7,1/1] i2c: add master driver for mellanox systems
>
> Hi,
>
> thanks for the patch and the prompt reworks. Also thank you to Vladimir for
> initial reviews!
>
> > Device supports:
> > - Master mode
> > - One physical bus
> > - Polling mode
>
> Out of interest: is there any interrupt at all?
Yes, it's possible to configure interrupt mode in HW, but we've never used it.
>
> > diff --git a/MAINTAINERS b/MAINTAINERS index 411e3b8..26d05f8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7881,6 +7881,14 @@ W: http://www.mellanox.com
> > Q: http://patchwork.ozlabs.org/project/netdev/list/
> > F: drivers/net/ethernet/mellanox/mlxsw/
> >
> > +MELLANOX MLXCPLD I2C DRIVER
> > +M: Vadim Pasternak
> > +M: Michael Shych
> > +L: linux-...@vger.kernel.org
> > +S: Supported
> > +F: drivers/i2c/busses/i2c-mlxcpld.c
> > +F: Documentation/i2c/busses/i2c-mlxcpld
> > +
>
> No need to change right now, but I think you could simplify all your drivers
> in
> one entry with
>
> F: *mlxcpld*
>
> or something similar to keep MAINTAINERS compact.
>
> > +/**
> > + * struct mlxcpld_i2c_curr_xfer - current transaction parameters:
> > + * @cmd: command;
> > + * @addr_width: address width;
> > + * @data_len: data length;
> > + * @cmd: command register;
> > + * @msg_num: message number;
> > + * @msg: pointer to message buffer;
> > + */
>
> While I value effort to describe struct members, this is so self-explaining
> that I
> think it could be left out.
>
> > +/**
> > + * struct mlxcpld_i2c_priv - private controller data:
> > + * @adap: i2c adapter;
> > + * @base_addr: base IO address;
> > + * @lock: bus access lock;
> > + * @xfer: current i2c transfer block;
> > + * @dev: device handle;
> > + */
>
> ditto
>
> > +/*
> > + * Check validity of current i2c message and all transfer.
> > + * Calculate also common length of all i2c messages in transfer.
> > + */
> > +static int mlxcpld_i2c_invalid_len(struct mlxcpld_i2c_priv *priv,
> > + const struct i2c_msg *msg, u8 *comm_len) {
> > + u8 max_len = msg->flags == I2C_M_RD ? MLXCPLD_I2C_DATA_REG_SZ -
> > +MLXCPLD_I2C_MAX_ADDR_LEN :
> MLXCPLD_I2C_DATA_REG_SZ;
> > +
> > + if (msg->len > max_len)
> > + return -EINVAL;
>
> If you populate a 'struct i2c_adapter_quirks' the core will do this check for
> you.
>
> > + *comm_len += msg->len;
> > + if (*comm_len > MLXCPLD_I2C_DATA_REG_SZ)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Check validity of received i2c messages parameters.
> > + * Returns 0 if OK, other - in case of invalid parameters
> > + * or common length of data that should be passed to CPLD */ static
> > +int mlxcpld_i2c_check_msg_params(struct mlxcpld_i2c_priv *priv,
> > + struct i2c_msg *msgs, int num,
> > + u8 *comm_len)
> > +{
> > + int i;
> > +
> > + if (!num) {
> > + dev_err(priv->dev, "Incorrect 0 num of messages\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (unlikely(msgs[0].addr > 0x7f)) {
> > + dev_err(priv->dev, "Invalid address 0x%03x\n",
> > + msgs[0].addr);
> > + return -EINVAL;
> > + }
> > +
> > + for (i = 0; i < num; ++i) {
> > + if (unlikely(!msgs[i].buf)) {
> > + dev_err(priv->dev, "Invalid buf in msg[%d]\n",
> > + i);
> > + return -EINVAL;
> > + }
>
> I was about to write "the core will check this for you", but wow, we are not
> good at this... I will try to come up with some patches soon. No need for you
> to
> changes this right now.
>
> ...
>
> > + case MLXCPLD_LPCI2C_ACK_IND:
> > + if (priv->xfer.cmd != I2C_M_RD)
> > + return (priv->xfer.addr_width + priv->xfer.data_len);
> > +
> > + if (priv->xfer.msg_num == 1)
> > + i = 0;
> > + else
> > + i = 1;
> > +
> > + if (!priv->xfer.msg[i].buf)
> > + return -EINVAL;
> > +
> > + /*
> > +* Actual read data len will be always the same as
> > +* requested len. 0xff (line pull-up) will be returned
> > +* if slave has no data to return. Thus don't read
> > +* MLXCPLD_LPCI2C_NUM_DAT_REG reg from CPLD.
> > +*/
> > + datalen = priv->xfer.data_len;
> > +
> > + mlxcpld_i2c_read_comm(priv, MLXCPLD_LPCI2C_DATA_REG,
> > + priv->xfer.msg[i].buf, datalen);
> > +
> > + return datalen;
> > +
> > + case MLXCPLD_LP
Re: [PATCH v5] mailbox: Add Tegra HSP driver
On Wed, Nov 16, 2016 at 11:11 PM, Thierry Reding wrote: > From: Thierry Reding > > This driver exposes a mailbox interface for interprocessor communication > using the Hardware Synchronization Primitives (HSP) module's doorbell > mechanism. There are multiple HSP instances and they provide additional > features such as shared mailboxes, shared and arbitrated semaphores. > > A driver for a remote processor can use the mailbox client provided by > the HSP driver and build an IPC protocol on top of this synchronization > mechanism. > > Based on work by Joseph Lo . > > Signed-off-by: Thierry Reding Acked-by: Jassi Brar
Re: [PATCH v4 05/10] IB/isert: Replace semaphore sem with completion
On Friday, November 18, 2016 12:27:32 PM CET Binoy Jayan wrote: > Hi Sagi, > > On 31 October 2016 at 02:42, Sagi Grimberg wrote: > >> The semaphore 'sem' in isert_device is used as completion, so convert > >> it to struct completion. Semaphores are going away in the future. > > > > > > Umm, this is 100% *not* true. np->sem is designed as a counting to > > sync the iscsi login thread with the connect requests coming from the > > initiators. So this is actually a reliable bug insertion :( > > > > NAK from me... > > Sorry for the late reply as I was held up in other activities. > > I converted this to a wait_event() implementation but as I was doing it, > I was wondering how it would have been different if it was a completion > and not a semaphore. > > File: drivers/infiniband/ulp/isert/ib_isert.c > > If isert_connected_handler() is called multiple times, adding an entry to the > list, and if that happens while we use completion, 'done' (part of struct > completion) would be incremented by 1 each time 'complete' is called from > isert_connected_handler. After 'n' iterations, done will be equal to 'n'. If > we > call wait_for_completion now from isert_accept_np, it would just decrement > 'done' by one and continue without blocking, consuming one node at a time > from the list 'isert_np->pending'. > > Alternatively if "done" becomes zero, and the next time wait_for_completion is > called, the API would add a node at the end of the wait queue 'wait' in > 'struct > completion' and block until "done" is nonzero. (Ref: do_wait_for_common) > It exists the wait when a call to 'complete' turns 'done' back to 1. > But if there > are multiple waits called before calling complete, all the tasks > calling the wait > gets queued up and they will all would see "done" set to zero. When complete > is called now, done turns 1 again and the first task in the queue is woken up > as it is serialized as FIFO. Now the first wait returns and the done is > decremented by 1 just before the return. > > Am I missing something here? I think you are right. This is behavior is actuallly documented in Documentation/scheduler/completion.txt: If complete() is called multiple times then this will allow for that number of waiters to continue - each call to complete() will simply increment the done element. Calling complete_all() multiple times is a bug though. Both complete() and complete_all() can be called in hard-irq/atomic context safely. However, this is fairly unusual behavior and I wasn't immediately aware of it either when I read Sagi's reply. While your patch looks correct, it's probably a good idea to point out the counting behavior of this completion as explicitly as possible, in the changelog text of the patch as well as in a code comment and perhaps in the naming of the completion. Arnd
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Andreas Dilger wrote: > >> If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for > >> stat() on that filesystem. > > > > We also need to specify here what happens if both bits are set. Should > > that be -EINVAL? > > If that is the case, then it doesn't make sense to have two contradictory > flags. Yes it does. There are actually *three* cases, not two. Maybe, rather than a pair of flags, I should stake out a 2-bit field with three possible values. > Pick a default behaviour (i.e. return what is known on the client), The default behaviour has to be what stat() does now for any particular filesystem. statx() is likely to get used to emulate stat() so that stat() can be made to return safe timestamps. If we make it so that statx() cannot do this, it's very likely that we'll see yet another stat() variant syscall being added. > and if this is 100% accurate (e.g. local filesystem or filesystem with > strong coherency) In a netfs, it was 100% accurate at the point the server started transmitting its reply. This may no longer be true - even with something like AFS that has change notifications. > then it can optionally set the SYNC flag in the returned > flags. So you suggest putting the SYNC flag(s) in the request mask rather than sharing the AT_* flag space? > If the application needs 100% accurate size info, then it can set the SYNC > flag in the request and the filesystem may need to do extra work to fetch > accurate data from the server. Note that one of the things that people asked for was a DONT_GO_TO_THE_SERVER_AT_ALL flag. I take it this is your suggested default? David
Re: [RFC PATCH] scsi: libsas: fix WARN on device removal
On 18/11/2016 01:53, Dan Williams wrote: On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote: On 11/11/2016 08:49, wangyijing wrote: I have not seen the flutter issue. I am just trying to solve the horrible WARN dump. However I do understand that there may be a issue related to how we queue the events; there was a recent attempt to fix this, but it came to nothing: https://www.spinics.net/lists/linux-scsi/msg1.html We found libsas hotplug several problems: 1. sysfs warning calltrace(like the case you found); Maybe you can then review my patch. I did it, I think your solution to fix the sysfs calltrace issue is ok, and what I worried about is we still need to fix the rest issues. So it's better if we could fix all issues one time. @Maintainers, would you be willing to accept this patch as an interim fix for the dastardly WARN while we try to fix the flutter issue? To me this adds a bug to quiet a benign, albeit noisy, warning. What is the bug which is being added? And it's a very noisy warning, as in 6K lines on the console when an expander is unplugged. .
[PATCH V5 1/2] PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform
The acpi_get_rc_resources() is used to get the RC register address that can
not be described in MCFG. It takes the _HID&segment to look for and outputs
the RC address resource. Use PNP0C02 devices to describe such RC address
resource. Use _UID to match segment to tell which root bus the PNP0C02
resource belong to.
Signed-off-by: Dongdong Liu
Signed-off-by: Tomasz Nowicki
---
drivers/pci/pci-acpi.c | 71 ++
drivers/pci/pci.h | 4 +++
2 files changed, 75 insertions(+)
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index d966d47..3557e3a 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -29,6 +29,77 @@
0x91, 0x17, 0xea, 0x4d, 0x19, 0xc3, 0x43, 0x4d
};
+#ifdef CONFIG_ARM64
+static int acpi_get_rc_addr(struct acpi_device *adev, struct resource *res)
+{
+ struct resource_entry *entry;
+ struct list_head list;
+ unsigned long flags;
+ int ret;
+
+ INIT_LIST_HEAD(&list);
+ flags = IORESOURCE_MEM;
+ ret = acpi_dev_get_resources(adev, &list,
+acpi_dev_filter_resource_type_cb,
+(void *) flags);
+ if (ret < 0) {
+ dev_err(&adev->dev,
+ "failed to parse _CRS method, error code %d\n", ret);
+ return ret;
+ } else if (ret == 0) {
+ dev_err(&adev->dev,
+ "no IO and memory resources present in _CRS\n");
+ return -EINVAL;
+ }
+
+ entry = list_first_entry(&list, struct resource_entry, node);
+ *res = *entry->res;
+ acpi_dev_free_resource_list(&list);
+ return 0;
+}
+
+static acpi_status acpi_match_rc(acpi_handle handle, u32 lvl, void *context,
+void **retval)
+{
+ u16 *segment = context;
+ unsigned long long uid;
+ acpi_status status;
+
+ status = acpi_evaluate_integer(handle, "_UID", NULL, &uid);
+ if (ACPI_FAILURE(status) || uid != *segment)
+ return AE_CTRL_DEPTH;
+
+ *(acpi_handle *)retval = handle;
+ return AE_CTRL_TERMINATE;
+}
+
+int acpi_get_rc_resources(const char *hid, u16 segment, struct resource *res)
+{
+ struct acpi_device *adev;
+ acpi_status status;
+ acpi_handle handle;
+ int ret;
+
+ status = acpi_get_devices(hid, acpi_match_rc, &segment, &handle);
+ if (ACPI_FAILURE(status)) {
+ pr_err("Can't find _HID %s device", hid);
+ return -ENODEV;
+ }
+
+ ret = acpi_bus_get_device(handle, &adev);
+ if (ret)
+ return ret;
+
+ ret = acpi_get_rc_addr(adev, res);
+ if (ret) {
+ dev_err(&adev->dev, "can't get RC resource");
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle)
{
acpi_status status = AE_NOT_EXIST;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4518562..17ffa38 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -356,4 +356,8 @@ static inline int pci_dev_specific_reset(struct pci_dev
*dev, int probe)
}
#endif
+#ifdef CONFIG_ARM64
+int acpi_get_rc_resources(const char *hid, u16 segment, struct resource *res);
+#endif
+
#endif /* DRIVERS_PCI_H */
--
1.9.1
[tip:efi/core] thunderbolt, efi: Fix Kconfig dependencies harder
Commit-ID: 5fbc89d37bb312c700dfa8121b02241a92b5df13
Gitweb: http://git.kernel.org/tip/5fbc89d37bb312c700dfa8121b02241a92b5df13
Author: Lukas Wunner
AuthorDate: Fri, 18 Nov 2016 09:22:59 +0100
Committer: Ingo Molnar
CommitDate: Fri, 18 Nov 2016 09:42:53 +0100
thunderbolt, efi: Fix Kconfig dependencies harder
Since commit c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from
EFI"), the THUNDERBOLT config option selects APPLE_PROPERTIES.
This broke the build for certain configs because APPLE_PROPERTIES is
located in a menu which depends on EFI: If EFI is not enabled, the
prerequisites needed for APPLE_PROPERTIES are not selected: Those are
EFI_DEV_PATH_PARSER and UCS2_STRING. Additionally EFI_DEV_PATH_PARSER
won't compile unless ACPI is enabled.
Commit 79f9cd35b05e ("thunderbolt, efi: Fix Kconfig dependencies")
sought to fix the breakage by making THUNDERBOLT select APPLE_PROPERTIES
only if EFI_STUB is enabled. On x86, EFI_STUB depends on EFI and EFI
depends on ACPI, so this fixed the build at least on this architecture.
However on arm and arm64, EFI_STUB does not depend on EFI, so once again
the prerequisites needed for APPLE_PROPERTIES are not selected.
Additionally ACPI is not available on arm and optional on arm64,
therefore EFI_DEV_PATH_PARSER won't compile.
Fix by selecting APPLE_PROPERTIES only on x86.
Suggested-by: Arnd Bergmann
Signed-off-by: Lukas Wunner
Acked-by: Arnd Bergmann
Cc: Andreas Noever
Cc: Ard Biesheuvel
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/5c241cf92eb1dc2421218c1204c6a9d22c9f847b.1479456179.git.lu...@wunner.de
Signed-off-by: Ingo Molnar
---
drivers/thunderbolt/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
index bb0318c..de5d27e 100644
--- a/drivers/thunderbolt/Kconfig
+++ b/drivers/thunderbolt/Kconfig
@@ -1,7 +1,7 @@
menuconfig THUNDERBOLT
tristate "Thunderbolt support for Apple devices"
depends on PCI
- select APPLE_PROPERTIES if EFI_STUB
+ select APPLE_PROPERTIES if EFI_STUB && X86
select CRC32
help
Cactus Ridge Thunderbolt Controller driver
[PATCH V5 0/2] Add ACPI support for HiSilicon SoCs Host Controllers
This patchset adds ACPI support for the HiSilicon Hip05/Hip06/Hip07 SoC PCIe controllers. The two patches respectively: - provides the common function acpi_get_rc_resources() for ARM64 platform. - adds the HiSilicon ACPI specific quirks. This patchset is based on branch pci/ecam-v6 It can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git(pci/ecam-v6) This patchset has been tested on HiSilicon D03 board. The dmesg log, /proc/iomem, and ACPI table information can be found: https://bugzilla.kernel.org/show_bug.cgi?id=187961 v4 -> v5: - obtain rc base addresses from PNP0C02 at the root of the ACPI namespace (under \_SB) instead of from sub-device under the RC. - merge the rewrited get rc resources code by Tomasz. - delete unused code. - drop the PATCH V4 1/2, will rework late as a seperate patch. v3 -> v4: - rebase on pci/ecam-v6. - delete the unnecessary link_up check code. v2 -> v3: - rebase against 4.9-rc1 and add Tomasz quirks V6 pathcset. - obtain rc base addresses from PNP0C02 as subdevice of PNP0A03 instead of hardcode the addresses. - modify hisi_pcie_acpi_rd_conf/hisi_pcie_acpi_wr_conf() according to Arnd comments. v1 -> v2: - rebase against Tomasz RFC V5 quirk mechanism - add ACPI support for the HiSilicon Hip07 SoC PCIe controllers. Dongdong Liu (2): PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers MAINTAINERS | 1 + drivers/acpi/pci_mcfg.c | 13 drivers/pci/host/Kconfig | 8 +++ drivers/pci/host/Makefile | 1 + drivers/pci/host/pcie-hisi-acpi.c | 124 ++ drivers/pci/pci-acpi.c| 71 ++ drivers/pci/pci.h | 4 ++ include/linux/pci-ecam.h | 5 ++ 8 files changed, 227 insertions(+) create mode 100644 drivers/pci/host/pcie-hisi-acpi.c -- 1.9.1
[PATCH V5 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers
PCIe controller in Hip05/HIP06/HIP07 SoCs is not ECAM compliant.
It is non ECAM only for the RC bus config space;for any other bus
underneath the root bus we support ECAM access.
Add specific quirks for PCI config space accessors.This involves:
1. New initialization call hisi_pcie_init() to obtain rc base
addresses from PNP0C02 at the root of the ACPI namespace (under \_SB).
2. New entry in common quirk array.
Signed-off-by: Dongdong Liu
Signed-off-by: Gabriele Paoloni
---
MAINTAINERS | 1 +
drivers/acpi/pci_mcfg.c | 13
drivers/pci/host/Kconfig | 8 +++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-hisi-acpi.c | 124 ++
include/linux/pci-ecam.h | 5 ++
6 files changed, 152 insertions(+)
create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..b224caa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9358,6 +9358,7 @@ L:linux-...@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
F: drivers/pci/host/pcie-hisi.c
+F: drivers/pci/host/pcie-hisi-acpi.c
PCIE DRIVER FOR ROCKCHIP
M: Shawn Lin
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ac21db3..b1b6fc7 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -57,6 +57,19 @@ struct mcfg_fixup {
{ "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
{ "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
{ "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
+#ifdef CONFIG_PCI_HISI_ACPI
+ #define PCI_ACPI_QUIRK_QUAD_DOM(table_id, seg, ops) \
+ { "HISI ", table_id, 0, seg + 0, MCFG_BUS_ANY, ops }, \
+ { "HISI ", table_id, 0, seg + 1, MCFG_BUS_ANY, ops }, \
+ { "HISI ", table_id, 0, seg + 2, MCFG_BUS_ANY, ops }, \
+ { "HISI ", table_id, 0, seg + 3, MCFG_BUS_ANY, ops }
+ PCI_ACPI_QUIRK_QUAD_DOM("HIP05 ", 0, &hisi_pcie_ops),
+ PCI_ACPI_QUIRK_QUAD_DOM("HIP06 ", 0, &hisi_pcie_ops),
+ PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 0, &hisi_pcie_ops),
+ PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 4, &hisi_pcie_ops),
+ PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 8, &hisi_pcie_ops),
+ PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 12, &hisi_pcie_ops),
+#endif
};
static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index ae98644..9ff2bcd 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -227,6 +227,14 @@ config PCI_HISI
Say Y here if you want PCIe controller support on HiSilicon
Hip05 and Hip06 and Hip07 SoCs
+config PCI_HISI_ACPI
+ depends on ACPI && ARM64
+ bool "HiSilicon Hip05 and Hip06 and Hip07 SoCs ACPI PCIe controllers"
+ select PNP
+ help
+ Say Y here if you want ACPI PCIe controller support on HiSilicon
+ Hip05 and Hip06 and Hip07 SoCs
+
config PCIE_QCOM
bool "Qualcomm PCIe controller"
depends on ARCH_QCOM && OF
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 084cb49..9402858 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pcie-hisi-acpi.c
b/drivers/pci/host/pcie-hisi-acpi.c
new file mode 100644
index 000..358c7c9
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-acpi.c
@@ -0,0 +1,124 @@
+/*
+ * PCIe host controller driver for HiSilicon HipXX SoCs
+ *
+ * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Dongdong Liu
+ * Gabriele Paoloni
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include "../pci.h"
+
+static int hisi_pcie_acpi_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+ int size, u32 *val)
+{
+ struct pci_config_window *cfg = bus->sysdata;
+ int dev = PCI_SLOT(devfn);
+
+ if (bus->number == cfg->busr.start) {
+ /* access only one slot on each root port */
+ if (dev > 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ else
+ return pci_generic_config_read32(bus, devfn, where,
+size, val);
+ }
+
+ return pci_generic_config_read(bus, devfn, where, size, val)
[tip:x86/urgent] x86/unwind: Prevent KASAN false positive warnings in guess unwinder
Commit-ID: c2d75e03d6307bda0e14b616818a6f7b09fd623a
Gitweb: http://git.kernel.org/tip/c2d75e03d6307bda0e14b616818a6f7b09fd623a
Author: Josh Poimboeuf
AuthorDate: Thu, 17 Nov 2016 09:57:23 -0600
Committer: Ingo Molnar
CommitDate: Fri, 18 Nov 2016 09:38:00 +0100
x86/unwind: Prevent KASAN false positive warnings in guess unwinder
The guess unwinder scans the entire stack, which can cause KASAN
"stack-out-of-bounds" false positive warnings. Tell KASAN to ignore it.
Reported-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: da...@codemonkey.org.uk
Cc: dvyu...@google.com
Link:
http://lkml.kernel.org/r/61939c0b2b2d63ce97ba59cba3b00fd47c2962cf.1479398226.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/unwind_guess.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index 2d721e5..b80e8bf 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -7,11 +7,13 @@
unsigned long unwind_get_return_address(struct unwind_state *state)
{
+ unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
+
if (unwind_done(state))
return 0;
return ftrace_graph_ret_addr(state->task, &state->graph_idx,
-*state->sp, state->sp);
+addr, state->sp);
}
EXPORT_SYMBOL_GPL(unwind_get_return_address);
@@ -23,8 +25,10 @@ bool unwind_next_frame(struct unwind_state *state)
return false;
do {
+ unsigned long addr = READ_ONCE_NOCHECK(*state->sp);
+
for (state->sp++; state->sp < info->end; state->sp++)
- if (__kernel_text_address(*state->sp))
+ if (__kernel_text_address(addr))
return true;
state->sp = info->next_sp;
[tip:perf/urgent] perf/x86: Add perf support for AMD family-17h processors
Commit-ID: e40ed1542dd779e5037a22c6b534e57127472365
Gitweb: http://git.kernel.org/tip/e40ed1542dd779e5037a22c6b534e57127472365
Author: Janakarajan Natarajan
AuthorDate: Thu, 17 Nov 2016 10:15:06 -0600
Committer: Ingo Molnar
CommitDate: Fri, 18 Nov 2016 09:45:57 +0100
perf/x86: Add perf support for AMD family-17h processors
This patch enables perf core PMU support for the new AMD family-17h processors.
In family-17h, there is no PMC-event constraint. All events, irrespective of
the type, can be measured using any of the six generic performance counters.
Signed-off-by: Janakarajan Natarajan
Acked-by: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Suravee Suthikulpanit
Cc: Thomas Gleixner
Cc: Vince Weaver
Link:
http://lkml.kernel.org/r/1479399306-13375-1-git-send-email-janakarajan.natara...@amd.com
Signed-off-by: Ingo Molnar
---
arch/x86/events/amd/core.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index f5f4b3f..afb222b 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -662,7 +662,13 @@ static int __init amd_core_pmu_init(void)
pr_cont("Fam15h ");
x86_pmu.get_event_constraints = amd_get_event_constraints_f15h;
break;
-
+ case 0x17:
+ pr_cont("Fam17h ");
+ /*
+* In family 17h, there are no event constraints in the PMC
hardware.
+* We fallback to using default amd_get_event_constraints.
+*/
+ break;
default:
pr_err("core perfctr but no constraints; unknown hardware!\n");
return -ENODEV;
why is the sys_close symbol exported ?
Following the various rootkit and system call redirection developments, the current way of identifying the location of the system call table seems to be brute force scanning the memory for the location of one of the system calls. This is only possible from a module if the symbol is exported: I see that only one system call symbol is still exported, that is sys_close. Removing this symbol export would hinder one of the ways of finding the systam call table: I have not been able to find the reason for exporting this particular symbol (while sys_open for example is not exported). Can anyone justify why that is ? Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France
[tip:efi/core] thunderbolt: Compile on x86 only
Commit-ID: b2c74191f4672c4b3265d0335910792b4f72026b Gitweb: http://git.kernel.org/tip/b2c74191f4672c4b3265d0335910792b4f72026b Author: Lukas Wunner AuthorDate: Fri, 18 Nov 2016 09:22:59 +0100 Committer: Ingo Molnar CommitDate: Fri, 18 Nov 2016 09:42:59 +0100 thunderbolt: Compile on x86 only So far Thunderbolt is (unfortunately) an Intel proprietary technology that is only available on x86, so compiling on other arches is pointless except for testing purposes. Amend Kconfig accordingly. Suggested-by: Arnd Bergmann Signed-off-by: Lukas Wunner Acked-by: Arnd Bergmann Cc: Andreas Noever Cc: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/7dfda728d3ee8a33c80c49b224da7359c6015eea.1479456179.git.lu...@wunner.de Signed-off-by: Ingo Molnar --- drivers/thunderbolt/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig index de5d27e..d35db16 100644 --- a/drivers/thunderbolt/Kconfig +++ b/drivers/thunderbolt/Kconfig @@ -1,6 +1,7 @@ menuconfig THUNDERBOLT tristate "Thunderbolt support for Apple devices" depends on PCI + depends on X86 || COMPILE_TEST select APPLE_PROPERTIES if EFI_STUB && X86 select CRC32 help
[tip:x86/urgent] x86/dumpstack: Prevent KASAN false positive warnings
Commit-ID: 91e08ab0c8515450258d7ad9033bfe69bebad25a
Gitweb: http://git.kernel.org/tip/91e08ab0c8515450258d7ad9033bfe69bebad25a
Author: Josh Poimboeuf
AuthorDate: Thu, 17 Nov 2016 09:57:24 -0600
Committer: Ingo Molnar
CommitDate: Fri, 18 Nov 2016 09:38:00 +0100
x86/dumpstack: Prevent KASAN false positive warnings
The oops stack dump code scans the entire stack, which can cause KASAN
"stack-out-of-bounds" false positive warnings. Tell KASAN to ignore it.
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: da...@codemonkey.org.uk
Cc: dvyu...@google.com
Link:
http://lkml.kernel.org/r/5f6e80c4b0c7f7f0b6211900847a247cdaad753c.1479398226.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/dumpstack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 9b7cf5c..85f854b 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -112,7 +112,7 @@ void show_trace_log_lvl(struct task_struct *task, struct
pt_regs *regs,
for (; stack < stack_info.end; stack++) {
unsigned long real_addr;
int reliable = 0;
- unsigned long addr = *stack;
+ unsigned long addr = READ_ONCE_NOCHECK(*stack);
unsigned long *ret_addr_p =
unwind_get_return_address_ptr(&state);
Re: [PATCH v11 1/6] drivers/platform/x86/p2sb: New Primary to Sideband bridge support driver for Intel SOC's
On Fri, Nov 18, 2016 at 01:22:25PM +0800, Tan Jui Nee wrote: > From: Andy Shevchenko > > There is already one and at least one more user coming which > require an access to Primary to Sideband bridge (P2SB) in order > to get IO or MMIO bar hidden by BIOS. > Create a driver to access P2SB for x86 devices. > > Signed-off-by: Yong, Jonathan > Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg
Re: [PATCH v4 05/10] IB/isert: Replace semaphore sem with completion
Hi Arnd, On 18 November 2016 at 14:28, Arnd Bergmann wrote: > On Friday, November 18, 2016 12:27:32 PM CET Binoy Jayan wrote: >> Hi Sagi, > I think you are right. This is behavior is actuallly documented in > Documentation/scheduler/completion.txt: Thanking for having a look. > However, this is fairly unusual behavior and I wasn't immediately aware > of it either when I read Sagi's reply. While your patch looks correct, > it's probably a good idea to point out the counting behavior of this > completion as explicitly as possible, in the changelog text of the patch > as well as in a code comment and perhaps in the naming of the completion. Will mention this and resend the patch series. Thanks, Binoy
Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Le 18/11/2016 à 09:59, Rafal Ozieblo a écrit :
> Hello,
>
>> From: Harini Katakam [mailto:harinikatakamli...@gmail.com]
>> Sent: 18 listopada 2016 05:30
>> To: Rafal Ozieblo
>> Cc: Nicolas Ferre; harini.kata...@xilinx.com; net...@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
>>
>> Hi Rafal,
>>
>> On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo wrote:
>>> -Original Message-
>>> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
>>> Sent: 17 listopada 2016 14:29
>>> To: Harini Katakam; Rafal Ozieblo
>>> Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
>>> linux-kernel@vger.kernel.org
>>> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support
>>> for GEM
>>>
Le 17/11/2016 à 13:21, Harini Katakam a écrit :
> Hi Rafal,
>
> On Thu, Nov 17, 2016 at 5:20 PM, Rafal Ozieblo wrote:
>> Hello,
>> I think, there could a bug in your patch.
>>
>>> +
>>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>> + dmacfg |= GEM_BIT(ADDR64); #endif
>>
>> You enable 64 bit addressing (64b dma bus width) always when appropriate
>> architecture config option is enabled.
>> But there are some legacy controllers which do not support that feature.
>> According Cadence hardware team:
>> "64 bit addressing was added in July 2013. Earlier version do not have
>> it.
>> This feature was enhanced in release August 2014 to have separate upper
>> address values for transmit and receive."
>>
>>> /* Bitfields in NSR */
>>> @@ -474,6 +479,10 @@
>>> struct macb_dma_desc {
>> > u32 addr;
>>> u32 ctrl;
>>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>> + u32 addrh;
>>> + u32 resvd;
>>> +#endif
>>> };
>>
>> It will not work for legacy hardware. Old descriptor is 2 words wide,
>> the new one is 4 words wide.
>> If you enable CONFIG_ARCH_DMA_ADDR_T_64BIT but hardware doesn't
>> support it at all, you will miss every second descriptor.
>>
>
> True, this feature is not available in all of Cadence IP versions.
> In fact, the IP version Zynq does not support this. But the one in ZynqMP
> does.
> So, we enable kernel config for 64 bit DMA addressing for this SoC
> and hence the driver picks it up. My assumption was that if the
> legacy IP does not support
> 64 bit addressing, then this DMA option wouldn't be enabled.
>
> There is a design config register in Cadence IP which is being read
> to check for 64 bit address support - DMA mask is set based on that.
> But the addition of two descriptor words cannot be based on this runtime
> check.
> For this reason, all the static changes were placed under this check.
We have quite a bunch of options in this driver to determinate what is the
real capacity of the underlying hardware.
If HW configuration registers are not appropriate, and it seems they are
not, I would advice to simply use the DT compatibility string.
Best regards,
--
Nicolas Ferre
>>>
>>> HW configuration registers are appropriate. The issue is that this code
>>> doesn’t use the capability bit to switch between different dma descriptors
>>> (2 words vs. 4 words).
>>> DMA descriptor size is chosen based on kernel configuration, not based on
>>> hardware capabilities.
>>
>> HW configuration register does give appropriate information.
>> But addition of two address words in the macb descriptor structure is a
>> static change.
>>
>> +static inline void macb_set_addr(struct macb_dma_desc *desc, dma_addr_t
>> +addr) {
>> + desc->addr = (u32)addr;
>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> + desc->addrh = (u32)(addr >> 32); #endif
>> +
>>
>> Even if the #ifdef condition here is changed to HW config check, addr and
>> addrh are different.
>> And "addrh" entry has to be present for 64 bit desc case to be handled
>> separately.
>> Can you please tell me how you propose change in DMA descriptor structure
>> from
>> 4 to 2 or 2 to 4 words *after* reading the DCFG register?
>
> It is very complex problem. I wrote to you because I faced the same issue.
> I'm working on PTP implementation for macb. When PTP is enabled there are
> additional two words in buffer descriptor.
Moreover, we can use PTP without the 64bits descriptor support (early
GEM revisions).
BTW, note that there is an initiative ongoing with Andrei to support
PTP/1588 on these devices with patches already send: please synchronize
with him.
https://marc.info/?l=linux-netdev&m=147282092309112&w=3
or
https://patchwork.kernel.org/patch/9310989/
and
https://patchwork.kernel.org/patch/9310991/
Regards,
> But hardware might not be compatible with PTP. Therefore I have to change DMA
> descriptor between 2 and 4 words after reading DCFG register (the same as you
> between 32b and 64b
Re: [PATCH v3 4/9] media: venus: vdec: add video decoder files
Hi Hans,
>>> +
>>> +static int
>>> +vdec_reqbufs(struct file *file, void *fh, struct v4l2_requestbuffers *b)
>>> +{
>>> + struct vb2_queue *queue = to_vb2q(file, b->type);
>>> +
>>> + if (!queue)
>>> + return -EINVAL;
>>> +
>>> + return vb2_reqbufs(queue, b);
>>> +}
>>
>> Is there any reason why the v4l2_m2m_ioctl_reqbufs et al helper functions
>> can't be used? I strongly recommend that, unless there is a specific reason
>> why that won't work.
>
> So that means I need to completely rewrite the v4l2 part and adopt it
> for mem2mem device APIs.
>
> If that is what you meant I can invest some time to make a estimation
> what would be the changes and time needed. After that we can decide what
> to do - take the driver as is and port it to mem2mem device APIs later
> on or wait for the this transition to happen before merging.
>
I made an attempt to adopt v4l2 part of the venus driver to m2m API's
and the result was ~300 less lines of code, but with the price of few
extensions in m2m APIs (and I still have issues with running
simultaneously multiple instances).
I have to add few functions/macros to iterate over a list (list_for_each
and friends). This is used to find the returned from decoder buffers by
address and associate them to vb2_buffer, because the decoder can change
the order of the output buffers.
The main problem I have is registering of the capture buffers before
session_start. This is requirement (disadvantage) of the firmware
implementation i.e. I need to announce capture buffers (address and size
of the buffer) to the firmware before start buffer interaction by
session_start.
So having that I think I will need one more week to stabilize the driver
to the state that it was before this m2m transition.
Thoughts?
--
regards,
Stan
Re: [Ksummit-discuss] Including images on Sphinx documents
On Thu, 17 Nov 2016, Linus Torvalds wrote:
> We have makefiles, but more importantly, few enough people actually
> *generate* the documentation, that I think if it's an option to just
> fix sphinx, we should do that instead. If it means that you have to
> have some development version of sphinx, so be it. Most people read
> the documentation either directly in the unprocessed text-files
> ("source code") or on the web (by searching for pre-formatted docs)
> that I really don't think we need to worry too much about the
> toolchain.
My secret plan was to make building documentation easy, and then trick
more people into actually doing that on a regular basis, to ensure we
keep the build working and the output sensible in a variety of
environments. Sure we have a bunch of people doing this, and we have
0day doing this, but I'd hate it if it became laborous and fiddly to set
up the toolchain to generate documentation.
So I'm not necessarily disagreeing with anything you say, but I think
there's value in having a low bar for entry (from the toolchain POV) for
people interested in working with documentation, whether they're
seasoned kernel developers or newcomers purely interested in
documentation.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
mm, floppy: unkillable task faulting on fd0
Hello,
The following program produces unkillable tasks blocked at the following stack:
[] wait_on_page_bit+0x1eb/0x2a0 mm/filemap.c:802
[< inline >] wait_on_page_locked ./include/linux/pagemap.h:508
[] filemap_fault+0x17c7/0x1e50 mm/filemap.c:2201
[] __do_fault+0x33c/0x8a0 mm/memory.c:2864
[< inline >] do_read_fault mm/memory.c:3191
[] do_fault+0xbb1/0x28d0 mm/memory.c:3326
[< inline >] handle_pte_fault mm/memory.c:3527
[< inline >] __handle_mm_fault mm/memory.c:3614
[] handle_mm_fault+0x159b/0x2cd0 mm/memory.c:3651
[] __do_page_fault+0x4fb/0xb60 arch/x86/mm/fault.c:1397
[] trace_do_page_fault+0x159/0x830 arch/x86/mm/fault.c:1490
[] do_async_page_fault+0x7c/0xd0 arch/x86/kernel/kvm.c:265
[] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1015
[] getname_flags+0x113/0x580 fs/namei.c:148
[] user_path_at_empty+0x32/0x50 fs/namei.c:2556
[< inline >] SYSC_readlinkat fs/stat.c:327
[< inline >] SyS_readlinkat fs/stat.c:315
[< inline >] SYSC_readlink fs/stat.c:352
[] SyS_readlink+0x12c/0x3f0 fs/stat.c:349
[] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:209
Before hang kernel prints:
[ 404.042351] floppy0: disk absent or changed during operation
[ 404.044187] floppy0: disk absent or changed during operation
[ 404.058637] floppy0: disk absent or changed during operation
[ 404.060152] floppy0: do_fd_request: timeout handler died. old
request running
On commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (Nov 13).
Run this program in a loop:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
int fd;
void* thr(void* arg)
{
if (rand() % 2)
usleep(rand() % 1000);
switch ((long)arg) {
case 0:
fd = syscall(__NR_open, "/dev/fd0", 0x900ul);
break;
case 1:
syscall(__NR_mmap, 0x20009000ul, 0x1000ul, 0x4ul, 0x12ul, fd, 0x0ul);
break;
case 2:
syscall(__NR_mmap, 0x20009000ul, 0x1000ul, 0x4ul, 0x12ul, fd, 0x0ul);
break;
case 3:
syscall(__NR_readlink, 0x20009000ul, 0x20009000ul, 0x100ul);
break;
case 4:
syscall(__NR_readlink, 0x20009000ul, 0x20009000ul, 0x100ul);
break;
}
return 0;
}
int main()
{
long i;
pthread_t th[5];
fd = syscall(__NR_open, "/dev/fd0", 0x900ul);
syscall(__NR_mmap, 0x20009000ul, 0x1000ul, 0x4ul, 0x12ul, fd, 0x0ul);
srand(getpid());
for (i = 0; i < 5; i++)
pthread_create(&th[i], 0, thr, (void*)i);
for (i = 0; i < 5; i++)
pthread_join(th[i], 0);
return 0;
}
Re: [tip:timers/core] ptp_clock: Allow for it to be optional
On Thursday, November 17, 2016 7:48:00 PM CET Nicolas Pitre wrote: > > > > It was introduced in linux-next today, but it only happens if you > > don't do a 'make clean' or 'make mrproper'. Apparently patch 1 > > of the series changes kconfig but that change does not trigger > > a rebuild of the kconfig binary for me. After removing kconfig > > from the object directory, it works again. > > That's odd. If I do a git checkout from linux-next of a commit before > this series, then "make oldconfig", and then checkout of master and > "make oldconfig again, in both cases I always get: > > $ make oldconfig > HOSTCC scripts/kconfig/conf.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > scripts/kconfig/conf --oldconfig Kconfig > [...] > > And obviously no errors. I usually build with "make -skj30", so it's possible that it only happens in a parallel build environment on the first run. > > I also ran into a problem with CONFIG_TIMERFD enabled but > > CONFIG_POSIX_TIMERS turned off. This could be related to some > > of my own patches though, haven't tried if that happens > > with just your patches applied. > > Tried that combination in my checkout of linux-next, and once again no > build errors here. Ok, thanks for testing this. It must be something in the y2038 patches I have on top of next. They clashed quite a bit with your work already, this added dependency is just one more detail for me to remember with my series, nothing you need to worry about. Arnd
Re: [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
[Notice this reply has little to do with the patch in question: I think it should be applied. I just want to involve some MMC/SD people here] On Thu, Nov 17, 2016 at 9:57 PM, wrote: > On 2016-11-17 10:34, Chen-Yu Tsai wrote: >> >> Given that MMC starts in open-drain mode and the pull-ups are required, >> it's best to enable it for all the pin settings. > > It's even more complicated than that with MMC. It starts in open-drain mode > for > CMD during initialization but changes to push-pull afterwards. The card has > internal pull-ups to prevent bus floating during setup and will disable them > after switching to 4bit mode (or 8bit for eMMC when available). > But even after switching to push-pull drivers there are states the bus would > float and pull ups have to ensure a high level on the bus. > > See JESD84-A441 chapter 7.15 ff as reference. > > The difference between the P-bit and Z-bit is that a P-bit is actively > driven > to HIGH by the card respectively host output driver, while Z-bit is driven > to > (respectively kept) HIGH by the pull-up resistors Rcmd respectively Rdat. > > Enabling the pull ups on the CPU would be the right choice considering that > most boards will not have external pull-ups. Even if they would have one, > adding the internal in parallel would work in almost all cases and the > increase in power consumption would be negligible. I guess you are referring to software-controlled pull up on the pad ring of the SoC. Nominally that should be handled by pin control like in this patch. It is not clear from context to me which of the lines need to be handled like this? Just the data lines? DAT0 would be the critical line to pull up in that case, since the others will not be used until bus switch anyways right? But what about CMD? I assume CLK should always be push-pull? Also: if the pins have an explicit Open Drain setting, should that be used? I guess so? Overall I think this construction is pretty common. We essentially have two classes of connections: - Those connecting the eMMC or even MMC/SD card directly to the SoC. No pull-ups on the board. Here it makes sense to have: 1. A pin control default state with open drain and pull-ups enabled for those lines and it then needs 2. A second "4/8bit mode" that will switch these pins to push-pull mode and turn off the pull-ups. If the OD+pull-up state is the default we should probably standardize a default name for the state when we kick in 4/8bit mode from the IOS operation. - Those connection the MMC/SD on an external slot through a levelshifter/EMI filter. In that case I guess it is pretty much dependent on the levelshifter or EMI thing how the lines out of the SoC should be configured, and usually it is static so you do not need to worry about it after boot configuration of pins. (Mostly no bias, push-pull I think.) I highly suspect a whole bunch of SoC drivers are not getting this business right today. Not even in out-of-tree vendor kernels. Yours, Linus Walleij
Re: [PATCH v14 00/22] Add Mediated device support
On 2016.11.17 16:51:45 -0700, Alex Williamson wrote: > On Thu, 17 Nov 2016 23:29:38 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Friday, November 18, 2016 5:25 AM > > > > > > On Thu, 17 Nov 2016 02:16:12 +0530 > > > Kirti Wankhede wrote: > > > > > > > > Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111 ++ > > > > Documentation/vfio-mediated-device.txt| 399 +++ > > > > MAINTAINERS |9 + > > > > drivers/vfio/Kconfig |1 + > > > > drivers/vfio/Makefile |1 + > > > > drivers/vfio/mdev/Kconfig | 17 + > > > > drivers/vfio/mdev/Makefile|5 + > > > > drivers/vfio/mdev/mdev_core.c | 385 +++ > > > > drivers/vfio/mdev/mdev_driver.c | 119 ++ > > > > drivers/vfio/mdev/mdev_private.h | 41 + > > > > drivers/vfio/mdev/mdev_sysfs.c| 286 + > > > > drivers/vfio/mdev/vfio_mdev.c | 180 +++ > > > > drivers/vfio/pci/vfio_pci.c | 83 +- > > > > drivers/vfio/platform/vfio_platform_common.c | 31 +- > > > > drivers/vfio/vfio.c | 340 +- > > > > drivers/vfio/vfio_iommu_type1.c | 872 +++--- > > > > include/linux/mdev.h | 177 +++ > > > > include/linux/vfio.h | 32 +- > > > > include/uapi/linux/vfio.h | 10 + > > > > samples/vfio-mdev/Makefile| 13 + > > > > samples/vfio-mdev/mtty.c | 1503 > > > + > > > > 21 files changed, 4358 insertions(+), 257 deletions(-) > > > > create mode 100644 Documentation/ABI/testing/sysfs-bus-vfio-mdev > > > > create mode 100644 Documentation/vfio-mediated-device.txt > > > > create mode 100644 drivers/vfio/mdev/Kconfig > > > > create mode 100644 drivers/vfio/mdev/Makefile > > > > create mode 100644 drivers/vfio/mdev/mdev_core.c > > > > create mode 100644 drivers/vfio/mdev/mdev_driver.c > > > > create mode 100644 drivers/vfio/mdev/mdev_private.h > > > > create mode 100644 drivers/vfio/mdev/mdev_sysfs.c > > > > create mode 100644 drivers/vfio/mdev/vfio_mdev.c > > > > create mode 100644 include/linux/mdev.h > > > > create mode 100644 samples/vfio-mdev/Makefile > > > > create mode 100644 samples/vfio-mdev/mtty.c > > > > > > As discussed, I dropped patch 12, updated the documentation, and added > > > 'retries' initialization. This is now applied to my next branch for > > > v4.10. Thanks to the reviewers and Kirti and Neo for your hard work! > > > Thanks, > > > > > > > That's a great news! Alex, do you have an idea when this series may > > hit linux-next? :-) > > Whenever there's a new build, hopefully within the next 24hrs, but I > don't really know the schedule. Thanks, > Alex, could you do a pull request of mdev for Daniel's drm-intel tree? We need to send KVMGT mdev support pull base on that. Thanks! -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature
Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
On Friday, November 11, 2016 6:07:07 PM CET zhichang.yuan wrote:
>
> I have similar idea as your PPC MMIO.
>
> We notice the prototype of {in/out()} is something like that:
>
> static inline u8 inb(unsigned long addr)
> static inline void outb(u8 value, unsigned long addr)
>
> The type of parameter 'addr' is unsigned long. For I/O space, it is big
> enough.
> So, could you divide this 'addr' into several bit segments? The top 8 bits is
> defined as bus index. For normal direct IO, the bus index is 0. For those bus
> device which need indirectIO or some special I/O accessors, when these devices
> are initializing, can request to allocate an unique ID to them, and register
> their own accessors to the entry which is corresponding to the ID.
Ah, have you looked at the IA64 code? It does exactly this.
For ARM64 we decided to use the same basic approach as powerpc with
a single range of virtual memory for mapping it as that somewhat
simplified all cases we knew about at the time.
> In this way, we can support multiple domains, I think.
> But I am not sure whether it is feasible, for example, are there some
> architectures/platforms had populated the top 8 bits? Do we need to request IO
> region from ioport_resource for those devices? etc...
On a 64-bit architecture, the top 32 bits of the port number are
definitely free to use for this, and 8 bits are probably sufficient.
Even on 32 bit architectures, I can't see why we'd ever need more than
16 bits worth of addressing within a domain, so using 8 bit domain
and 16 bit address leaves 8 or 40 unused bits.
Arnd
Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
On Monday, November 14, 2016 11:11:11 AM CET One Thousand Gnomes wrote: > > > It's not a safe assumption for x86 at least. There are a few systems with > > > multiple ISA busses particularly older laptops with a docking station. > > > > But do they have multiple ISA domains? There is no real harm in supporting > > it, the (small) downsides I can think of are: > > I don't believe they x86 class ones have multiple ISA domains. But as > I've said I don't know how the electronics in the older ThinkPad worked > when it used two PIIX4s with some LPC or ISA stuff on each. > > It works in DOS and unmodified Linux so I'm pretty sure there are no > additional domains. Likewise the various x86 schemes that route some bits > of ISA bus off into strange places work in DOS and don't have any > overlaps. > > yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat > ISA space appropriately to the card. Right, that's what I had expected, so we still don't even need to handle multiple ISA I/O address spaces for the only known case of multiple ISA buses, though we may decide to generalize the code like that anyway. Arnd
[PATCH 1/2] PM / Domains: Introduce domain-performance-state binding
Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.
The power-domains until now were only concentrating on the idle state
management of the device and this needs to change in order to reuse the
infrastructure of power domains for active state management.
This patch introduces a new optional property for the consumers of the
power-domains: domain-performance-state.
If the consumers don't need the capability of switching to different
domain performance states at runtime, then they can simply define their
required domain performance state in their node directly. Otherwise the
consumers can define their requirements with help of other
infrastructure, for example the OPP table.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/power/power_domain.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
index e1650364b296..db42eacf8b5c 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -106,6 +106,12 @@ domain provided by the 'parent' power controller.
- power-domains : A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle.
+Optional properties:
+- domain-performance-state: A positive integer value representing the minimum
+ performance level (of the parent domain) required by the consumer for its
+ working. The integer value '1' represents the lowest performance level and
the
+ highest value represents the highest performance level.
+
Example:
leaky-device@1235 {
--
2.7.1.410.g6faf27b
[PATCH 0/2] PM / Domains / OPP: Introduce domain-performance-state binding
Hello, Some platforms have the capability to configure the performance state of their Power Domains. The performance levels are represented by positive integer values, a lower value represents lower performance state. We had some discussions about it in the past on the PM list [1], which is followed by discussions during the LPC. The outcome of all that was that we should extend Power Domain framework to support active state power management as well. The power-domains until now were only concentrating on the idle state management of the device and this needs to change in order to reuse the infrastructure of power domains for active state management. To get a complete picture of the proposed plan, following is what we need to do: - Create DT bindings to get domain performance state information for the platforms. - Enhance OPP framework to parse these and call into the PM Qos framework with a performance state request. - Enhance PM Qos framework to provide the API to be used by consumers (or OPP framework) and pass it on to the (Generic) Power Domain framework. - Enhance Generic Power Domain framework to accept such requests, accumulate all belonging to a single power domain and call domain driver specific callback with the performance state we want for the domain. - The domain driver shall then, in a platform specific way, set the requested performance level. - Note that these features are applicable to the CPU, GPU and other IIO or non-IIO devices. - There can be cases where a device can choose between multiple power domains based on what performance level we want for the device. In such cases, we should represent the multiplexer with a separate power domain. In effect, the device (or OPP table) will correspond to a single power domain, but the backend driver of that domain shall implement the multiplexing functionality. This patchset implements the very first part of this chain and introduces a new optional property for the consumers of the power-domains: domain-performance-state. This property can be used directly by the consumer or its OPP table. -- viresh [1] https://marc.info/?l=linux-pm&m=147747923708075&w=2 Viresh Kumar (2): PM / Domains: Introduce domain-performance-state binding PM / OPP: Introduce domain-performance-state binding to OPP nodes Documentation/devicetree/bindings/opp/opp.txt | 57 ++ .../devicetree/bindings/power/power_domain.txt | 6 +++ 2 files changed, 63 insertions(+) -- 2.7.1.410.g6faf27b
[PATCH 2/2] PM / OPP: Introduce domain-performance-state binding to OPP nodes
Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.
If the consumers don't need the capability of switching to different
domain performance states at runtime, then they can simply define their
required domain performance state in their nodes directly.
But if the device needs the capability of switching to different domain
performance states, as they may need to support different clock rates,
then the per OPP node can be used to contain that information.
This patch introduces the domain-performance-state (already defined by
Power Domain bindings) to the per OPP node. It can contain a single
positive integer value. An example is also provided.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 57 +++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index ee91cbdd95ee..9fb7804f784d 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -145,6 +145,14 @@ properties.
- status: Marks the node enabled/disabled.
+- domain-performance-state: A positive integer value representing the minimum
+ performance level (of the parent domain) required by the consumer for the
+ working of respective OPP. The integer value '1' represents the lowest
+ performance level and the highest value represents the highest performance
+ level. The consumer device node (which contains phandle to the OPP table in
+ its "operating-points-v2" property) should have its "power-domains" property
+ set as well.
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
@@ -517,3 +525,52 @@ Example 5: opp-supported-hw
};
};
};
+
+Example 7: domain-Performance-state:
+(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state
2)
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ clocks = <&clk_controller 0>;
+ clock-names = "cpu";
+ cpu-supply = <&cpu_supply0>;
+ operating-points-v2 = <&cpu0_opp_table>;
+ power-domains = <&foo_pd>;
+ };
+ };
+
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <97 975000 985000>;
+ opp-microamp = <7>;
+ clock-latency-ns = <30>;
+ opp-suspend;
+ domain-performance-state = <1>;
+ };
+ opp@11 {
+ opp-hz = /bits/ 64 <11>;
+ opp-microvolt = <98 100 101>;
+ opp-microamp = <8>;
+ clock-latency-ns = <31>;
+ domain-performance-state = <2>;
+ };
+ opp@12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <1025000>;
+ clock-latency-ns = <29>;
+ turbo-mode;
+ domain-performance-state = <2>;
+ };
+ };
+};
--
2.7.1.410.g6faf27b
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
On Nov 18, 2016, at 1:59 AM, David Howells wrote: > > Andreas Dilger wrote: > If neither AT_STATX_*_SYNC flag is set, the behaviour is the default for stat() on that filesystem. >>> >>> We also need to specify here what happens if both bits are set. Should >>> that be -EINVAL? >> >> If that is the case, then it doesn't make sense to have two contradictory >> flags. > > Yes it does. There are actually *three* cases, not two. Maybe, rather > than a pair of flags, I should stake out a 2-bit field with three possible > values. That would probably be better in this case. >> Pick a default behaviour (i.e. return what is known on the client), > > The default behaviour has to be what stat() does now for any particular > filesystem. statx() is likely to get used to emulate stat() so that stat() > can be made to return safe timestamps. If we make it so that statx() cannot > do this, it's very likely that we'll see yet another stat() variant syscall > being added. > >> and if this is 100% accurate (e.g. local filesystem or filesystem with >> strong coherency) > > In a netfs, it was 100% accurate at the point the server started > transmitting its reply. This may no longer be true - even with something > like AFS that has change notifications. Sure, that is always true, even when running with a local filesystem. My distinction here is "whether the client currently has a lock that ensures its copy of the size is correct" vs. "the client has some size that was correct at one point but may be totally incorrect now". >> then it can optionally set the SYNC flag in the returned >> flags. > > So you suggest putting the SYNC flag(s) in the request mask rather than > sharing the AT_* flag space? Sorry, I was conflating flags. >> If the application needs 100% accurate size info, then it can set the SYNC >> flag in the request and the filesystem may need to do extra work to fetch >> accurate data from the server. > > Note that one of the things that people asked for was a > DONT_GO_TO_THE_SERVER_AT_ALL flag. I take it this is your suggested default? Isn't that what NFS does today? In any case, I'm not trying to rewrite NFS semantics here. The main fix would be to have the three-valued two-bit flag so that there aren't two flags that mean opposite things. That would also allow expansion to have a fourth state in the future, if there was a need. Cheers, Andreas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v11 3/6] x86/intel-ivi: Add Intel In-Vehicle Infotainment (IVI) systems used in cars support
On Fri, 18 Nov 2016, Tan Jui Nee wrote: > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index bada636..6019755 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -512,6 +512,16 @@ config X86_INTEL_CE > This option compiles in support for the CE4100 SOC for settop > boxes and media devices. > > +config X86_INTEL_IVI > + bool "Intel In-Vehicle Infotainment (IVI) systems used in cars" > + depends on X86 && PCI > + select P2SB > + ---help--- > + Select this option to enable MMIO BAR access over the P2SB for > + non-ACPI Intel Apollo Lake SoC platforms. This driver uses the P2SB > + hide/unhide mechanism cooperatively to pass the PCI BAR address to > + the platform driver, currently GPIO. Errm. INTEL_IVI does not enable MMIO BAR access over P2SB, CONFIG_P2SB does. Thanks, tglx
[PATCH] usb: hcd.h: construct hub class request conastants from simpler constants
Currently, each hub class request constant is defined by a line like: Where the "magic" number for the high byte is one of 0x20, 0xa0, 0x23, 0xa3. The 0x80 bit that changes inditace USB_DIR_IN, and the 0x03 that pops up is the difference between USB_RECIP_DEVICE (0x00) and USB_RECIP_OTHER (0x03). The constant 0x20 bit is USB_TYPE_CLASS. This patch eliminates those magic numbers by defining a macro to help construct these hub class request from simpler constants. Note that USB_RT_HUB is defined as (USB_TYPE_CLASS | USB_RECIP_DEVICE) and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER). Signed-off-by: Tal Shorer --- include/linux/usb/hcd.h | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h index 66fc137..2405853 100644 --- a/include/linux/usb/hcd.h +++ b/include/linux/usb/hcd.h @@ -566,21 +566,29 @@ extern void usb_ep0_reinit(struct usb_device *); ((USB_DIR_OUT|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8) /* class requests from the USB 2.0 hub spec, table 11-15 */ +#define HUB_CLASS_REQ(dir, type, request) dir) | (type)) << 8) | (request)) /* GetBusState and SetHubDescriptor are optional, omitted */ -#define ClearHubFeature(0x2000 | USB_REQ_CLEAR_FEATURE) -#define ClearPortFeature (0x2300 | USB_REQ_CLEAR_FEATURE) -#define GetHubDescriptor (0xa000 | USB_REQ_GET_DESCRIPTOR) -#define GetHubStatus (0xa000 | USB_REQ_GET_STATUS) -#define GetPortStatus (0xa300 | USB_REQ_GET_STATUS) -#define SetHubFeature (0x2000 | USB_REQ_SET_FEATURE) -#define SetPortFeature (0x2300 | USB_REQ_SET_FEATURE) +#define ClearHubFeature \ + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_HUB, USB_REQ_CLEAR_FEATURE) +#define ClearPortFeature \ + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_PORT, USB_REQ_CLEAR_FEATURE) +#define GetHubDescriptor \ + HUB_CLASS_REQ(USB_DIR_IN, USB_RT_HUB, USB_REQ_GET_DESCRIPTOR) +#define GetHubStatus HUB_CLASS_REQ(USB_DIR_IN, USB_RT_HUB, USB_REQ_GET_STATUS) +#define GetPortStatus \ + HUB_CLASS_REQ(USB_DIR_IN, USB_RT_PORT, USB_REQ_GET_STATUS) +#define SetHubFeature \ + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_HUB, USB_REQ_SET_FEATURE) +#define SetPortFeature \ + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_PORT, USB_REQ_SET_FEATURE) /*-*/ /* class requests from USB 3.1 hub spec, table 10-7 */ -#define SetHubDepth(0x2000 | HUB_SET_DEPTH) -#define GetPortErrorCount (0xa300 | HUB_GET_PORT_ERR_COUNT) +#define SetHubDepth HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_HUB, HUB_SET_DEPTH) +#define GetPortErrorCount \ + HUB_CLASS_REQ(USB_DIR_IN, USB_RT_PORT, HUB_GET_PORT_ERR_COUNT) /* * Generic bandwidth allocation constants/support -- 2.5.0
RE: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Hello,
> From: Harini Katakam [mailto:harinikatakamli...@gmail.com]
> Sent: 18 listopada 2016 05:30
> To: Rafal Ozieblo
> Cc: Nicolas Ferre; harini.kata...@xilinx.com; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
>
> Hi Rafal,
>
> On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo wrote:
> > -Original Message-
> > From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
> > Sent: 17 listopada 2016 14:29
> > To: Harini Katakam; Rafal Ozieblo
> > Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support
> > for GEM
> >
> >> Le 17/11/2016 à 13:21, Harini Katakam a écrit :
> >> > Hi Rafal,
> >> >
> >> > On Thu, Nov 17, 2016 at 5:20 PM, Rafal Ozieblo
> >> > wrote:
> >> >> Hello,
> >> >> I think, there could a bug in your patch.
> >> >>
> >> >>> +
> >> >>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> >> >>> + dmacfg |= GEM_BIT(ADDR64); #endif
> >> >>
> >> >> You enable 64 bit addressing (64b dma bus width) always when
> >> >> appropriate architecture config option is enabled.
> >> >> But there are some legacy controllers which do not support that
> >> >> feature. According Cadence hardware team:
> >> >> "64 bit addressing was added in July 2013. Earlier version do not have
> >> >> it.
> >> >> This feature was enhanced in release August 2014 to have separate upper
> >> >> address values for transmit and receive."
> >> >>
> >> >>> /* Bitfields in NSR */
> >> >>> @@ -474,6 +479,10 @@
> >> >>> struct macb_dma_desc {
> >> >> > u32 addr;
> >> >>> u32 ctrl;
> >> >>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> >> >>> + u32 addrh;
> >> >>> + u32 resvd;
> >> >>> +#endif
> >> >>> };
> >> >>
> >> >> It will not work for legacy hardware. Old descriptor is 2 words wide,
> >> >> the new one is 4 words wide.
> >> >> If you enable CONFIG_ARCH_DMA_ADDR_T_64BIT but hardware doesn't
> >> >> support it at all, you will miss every second descriptor.
> >> >>
> >> >
> >> > True, this feature is not available in all of Cadence IP versions.
> >> > In fact, the IP version Zynq does not support this. But the one in
> >> > ZynqMP does.
> >> > So, we enable kernel config for 64 bit DMA addressing for this SoC
> >> > and hence the driver picks it up. My assumption was that if the
> >> > legacy IP does not support
> >> > 64 bit addressing, then this DMA option wouldn't be enabled.
> >> >
> >> > There is a design config register in Cadence IP which is being read
> >> > to check for 64 bit address support - DMA mask is set based on that.
> >> > But the addition of two descriptor words cannot be based on this runtime
> >> > check.
> >> > For this reason, all the static changes were placed under this check.
> >>
> >> We have quite a bunch of options in this driver to determinate what is the
> >> real capacity of the underlying hardware.
> >> If HW configuration registers are not appropriate, and it seems they are
> >> not, I would advice to simply use the DT compatibility string.
> >>
> >> Best regards,
> >> --
> >> Nicolas Ferre
> >
> > HW configuration registers are appropriate. The issue is that this code
> > doesn’t use the capability bit to switch between different dma descriptors
> > (2 words vs. 4 words).
> > DMA descriptor size is chosen based on kernel configuration, not based on
> > hardware capabilities.
>
> HW configuration register does give appropriate information.
> But addition of two address words in the macb descriptor structure is a
> static change.
>
> +static inline void macb_set_addr(struct macb_dma_desc *desc, dma_addr_t
> +addr) {
> + desc->addr = (u32)addr;
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + desc->addrh = (u32)(addr >> 32); #endif
> +
>
> Even if the #ifdef condition here is changed to HW config check, addr and
> addrh are different.
> And "addrh" entry has to be present for 64 bit desc case to be handled
> separately.
> Can you please tell me how you propose change in DMA descriptor structure from
> 4 to 2 or 2 to 4 words *after* reading the DCFG register?
It is very complex problem. I wrote to you because I faced the same issue. I'm
working on PTP implementation for macb. When PTP is enabled there are
additional two words in buffer descriptor.
But hardware might not be compatible with PTP. Therefore I have to change DMA
descriptor between 2 and 4 words after reading DCFG register (the same as you
between 32b and 64b).
When we consider both PTP and 64 bits, we end up with 4 different descriptors!
1. 32b and without PTP support:
struct macb_dma_desc {
u32 addr;
u32 ctrl;
}
2. 64b and without PTP support:
struct macb_dma_desc {
u32 addr;
u32 ctrl;
u32 addrh;
u32 resvd;
}
3. 32 and PTP support:
struct macb_dma_desc {
u32 addr;
u32 ctrl;
u32
Re: [PATCH net v2 7/7] net: ethernet: ti: cpsw: fix fixed-link phy probe deferral
On Thu, Nov 17, 2016 at 06:19:20PM +0100, Johan Hovold wrote:
> On Thu, Nov 17, 2016 at 12:04:16PM -0500, David Miller wrote:
> > From: Johan Hovold
> > Date: Thu, 17 Nov 2016 17:40:04 +0100
> >
> > > Make sure to propagate errors from of_phy_register_fixed_link() which
> > > can fail with -EPROBE_DEFER.
> > >
> > > Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for fixed-link
> > > PHY")
> > > Signed-off-by: Johan Hovold
> >
> > Johan, when you update a patch within a series you must post the
> > entire series freshly to the lists, cover posting and all.
>
> I'm quite sure that is exactly what I did. Did you only get this last
> patch out of the seven?
The full series has made it to the lists:
https://marc.info/?l=linux-netdev&m=147940433115984&w=2
Perhaps some messages just got held up.
Let me know if you still want me to resend.
Thanks,
Johan
[GIT PULL] sound fixes for 4.9-rc6
Linus,
please pull sound fixes for v4.9-rc6 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-4.9-rc6
The topmost commit is 6ff1a25318ebf688ef9593fe09cd449f6fb4ad31
sound fixes for 4.9-rc6
Three trivial fixes: a regression fix for ASRock mobo, a
use-after-free fix at hot-unplug of USB-audio, and a quirk for new
Thinkpad models.
Hui Wang (1):
ALSA: hda - add a new condition to check if it is thinkpad
Takashi Iwai (2):
ALSA: hda - Fix mic regression by ASRock mobo fixup
ALSA: usb-audio: Fix use-after-free of usb_device at disconnect
---
sound/pci/hda/patch_realtek.c | 2 --
sound/pci/hda/thinkpad_helper.c | 3 ++-
sound/usb/card.c| 3 ++-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 2f909dd8b7b8..ea81c08ddc7a 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6907,8 +6907,6 @@ static const struct hda_fixup alc662_fixups[] = {
.v.pins = (const struct hda_pintbl[]) {
{ 0x15, 0x40f000f0 }, /* disabled */
{ 0x16, 0x40f000f0 }, /* disabled */
- { 0x18, 0x01014011 }, /* LO */
- { 0x1a, 0x01014012 }, /* LO */
{ }
}
},
diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c
index 6a23302297c9..4d9d320a7971 100644
--- a/sound/pci/hda/thinkpad_helper.c
+++ b/sound/pci/hda/thinkpad_helper.c
@@ -13,7 +13,8 @@ static void (*old_vmaster_hook)(void *, int);
static bool is_thinkpad(struct hda_codec *codec)
{
return (codec->core.subsystem_id >> 16 == 0x17aa) &&
- (acpi_dev_found("LEN0068") || acpi_dev_found("IBM0068"));
+ (acpi_dev_found("LEN0068") || acpi_dev_found("LEN0268") ||
+ acpi_dev_found("IBM0068"));
}
static void update_tpacpi_mute_led(void *private_data, int enabled)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 9e5276d6dda0..2ddc034673a8 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -315,7 +315,8 @@ static int snd_usb_audio_free(struct snd_usb_audio *chip)
snd_usb_endpoint_free(ep);
mutex_destroy(&chip->mutex);
- dev_set_drvdata(&chip->dev->dev, NULL);
+ if (!atomic_read(&chip->shutdown))
+ dev_set_drvdata(&chip->dev->dev, NULL);
kfree(chip);
return 0;
}
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Dave Chinner wrote: > > (5) Data version number: Could be used by userspace NFS servers [Aneesh > > Kumar]. > > > > Can also be used to modify fill_post_wcc() in NFSD which retrieves > > i_version directly, but has just called vfs_getattr(). It could get > > it from the kstat struct if it used vfs_xgetattr() instead. > > This needs a much clearer name that stx_version as "version" is > entirely ambiguous. e.g. Inodes have internal version numbers to > disambiguate life cycles. and there are versioning filesystems > which have multiple versions of the same file. We've already been through that. I wanted to call it stx_data_version but that got argued down to stx_version. The problem is that what the version number means is entirely filesystem dependent, and it might not just reflect changes in the data. > So if stx_version this is intended to export the internal filesystem > inode change counter (i.e. inode->i_version) then lets call it that: > stx_modification_count. It's clear and unambiguous as to what it > represents, especially as this counter is more than just a "data > modification" counter - inode metadata modifications will also > cause it to change I disagree that it's unambiguous. It works like mtime, right? Which wouldn't be of use for certain filesystems. An example of this would be AFS, where it's incremented by 1 each time a write is committed, but is not updated for metadata changes. This is what matters for data caching. > > (13) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > Note that the Linux IOC flags are a mess and filesystems such as Ext4 > > define flags that aren't in linux/fs.h, so translation in the kernel > > may be a necessity (or, possibly, we provide the filesystem type too). > > And we now also have FS_IOC_FSGETXATTR that extends the flags > and information userspace can get from filesystems. It makes little > sense to now add xstat() and not add everything this interface > also exports... I'm not sure I agree. Stuff like extent sizes and extent hint flags seem like very specialised things that don't belong in the stat interface. The project ID, on the other hand is arguably a good thing to include. But we can always add this later. Note that are also two variants of the fsxattr struct defined in the kernel - though one is a superset of the other. > > Time fields are split into separate seconds and nanoseconds fields to make > > packing easier and the granularities can be queried with the filesystem > > info system call. Note that times will be negative if before 1970; in such > > a case, the nanosecond fields will also be negative if not zero. > > So what happens in ten years time when we want to support > femptosecond resolution in the timestamp interface? We've got to > change everything to 64 bit? Shouldn't we just make everything > timestamp related 64 bit? You really think we're going to have accurate timestamps with a resolution of a millionth of a nanosecond? This means you're going to be doing a 64-bit division every time you want a nanosecond timestamp. Also, violet light has a period of ~1.2fs so your 1fs oscillator might emit UV radiation. > > The bits defined in the stx_attributes field convey information about a > > file, how it is accessed, where it is and what it does. The following > > attributes map to FS_*_FL flags and are the same numerical value: > > Please isolate the new interface flags completely from the FS_*_FL > values. We should not repeat the mistake of tying values derived > from filesystem specific on-disk values to a user interface. Why shouldn't I make a numerical correspondance with at least one set of such flags? I get to define a whole new numberspace and can pick the values I want. I see no particular reason to pick explicitly non-corresponding values where possible. Now, I can agree that the code should say, for example: if (ext4->flag & FS_COMPRESSED_FL) statx.attr |= STATX_ATTR_COMPRESSED; if (ext4->flag & FS_ENCRYPTED_FL) statx.attr |= STATX_ATTR_ENCRYPTED; if (ext4->flag & FS_IMMUTABLE_FL) statx.attr |= STATX_ATTR_IMMUTABLE; ... and that the *compiler* should collapse this to: statx.attr |= ext4->flag & mask; but see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317 David
Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Hi Rafal,
On Fri, Nov 18, 2016 at 3:00 PM, Rafal Ozieblo wrote:
>>-Original Message-
>>From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
>>Sent: 18 listopada 2016 10:10
>>To: Rafal Ozieblo; Harini Katakam; Andrei Pistirica
>>Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
>>linux-kernel@vger.kernel.org
>>Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
>>
>>Le 18/11/2016 à 09:59, Rafal Ozieblo a écrit :
>>> Hello,
>>>
From: Harini Katakam [mailto:harinikatakamli...@gmail.com]
Sent: 18 listopada 2016 05:30
To: Rafal Ozieblo
Cc: Nicolas Ferre; harini.kata...@xilinx.com; net...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support
for GEM
Hi Rafal,
On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo wrote:
> -Original Message-
> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
> Sent: 17 listopada 2016 14:29
> To: Harini Katakam; Rafal Ozieblo
> Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing
> support for GEM
>
>> Le 17/11/2016 à 13:21, Harini Katakam a écrit :
>>> Hi Rafal,
>>>
>>> On Thu, Nov 17, 2016 at 5:20 PM, Rafal Ozieblo
>>> wrote:
Hello,
I think, there could a bug in your patch.
> +
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + dmacfg |= GEM_BIT(ADDR64); #endif
You enable 64 bit addressing (64b dma bus width) always when
appropriate architecture config option is enabled.
But there are some legacy controllers which do not support that
feature. According Cadence hardware team:
"64 bit addressing was added in July 2013. Earlier version do not have
it.
This feature was enhanced in release August 2014 to have separate
upper address values for transmit and receive."
> /* Bitfields in NSR */
> @@ -474,6 +479,10 @@
> struct macb_dma_desc {
> u32 addr;
> u32 ctrl;
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + u32 addrh;
> + u32 resvd;
> +#endif
> };
It will not work for legacy hardware. Old descriptor is 2 words wide,
the new one is 4 words wide.
If you enable CONFIG_ARCH_DMA_ADDR_T_64BIT but hardware doesn't
support it at all, you will miss every second descriptor.
>>>
>>> True, this feature is not available in all of Cadence IP versions.
>>> In fact, the IP version Zynq does not support this. But the one in
>>> ZynqMP does.
>>> So, we enable kernel config for 64 bit DMA addressing for this SoC
>>> and hence the driver picks it up. My assumption was that if the
>>> legacy IP does not support
>>> 64 bit addressing, then this DMA option wouldn't be enabled.
>>>
>>> There is a design config register in Cadence IP which is being
>>> read to check for 64 bit address support - DMA mask is set based on
>>> that.
>>> But the addition of two descriptor words cannot be based on this
>>> runtime check.
>>> For this reason, all the static changes were placed under this check.
>>
>> We have quite a bunch of options in this driver to determinate what is
>> the real capacity of the underlying hardware.
>> If HW configuration registers are not appropriate, and it seems they are
>> not, I would advice to simply use the DT compatibility string.
>>
>> Best regards,
>> --
>> Nicolas Ferre
>
> HW configuration registers are appropriate. The issue is that this code
> doesn’t use the capability bit to switch between different dma
> descriptors (2 words vs. 4 words).
> DMA descriptor size is chosen based on kernel configuration, not based on
> hardware capabilities.
HW configuration register does give appropriate information.
But addition of two address words in the macb descriptor structure is a
static change.
+static inline void macb_set_addr(struct macb_dma_desc *desc,
+dma_addr_t
+addr) {
+ desc->addr = (u32)addr;
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+ desc->addrh = (u32)(addr >> 32); #endif
+
Even if the #ifdef condition here is changed to HW config check, addr and
addrh are different.
And "addrh" entry has to be present for 64 bit desc case to be handled
separately.
Can you please tell me how you propose change in DMA descriptor
structure from
4 to 2 or 2 to 4 words *after* reading the DCFG register?
>>>
>>> It is very complex problem. I wrote to you because I faced the same issue.
>>> I'm working on PTP implementation for macb. When PTP
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Dave Chinner wrote: > > STATX_ATTR_KERNEL_API File is kernel API (eg: procfs/sysfs) > > STATX_ATTR_REMOTE File is remote and needs network > > STATX_ATTR_FABRICATED File was made up by fs > > Every file is fabricated by a filesystem :P > > Perhaps you're wanting "virtual file" because it is has no physical > presence? Yeah - that might be a better name. The idea of FABRICATED is to note objects that have no actual existence in the backing store. Directories that had to be invented to act as mountpoints would be a good example of this. > > Fields in struct statx come in a number of classes: > > > > (0) stx_dev_*, stx_blksize. > > > > These are local system information and are always available. > > What does stx_blksize actually mean? It's completely ambiguous in > stat() because we don't actually report the physical block size > here - we report the "minimum unit of efficient IO" that we expect > applications to use. Please define :P Definition: "Same as struct stat::st_blksize". > > The following test program can be used to test the statx system call: > > > > samples/statx/test-statx.c > > > > Just compile and run, passing it paths to the files you want to examine. > > The file is built automatically if CONFIG_SAMPLES is enabled. > > Can we get xfstests written to exercise and validate all this > functionality, please? I'd suggest that adding xfs_io support for > the statx syscall would be far more useful for xfstests than a > standalone test program, too. We already have equivalent stat() > functionality in xfs_io and that's used quite a bit in xfstests Feel free to write some! ;-) But I need a simple standalone test program to be able to test what I write, and I've no inclination to wheel out huge testsuites for an interface that people are still arguing about and wanting changed. David
Re: [PATCH v2] vgaarb: Use dev_printk() when possible
On Thu, Nov 17, 2016 at 02:20:59PM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 17, 2016 at 07:59:21PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 17, 2016 at 11:47:58AM -0600, Bjorn Helgaas wrote:
> > > Use dev_printk() when possible. This makes messages more consistent with
> > > other device-related messages and, in some cases, adds useful information.
> > > This changes messages like this:
> > >
> > > vgaarb: failed to allocate pci device
> > > vgaarb: setting as boot device: PCI::01:00.0
> > > vgaarb: device added:
> > > PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
> > > vgaarb: bridge control possible :01:00.0
> > >
> > > to this:
> > >
> > > pci :01:00.0: vgaarb: failed to allocate VGA arbiter data
> > > pci :01:00.0: vgaarb: setting as boot VGA device
> > > pci :01:00.0: vgaarb: VGA device added:
> > > decodes=io+mem,owns=io+mem,locks=none
> > > pci :01:00.0: vgaarb: bridge control possible
> > >
> > > No functional change intended.
> >
> > Found one more nit below where there was one relevant change that
> > shouldn't be here.
>
> > > @@ -1189,24 +1194,25 @@ static ssize_t vga_arb_write(struct file *file,
> > > const char __user *buf,
> > > ret_val = -EPROTO;
> > > goto done;
> > > }
> > > - pr_debug("%s ==> %x:%x:%x.%x\n", curr_pos,
> > > - domain, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> > > -
> > > pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
> > > - pr_debug("pdev %p\n", pdev);
> > > if (!pdev) {
> > > - pr_err("invalid PCI address %x:%x:%x\n",
> > > - domain, bus, devfn);
> > > + pr_err("invalid PCI address
> > > %04x:%02x:%02x.%x\n",
> > > + domain, bus, PCI_SLOT(devfn),
> > > + PCI_FUNC(devfn));
> >
> > Userspace-triggerable dmesg spam is imo not good, this needs to stay at
> > debug level.
>
> I did move these around slightly, but I don't *think* I changed
> anything from debug to err level. Previously:
>
> pr_debug("%s ==> %x:%x:%x.%x\n", ...);
> pdev = pci_get_domain_bus_and_slot(...);
> pr_debug("pdev %p\n", pdev);
> if (!pdev) {
> pr_err("invalid PCI address %x:%x:%x\n", ...);
> }
>
> after my patch:
>
> pdev = pci_get_domain_bus_and_slot(...);
> if (!pdev) {
> pr_err("invalid PCI address %x:%x:%x\n", ...);
> }
> pr_debug("%s ==> %x:%x:%x.%x pdev %p\n", ...);
>
> The pr_err() was there before. I'd be glad to change that to a
> pr_debug() if you prefer.
Oh right, misread the diff. Applied your patch, but a s/pr_err/pr_debug
for anything userspace can trigger in the string parsing would be nice.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/3] virtio: Basic implementation of virtio pstore driver
On 18/11/2016 04:32, Namhyung Kim wrote: >> In addition, the firmware will need to reserve a few KB of RAM for the error >> log >> address range (I checked a real system and it reserves 8KB). The first eight >> bytes are needed for the record identifier interface, because there's no such >> thing as 64-bit I/O ports, and the rest can be used for the actual buffer. > > Is there a limit on the size? It'd be great if it can use a few MB.. Yes, you can make it customizable. >>> Also I need to control pstore driver like using bigger buffer, >>> enabling specific message types and so on if ERST supports. Is it >>> possible for ERST to provide such information? >> >> It's the normal pstore driver, same as on a real server. What exactly do you >> need? > > Well, I don't want to send additional pstore messages to the device if > it cannot handle them properly - for example, ftrace message should not > overwrite kmsg dump. It'd be great if device somehow could expose > acceptable message types to the driver IMHO. This is something that you have to do in the usual kernel pstore infrastructure. It should not be specific to virtualization. Paolo > Btw I prefer using the kvmtool for my kernel work since it's much more > simpler..
RE: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
>-Original Message-
>From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
>Sent: 18 listopada 2016 10:10
>To: Rafal Ozieblo; Harini Katakam; Andrei Pistirica
>Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
>linux-kernel@vger.kernel.org
>Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
>
>
>
>Le 18/11/2016 à 09:59, Rafal Ozieblo a écrit :
>
>> Hello,
>>
>>
>>
>>> From: Harini Katakam [mailto:harinikatakamli...@gmail.com]
>>>
>>> Sent: 18 listopada 2016 05:30
>>>
>>> To: Rafal Ozieblo
>>>
>>> Cc: Nicolas Ferre; harini.kata...@xilinx.com; net...@vger.kernel.org;
>>>
>>> linux-kernel@vger.kernel.org
>>>
>>> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support
>>>
>>> for GEM
>>>
>>>
>>>
>>> Hi Rafal,
>>>
>>>
>>>
>>> On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo wrote:
>>>
-Original Message-
From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
Sent: 17 listopada 2016 14:29
To: Harini Katakam; Rafal Ozieblo
Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing
support for GEM
> Le 17/11/2016 à 13:21, Harini Katakam a écrit :
>
>> Hi Rafal,
>>
>>
>>
>> On Thu, Nov 17, 2016 at 5:20 PM, Rafal Ozieblo
>> wrote:
>>> Hello,
>>>
>>> I think, there could a bug in your patch.
>>>
>>>
>>>
+
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+ dmacfg |= GEM_BIT(ADDR64); #endif
>>>
>>>
>>> You enable 64 bit addressing (64b dma bus width) always when
>>> appropriate architecture config option is enabled.
>>>
>>> But there are some legacy controllers which do not support that
>>> feature. According Cadence hardware team:
>>>
>>> "64 bit addressing was added in July 2013. Earlier version do not have
>>> it.
>>> This feature was enhanced in release August 2014 to have separate upper
>>> address values for transmit and receive."
>>>
>>>
>>>
/* Bitfields in NSR */
@@ -474,6 +479,10 @@
struct macb_dma_desc {
>>> > u32 addr;
>>>
u32 ctrl;
Re: [virtio-dev] Re: [PATCH 1/3] virtio: Basic implementation of virtio pstore driver
On 18/11/2016 05:07, Michael S. Tsirkin wrote: > On Fri, Nov 18, 2016 at 12:32:06PM +0900, Namhyung Kim wrote: >> Btw I prefer using the kvmtool for my kernel work since it's much more >> simpler.. > > Up to you but then you should extend that to support 1.0 spec. > I strongly object to adding to the list of legacy interfaces > we need to maintain. I object to adding paravirtualization unless there is a good reason why the usual mechanisms for physical machines cannot be used. The cost of maintaining a spec, two device implementations (kvmtool+qemu) and a driver is not small, plus it will not work on older kernels. Paolo
Re: [PATCH] [media] VPU: mediatek: fix dereference of pdev before checking it is null
On 16/11/16 20:16, Colin King wrote:
From: Colin Ian King
pdev is dereferenced using platform_get_drvdata before a check to
see if it is null, hence there could be a potential null pointer
dereference issue. Instead, first check if pdev is null and only then
deference pdev when initializing vpu.
Found with static analysis by CoverityScan, CID 1357797
Signed-off-by: Colin Ian King
---
Reviewed-by: Matthias Brugger
drivers/media/platform/mtk-vpu/mtk_vpu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index c9bf58c..41f31b2 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -523,9 +523,9 @@ static int load_requested_vpu(struct mtk_vpu *vpu,
int vpu_load_firmware(struct platform_device *pdev)
{
- struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+ struct mtk_vpu *vpu;
struct device *dev = &pdev->dev;
- struct vpu_run *run = &vpu->run;
+ struct vpu_run *run;
const struct firmware *vpu_fw = NULL;
int ret;
@@ -533,6 +533,8 @@ int vpu_load_firmware(struct platform_device *pdev)
dev_err(dev, "VPU platform device is invalid\n");
return -EINVAL;
}
+ vpu = platform_get_drvdata(pdev);
+ run = &vpu->run;
mutex_lock(&vpu->vpu_mutex);
if (vpu->fw_loaded) {
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available
Andreas Dilger wrote: > > What happens when an application uses STATX_ALL from a future kernel > > that defines more flags than are initially supported, and that > > application then is run on a kernel that onyl supports the initial > > fields? > > Fields that are unknown by the current kernel/filesystem will not be set, > and this is reflected in the flags that are returned to userspace. Yep. A userspace program can stick 0x in there if it wants. No error will be incurred. It just won't necessarily get anything back for each of those bits. That said, if we, say, want to reserve bit 31 as a struct extension bit, sticking in 0x without knowing what this is going to do to you on a kernel that supports a longer struct might give you a problem. But, basically, STATX_ALL indicates what flags have fields in the copy of the struct you got from the header file. There's an extra scenario: you could compile your userspace program against the headers for a particular kernel and then run against a later kernel. In such a case, you may find bits set that are outside STATX_ALL in stx_mask. However, you don't have definitions for those bits and can only ignore them. > > Again, we have many more common and extended flags than this. > > NOATIME and SYNC are two that immediately come to mind as generic > > flags that should be in this... > > Sure, and they can be added incrementally in a later patch. I'm not > sure why NOATIME and SYNC are missing, and I'm not against adding them, > but it is equally likely that they were removed in a previous round of > bikeshedding to avoid some real or perceived issue, so that this patch > can finally land rather than being in limbo for another 5 years. Does it make sense to return them through statx? Note that NOATIME might be considered superfluous given that STATX_ATIME is cleared in such a case. > >> New flags include: > >> > >>STATX_ATTR_NONUNIX_OWNERSHIPFile doesn't have Unixy ownership > >>STATX_ATTR_HAS_ACL File has an ACL > > > > So statx will require us to do ACL lookups? i.e. instead of just > > reading the inode to get the information, we'll also have to do > > extended attribute lookups? That's potentially very expensive if > > the extended attribute is not stored in the inode > > No, there is no requirement to return anything that the caller didn't > ask for. Only fields that are explicitly requested need to be returned, > and others can optionally be returned if it is easy for the filesystem > to do so. Actually, Dave might have a point. We don't necessarily know that the file has an ACL without doing a getxattr() to probe for it - on the other hand, I would expect the permissions check to have done precisely that. David
Re: [PATCH] usb: hcd.h: construct hub class request conastants from simpler constants
On Fri, Nov 18, 2016 at 11:30:18AM +0200, Tal Shorer wrote: > Currently, each hub class request constant is defined by a line like: > > Where the "magic" number for the high byte is one of 0x20, 0xa0, 0x23, > 0xa3. I think your description here is missing something... > The 0x80 bit that changes inditace USB_DIR_IN, and the 0x03 that > pops up is the difference between USB_RECIP_DEVICE (0x00) and > USB_RECIP_OTHER (0x03). The constant 0x20 bit is USB_TYPE_CLASS. > > This patch eliminates those magic numbers by defining a macro to help > construct these hub class request from simpler constants. > Note that USB_RT_HUB is defined as (USB_TYPE_CLASS | USB_RECIP_DEVICE) > and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER). > > Signed-off-by: Tal Shorer > --- > include/linux/usb/hcd.h | 26 +- > 1 file changed, 17 insertions(+), 9 deletions(-) > > diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h > index 66fc137..2405853 100644 > --- a/include/linux/usb/hcd.h > +++ b/include/linux/usb/hcd.h > @@ -566,21 +566,29 @@ extern void usb_ep0_reinit(struct usb_device *); > ((USB_DIR_OUT|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8) > > /* class requests from the USB 2.0 hub spec, table 11-15 */ > +#define HUB_CLASS_REQ(dir, type, request) dir) | (type)) << 8) | > (request)) > /* GetBusState and SetHubDescriptor are optional, omitted */ > -#define ClearHubFeature (0x2000 | USB_REQ_CLEAR_FEATURE) > -#define ClearPortFeature (0x2300 | USB_REQ_CLEAR_FEATURE) > -#define GetHubDescriptor (0xa000 | USB_REQ_GET_DESCRIPTOR) > -#define GetHubStatus (0xa000 | USB_REQ_GET_STATUS) > -#define GetPortStatus(0xa300 | USB_REQ_GET_STATUS) > -#define SetHubFeature(0x2000 | USB_REQ_SET_FEATURE) > -#define SetPortFeature (0x2300 | USB_REQ_SET_FEATURE) > +#define ClearHubFeature \ > + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_HUB, USB_REQ_CLEAR_FEATURE) > +#define ClearPortFeature \ > + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_PORT, USB_REQ_CLEAR_FEATURE) > +#define GetHubDescriptor \ > + HUB_CLASS_REQ(USB_DIR_IN, USB_RT_HUB, USB_REQ_GET_DESCRIPTOR) > +#define GetHubStatus HUB_CLASS_REQ(USB_DIR_IN, USB_RT_HUB, > USB_REQ_GET_STATUS) > +#define GetPortStatus \ > + HUB_CLASS_REQ(USB_DIR_IN, USB_RT_PORT, USB_REQ_GET_STATUS) > +#define SetHubFeature \ > + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_HUB, USB_REQ_SET_FEATURE) > +#define SetPortFeature \ > + HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_PORT, USB_REQ_SET_FEATURE) That's a bit harder to read now, right? Just put them all on one line please. > /*-*/ > > /* class requests from USB 3.1 hub spec, table 10-7 */ > -#define SetHubDepth (0x2000 | HUB_SET_DEPTH) > -#define GetPortErrorCount(0xa300 | HUB_GET_PORT_ERR_COUNT) > +#define SetHubDepth HUB_CLASS_REQ(USB_DIR_OUT, USB_RT_HUB, HUB_SET_DEPTH) > +#define GetPortErrorCount \ > + HUB_CLASS_REQ(USB_DIR_IN, USB_RT_PORT, HUB_GET_PORT_ERR_COUNT) Same here. thanks, greg k-h
Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Hi Rafal, > I can’t see a place where you enable extended descriptor for PTP. Did you add > support for extended PTP descriptor? Sorry, that was separate patch in the series: http://lkml.iu.edu/hypermail/linux/kernel/1509.1/02239.html > "DMA Configuration Register" 0x010: > 29 tx_bd_extended_mode_en "Enable TX extended BD mode. See TX BD > control register definition for description of feature." > 28 rx_bd_extended_mode_en "Enable RX extended BD mode. See RX BD > control register definition for description of feature." > > Can I send you our patch for comparison ? Sure, please mail. Also, please mention the Cadence IP version number you use. Regards, Harini
[tip:x86/timers] x86/tsc: Add X86_FEATURE_TSC_KNOWN_FREQ flag
Commit-ID: 47c95a46d0fae07762f0a38aa3709ae63f307048
Gitweb: http://git.kernel.org/tip/47c95a46d0fae07762f0a38aa3709ae63f307048
Author: Bin Gao
AuthorDate: Tue, 15 Nov 2016 12:27:21 -0800
Committer: Thomas Gleixner
CommitDate: Fri, 18 Nov 2016 10:58:30 +0100
x86/tsc: Add X86_FEATURE_TSC_KNOWN_FREQ flag
The X86_FEATURE_TSC_RELIABLE flag in Linux kernel implies both reliable
(at runtime) and trustable (at calibration). But reliable running and
trustable calibration independent of each other.
Add a new flag X86_FEATURE_TSC_KNOWN_FREQ, which denotes that the frequency
is known (via MSR/CPUID). This flag is only meant to skip the long term
calibration on systems which have a known frequency.
Add X86_FEATURE_TSC_KNOWN_FREQ to the skip the delayed calibration and
leave X86_FEATURE_TSC_RELIABLE in place.
After converting the existing users of X86_FEATURE_TSC_RELIABLE to use
either both flags or just X86_FEATURE_TSC_KNOWN_FREQ we can seperate the
functionality.
Suggested-by: Thomas Gleixner
Signed-off-by: Bin Gao
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1479241644-234277-2-git-send-email-bin@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/tsc.c | 11 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index a396292..7f6a5f8 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -106,6 +106,7 @@
#define X86_FEATURE_APERFMPERF ( 3*32+28) /* APERFMPERF */
#define X86_FEATURE_EAGER_FPU ( 3*32+29) /* "eagerfpu" Non lazy FPU restore */
#define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 state
*/
+#define X86_FEATURE_TSC_KNOWN_FREQ ( 3*32+31) /* TSC has known frequency */
/* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
#define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46b2f41..d2c4ee4 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1283,10 +1283,15 @@ static int __init init_tsc_clocksource(void)
clocksource_tsc.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
/*
-* Trust the results of the earlier calibration on systems
-* exporting a reliable TSC.
+* When TSC frequency is known (retrieved via MSR or CPUID), we skip
+* the refined calibration and directly register it as a clocksource.
+*
+* We still keep the TSC_RELIABLE flag here to avoid regressions -
+* it will be removed after all the conversion for other code paths
+* connected to this flag is done.
*/
- if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE)) {
+ if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ||
+ boot_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) {
clocksource_register_khz(&clocksource_tsc, tsc_khz);
return 0;
}
[tip:x86/timers] x86/tsc: Mark TSC frequency determined by CPUID as known
Commit-ID: 4ca4df0b7eb06df264b2919759957f6d6ea1822e Gitweb: http://git.kernel.org/tip/4ca4df0b7eb06df264b2919759957f6d6ea1822e Author: Bin Gao AuthorDate: Tue, 15 Nov 2016 12:27:22 -0800 Committer: Thomas Gleixner CommitDate: Fri, 18 Nov 2016 10:58:30 +0100 x86/tsc: Mark TSC frequency determined by CPUID as known CPUs/SoCs with CPUID leaf 0x15 come with a known frequency and will report the frequency to software via CPUID instruction. This hardware provided frequency is the "real" frequency of TSC. Set the X86_FEATURE_TSC_KNOWN_FREQ flag for such systems to skip the software calibration process. A 24 hours test on one of the CPUID 0x15 capable platforms was conducted. PIT calibrated frequency resulted in more than 3 seconds drift whereas the CPUID determined frequency showed less than 0.5 second drift. Signed-off-by: Bin Gao Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1479241644-234277-3-git-send-email-bin@linux.intel.com Signed-off-by: Thomas Gleixner --- arch/x86/kernel/tsc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index d2c4ee4..e58c319 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -702,6 +702,13 @@ unsigned long native_calibrate_tsc(void) } } + /* +* TSC frequency determined by CPUID is a "hardware reported" +* frequency and is the most accurate one so far we have. This +* is considered a known frequency. +*/ + setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); + return crystal_khz * ebx_numerator / eax_denominator; }
[Resend PATCH] drm/mediatek: fix null pointer dereference
The probe function requests the interrupt before initializing
the ddp component. Which leads to a null pointer dereference at boot.
Fix this by requesting the interrput after all components got
initialized properly.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
MT8173.")
Signed-off-by: Matthias Brugger
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 019b7ca..1e78159 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -250,13 +250,6 @@ static int mtk_disp_ovl_probe(struct
platform_device *pdev)
if (irq < 0)
return irq;
- ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
- IRQF_TRIGGER_NONE, dev_name(dev), priv);
- if (ret < 0) {
- dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
- return ret;
- }
-
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_OVL);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
@@ -272,6 +265,13 @@ static int mtk_disp_ovl_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, priv);
+ ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
+ IRQF_TRIGGER_NONE, dev_name(dev), priv);
+ if (ret < 0) {
+ dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
+ return ret;
+ }
+
ret = component_add(dev, &mtk_disp_ovl_component_ops);
if (ret)
dev_err(dev, "Failed to add component: %d\n", ret);
--
2.10.1
Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Fri, Nov 18, 2016 at 08:48:36AM +, Levy, Amir (Jer) wrote: > > BTW, it is quite a shame that the Thunderbolt firmware version can't > > be read from Linux. > > > > This is WIP, once this patch will be upstream, we will be able to focus more > on aligning Linux with the Thunderbolt features that we have for windows. Why is this patch somehow holding that work back? You aren't just sitting around waiting for people to review this and not doing anything else, right? Is there some basic building block in these patches that your firmware download code is going to rely on? confused, greg k-h
[tip:x86/timers] x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs
Commit-ID: f3a02ecebed7df7d5d68898628dea7a3bfcf03e3
Gitweb: http://git.kernel.org/tip/f3a02ecebed7df7d5d68898628dea7a3bfcf03e3
Author: Bin Gao
AuthorDate: Tue, 15 Nov 2016 12:27:24 -0800
Committer: Thomas Gleixner
CommitDate: Fri, 18 Nov 2016 10:58:31 +0100
x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs
TSC on Intel Atom SoCs capable of determining TSC frequency by MSR is
reliable and the frequency is known (provided by HW).
On these platforms PIT/HPET is generally not available so calibration won't
work at all and there is no other clocksource to act as a watchdog for the
TSC, so we have no other choice than to trust it.
Set both X86_FEATURE_TSC_KNOWN_FREQ and X86_FEATURE_TSC_RELIABLE flags to
make sure the calibration is skipped and no watchdog is required.
Signed-off-by: Bin Gao
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1479241644-234277-5-git-send-email-bin@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/tsc_msr.c | 19 +++
arch/x86/platform/intel-mid/mfld.c | 9 +++--
arch/x86/platform/intel-mid/mrfld.c | 8 ++--
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 0fe720d..19afdbd 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -100,5 +100,24 @@ unsigned long cpu_khz_from_msr(void)
#ifdef CONFIG_X86_LOCAL_APIC
lapic_timer_frequency = (freq * 1000) / HZ;
#endif
+
+ /*
+* TSC frequency determined by MSR is always considered "known"
+* because it is reported by HW.
+* Another fact is that on MSR capable platforms, PIT/HPET is
+* generally not available so calibration won't work at all.
+*/
+ setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+
+ /*
+* Unfortunately there is no way for hardware to tell whether the
+* TSC is reliable. We were told by silicon design team that TSC
+* on Atom SoCs are always "reliable". TSC is also the only
+* reliable clocksource on these SoCs (HPET is either not present
+* or not functional) so mark TSC reliable which removes the
+* requirement for a watchdog clocksource.
+*/
+ setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+
return res;
}
diff --git a/arch/x86/platform/intel-mid/mfld.c
b/arch/x86/platform/intel-mid/mfld.c
index 1eb47b6..e793fe5 100644
--- a/arch/x86/platform/intel-mid/mfld.c
+++ b/arch/x86/platform/intel-mid/mfld.c
@@ -49,8 +49,13 @@ static unsigned long __init mfld_calibrate_tsc(void)
fast_calibrate = ratio * fsb;
pr_debug("read penwell tsc %lu khz\n", fast_calibrate);
lapic_timer_frequency = fsb * 1000 / HZ;
- /* mark tsc clocksource as reliable */
- set_cpu_cap(&boot_cpu_data, X86_FEATURE_TSC_RELIABLE);
+
+ /*
+* TSC on Intel Atom SoCs is reliable and of known frequency.
+* See tsc_msr.c for details.
+*/
+ setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+ setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
return fast_calibrate;
}
diff --git a/arch/x86/platform/intel-mid/mrfld.c
b/arch/x86/platform/intel-mid/mrfld.c
index 59253db..e0607c7 100644
--- a/arch/x86/platform/intel-mid/mrfld.c
+++ b/arch/x86/platform/intel-mid/mrfld.c
@@ -78,8 +78,12 @@ static unsigned long __init tangier_calibrate_tsc(void)
pr_debug("Setting lapic_timer_frequency = %d\n",
lapic_timer_frequency);
- /* mark tsc clocksource as reliable */
- set_cpu_cap(&boot_cpu_data, X86_FEATURE_TSC_RELIABLE);
+ /*
+* TSC on Intel Atom SoCs is reliable and of known frequency.
+* See tsc_msr.c for details.
+*/
+ setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+ setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
return fast_calibrate;
}
[tip:x86/timers] x86/tsc: Mark Intel ATOM_GOLDMONT TSC reliable
Commit-ID: 4635fdc696a8e89eead3ea1712ae6ada38538d40 Gitweb: http://git.kernel.org/tip/4635fdc696a8e89eead3ea1712ae6ada38538d40 Author: Bin Gao AuthorDate: Tue, 15 Nov 2016 12:27:23 -0800 Committer: Thomas Gleixner CommitDate: Fri, 18 Nov 2016 10:58:30 +0100 x86/tsc: Mark Intel ATOM_GOLDMONT TSC reliable On Intel GOLDMONT Atom SoC TSC is the only available clocksource, so there is no way to do software calibration or have a watchdog clocksource for it. Software calibration is already disabled via the TSC_KNOWN_FREQ flag, but the watchdog requirement still persists, so such systems cannot switch to high resolution/nohz mode. Mark it reliable, so it becomes usable. Hardware teams confirmed that this is safe on that SoC. Signed-off-by: Bin Gao Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1479241644-234277-4-git-send-email-bin@linux.intel.com Signed-off-by: Thomas Gleixner --- arch/x86/kernel/tsc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index e58c319..f4dfdaa 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -709,6 +709,13 @@ unsigned long native_calibrate_tsc(void) */ setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); + /* +* For Atom SoCs TSC is the only reliable clocksource. +* Mark TSC reliable so no watchdog on it. +*/ + if (boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT) + setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); + return crystal_khz * ebx_numerator / eax_denominator; }
RE: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
Hi Eric, Have you sent out QEMU side patches based on this new approach? In case I missed please point me the patches? Thanks -Bharat > -Original Message- > From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- > boun...@lists.linux-foundation.org] On Behalf Of Eric Auger > Sent: Tuesday, November 15, 2016 6:39 PM > To: eric.au...@redhat.com; eric.auger@gmail.com; > christoffer.d...@linaro.org; marc.zyng...@arm.com; > robin.mur...@arm.com; alex.william...@redhat.com; > will.dea...@arm.com; j...@8bytes.org; t...@linutronix.de; > ja...@lakedaemon.net; linux-arm-ker...@lists.infradead.org > Cc: drjo...@redhat.com; k...@vger.kernel.org; punit.agra...@arm.com; > linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org; > pranav.sawargaon...@gmail.com > Subject: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and > IOVA reserved regions > > Following LPC discussions, we now report reserved regions through iommu- > group sysfs reserved_regions attribute file. > > Reserved regions are populated through the IOMMU get_resv_region > callback (former get_dm_regions), now implemented by amd-iommu, intel- > iommu and arm-smmu. > > The intel-iommu reports the [FEE0_h - FEF0_000h] MSI window as an > IOMMU_RESV_NOMAP reserved region. > > arm-smmu reports the MSI window (arbitrarily located at 0x800 and 1MB > large) and the PCI host bridge windows. > > The series integrates a not officially posted patch from Robin: > "iommu/dma: Allow MSI-only cookies". > > This series currently does not address IRQ safety assessment. > > Best Regards > > Eric > > Git: complete series available at > https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3 > > History: > RFC v2 -> v3: > - switch to an iommu-group sysfs API > - use new dummy allocator provided by Robin > - dummy allocator initialized by vfio-iommu-type1 after enumerating > the reserved regions > - at the moment ARM MSI base address/size is left unchanged compared > to v2 > - we currently report reserved regions and not usable IOVA regions as > requested by Alex > > RFC v1 -> v2: > - fix intel_add_reserved_regions > - add mutex lock/unlock in vfio_iommu_type1 > > > Eric Auger (10): > iommu/dma: Allow MSI-only cookies > iommu: Rename iommu_dm_regions into iommu_resv_regions > iommu: Add new reserved IOMMU attributes > iommu: iommu_alloc_resv_region > iommu: Do not map reserved regions > iommu: iommu_get_group_resv_regions > iommu: Implement reserved_regions iommu-group sysfs file > iommu/vt-d: Implement reserved region get/put callbacks > iommu/arm-smmu: Implement reserved region get/put callbacks > vfio/type1: Get MSI cookie > > drivers/iommu/amd_iommu.c | 20 +++--- > drivers/iommu/arm-smmu.c| 52 +++ > drivers/iommu/dma-iommu.c | 116 ++ > --- > drivers/iommu/intel-iommu.c | 50 ++ > drivers/iommu/iommu.c | 141 > > drivers/vfio/vfio_iommu_type1.c | 26 > include/linux/dma-iommu.h | 7 ++ > include/linux/iommu.h | 49 ++ > 8 files changed, 391 insertions(+), 70 deletions(-) > > -- > 1.9.1 > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC][PATCH 7/7] kref: Implement using refcount_t
>Provide refcount_t, an atomic_t like primitive built just for refcounting. >It provides overflow and underflow checks as well as saturation semantics such >that when it overflows, we'll never attempt to free it again, ever. Peter do you have the changes to the refcount_t interface compare to the version in this patch? We are now starting working on atomic_t --> refcount_t conversions and it would save a bit of work to have latest version from you that we can be based upon. Best Regards, Elena.
Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Hi Harini,
On 18.11.2016 10:43, Harini Katakam wrote:
Hi Rafal,
On Fri, Nov 18, 2016 at 3:00 PM, Rafal Ozieblo wrote:
-Original Message-
From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
Sent: 18 listopada 2016 10:10
To: Rafal Ozieblo; Harini Katakam; Andrei Pistirica
Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Le 18/11/2016 à 09:59, Rafal Ozieblo a écrit :
Hello,
From: Harini Katakam [mailto:harinikatakamli...@gmail.com]
Sent: 18 listopada 2016 05:30
To: Rafal Ozieblo
Cc: Nicolas Ferre; harini.kata...@xilinx.com; net...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support
for GEM
Hi Rafal,
On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo wrote:
-Original Message-
From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
Sent: 17 listopada 2016 14:29
To: Harini Katakam; Rafal Ozieblo
Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing
support for GEM
Le 17/11/2016 à 13:21, Harini Katakam a écrit :
Hi Rafal,
On Thu, Nov 17, 2016 at 5:20 PM, Rafal Ozieblo wrote:
Hello,
I think, there could a bug in your patch.
+
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+ dmacfg |= GEM_BIT(ADDR64); #endif
You enable 64 bit addressing (64b dma bus width) always when appropriate
architecture config option is enabled.
But there are some legacy controllers which do not support that feature.
According Cadence hardware team:
"64 bit addressing was added in July 2013. Earlier version do not have it.
This feature was enhanced in release August 2014 to have separate upper address
values for transmit and receive."
/* Bitfields in NSR */
@@ -474,6 +479,10 @@
struct macb_dma_desc {
> u32 addr;
u32 ctrl;
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+ u32 addrh;
+ u32 resvd;
+#endif
};
It will not work for legacy hardware. Old descriptor is 2 words wide, the new
one is 4 words wide.
If you enable CONFIG_ARCH_DMA_ADDR_T_64BIT but hardware doesn't
support it at all, you will miss every second descriptor.
True, this feature is not available in all of Cadence IP versions.
In fact, the IP version Zynq does not support this. But the one in ZynqMP does.
So, we enable kernel config for 64 bit DMA addressing for this SoC
and hence the driver picks it up. My assumption was that if the
legacy IP does not support
64 bit addressing, then this DMA option wouldn't be enabled.
There is a design config register in Cadence IP which is being
read to check for 64 bit address support - DMA mask is set based on that.
But the addition of two descriptor words cannot be based on this runtime check.
For this reason, all the static changes were placed under this check.
We have quite a bunch of options in this driver to determinate what is the real
capacity of the underlying hardware.
If HW configuration registers are not appropriate, and it seems they are not, I
would advice to simply use the DT compatibility string.
Best regards,
--
Nicolas Ferre
HW configuration registers are appropriate. The issue is that this code doesn’t
use the capability bit to switch between different dma descriptors (2 words vs.
4 words).
DMA descriptor size is chosen based on kernel configuration, not based on
hardware capabilities.
HW configuration register does give appropriate information.
But addition of two address words in the macb descriptor structure is a static
change.
+static inline void macb_set_addr(struct macb_dma_desc *desc,
+dma_addr_t
+addr) {
+ desc->addr = (u32)addr;
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+ desc->addrh = (u32)(addr >> 32); #endif
+
Even if the #ifdef condition here is changed to HW config check, addr and addrh
are different.
And "addrh" entry has to be present for 64 bit desc case to be handled
separately.
Can you please tell me how you propose change in DMA descriptor
structure from
4 to 2 or 2 to 4 words *after* reading the DCFG register?
It is very complex problem. I wrote to you because I faced the same issue. I'm
working on PTP implementation for macb. When PTP is enabled there are
additional two words in buffer descriptor.
Moreover, we can use PTP without the 64bits descriptor support (early GEM
revisions).
BTW, note that there is an initiative ongoing with Andrei to support
PTP/1588 on these devices with patches already send: please synchronize with
him.
https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlinux-2Dnetdev-26m-3D147282092309112-26w-3D3&d=DgIDaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=MWSZN_jP4BHjuU9UFsrndALGeJqIXzD0WtGCtCg4L5E&m=jUmZzqwn1uRrvcqF3BHCHFC6ZsKoZkU3vT8gJ-7fnsE&s=kr_km0MKQBzpkaOt0fkM-FIajN1-pOylzzTjsXi-vak&e=
or
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9310989_&d=DgID
logfs: GPF in logfs_alloc_inode
Hello, The following program triggers GPF in logfs_alloc_inode: https://gist.githubusercontent.com/dvyukov/64a2113e4cb484d9b7e0ef4ff8a522d0/raw/fffdfb8b781ec758563e08765a258da71e6ff2a1/gistfile1.txt general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 2 PID: 6602 Comm: a.out Not tainted 4.9.0-rc5+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 88003604c400 task.stack: 88003538 RIP: 0010:[] [< inline >] i_uid_write ./include/linux/fs.h:1469 RIP: 0010:[] [] logfs_init_inode.isra.5+0x155/0x480 fs/logfs/inode.c:212 RSP: 0018:880035387838 EFLAGS: 00010206 RAX: dc00 RBX: 8800640af9e0 RCX: RDX: 011b RSI: 8995e940 RDI: 08d8 RBP: 8800353878c0 R08: 04d0 R09: R10: 0006 R11: R12: 8800640afe00 R13: 110006a70f07 R14: R15: 88006b563700 FS: 01b3b940() GS:88006d00() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f8526a449de CR3: 34106000 CR4: 06e0 Stack: 41b58ab3 894c4c0b 82513fc0 aa81 819efe35 88006a63a7ff 11000d4c7500 e8c18490 0001819effad 0003 880c 0282 Call Trace: [] logfs_alloc_inode+0x35/0x40 fs/logfs/inode.c:234 [] alloc_inode+0x66/0x180 fs/inode.c:207 [] new_inode_pseudo+0x6e/0x190 fs/inode.c:889 [] new_inode+0x21/0x50 fs/inode.c:918 [] logfs_new_meta_inode+0x26/0x120 fs/logfs/inode.c:267 [] logfs_init_mapping+0x47/0x160 fs/logfs/segment.c:912 [< inline >] logfs_read_sb fs/logfs/super.c:446 [< inline >] logfs_get_sb_device fs/logfs/super.c:546 [] logfs_mount+0x690/0x1e50 fs/logfs/super.c:600 [] mount_fs+0x9c/0x2e0 fs/super.c:1177 [] vfs_kern_mount.part.22+0x6c/0x2f0 fs/namespace.c:954 [< inline >] vfs_kern_mount fs/namespace.c:2433 [< inline >] do_new_mount fs/namespace.c:2436 [] do_mount+0x41d/0x2db0 fs/namespace.c:2758 [< inline >] SYSC_mount fs/namespace.c:2974 [] SyS_mount+0xb0/0x120 fs/namespace.c:2951 [] entry_SYSCALL_64_fastpath+0x23/0xc6 arch/x86/entry/entry_64.S:209 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 13 03 00 00 4c 8b 73 28 48 b8 00 00 00 00 00 fc ff df 49 8d be d8 08 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 e3 02 00 00 48 8d 7b 04 48 b8 00 00 00 00 00 RIP [< inline >] i_uid_write ./include/linux/fs.h:1469 RIP [] logfs_init_inode.isra.5+0x155/0x480 fs/logfs/inode.c:212 RSP ---[ end trace a44003de9322a2bc ]--- LogFS: Start mount 1 == BUG: KASAN: use-after-free in __rwsem_down_write_failed_common+0xde7/0xf90 at addr 88003604c430 Read of size 4 by task a.out/6605 CPU: 1 PID: 6605 Comm: a.out Tainted: GB D 4.9.0-rc5+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 88003cf6f130 834c2a59 0001 1100079eddb9 ed00079eddb1 41b58ab3 895758d0 834c276b 894f179e 815774c0 88003cf6eff0 dc00 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:159 [< inline >] print_address_description mm/kasan/report.c:197 [< inline >] kasan_report_error mm/kasan/report.c:286 [] kasan_report+0x1eb/0x4c0 mm/kasan/report.c:306 [] __asan_report_load4_noabort+0x19/0x20 mm/kasan/report.c:331 [< inline >] rwsem_optimistic_spin kernel/locking/rwsem-xadd.c:339 [] __rwsem_down_write_failed_common+0xde7/0xf90 kernel/locking/rwsem-xadd.c:470 [] rwsem_down_write_failed+0x13/0x20 kernel/locking/rwsem-xadd.c:555 [] call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:105 [< inline >] __down_write ./arch/x86/include/asm/rwsem.h:125 [] down_write+0xac/0x120 kernel/locking/rwsem.c:54 [] grab_super+0xa8/0x290 fs/super.c:364 [] sget_userns+0x1f8/0xd40 fs/super.c:491 [] sget+0xc4/0x100 fs/super.c:548 [< inline >] logfs_get_sb_device fs/logfs/super.c:522 [] logfs_mount+0x38e/0x1e50 fs/logfs/super.c:600 [] mount_fs+0x9c/0x2e0 fs/super.c:1177 [] vfs_kern_mount.part.22+0x6c/0x2f0 fs/namespace.c:954 [< inline >] vfs_kern_mount fs/namespace.c:2433 [< inline >] do_new_mount fs/namespace.c:2436 [] do_mount+0x41d/0x2db0 fs/namespace.c:2758 [< inline >] SYSC_mount fs/namespace.c:2974 [] SyS_mount+0xb0/0x120 fs/namespace.c:2951 [] entry_SYSCALL_64_fastpath+0x23/0xc6 arch/x86/entry/entry_64.S:209 Object at 88003604c400, in cache task_struct size: 5632 Allocated: PID = 6598 [ 204.878017] [] save_stack_trace+0x1b/0x20 [ 204.878017] [] save_stack+0x43/0xd0 [ 204.878017] [] kasan_kmalloc+0xad/0xe0 [ 204.878017] [] kasan_slab_alloc+0x12/0x20 [ 204.87
Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Hi Rafal,
On Fri, Nov 18, 2016 at 2:29 PM, Rafal Ozieblo wrote:
> Hello,
>
>> From: Harini Katakam [mailto:harinikatakamli...@gmail.com]
>> Sent: 18 listopada 2016 05:30
>> To: Rafal Ozieblo
>> Cc: Nicolas Ferre; harini.kata...@xilinx.com; net...@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
>>
>> Hi Rafal,
>>
>> On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo wrote:
>> > -Original Message-
>> > From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
>> > Sent: 17 listopada 2016 14:29
>> > To: Harini Katakam; Rafal Ozieblo
>> > Cc: harini.kata...@xilinx.com; net...@vger.kernel.org;
>> > linux-kernel@vger.kernel.org
>> > Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support
>> > for GEM
>> >
>> >> Le 17/11/2016 à 13:21, Harini Katakam a écrit :
>> >> > Hi Rafal,
>> >> >
>> >> > On Thu, Nov 17, 2016 at 5:20 PM, Rafal Ozieblo
>> >> > wrote:
>> >> >> Hello,
>> >> >> I think, there could a bug in your patch.
>> >> >>
>> >> >>> +
>> >> >>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> >> >>> + dmacfg |= GEM_BIT(ADDR64); #endif
>> >> >>
>> >> >> You enable 64 bit addressing (64b dma bus width) always when
>> >> >> appropriate architecture config option is enabled.
>> >> >> But there are some legacy controllers which do not support that
>> >> >> feature. According Cadence hardware team:
>> >> >> "64 bit addressing was added in July 2013. Earlier version do not have
>> >> >> it.
>> >> >> This feature was enhanced in release August 2014 to have separate
>> >> >> upper address values for transmit and receive."
>> >> >>
>> >> >>> /* Bitfields in NSR */
>> >> >>> @@ -474,6 +479,10 @@
>> >> >>> struct macb_dma_desc {
>> >> >> > u32 addr;
>> >> >>> u32 ctrl;
>> >> >>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> >> >>> + u32 addrh;
>> >> >>> + u32 resvd;
>> >> >>> +#endif
>> >> >>> };
>> >> >>
>> >> >> It will not work for legacy hardware. Old descriptor is 2 words wide,
>> >> >> the new one is 4 words wide.
>> >> >> If you enable CONFIG_ARCH_DMA_ADDR_T_64BIT but hardware doesn't
>> >> >> support it at all, you will miss every second descriptor.
>> >> >>
>> >> >
>> >> > True, this feature is not available in all of Cadence IP versions.
>> >> > In fact, the IP version Zynq does not support this. But the one in
>> >> > ZynqMP does.
>> >> > So, we enable kernel config for 64 bit DMA addressing for this SoC
>> >> > and hence the driver picks it up. My assumption was that if the
>> >> > legacy IP does not support
>> >> > 64 bit addressing, then this DMA option wouldn't be enabled.
>> >> >
>> >> > There is a design config register in Cadence IP which is being read
>> >> > to check for 64 bit address support - DMA mask is set based on that.
>> >> > But the addition of two descriptor words cannot be based on this
>> >> > runtime check.
>> >> > For this reason, all the static changes were placed under this check.
>> >>
>> >> We have quite a bunch of options in this driver to determinate what is
>> >> the real capacity of the underlying hardware.
>> >> If HW configuration registers are not appropriate, and it seems they are
>> >> not, I would advice to simply use the DT compatibility string.
>> >>
>> >> Best regards,
>> >> --
>> >> Nicolas Ferre
>> >
>> > HW configuration registers are appropriate. The issue is that this code
>> > doesn’t use the capability bit to switch between different dma descriptors
>> > (2 words vs. 4 words).
>> > DMA descriptor size is chosen based on kernel configuration, not based on
>> > hardware capabilities.
>>
>> HW configuration register does give appropriate information.
>> But addition of two address words in the macb descriptor structure is a
>> static change.
>>
>> +static inline void macb_set_addr(struct macb_dma_desc *desc, dma_addr_t
>> +addr) {
>> + desc->addr = (u32)addr;
>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> + desc->addrh = (u32)(addr >> 32); #endif
>> +
>>
>> Even if the #ifdef condition here is changed to HW config check, addr and
>> addrh are different.
>> And "addrh" entry has to be present for 64 bit desc case to be handled
>> separately.
>> Can you please tell me how you propose change in DMA descriptor structure
>> from
>> 4 to 2 or 2 to 4 words *after* reading the DCFG register?
>
> It is very complex problem. I wrote to you because I faced the same issue.
> I'm working on PTP implementation for macb. When PTP is enabled there are
> additional two words in buffer descriptor.
> But hardware might not be compatible with PTP. Therefore I have to change DMA
> descriptor between 2 and 4 words after reading DCFG register (the same as you
> between 32b and 64b).
> When we consider both PTP and 64 bits, we end up with 4 different descriptors!
Agree
> (Below is kind of pseudo code only to show my idea. All defines like 64B or
> PTP are omitted for simplicity)
>
> 1. Prepare appropriate structures:
>
> str
Клиентские базы тел +79139230330 Соберем для Вас по интернет!
Клиентские базы тел +79139230330 Соберем для Вас по интернет!
RE: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
> >-Original Message- >From: Harini Katakam [mailto:harinikatakamli...@gmail.com] >Sent: 18 listopada 2016 10:44 >To: Rafal Ozieblo >Cc: Nicolas Ferre; Andrei Pistirica; harini.kata...@xilinx.com; >net...@vger.kernel.org; linux-kernel@vger.kernel.org > >Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM > > > >Hi Rafal, > > > >On Fri, Nov 18, 2016 at 3:00 PM, Rafal Ozieblo wrote: > >>>-Original Message- >>> >>>From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] >>> >>>Sent: 18 listopada 2016 10:10 >>> >>>To: Rafal Ozieblo; Harini Katakam; Andrei Pistirica >>> >>>Cc: harini.kata...@xilinx.com; net...@vger.kernel.org; >>> >>>linux-kernel@vger.kernel.org >>> >>>Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support >>> >>>for GEM >>> >>> >>> >>>Le 18/11/2016 à 09:59, Rafal Ozieblo a écrit : >>> Hello, > From: Harini Katakam [mailto:harinikatakamli...@gmail.com] > > Sent: 18 listopada 2016 05:30 > > To: Rafal Ozieblo > > Cc: Nicolas Ferre; harini.kata...@xilinx.com; > > net...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing > > support for GEM > > > > Hi Rafal, > > > > On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo > wrote: >> -Original Message- >> >> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] >> >> Sent: 17 listopada 2016 14:29 >> >> To: Harini Katakam; Rafal Ozieblo >> >> Cc: harini.kata...@xilinx.com; net...@vger.kernel.org; >> >> linux-kernel@vger.kernel.org >> >> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing >> >> support for GEM >> >> >> >>> Le 17/11/2016 à 13:21, Harini Katakam a écrit : >>> Hi Rafal, On Thu, Nov 17, 2016 at 5:20 PM, Rafal
Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM
Le 18/11/2016 à 10:59, Rafal Ozieblo a écrit : >> >> -Original Message- >> From: Harini Katakam [mailto:harinikatakamli...@gmail.com] >> Sent: 18 listopada 2016 10:44 >> To: Rafal Ozieblo >> Cc: Nicolas Ferre; Andrei Pistirica; harini.kata...@xilinx.com; >> net...@vger.kernel.org; linux-kernel@vger.kernel.org >> >> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for >> GEM >> >> >> Hi Rafal, >> >> >> >> On Fri, Nov 18, 2016 at 3:00 PM, Rafal Ozieblo wrote: >> -Original Message- From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] Sent: 18 listopada 2016 10:10 To: Rafal Ozieblo; Harini Katakam; Andrei Pistirica Cc: harini.kata...@xilinx.com; net...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing support for GEM Le 18/11/2016 à 09:59, Rafal Ozieblo a écrit : > Hello, > > > >> From: Harini Katakam [mailto:harinikatakamli...@gmail.com] >> >> Sent: 18 listopada 2016 05:30 >> >> To: Rafal Ozieblo >> >> Cc: Nicolas Ferre; harini.kata...@xilinx.com; >> >> net...@vger.kernel.org; linux-kernel@vger.kernel.org >> >> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing >> >> support for GEM >> >> >> >> Hi Rafal, >> >> >> >> On Thu, Nov 17, 2016 at 7:05 PM, Rafal Ozieblo >> wrote: >>> -Original Message- >>> >>> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] >>> >>> Sent: 17 listopada 2016 14:29 >>> >>> To: Harini Katakam; Rafal Ozieblo >>> >>> Cc: harini.kata...@xilinx.com; net...@vger.kernel.org; >>> >>> linux-kernel@vger.kernel.org >>> >>> Subject: Re: [RFC PATCH 2/2] net: macb: Add 64 bit addressing >>> >>> support for GEM >>> >>> >>> Le 17/11/2016 à 13:21, Harini Katakam a écrit : > Hi Rafal, >
Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Fri, Nov 18, 2016 at 04:26:34PM +0800, Boqun Feng wrote:
> On Thu, Nov 17, 2016 at 04:36:24PM +, Will Deacon wrote:
> > On Thu, Nov 17, 2016 at 05:11:10PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 17, 2016 at 12:08:36PM +, Will Deacon wrote:
> > > > All sounds reasonable to me. It's worth pointing out that you can't
> > > > create
> > > > order using a control dependency hanging off the status flag of a
> > > > store-conditional, but the code in question here has the dependency from
> > > > the loaded value, which is sufficient.
> > >
> > > Yeah, I'm always surprised by that 'feature'. Is that ARM specific? Or
> > > so more LL/SC archs have this?
> >
> > In general, I'm not sure, but I think PPC does allow for the control
> > dependency.
> >
>
> You guys mean the "control dependency" from a sc to subsequent WRITE,
> like in the following litmus?
>
> PPC sc-control
> ""
> {
> 0:r11=x;0:r12=y;0:r3=1;0:r10=0;
> 1:r11=x;1:r12=y;
> }
>
> P0 | P1 ;
> lwarx r2, r10, r11 | lwz r2, 0(r12) ;
> stwcx. r3, r10, r11 | lwsync ;
> bne Fail |;
> stw r3, 0(r12) | lwz r1, 0(r11) ;
> Fail:|;
>
> exists
> (1:r2 = 1 /\ x = 1 /\ 1:r1 = 0)
>
> PPCMEM and herd both said the exists-clause could be triggered
> "Sometimes".
>
> And ISA said:
>
> """
> Because a Store Conditional instruction may complete before its store
> has been performed, a conditional Branch instruction that depends on the
> CR0 value set by a Store Conditional instruction does not order the
> Store Conditional's store with respect to storage accesses caused by
> instructions that follow the Branch.
> """
>
> So ppc doesn't honor this "control dependency". ;-)
Oh, wow! I was feeling like the odd duck after talking to paulmck and
Alan Stern about this at LPC, but now it looks like I have company on
the island of misfit memory models.
Will
Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
On Monday, November 14, 2016 11:26:25 AM CET liviu.du...@arm.com wrote: > On Mon, Nov 14, 2016 at 08:26:42AM +, Gabriele Paoloni wrote: > > > Nope, that is not what it means. It means that PCI devices can see I/O > > > addresses > > > on the bus that start from 0. There never was any usage for non-PCI > > > controllers > > > > So I am a bit confused... > > From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps > > It seems that ISA buses operate on cpu I/O address range [0, 0xFFF]. > > I thought that was the reason why for most architectures we have > > PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers > > usually use [0, PCIBIOS_MIN_IO - 1] ) > > First of all, cpu I/O addresses is an x86-ism. ARM architectures and others > have no separate address space for I/O, it is all merged into one unified > address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean > that we don't care about ISA I/O because the platform does not support having > an ISA bus (e.g.). I think to be more specific, PCIBIOS_MIN_IO=0 would indicate that you cannot have a PCI-to-ISA or PCI-to-LPC bridge in any PCI domain. This is different from having an LPC master outside of PCI, as that lives in its own domain and has a separately addressable I/O space. > > As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO) > > to allow special ISA controllers to use that range with special > > accessors. > > Having a variable threshold would make life much more difficult > > as there would be a probe dependency between the PCI controller and > > the special ISA one (PCI to wait for the special ISA device to be > > probed and set the right threshold value from DT or ACPI table). > > > > Instead using PCIBIOS_MIN_IO is easier and should not impose much > > constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to > > the PCI controller for I/O tokens... > > What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves > space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve > space for your direct address I/O on top of PCIBIOS_MIN_IO. The PCIBIOS_MIN_DIRECT_IO name still suggests having something related to PCIBIOS_MIN_IO, but it really isn't. We are talking about multiple concepts here that are not the same but that are somewhat related: a) keeping PCI devices from allocating low I/O ports on the PCI bus that would conflict with ISA devices behind a bridge of the same bus. b) reserving the low 0x0-0xfff range of the Linux-internal I/O space abstraction to a particular LPC or PCI domain to make legacy device drivers work that hardcode a particular port number. c) Redirecting inb/outb to call a domain-specific accessor function rather than doing the normal MMIO window for an LPC master or more generally any arbitrary LPC or PCI domain that has a nonstandard I/O space. [side note: actually if we generalized this, we could avoid assigning an MMIO range for the I/O space on the pci-mvebu driver, and that would help free up some other remapping windows] I think there is no need to change a) here, we have PCIBIOS_MIN_IO today and even if we don't need it, there is no obvious downside. I would also argue that we can ignore b) for the discussion of the HiSilicon LPC driver, we just need to assign some range of logical addresses to each domain. That means solving c) is the important problem here, and it shouldn't be so hard. We can do this either with a single special domain as in the v5 patch series, or by generalizing it so that any I/O space mapping gets looked up through the device pointer of the bus master. Arnd
mm: BUG in pgtable_pmd_page_dtor
Hello, I've got the following BUG while running syzkaller on a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (4.9-rc5). Unfortunately it's not reproducible. kernel BUG at ./include/linux/mm.h:1743! invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 3 PID: 4049 Comm: syz-fuzzer Not tainted 4.9.0-rc5+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 88006ad028c0 task.stack: 8800667e RIP: 0010:[] [< inline >] pgtable_pmd_page_dtor include/linux/mm.h:1743 RIP: 0010:[] [] ___pmd_free_tlb+0x3db/0x5a0 arch/x86/mm/pgtable.c:74 RSP: 0018:8800667e6908 EFLAGS: 00010292 RAX: RBX: 11000ccfcd25 RCX: RDX: RSI: 0001 RDI: ed000ccfcd10 RBP: 8800667e6a70 R08: 0001 R09: R10: dc00 R11: 0001 R12: 8800667e6ef8 R13: 8800667e6a48 R14: eae196c0 R15: 0003865b FS: 7f152a530700() GS:88006d10() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f1514bff9d0 CR3: 09821000 CR4: 06e0 DR0: 0400 DR1: 0400 DR2: DR3: DR6: 0ff0 DR7: 0600 Stack: 88006ad030e0 88006ad030b8 dc00 41b58ab3 894db568 8130ded0 8156b2a0 0082 88006ad030e0 11000ccfcd30 11000ccfcd38 Call Trace: [< inline >] __pmd_free_tlb arch/x86/include/asm/pgalloc.h:110 [< inline >] free_pmd_range mm/memory.c:443 [< inline >] free_pud_range mm/memory.c:461 [] free_pgd_range+0xb98/0x1270 mm/memory.c:537 [] free_pgtables+0x275/0x340 mm/memory.c:569 [] exit_mmap+0x281/0x4e0 mm/mmap.c:2942 [< inline >] __mmput kernel/fork.c:866 [] mmput+0x20e/0x4c0 kernel/fork.c:888 [< inline >] exit_mm kernel/exit.c:512 [] do_exit+0x960/0x2640 kernel/exit.c:815 [] do_group_exit+0x14e/0x420 kernel/exit.c:931 [] get_signal+0x663/0x1880 kernel/signal.c:2307 [] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807 [] exit_to_usermode_loop+0x1ea/0x2d0 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [] syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259 [] entry_SYSCALL_64_fastpath+0xc4/0xc6 Code: 10 00 00 4c 89 e7 e8 25 6c 63 00 e9 9b fd ff ff e8 0b 9e 3d 00 0f 0b e8 04 9e 3d 00 48 c7 c6 00 ac 27 88 4c 89 f7 e8 85 9e 62 00 <0f> 0b e8 9e 2d 6e 00 e9 1a fe ff ff 48 89 cf 48 89 8d b0 fe ff RIP [< inline >] pgtable_pmd_page_dtor include/linux/mm.h:1743 RIP [] ___pmd_free_tlb+0x3db/0x5a0 arch/x86/mm/pgtable.c:74 RSP ---[ end trace 4ef4b70d88f62f8a ]---
kvm: slab-out-of-bounds write in __apic_accept_irq
Hello, The following program triggers slab-out-of-bounds write in __apic_accept_irq: https://gist.githubusercontent.com/dvyukov/6ef34f4a775091d664e18308aa0d5fa6/raw/bf12c7261fbb20cb0ff4318316f0fae7bd948eff/gistfile1.txt On commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6 (4.9-rc5) == BUG: KASAN: slab-out-of-bounds in __apic_accept_irq+0xb33/0xb50 at addr 880035d4918f Write of size 1 by task a.out/27101 CPU: 1 PID: 27101 Comm: a.out Not tainted 4.9.0-rc5+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 880035c16ff0 834c2a59 0001 110006b82d91 ed0006b82d89 41b58ab3 895758d0 834c276b 41b58ab3 0002 110006b82d95 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:159 [< inline >] print_address_description mm/kasan/report.c:197 [< inline >] kasan_report_error mm/kasan/report.c:286 [] kasan_report+0x1eb/0x4c0 mm/kasan/report.c:306 [] __asan_report_store1_noabort+0x1c/0x20 mm/kasan/report.c:334 [] __apic_accept_irq+0xb33/0xb50 arch/x86/kvm/lapic.c:905 [] kvm_apic_set_irq+0x10e/0x180 arch/x86/kvm/lapic.c:495 [] kvm_irq_delivery_to_apic+0x732/0xc10 arch/x86/kvm/irq_comm.c:86 [] ioapic_service+0x41d/0x760 arch/x86/kvm/ioapic.c:360 [] ioapic_set_irq+0x275/0x6c0 arch/x86/kvm/ioapic.c:222 [< inline >] kvm_ioapic_inject_all arch/x86/kvm/ioapic.c:235 [] kvm_set_ioapic+0x223/0x310 arch/x86/kvm/ioapic.c:670 [< inline >] kvm_vm_ioctl_set_irqchip arch/x86/kvm/x86.c:3668 [] kvm_arch_vm_ioctl+0x1a08/0x23c0 arch/x86/kvm/x86.c:3999 [] kvm_vm_ioctl+0x1fa/0x1a70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3099 [< inline >] vfs_ioctl fs/ioctl.c:43 [] do_vfs_ioctl+0x1c4/0x1630 fs/ioctl.c:679 [< inline >] SYSC_ioctl fs/ioctl.c:694 [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:685 [] entry_SYSCALL_64_fastpath+0x23/0xc6 arch/x86/entry/entry_64.S:209 Object at 880035d48bc0, in cache kmalloc-2048 size: 2048 Allocated: PID = 27101 [ 291.279030] [] save_stack_trace+0x1b/0x20 [ 291.279030] [] save_stack+0x43/0xd0 [ 291.279030] [] kasan_kmalloc+0xad/0xe0 [ 291.279030] [] kmem_cache_alloc_trace+0x12c/0x710 [ 291.279030] [] kvm_ioapic_init+0xa0/0x680 [ 291.279030] [] kvm_arch_vm_ioctl+0x11d7/0x23c0 [ 291.279030] [] kvm_vm_ioctl+0x1fa/0x1a70 [ 291.279030] [] do_vfs_ioctl+0x1c4/0x1630 [ 291.279030] [] SyS_ioctl+0x94/0xc0 [ 291.279030] [] entry_SYSCALL_64_fastpath+0x23/0xc6 Memory state around the buggy address: 880035d49080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880035d49100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >880035d49180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 880035d49200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880035d49280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc == Disabling lock debugging due to kernel taint Disabled LAPIC found during irq injection
Re: [Ksummit-discuss] Including images on Sphinx documents
On Fri, Nov 18, 2016 at 11:15:09AM +0200, Jani Nikula wrote:
> On Thu, 17 Nov 2016, Linus Torvalds wrote:
> > We have makefiles, but more importantly, few enough people actually
> > *generate* the documentation, that I think if it's an option to just
> > fix sphinx, we should do that instead. If it means that you have to
> > have some development version of sphinx, so be it. Most people read
> > the documentation either directly in the unprocessed text-files
> > ("source code") or on the web (by searching for pre-formatted docs)
> > that I really don't think we need to worry too much about the
> > toolchain.
>
> My secret plan was to make building documentation easy, and then trick
> more people into actually doing that on a regular basis, to ensure we
> keep the build working and the output sensible in a variety of
> environments. Sure we have a bunch of people doing this, and we have
> 0day doing this, but I'd hate it if it became laborous and fiddly to set
> up the toolchain to generate documentation.
>
> So I'm not necessarily disagreeing with anything you say, but I think
> there's value in having a low bar for entry (from the toolchain POV) for
> people interested in working with documentation, whether they're
> seasoned kernel developers or newcomers purely interested in
> documentation.
Yeah, I want a low bar for doc building too. The initial hack fest we had
to add cross-linking and other dearly needed stuff increased the build
time so much that everyone stopped creating docs. It's of course not as
extreme, but stating that "no one runs the doc toolchain" is imo akin to
"no one runs gcc, developers just read the source and users install rpms".
It's totally true, until you try to change stuff, then you have to be able
to build that pile fast and with an easily-obtained toolchain.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCHv2 5/6] arm64: Use __pa_symbol for _end
On 16 November 2016 at 17:32, Catalin Marinas wrote:
> On Tue, Nov 15, 2016 at 04:09:07PM -0800, Laura Abbott wrote:
>> On 11/15/2016 10:35 AM, Catalin Marinas wrote:
>> > I'm fine with __pa_symbol use entirely from under arch/arm64. But if you
>> > want to use __pa_symbol, I tried to change most (all?) places where
>> > necessary, together with making virt_to_phys() only deal with the kernel
>> > linear mapping. Not sure it looks cleaner, especially the
>> > __va(__pa_symbol()) cases (we could replace the latter with another
>> > macro and proper comment):
>>
>> I agree everything should be converted over, I was considering doing
>> that in a separate patch but this covers everything nicely. Are you
>> okay with me folding this in? (Few comments below)
>
> Yes. I would also like Ard to review it since he introduced the current
> __virt_to_phys() macro.
>
I think this is a clear improvement. I didn't dare to propose it at
the time, due to the fallout, but it is obviously much better to have
separate accessors than to have runtime tests to decide something that
is already known at compile time. My only concern is potential uses in
generic code: I think there may be something in the handling of
initramfs, or freeing the __init segment (I know it had 'init' in the
name :-)) that refers to the physical address of symbols, but I don't
remember exactly what it is.
Did you test it with a initramfs?
>> > diff --git a/arch/arm64/include/asm/memory.h
>> > b/arch/arm64/include/asm/memory.h
>> > index eac3dbb7e313..e02f45e5ee1b 100644
>> > --- a/arch/arm64/include/asm/memory.h
>> > +++ b/arch/arm64/include/asm/memory.h
>> > @@ -169,15 +169,22 @@ extern u64kimage_voffset;
>> > */
>> > #define __virt_to_phys_nodebug(x) ({
>> > \
>> > phys_addr_t __x = (phys_addr_t)(x); \
>> > - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
>> > -(__x - kimage_voffset); })
>> > + VM_BUG_ON(!(__x & BIT(VA_BITS - 1))); \
>> > + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
>> > +})
>>
>> I do think this is easier to understand vs the ternary operator.
>> I'll add a comment detailing the use of __pa vs __pa_symbol somewhere
>> as well.
>
> Of course, a comment is welcome (I just did a quick hack to check that
> it works).
>
>> > --- a/arch/arm64/include/asm/mmu_context.h
>> > +++ b/arch/arm64/include/asm/mmu_context.h
>> > @@ -44,7 +44,7 @@ static inline void contextidr_thread_switch(struct
>> > task_struct *next)
>> > */
>> > static inline void cpu_set_reserved_ttbr0(void)
>> > {
>> > - unsigned long ttbr = virt_to_phys(empty_zero_page);
>> > + unsigned long ttbr = __pa_symbol(empty_zero_page);
>> >
>> > write_sysreg(ttbr, ttbr0_el1);
>> > isb();
>> > @@ -113,7 +113,7 @@ static inline void cpu_install_idmap(void)
>> > local_flush_tlb_all();
>> > cpu_set_idmap_tcr_t0sz();
>> >
>> > - cpu_switch_mm(idmap_pg_dir, &init_mm);
>> > + cpu_switch_mm(__va(__pa_symbol(idmap_pg_dir)), &init_mm);
>>
>> Yes, the __va(__pa_symbol(..)) idiom needs to be macroized and commented...
>
> Indeed. At the same time we should also replace the LMADDR macro in
> hibernate.c with whatever you come up with.
>
>> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
>> > index d55a7b09959b..81c03c74e5fe 100644
>> > --- a/arch/arm64/kernel/hibernate.c
>> > +++ b/arch/arm64/kernel/hibernate.c
>> > @@ -51,7 +51,7 @@
>> > extern int in_suspend;
>> >
>> > /* Find a symbols alias in the linear map */
>> > -#define LMADDR(x) phys_to_virt(virt_to_phys(x))
>> > +#define LMADDR(x) __va(__pa_symbol(x))
>>
>> ...Perhaps just borrowing this macro?
>
> Yes but I don't particularly like the name, especially since it goes
> into a .h file. Maybe __lm_sym_addr() or something else if you have a
> better idea.
>
>> > diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>> > index 874c78201a2b..98dae943e496 100644
>> > --- a/arch/arm64/mm/physaddr.c
>> > +++ b/arch/arm64/mm/physaddr.c
>> > @@ -14,8 +14,8 @@ unsigned long __virt_to_phys(unsigned long x)
>> > */
>> > return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>> > } else {
>> > - VIRTUAL_BUG_ON(x < kimage_vaddr || x >= (unsigned long)_end);
>> > - return (__x - kimage_voffset);
>> > + WARN_ON(1);
>>
>> Was the deletion of the BUG_ON here intentional? VIRTUAL_BUG_ON
>> is the check enabled by CONFIG_DEBUG_VIRTUAL vs just CONFIG_DEBUG_VM.
>> I intentionally kept CONFIG_DEBUG_VIRTUAL separate since the checks
>> are expensive.
>
> I wanted to always get a warning but fall back to __phys_addr_symbol()
> so that I can track down other uses of __virt_to_phys() on kernel
> symbols without killing the kernel. A better option would have been
> VIRTUAL_WARN_ON (or *_ONCE) but we don't have it. VM_WARN_ON, as you
> said, is indep
