Re: [PATCH] UBI: rename free variable

[Heiko Schocher]

Hello Al,

Am 09.10.2015 um 07:39 schrieb Al Viro:

On Fri, Oct 09, 2015 at 06:39:52AM +0200, Heiko Schocher wrote:

Hello Al,
Sorry, I should have added this info immediately into the patch ...

We have in U-Boot a compat.h file, in which we collect all things
we need to make linux code running under U-Boot, and there we map
kfree() to free(), see:

http://git.denx.de/?p=u-boot.git;a=blob;f=include/linux/compat.h;h=fbebf910addd994d265d21c4fbaa0a2f48f4ccb1;hb=996ec1dcc58a34b53891acde0ec5df9141b5fcc2#l58

So, if we use a var name "free", this will conflict ... and I get
for example when compiling the UBI code:

   CC  drivers/mtd/ubi/fastmap.o
drivers/mtd/ubi/fastmap.c: In function 'scan_pool':
drivers/mtd/ubi/fastmap.c:475:3: error: called object 'free' is not a function

So with this patch, we have less differences to kernel files ...


Umm... wouldn't it be easier to replace that mix of #define and static inline
with uniform use of static inline, rather than playing whack-a-mole like
that?


Yes, fully correct, thanks for helping.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 17/38] perf tools: Maintain map groups list in a leader thread

[Namhyung Kim]

On Thu, Oct 08, 2015 at 02:51:43PM +0200, Jiri Olsa wrote:
> On Fri, Oct 02, 2015 at 02:18:58PM +0900, Namhyung Kim wrote:
> 
> SNIP
> 
> > +static int thread__clone_map_groups(struct thread *thread,
> > +   struct thread *parent);
> > +
> >  int __thread__set_comm(struct thread *thread, const char *str, u64 
> > timestamp,
> >bool exec)
> >  {
> > @@ -182,6 +257,40 @@ int __thread__set_comm(struct thread *thread, const 
> > char *str, u64 timestamp,
> > unwind__flush_access(thread);
> > }
> >  
> > +   if (exec) {
> > +   struct machine *machine;
> > +
> > +   BUG_ON(thread->mg == NULL || thread->mg->machine == NULL);
> > +
> > +   machine = thread->mg->machine;
> > +
> > +   if (thread->tid != thread->pid_) {
> > +   struct map_groups *old = thread->mg;
> > +   struct thread *leader;
> > +
> > +   leader = machine__findnew_thread(machine, thread->pid_,
> > +thread->pid_);
> > +
> > +   /* now it'll be a new leader */
> > +   thread->pid_ = thread->tid;
> > +
> > +   thread->mg = map_groups__new(old->machine);
> > +   if (thread->mg == NULL)
> > +   return -ENOMEM;
> 
> hum, isn't this leaking thread->mg ?
> should we call map_groups__put(old) at the end of block?

You're right!  Will fix.

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

linux-next: Tree for Oct 9

[Stephen Rothwell]

Hi all,

Changes since 20151008:

My fixes tree contains:
"perf tools: Fix build break on powerpc due to sample_reg_masks"
"word-at-a-time.h: powerpc: implement define zero_bytemask"

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto linux-next again :-(

The battery tree still had its build failure so I used the version from
next-20150925.

The tip tree gained a conflict against the crypto-current tree.

The chrome-platform tree lost its build failure.

Non-merge commits (relative to Linus' tree): 5944
 4803 files changed, 250566 insertions(+), 101520 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (c6fa8e6de3dc Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (61196131f628 perf tools: Fix build break on powerpc due 
to sample_reg_masks)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (868e87ccda24 ARM: make RiscPC depend on MMU)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs 
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (4108efb02daa cxl: Fix number of allocated pages in 
SPA)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (85121d6ee697 net/mlx4: Remove shared_ports variable at 
mlx4_enable_msi_x)
Merging ipsec/master (4e077237cfb6 xfrm: Fix state threshold configuration from 
userspace)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for 
nf_dup_ipv{4,6})
Merging sound-current/for-linus (601d62959d08 Merge tag 'asoc-fix-v4.3-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access 
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag 
'iwlwifi-for-kalle-2015-10-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (0c5562716787 drivers/tty: require read access 
for controlling terminal)
Merging usb.current/usb-linus (72194739f546 usb: Add device quirk for Logitech 
PTZ cameras)
Merging usb-gadget-fixes/fixes (f5f6afa85aa8 usb: renesas_usbhs: Add support 
for R-Car H3)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (b1d562acc78f staging: speakup: fix 
speakup-r regression)
Merging char-misc.current/char-misc-linus (41ada9df7f34 mcb: Fix error handling 
in mcb_pci_probe())
Merging input-current/for-linus (879f2fea8a5a Input: ads7846 - correct the 
value got from SPI)
Merging crypto-current/master (92b279070dd6 crypto: camellia_aesni_avx - Fix 
CPU feature checks)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes 

Re: [RFC/PATCH 15/38] perf tools: Introduce machine__find*_thread_by_time()

[Namhyung Kim]

On Thu, Oct 08, 2015 at 02:20:11PM +0200, Jiri Olsa wrote:
> On Fri, Oct 02, 2015 at 02:18:56PM +0900, Namhyung Kim wrote:
> 
> SNIP
> 
> > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> > index 674792e8fa2f..ad7c2a00bff8 100644
> > --- a/tools/perf/util/thread.c
> > +++ b/tools/perf/util/thread.c
> > @@ -160,6 +160,9 @@ int __thread__set_comm(struct thread *thread, const 
> > char *str, u64 timestamp,
> >  
> > /* Override the default :tid entry */
> > if (!thread->comm_set) {
> > +   if (!thread->start_time)
> > +   thread->start_time = timestamp;
> > +
> > err = comm__override(curr, str, timestamp, exec);
> > if (err)
> > return err;
> > @@ -266,6 +269,7 @@ int thread__fork(struct thread *thread, struct thread 
> > *parent, u64 timestamp)
> > }
> >  
> > thread->ppid = parent->tid;
> > +   thread->start_time = timestamp;
> > return thread__clone_map_groups(thread, parent);
> >  }
> >  
> > diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
> > index b8f794d97b75..97026a9660ec 100644
> > --- a/tools/perf/util/thread.h
> > +++ b/tools/perf/util/thread.h
> > @@ -28,6 +28,7 @@ struct thread {
> > booldead; /* thread is in dead_threads list */
> > struct list_headcomm_list;
> > u64 db_id;
> > +   u64 start_time;
> 
> introducing start_time could be in separate patch
> would ease up the review a bit

Will split.

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

Re: [RFC/PATCH 02/38] perf tools: Save mmap_param.len instead of mask

[Namhyung Kim]

Hi Jiri,

On Thu, Oct 08, 2015 at 12:17:11PM +0200, Jiri Olsa wrote:
> On Fri, Oct 02, 2015 at 02:18:43PM +0900, Namhyung Kim wrote:
> > It is more convenient saving mmap length rather than (bit) mask.  With
> > this patch, we can eliminate dependency to perf_evlist other than
> > getting mmap_desc for dealing with mmaps.  The mask and length can be
> > converted using perf_evlist__mmap_mask/len().
> > 
> > Cc: Jiri Olsa 
> > Cc: Adrian Hunter 
> > Signed-off-by: Namhyung Kim 
> 
> after this patch I'm hitting:
> 
> [jolsa@krava perf]$ ./perf record  kill
> kill: not enough arguments
> perf: util/evlist.c:1003: perf_evlist__mmap_len: Assertion `!((mask & 
> page_size) != 0)' failed.
> Aborted (core dumped)
> [jolsa@krava perf]$ 

This is strange..  I think I fixed it already.  And the expression in
the assertion is different than the code in the patch:

  static size_t perf_evlist__mmap_len(size_t mask)
  {
 BUG_ON(((mask + 1) % page_size) != 0);
  
 return mask + 1 + page_size;
  }

Could you please double check?

Thanks,
Namhyung


> 
> 
> jirka
> 
> > ---
> >  tools/perf/util/evlist.c | 31 +--
> >  1 file changed, 25 insertions(+), 6 deletions(-)
> > 
> > diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> > index c5180a29db1b..e46adcd5b408 100644
> > --- a/tools/perf/util/evlist.c
> > +++ b/tools/perf/util/evlist.c
> > @@ -29,6 +29,8 @@
> >  
> >  static void perf_evlist__mmap_put(struct perf_evlist *evlist, int idx);
> >  static void __perf_evlist__munmap(struct perf_evlist *evlist, int idx);
> > +static size_t perf_evlist__mmap_mask(size_t len);
> > +static size_t perf_evlist__mmap_len(size_t mask);
> >  
> >  #define FD(e, x, y) (*(int *)xyarray__entry(e->fd, x, y))
> >  #define SID(e, x, y) xyarray__entry(e->sample_id, x, y)
> > @@ -871,7 +873,9 @@ void __weak auxtrace_mmap_params__set_idx(
> >  static void __perf_evlist__munmap(struct perf_evlist *evlist, int idx)
> >  {
> > if (evlist->mmap[idx].base != NULL) {
> > -   munmap(evlist->mmap[idx].base, evlist->mmap_len);
> > +   size_t mmap_len = perf_evlist__mmap_len(evlist->mmap[idx].mask);
> > +
> > +   munmap(evlist->mmap[idx].base, mmap_len);
> > evlist->mmap[idx].base = NULL;
> > atomic_set(>mmap[idx].refcnt, 0);
> > }
> > @@ -901,8 +905,8 @@ static int perf_evlist__alloc_mmap(struct perf_evlist 
> > *evlist)
> >  }
> >  
> >  struct mmap_params {
> > -   int prot;
> > -   int mask;
> > +   int prot;
> > +   size_t  len;
> > struct auxtrace_mmap_params auxtrace_mp;
> >  };
> >  
> > @@ -924,8 +928,8 @@ static int __perf_evlist__mmap(struct perf_evlist 
> > *evlist, int idx,
> >  */
> > atomic_set(>mmap[idx].refcnt, 2);
> > evlist->mmap[idx].prev = 0;
> > -   evlist->mmap[idx].mask = mp->mask;
> > -   evlist->mmap[idx].base = mmap(NULL, evlist->mmap_len, mp->prot,
> > +   evlist->mmap[idx].mask = perf_evlist__mmap_mask(mp->len);
> > +   evlist->mmap[idx].base = mmap(NULL, mp->len, mp->prot,
> >   MAP_SHARED, fd, 0);
> > if (evlist->mmap[idx].base == MAP_FAILED) {
> > pr_debug2("failed to mmap perf event ring buffer, error %d\n",
> > @@ -1071,6 +1075,21 @@ static size_t perf_evlist__mmap_size(unsigned long 
> > pages)
> > return (pages + 1) * page_size;
> >  }
> >  
> > +static size_t perf_evlist__mmap_mask(size_t len)
> > +{
> > +   BUG_ON(len <= page_size);
> > +   BUG_ON((len % page_size) != 0);
> > +
> > +   return len - page_size - 1;
> > +}
> > +
> > +static size_t perf_evlist__mmap_len(size_t mask)
> > +{
> > +   BUG_ON(((mask + 1) % page_size) != 0);
> > +
> > +   return mask + 1 + page_size;
> > +}
> > +
> >  static long parse_pages_arg(const char *str, unsigned long min,
> > unsigned long max)
> >  {
> > @@ -1176,7 +1195,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist, 
> > unsigned int pages,
> > evlist->overwrite = overwrite;
> > evlist->mmap_len = perf_evlist__mmap_size(pages);
> > pr_debug("mmap size %zuB\n", evlist->mmap_len);
> > -   mp.mask = evlist->mmap_len - page_size - 1;
> > +   mp.len = evlist->mmap_len;
> >  
> > auxtrace_mmap_params__init(_mp, evlist->mmap_len,
> >auxtrace_pages, auxtrace_overwrite);
> > -- 
> > 2.6.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts

[Jesper Nilsson]

Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
as well as absolute timeout.

Signed-off-by: Jesper Nilsson 
---
Resending after some discussion with Thomas Gleixner at ELCE,
and Cc:ing John Stultz and Michael Kerrisk who may have comments.

Longer background:

One of the uses for TFD_TIMER_CANCEL_ON_SET is to get
an event when the CLOCK_REALTIME changes (as by NTP or user action).
In this case, the timeout irrelevant, and the maximum
available value would be selected to avoid mis-triggers.

However, timerfd uses time_t for configuration, and the maximum
value on a 32bit time_t system is actually a valid time
(near 2038-01-19 03:14) in the 64bit ktime_t used internally in timerfd.

One way of provoking this problem would be to set the time
using "date '2038-01-19 03:14'" and letting the time roll over
a few seconds later.

After this time, a timerfd will continuously fire
when configured with a maximum absolute timeout,
potentially stealing all CPU and stopping the application
from doing what it really should be doing.
Which would be fine, unless the application is systemd
and loops at startup, leaving the system in a state where
the kernel is up, but nothing running in userspace. :-(

This problem was further exposed in kernel v3.19 by
commit a6d6e1c879efa4b77e250c34fe5fe1c34e6ef070
which introduced 64bit time in the RTC subsystem.
On an unconfigured RTC or an RTC with flat/removed battery
the date on could be random, and in some cases past 2038.

Of course, the proposed patch only allows the setting of relative
timeouts with TFD_TIMER_CANCEL_ON_SET, any application using
it would also need to be patched to use the relative timer
for this solve the described problem.

Another solution would be to add a new flag to timerfd_settime()
to indicate that the timer value is irrelevant, but I considered
it an unnecessary waste of a flag-bit.

A third possible solution is to steal the time (0,0)
(which currently gives -EINVAL) to indicate that the timeout
is irrelevant. This would however be a change in behaviour
that a current user wouldn't expect, perhaps making a previously
correctly failing application wait until a time change (or forever)

Tested on a MIPS 34Kc with kernel v4.1.

 fs/timerfd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/timerfd.c b/fs/timerfd.c
index b94fa6c..8ec3aeb 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -134,7 +134,7 @@ static void timerfd_setup_cancel(struct timerfd_ctx *ctx, 
int flags)
 {
if ((ctx->clockid == CLOCK_REALTIME ||
 ctx->clockid == CLOCK_REALTIME_ALARM) &&
-   (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
+   (flags & TFD_TIMER_CANCEL_ON_SET)) {
if (!ctx->might_cancel) {
ctx->might_cancel = true;
spin_lock(_lock);
-- 
1.7.10.4


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

RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

[Zheng, Lv]

Hi, Yu

> From: Chen, Yu C
> Sent: Friday, October 09, 2015 4:20 PM
> 
> For ACPI compatible system, SCI(ACPI System Control
> Interrupt) is used to wake system up from suspend-to-idle.
> Once CPU is woken up by SCI, interrupt handler will
> firstly checks if current interrupt is legal to wake up
> the whole system, thus irq_pm_check_wakeup is invoked
> to validate the irq number. However, before suspend-to-idle,
> acpi_gbl_FADT.sci_interrupt is marked rather than actual
> irq number in acpi_freeze_prepare, this might lead to unable
> to wake up the system.
> 
> This patch fixes this problem by marking the irq number
> return by acpi_gsi_to_irq as IRQD_WAKEUP_STATE, rather than
> marking the acpi_gbl_FADT.sci_interrupt. Meanwhile this patch
> fixes the same problems inside acpi_os_remove_interrupt_handler
> and acpi_os_wait_events_complete respectively.
> 
> Signed-off-by: Chen Yu 
> ---
> v3:
>  - 1.Rename acpi_inuse_irq to acpi_sci_irq for better understanding.
>2.If the irq handler is not registered, skip the synchronize_hardirq
>  in acpi_os_wait_events_complete and return immediately in
>  acpi_os_remove_interrupt_handler.
>3.For acpi_freeze_prepare and acpi_freeze_restore, if the acpi irq
>  handler is not properly registered, we do not leverage acpi irq
>  to wake up the system, but expect other peripherals(such as PCI devices
>  and USB devices)to invoke enable_irq_wake for us.
> v2:
>  - 1.Define a global acpi_inuse_irq variable, store irq in it
>  and access it directly from acpi_freeze_prepare(), and it
>  doesn't have to depend on CONFIG_SUSPEND as it is just the
>  IRQ number actually used by ACPI.
>2.Also fix the same problems inside acpi_os_remove_interrupt_handler,
>  acpi_os_wait_events_complete.
> ---
>  drivers/acpi/osl.c   | 12 
>  drivers/acpi/sleep.c |  6 --
>  include/linux/acpi.h |  3 +++
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 739a4a6..8e1a5d3 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -81,6 +81,7 @@ static struct workqueue_struct *kacpid_wq;
>  static struct workqueue_struct *kacpi_notify_wq;
>  static struct workqueue_struct *kacpi_hotplug_wq;
>  static bool acpi_os_initialized;
> +unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
> 
>  /*
>   * This list of permanent mappings is for memory that may be accessed from
> @@ -856,17 +857,20 @@ acpi_os_install_interrupt_handler(u32 gsi, 
> acpi_osd_handler handler,
>   acpi_irq_handler = NULL;
>   return AE_NOT_ACQUIRED;
>   }
> + acpi_sci_irq = irq;
> 
>   return AE_OK;
>  }
> 
>  acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler 
> handler)

Why don't you rename irq here to gsi to improve the readability?
The false naming and the wrong example written for this function are probably 
the root causes of all other bad code.
So if we want to stop people making future mistakes, we need to cleanup 
ourselves.

Thanks and best regards
-Lv

>  {
> - if (irq != acpi_gbl_FADT.sci_interrupt)
> + if ((irq != acpi_gbl_FADT.sci_interrupt) ||
> + IS_INVALID_ACPI_IRQ(acpi_sci_irq))
>   return AE_BAD_PARAMETER;
> 
> - free_irq(irq, acpi_irq);
> + free_irq(acpi_sci_irq, acpi_irq);
>   acpi_irq_handler = NULL;
> + acpi_sci_irq = INVALID_ACPI_IRQ;
> 
>   return AE_OK;
>  }
> @@ -1180,8 +1184,8 @@ void acpi_os_wait_events_complete(void)
>* Make sure the GPE handler or the fixed event handler is not used
>* on another CPU after removal.
>*/
> - if (acpi_irq_handler)
> - synchronize_hardirq(acpi_gbl_FADT.sci_interrupt);
> + if (!IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> + synchronize_hardirq(acpi_sci_irq);
>   flush_workqueue(kacpid_wq);
>   flush_workqueue(kacpi_notify_wq);
>  }
> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> index 2f0d4db..1704595 100644
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -632,14 +632,16 @@ static int acpi_freeze_prepare(void)
>   acpi_enable_wakeup_devices(ACPI_STATE_S0);
>   acpi_enable_all_wakeup_gpes();
>   acpi_os_wait_events_complete();
> - enable_irq_wake(acpi_gbl_FADT.sci_interrupt);
> + if (!IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> + enable_irq_wake(acpi_sci_irq);
>   return 0;
>  }
> 
>  static void acpi_freeze_restore(void)
>  {
>   acpi_disable_wakeup_devices(ACPI_STATE_S0);
> - disable_irq_wake(acpi_gbl_FADT.sci_interrupt);
> + if (!IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> + disable_irq_wake(acpi_sci_irq);
>   acpi_enable_all_runtime_gpes();
>  }
> 
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 43856d1..2f05dc0 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -193,6 +193,9 @@ int acpi_ioapic_registered(acpi_handle handle, u32 
> 

Re: [PATCH 2/4] i2c: rcar: enable RuntimePM before registering to the core

[Geert Uytterhoeven]

Hi Wolfram,

On Fri, Oct 9, 2015 at 8:54 AM, Wolfram Sang  wrote:
> The core may register clients attached to this master which may use
> funtionality from the master. So, RuntimePM must be enabled before, otherwise
> this will fail. While here, move drvdata, too.

Thanks for your patch!

> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/i2c/busses/i2c-rcar.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index d8361dada58455..3d7536d78cb366 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -690,15 +690,15 @@ static int rcar_i2c_probe(struct platform_device *pdev)
> return ret;
> }
>
> +   pm_runtime_enable(dev);
> +   platform_set_drvdata(pdev, priv);
> +
> ret = i2c_add_numbered_adapter(adap);
> if (ret < 0) {
> dev_err(dev, "reg adap failed: %d\n", ret);

You forgot to call pm_runtime_disable() in the error path.
I think some of your other patches suffer from the same issue.

> return ret;
> }

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ath6kl: remove redundant null pointer check on send_pkt

[Kalle Valo]

Colin King  writes:

> From: Colin Ian King 
>
> The check for send_pkt being NULL is redundant before the call
> to htc_reclaim_txctrl_buf, therefore it should be removed. This was
> detected by static analysis by cppcheck.
>
> Signed-off-by: Colin Ian King 

Applied, thanks.

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

[PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv

[wangxfdu]

From: Xiang Wang 

1. Support setting hs_hcnt and hs_lcnt
2. Get bus speed mode from ACPI companion of the
i2c controller.

Signed-off-by: Xiang Wang 
---
 drivers/i2c/busses/i2c-designware-pcidrv.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 6643d2d..0f4c0c4 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -54,8 +54,10 @@ enum dw_pci_ctl_id_t {
 struct dw_scl_sda_cfg {
u32 ss_hcnt;
u32 fs_hcnt;
+   u32 hs_hcnt;
u32 ss_lcnt;
u32 fs_lcnt;
+   u32 hs_lcnt;
u32 sda_hold;
 };
 
@@ -237,8 +239,10 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
cfg = controller->scl_sda_cfg;
dev->ss_hcnt = cfg->ss_hcnt;
dev->fs_hcnt = cfg->fs_hcnt;
+   dev->hs_hcnt = cfg->hs_hcnt;
dev->ss_lcnt = cfg->ss_lcnt;
dev->fs_lcnt = cfg->fs_lcnt;
+   dev->hs_lcnt = cfg->hs_lcnt;
dev->sda_hold_time = cfg->sda_hold;
}
 
@@ -246,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
 
dev->tx_fifo_depth = controller->tx_fifo_depth;
dev->rx_fifo_depth = controller->rx_fifo_depth;
+
+   i2c_dw_acpi_setup_speed(>dev, dev);
+
r = i2c_dw_init(dev);
if (r)
return r;
-- 
2.5.3

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

RE: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

> On 09/10/15 06:11, Bharat Kumar Gogada wrote:
>  +struct nwl_msi {  /* struct nwl_msi - MSI information
> >> */
>  +  struct msi_controller chip; /* chip: MSI controller */
> >>>
>  We're moving away from msi_controller altogether, as the kernel now
>  has all the necessary infrastructure to do this properly.
> >>>
> >>> Our current GIC version does not have separate msi controller (we
> >>> are not using GICv2m or GICv3), so is it necessary to have separate
> >>> msi controller node ? Please give me clarity on this.
> >>
> >> This has nothing to do with the version of the GIC you are using
> >> (XGene doesn't have GICv2m or v3 either). This is about reducing code
> >> duplication and having something that we can maintain. See also
> >> https://lkml.org/lkml/2015/9/20/193 for yet another example.
> >>
> >> I still plan to kill msi_controller, and I'd like to avoid more
> >> dependencies with it. MSI domains are the way to do it.
> >>
> > Sorry previously I haven't configured my email client properly so resending.
> 
> Thanks for doing so, much appreciated.
> 
> > Since we don't have separate MSI controller, and our PCIe controller
> > is handling MSI, is it necessary to create a separate MSI controller
> > node because we don't have any 'reg' space.
> 
> No, your PCI controller can perfectly be part of the PCIe node.
You meant 'msi-controller' property to be part of PCIe node?

> 
> > Please let me know whether we require a separate msi file as suggested
> > in your previous comments to separate MSI controller and PCIE
> > controller in two files, if we don't have separate node. If we do not
> > need a separate node do we need to embed MSI controller child node  in
> > PCIe controller node itself, and what properties does this child node
> > will require other than 'interrupts'.
> 
> If you want to keep them in the same file, please at least have two separate
> patches. These are two different functions, and they should be reviewed
> separately.
> 
What I meant is if we don't have separate msi node do we need separate file? 
If you meant msi controller to be part of same node then we will use single 
file and will
try to have two separate patches.

Thanks,
Bharat

> It will help everyone to understand your code, and speed up the reviewing
> process.
> 
> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] HID: multitouch: Fetch feature reports on demand for Win8 devices

[Mika Westerberg]

On Thu, Oct 08, 2015 at 06:10:23PM -0700, Andrew Duggan wrote:
> No, this touchpad doesn't have HID_QUIRK_NO_INIT_REPORTS set and
> usbhid/hid-core.c is calling usbhid_init_reports() which is retrieving
> feature 8. But, I did some additional testing and I wasn't able to reproduce
> this issue on other systems. The failure occurs on a Dell XPS 13 9343, but
> the exact same touchpad and the exact same kernel (I booted both systems off
> an external HD to ensure that the kernel and OS are identical) I didn't see
> a problem. I also tried a different USB PTP touchpad which didn't have an
> issue. Also, I tried returning in mt_get_feature() instead of reading the
> report when the report id is 8. When I did that everything worked.
> 
> So as of right now, it looks like a single non production USB PTP touchpad
> fails on one particular system. But, all other tests have been successful.
> 
> Let me know if you have any other suggestions for me to test. But, it seems
> like this failure might be fairly isolated.

Thanks a lot for testing all this.

If the failure is limited to a single non-production touchpad then, I
suppose we should be fine. As long as there are no such systems out
there in the wild.

One additional thing we could check in mt_get_feature() is if the device
is connected via I2C and only in that case fetch the feature in
question.

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

Re: [PATCH 4/4] arm64: dts: enable idle states for Hi6220

[Leo Yan]

Hi Sudeep,

On Fri, Oct 09, 2015 at 09:48:17AM +0100, Sudeep Holla wrote:
> 
> 
> On 09/10/15 05:36, Leo Yan wrote:
> >Add cpu and cluster level's low power state for Hi6220.
> >
> >Signed-off-by: Leo Yan 
> >---
> >  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 31 
> > +++
> >  1 file changed, 31 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> >b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> >index 7edbe42..e83802a 100644
> >--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> >+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> >@@ -52,11 +52,35 @@
> > };
> > };
> >
> >+idle-states {
> >+entry-method = "arm,psci";
> 
> Please refer the bindings:   ^ should be just "psci"
> 
> Otherwise looks good.
> Acked-by: Sudeep Holla 

Will fix it, thanks for review.

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

Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

[Kosuke Tatsukawa]

Paolo Bonzini wrote:
> On 09/10/2015 02:35, Kosuke Tatsukawa wrote:
>> async_pf_executekvm_vcpu_block
>> 
>> spin_lock(>async_pf.lock);
>> if (waitqueue_active(>wq))
>> /* The CPU might reorder the test for
>>the waitqueue up here, before
>>prior writes complete */
>> prepare_to_wait(>wq, ,
>>   TASK_INTERRUPTIBLE);
>> /*if (kvm_vcpu_check_block(vcpu) < 0) */
>>  /*if (kvm_arch_vcpu_runnable(vcpu)) { */
>>   ...
>>   return (vcpu->arch.mp_state == 
>> KVM_MP_STATE_RUNNABLE &&
>> !vcpu->arch.apf.halted)
>> || 
>> !list_empty_careful(>async_pf.done)
>>  ...
> 
> The new memory barrier isn't "paired" with any other, and in
> fact I think that the same issue exists on the other side: 
> list_empty_careful(>async_pf.done) may be reordered up,
> before the prepare_to_wait:

smp_store_mb() called from set_current_state(), which is called from
prepare_to_wait() should prevent reordering such as below from
happening.  wait_event*() also calls set_current_state() inside.


> spin_lock(>async_pf.lock);
> (vcpu->arch.mp_state == 
> KVM_MP_STATE_RUNNABLE &&
> !vcpu->arch.apf.halted)
> || 
> !list_empty_careful(>async_pf.done)
> ...
> prepare_to_wait(>wq, ,
>   TASK_INTERRUPTIBLE);
> /*if (kvm_vcpu_check_block(vcpu) < 0) */
>  /*if (kvm_arch_vcpu_runnable(vcpu)) { */
>   ...
>  return 0;
> list_add_tail(>link,
>   >async_pf.done);
> spin_unlock(>async_pf.lock);
> waited = true;
> schedule();
> if (waitqueue_active(>wq))
> 
> So you need another smp_mb() after prepare_to_wait().  I'm not sure
> if it's needed also for your original tty report, but I think it is
> for https://lkml.org/lkml/2015/10/8/989 ("mei: fix waitqueue_active
> without memory barrier in mei drivers").
> 
> I wonder if it makes sense to introduce smp_mb__before_spin_lock()
> and smp_mb__after_spin_unlock().  On x86 the former could be a
> simple compiler barrier, and on s390 both of them could.  But that
> should be a separate patch.

The problem on the waiter side occurs if add_wait_queue() or
__add_wait_queue() is directly called without memory barriers nor locks
protecting it.


> Thanks,
> 
> Paolo
---
Kosuke TATSUKAWA  | 3rd IT Platform Department
  | IT Platform Division, NEC Corporation
  | ta...@ab.jp.nec.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/6] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:06PM +0800, Jisheng Zhang wrote:
> This is to add the pinctrl dependency for Marvell Berlin SoCs.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

> ---
>  arch/arm64/Kconfig.platforms | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index c6e2c75..3d17ee2 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -9,6 +9,7 @@ config ARCH_BERLIN
>   bool "Marvell Berlin SoC Family"
>   select ARCH_REQUIRE_GPIOLIB
>   select DW_APB_ICTL
> + select PINCTRL
>   help
> This enables support for Marvell Berlin SoC Family
>  
> -- 
> 2.6.1
> 

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/6] pinctrl: berlin: introduce berlin_pinctrl_probe_regmap()

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:04PM +0800, Jisheng Zhang wrote:
> This is to prepare for the next berlin4ct support, where we won't use
> simple-mfd any more.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

> ---
>  drivers/pinctrl/berlin/berlin.c | 26 +-
>  drivers/pinctrl/berlin/berlin.h |  4 
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
> index f495806..898afa4 100644
> --- a/drivers/pinctrl/berlin/berlin.c
> +++ b/drivers/pinctrl/berlin/berlin.c
> @@ -292,20 +292,14 @@ static struct pinctrl_desc berlin_pctrl_desc = {
>   .owner  = THIS_MODULE,
>  };
>  
> -int berlin_pinctrl_probe(struct platform_device *pdev,
> -  const struct berlin_pinctrl_desc *desc)
> +int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
> + const struct berlin_pinctrl_desc *desc,
> + struct regmap *regmap)
>  {
>   struct device *dev = >dev;
> - struct device_node *parent_np = of_get_parent(dev->of_node);
>   struct berlin_pinctrl *pctrl;
> - struct regmap *regmap;
>   int ret;
>  
> - regmap = syscon_node_to_regmap(parent_np);
> - of_node_put(parent_np);
> - if (IS_ERR(regmap))
> - return PTR_ERR(regmap);
> -
>   pctrl = devm_kzalloc(dev, sizeof(*pctrl), GFP_KERNEL);
>   if (!pctrl)
>   return -ENOMEM;
> @@ -330,3 +324,17 @@ int berlin_pinctrl_probe(struct platform_device *pdev,
>  
>   return 0;
>  }
> +
> +int berlin_pinctrl_probe(struct platform_device *pdev,
> +  const struct berlin_pinctrl_desc *desc)
> +{
> + struct device *dev = >dev;
> + struct device_node *parent_np = of_get_parent(dev->of_node);
> + struct regmap *regmap = syscon_node_to_regmap(parent_np);
> +
> + of_node_put(parent_np);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + return berlin_pinctrl_probe_regmap(pdev, desc, regmap);
> +}
> diff --git a/drivers/pinctrl/berlin/berlin.h b/drivers/pinctrl/berlin/berlin.h
> index e1aa841..dabbd2a 100644
> --- a/drivers/pinctrl/berlin/berlin.h
> +++ b/drivers/pinctrl/berlin/berlin.h
> @@ -58,4 +58,8 @@ struct berlin_pinctrl_function {
>  int berlin_pinctrl_probe(struct platform_device *pdev,
>const struct berlin_pinctrl_desc *desc);
>  
> +int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
> + const struct berlin_pinctrl_desc *desc,
> + struct regmap *regmap);
> +
>  #endif /* __PINCTRL_BERLIN_H */
> -- 
> 2.6.1
> 

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] i2c: designware: add High-speed mode support

[Andy Shevchenko]

On Fri, 2015-10-09 at 16:47 +0800, wangx...@gmail.com wrote:
> From: Xiang Wang 
> 
> 1. Add High-speed mode support in designware core
> 2. Add function i2c_dw_acpi_setup_speed to determine
> the bus speed from ACPI table.
> 
> Signed-off-by: Xiang Wang 
> ---
>  drivers/i2c/busses/i2c-designware-core.c | 88 
> 
>  drivers/i2c/busses/i2c-designware-core.h | 11 
>  2 files changed, 99 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-core.c 
> b/drivers/i2c/busses/i2c-designware-core.c
> index 6f19a33..f5c0d18 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Shouldn't be a part of platform driver?

>  #include "i2c-designware-core.h"
>  
>  /*
> @@ -42,6 +43,8 @@
>  #define DW_IC_SS_SCL_LCNT0x18
>  #define DW_IC_FS_SCL_HCNT0x1c
>  #define DW_IC_FS_SCL_LCNT0x20
> +#define DW_IC_HS_SCL_HCNT0x24
> +#define DW_IC_HS_SCL_LCNT0x28
>  #define DW_IC_INTR_STAT  0x2c
>  #define DW_IC_INTR_MASK  0x30
>  #define DW_IC_RAW_INTR_STAT  0x34
> @@ -358,6 +361,16 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
>   dw_writel(dev, lcnt, DW_IC_FS_SCL_LCNT);
>   dev_dbg(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, 
> lcnt);
>  
> + if (dev->hs_hcnt && dev->hs_lcnt) {
> + hcnt = dev->hs_hcnt;
> + lcnt = dev->hs_lcnt;
> +
> + dw_writel(dev, hcnt, DW_IC_HS_SCL_HCNT);
> + dw_writel(dev, lcnt, DW_IC_HS_SCL_LCNT);
> + dev_dbg(dev->dev, "High-speed mode HCNT:LCNT = 
> %d:%d\n",
> + hcnt, lcnt);
> + }
> +
>   /* Configure SDA Hold Time if required */
>   if (dev->sda_hold_time) {
>   reg = dw_readl(dev, DW_IC_COMP_VERSION);
> @@ -381,6 +394,81 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
>  }
>  EXPORT_SYMBOL_GPL(i2c_dw_init);
>  
> +#ifdef CONFIG_ACPI
> +static int i2c_dw_acpi_get_freq(struct acpi_resource *ares, void 
> *data)
> +{
> + struct dw_i2c_dev *i2c = data;
> + struct acpi_resource_i2c_serialbus *sb;
> + u32 i2c_speed;
> +
> + if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
> + sb = >data.i2c_serial_bus;
> +
> + if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
> + i2c_speed = sb->connection_speed;
> + if (i2c_speed == DW_STD_SPEED) {
> + i2c->master_cfg &= 
> ~DW_IC_SPEED_MASK;
> + i2c->master_cfg |= 
> DW_IC_CON_SPEED_STD;
> + } else if (i2c_speed == DW_FAST_SPEED) {
> + i2c->master_cfg &= 
> ~DW_IC_SPEED_MASK;
> + i2c->master_cfg |= 
> DW_IC_CON_SPEED_FAST;
> + } else if (i2c_speed == DW_HIGH_SPEED) {
> + i2c->master_cfg &= 
> ~DW_IC_SPEED_MASK;
> + i2c->master_cfg |= 
> DW_IC_CON_SPEED_HIGH;
> + } else {
> + dev_err(i2c->dev, "unsupported 
> speed: %d\n",
> + i2c_speed);
> + }
> +
> + dev_dbg(i2c->dev, "i2c device speed from 
> acpi = %d\n",
> + i2c_speed);
> + }
> + }
> +
> + return 1;
> +}
> +
> +static acpi_status acpi_i2c_find_device_speed(acpi_handle handle, 
> u32 level,
> + void *data, void 
> **return_value)
> +{
> + struct dw_i2c_dev *i2c = data;
> + struct list_head resource_list;
> + struct acpi_device *adev;
> +
> + if (acpi_bus_get_device(handle, ))
> + return AE_OK;
> + if (acpi_bus_get_status(adev) || !adev->status.present)
> + return AE_OK;
> +
> + INIT_LIST_HEAD(_list);
> + acpi_dev_get_resources(adev, _list,
> + i2c_dw_acpi_get_freq, i2c);
> + acpi_dev_free_resource_list(_list);
> +
> + return AE_OK;
> +}
> +
> +void i2c_dw_acpi_setup_speed(struct device *pdev, struct dw_i2c_dev 
> *dev)
> +{
> + acpi_handle handle = ACPI_HANDLE(pdev);
> + acpi_status status;
> +
> + if (handle == NULL)
> + return;
> +
> + /* Find I2C adapter bus frequency */
> + status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
> +  acpi_i2c_find_device_speed, 
> NULL,
> +  dev, NULL);
> + if (ACPI_FAILURE(status))
> + dev_warn(pdev, "failed to get I2C bus freq\n");
> +}
> +
> +#else
> +void i2c_dw_acpi_setup_speed(struct device *pdev, struct dw_i2c_dev 
> *dev) {}
> +#endif
> +EXPORT_SYMBOL_GPL(i2c_dw_acpi_setup_speed);
> +
>  /*
>   * Waiting for bus not busy
>   */
> diff --git a/drivers/i2c/busses/i2c-designware-core.h 
> 

Re: [PATCH v2 net-next 1/3] bpf: enable non-root eBPF programs

[Thomas Graf]

On 10/08/15 at 08:20pm, Hannes Frederic Sowa wrote:
> Hi Alexei,
> 
> On Thu, Oct 8, 2015, at 07:23, Alexei Starovoitov wrote:
> > The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
> > This toggle defaults to off (0), but can be set true (1).  Once true,
> > bpf programs and maps cannot be accessed from unprivileged process,
> > and the toggle cannot be set back to false.
> 
> This approach seems fine to me.
> 
> I am wondering if it makes sense to somehow allow ebpf access per
> namespace? I currently have no idea how that could work and on which
> namespace type to depend or going with a prctl or even cgroup maybe. The
> rationale behind this is, that maybe some namespaces like openstack
> router namespaces could make usage of advanced ebpf capabilities in the
> kernel, while other namespaces, especially where untrusted third parties
> are hosted, shouldn't have access to those facilities.
> 
> In that way, hosters would be able to e.g. deploy more efficient
> performance monitoring container (which should still need not to run as
> root) while the majority of the users has no access to that. Or think
> about routing instances in some namespaces, etc. etc.

The standard way of granting privileges like this for containers is
through CAP_ which does seem like a good fit for this as well and would
also solve your mentioned openstack use case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv

[Andy Shevchenko]

On Fri, 2015-10-09 at 16:47 +0800, wangx...@gmail.com wrote:
> From: Xiang Wang 
> 
> 1. Support setting hs_hcnt and hs_lcnt
> 2. Get bus speed mode from ACPI companion of the
> i2c controller.
> 
> Signed-off-by: Xiang Wang 
> ---
>  drivers/i2c/busses/i2c-designware-pcidrv.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
> b/drivers/i2c/busses/i2c-designware-pcidrv.c
> index 6643d2d..0f4c0c4 100644
> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> @@ -54,8 +54,10 @@ enum dw_pci_ctl_id_t {
>  struct dw_scl_sda_cfg {
>   u32 ss_hcnt;
>   u32 fs_hcnt;
> + u32 hs_hcnt;
>   u32 ss_lcnt;
>   u32 fs_lcnt;
> + u32 hs_lcnt;
>   u32 sda_hold;
>  };
>  
> @@ -237,8 +239,10 @@ static int i2c_dw_pci_probe(struct pci_dev 
> *pdev,
>   cfg = controller->scl_sda_cfg;
>   dev->ss_hcnt = cfg->ss_hcnt;
>   dev->fs_hcnt = cfg->fs_hcnt;
> + dev->hs_hcnt = cfg->hs_hcnt;
>   dev->ss_lcnt = cfg->ss_lcnt;
>   dev->fs_lcnt = cfg->fs_lcnt;
> + dev->hs_lcnt = cfg->hs_lcnt;
>   dev->sda_hold_time = cfg->sda_hold;
>   }
>  
> @@ -246,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
>  
>   dev->tx_fifo_depth = controller->tx_fifo_depth;
>   dev->rx_fifo_depth = controller->rx_fifo_depth;
> +
> + i2c_dw_acpi_setup_speed(>dev, dev);

Don't see a relationship between PCI driver and this ACPI stuff.

> +
>   r = i2c_dw_init(dev);
>   if (r)
>   return r;

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

[PATCH v2 1/4] i2c: designware-platdrv: enable RuntimePM before registering to the core

[Wolfram Sang]

From: Wolfram Sang 

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3dd2de31a2f8d3..73d58415bbc100 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -253,12 +253,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;
 
-   r = i2c_add_numbered_adapter(adap);
-   if (r) {
-   dev_err(>dev, "failure adding adapter\n");
-   return r;
-   }
-
if (dev->pm_runtime_disabled) {
pm_runtime_forbid(>dev);
} else {
@@ -268,6 +262,13 @@ static int dw_i2c_probe(struct platform_device *pdev)
pm_runtime_enable(>dev);
}
 
+   r = i2c_add_numbered_adapter(adap);
+   if (r) {
+   dev_err(>dev, "failure adding adapter\n");
+   pm_runtime_disable(>dev);
+   return r;
+   }
+
return 0;
 }
 
-- 
2.1.4

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

[PATCH v2 2/4] i2c: rcar: enable RuntimePM before registering to the core

[Wolfram Sang]

From: Wolfram Sang 

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-rcar.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index d8361dada58455..d8b5a8fee1e6c8 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -690,15 +690,16 @@ static int rcar_i2c_probe(struct platform_device *pdev)
return ret;
}
 
+   pm_runtime_enable(dev);
+   platform_set_drvdata(pdev, priv);
+
ret = i2c_add_numbered_adapter(adap);
if (ret < 0) {
dev_err(dev, "reg adap failed: %d\n", ret);
+   pm_runtime_disable(dev);
return ret;
}
 
-   pm_runtime_enable(dev);
-   platform_set_drvdata(pdev, priv);
-
dev_info(dev, "probed\n");
 
return 0;
-- 
2.1.4

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

RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

[Chen, Yu C]

Hi, LV

> -Original Message-
> From: Zheng, Lv
> Sent: Friday, October 09, 2015 4:33 PM
> To: Chen, Yu C; r...@rjwysocki.net; l...@kernel.org
> Cc: linux...@vger.kernel.org; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Zhang, Rui
> Subject: RE: [PATCH][v3] ACPI / PM: Fix incorrect wakeup irq setting before
> suspend-to-idle
> 
> Hi, Yu
> 
> > From: Chen, Yu C
> > Sent: Friday, October 09, 2015 4:20 PM
> >
> >
> >  acpi_status acpi_os_remove_interrupt_handler(u32 irq,
> > acpi_osd_handler handler)
> 
> Why don't you rename irq here to gsi to improve the readability?
> The false naming and the wrong example written for this function are
> probably the root causes of all other bad code.
> So if we want to stop people making future mistakes, we need to cleanup
> ourselves.
> 
OK, will rewrite in next version.

> Thanks and best regards
> -Lv
> 

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

Re: [PATCH] workqueue: Allocate the unbound pool using local node memory

[Hillf Danton]

> From: Xunlei Pang 
> 
> Currently, get_unbound_pool() uses kzalloc() to allocate the
> worker pool. Actually, we can use the right node to do the
> allocation, achieving local memory access.
> 
> This patch selects target node first, and uses kzalloc_node()
> instead.
> 
> Signed-off-by: Xunlei Pang 
> ---
>  kernel/workqueue.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index ca71582..96d3747 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3199,6 +3199,7 @@ static struct worker_pool *get_unbound_pool(const 
> struct workqueue_attrs *attrs)
>   u32 hash = wqattrs_hash(attrs);
>   struct worker_pool *pool;
>   int node;
> + int target_node = NUMA_NO_NODE;
> 
>   lockdep_assert_held(_pool_mutex);
> 
> @@ -3210,13 +3211,25 @@ static struct worker_pool *get_unbound_pool(const 
> struct workqueue_attrs *attrs)
>   }
>   }
> 
> + /* if cpumask is contained inside a NUMA node, we belong to that node */
> + if (wq_numa_enabled) {
> + for_each_node(node) {
> + if (cpumask_subset(attrs->cpumask,
> +wq_numa_possible_cpumask[node])) {
> + target_node = node;
> + break;
> + }
> + }
> + }
> +
>   /* nope, create a new one */
> - pool = kzalloc(sizeof(*pool), GFP_KERNEL);
> + pool = kzalloc_node(sizeof(*pool), GFP_KERNEL, target_node);

What if target_node is short of pages at the moment?

>   if (!pool || init_worker_pool(pool) < 0)
>   goto fail;
> 
>   lockdep_set_subclass(>lock, 1);   /* see put_pwq() */
>   copy_workqueue_attrs(pool->attrs, attrs);
> + pool->node = target_node;
> 
>   /*
>* no_numa isn't a worker_pool attribute, always clear it.  See
> @@ -3224,17 +3237,6 @@ static struct worker_pool *get_unbound_pool(const 
> struct workqueue_attrs *attrs)
>*/
>   pool->attrs->no_numa = false;
> 
> - /* if cpumask is contained inside a NUMA node, we belong to that node */
> - if (wq_numa_enabled) {
> - for_each_node(node) {
> - if (cpumask_subset(pool->attrs->cpumask,
> -wq_numa_possible_cpumask[node])) {
> - pool->node = node;
> - break;
> - }
> - }
> - }
> -
>   if (worker_pool_assign_id(pool) < 0)
>   goto fail;
> 
> --
> 1.9.1

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

Re: [PATCH v2 3/5] ARM: mvebu: set SW polling as SDHCI card detection on A388-GP

[Marcin Wojtas]

Hi Thomas,


2015-10-09 9:52 GMT+02:00 Thomas Petazzoni
:
> Dear Marcin Wojtas,
>
> On Fri,  9 Oct 2015 03:03:53 +0200, Marcin Wojtas wrote:
>> The newest revisions of A388-GP (v1.5 and higher) support only
>> DAT3-based card detection. Revisions < v1.5 based on GPIO detection
>> via I2C expander, but this solution is supposed to be deprecated on
>> new boards. In order to satisfy all type of hardware this commit
>> changes card detection to use software polling mechanism.
>>
>> Signed-off-by: Marcin Wojtas 
>
> Can we add a comment on the DT that explains why SW polling is used,
> and which other mechanism can be used depending on the board revision?

Sure, good idea. Do you think the below would be sufficient?
sdhci@d8000 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
no-1-8-v;
/*
 * A388-GP board v1.5 and higher replace
 * hitherto card detection method based on GPIO
 * with the one using DAT3 pin. As they are
 * incompatible, software-based polling is
 * enabled with 'broken-cd' property. For boards
 * older than v1.5 it can be replaced with:
 * 'cd-gpios = < 5 GPIO_ACTIVE_LOW>;',
 * whereas for the newer ones following can be
 * used instead:
 * 'dat3-cd;'
 * 'cd-inverted;'
 */
broken-cd;
wp-inverted;
bus-width = <8>;
status = "okay";
};

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

PROBLEM: Concurrency issue in sem_lock

[Felix Hübner]

Hi all,

I have just reported a concurrency issue in the implementation of
sem_lock, see https://bugzilla.kernel.org/show_bug.cgi?id=105651

Please set me to CC for answers/comments.


[1.] One line summary of the problem:

Concurrency issue in sem_lock

[2.] Full description of the problem/report:

In line 376 (file ipc/sem.c) sem_wait_array is called with pre condition
sma->complex_count!=0 resulting in an immediate return.

The following scenario is possible, allowing P0 and P1 to be in the
critical section (section between sem_lock und sem_unlock) at the same time:

P0 is a process performing up with semtimedop on single semaphore 1.
P1 is a process performing up with semtimedop on single semaphore 1.
P2 is a process performing down with semtimedop on semaphores 1 and 2.

start condition:

sma->complex_count=0

All line references apply to the file ipc/sem.c.

# P0 runs sem_lock up to line 332: if(sma->complex_count==0) evaluates
to true

static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
  int nsops)
{
struct sem *sem;

if (nsops != 1) {
...
}
sem = sma->sem_base + sops->sem_num;

if (sma->complex_count == 0) {

# P1 runs sem_lock up to line 329.

static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
  int nsops)
{
struct sem *sem;

if (nsops != 1) {
...
}

sem = sma->sem_base + sops->sem_num;

# P2 runs sem_lock to (including) line 310.

static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
  int nsops)
{
struct sem *sem;

if (nsops != 1) {
ipc_lock_object(>sem_perm);

sem_wait_array(sma);

# P0 does spin_lock(>lock); in line 336.

spin_lock(>lock);

# P2 performs rest of semtimedop, increments complex_count and ends up
in line 1961 and starts to sleep.

return -1;
}

  ##semtimedop:
locknum = sem_lock(sma, sops, nsops);

...

error = perform_atomic_semop(sma, );
if (error == 0) {
...
}
if (error <= 0)
...

if (nsops == 1) {
...
} else {
if (!sma->complex_count)
merge_queues(sma);

if (alter)
list_add_tail(, >pending_alter);
else
list_add_tail(, >pending_const);

sma->complex_count++;
}

queue.status = -EINTR;
queue.sleeper = current;

sleep_again:
__set_current_state(TASK_INTERRUPTIBLE);
sem_unlock(sma, locknum);
rcu_read_unlock();

if (timeout)
jiffies_left = schedule_timeout(jiffies_left);
else
schedule();

# P1 evaluates if(sem->complex_count==0) in line 331 and ends up in line
361.

if (sma->complex_count == 0) {
...
}

# P0 evaluates if(!spin_is_locked(>sem_perm.lock)) in line 339 and
ends up after line 346.

if (!spin_is_locked(>sem_perm.lock)) { 
ipc_smp_acquire__after_spin_is_unlocked();


# P1 performs ipc_lock_object(>sem_perm); line 362; it then
evaluates if(sma->complex_count==0) and executes the else statement,
calls sem_wait_array in line 376, which returns erroneously.

ipc_lock_object(>sem_perm);

if (sma->complex_count == 0) {
...
} else {
sem_wait_array(sma);

static void sem_wait_array(struct sem_array*sma)
{
int i;
struct sem *sem;

if (sma->complex_count)  {
return;
}   

return -1;
}

# P1 runs the rest of semtimedop and wakes P2 up in do_smart_update
(line 1911), update_queue and unlink_queue respectively. This reduces
complex_count.

locknum = sem_lock(sma, sops, nsops);
...
...
error = perform_atomic_semop(sma, );
if (error == 0) {
if (alter)
do_smart_update(sma, sops, nsops, 1, );

# P0 now evaluates if(sma->complex_count==0) in line 353 and is able to
enter the critical section, while P1 is still in do_smart_update().

if (sma->complex_count == 0) {
/* fast path successful! */
return sops->sem_num;
}   


Thanks to Manfred Spraul for his comments on the problem description.


[3.] Keywords (i.e., modules, networking, kernel):
IPC, sem_lock
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
4.3.0-rc4

[5.] Most recent 

[PATCH v4 6/6] arm64: dts: berlin4ct: add default pinmux for uart0

[Jisheng Zhang]

Add urt0 txd and rxd muxing setup in the dtsi because uart0 always uses
them to work, no other possibilities.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index 8e66355..a4a1876 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -288,12 +288,19 @@
clocks = <>;
reg-shift = <2>;
status = "disabled";
+   pinctrl-0 = <_pmux>;
+   pinctrl-names = "default";
};
};
 
system_pinctrl: pin-controller@fe2200 {
compatible = "marvell,berlin4ct-system-pinctrl";
reg = <0xfe2200 0xc>;
+
+   uart0_pmux: uart0-pmux {
+   groups = "SM_URT0_TXD", "SM_URT0_RXD";
+   function = "uart0";
+   };
};
};
 };
-- 
2.6.1

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

[PATCH v4 3/6] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs

[Jisheng Zhang]

This is to add the pinctrl dependency for Marvell Berlin SoCs.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index c6e2c75..3d17ee2 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -9,6 +9,7 @@ config ARCH_BERLIN
bool "Marvell Berlin SoC Family"
select ARCH_REQUIRE_GPIOLIB
select DW_APB_ICTL
+   select PINCTRL
help
  This enables support for Marvell Berlin SoC Family
 
-- 
2.6.1

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

[PATCH v4 0/6] arm64: berlin: add pinctrl support

[Jisheng Zhang]

This series adds support for Marvell berlin4ct pin-controller, allowing
to configure the pin muxing from the device tree.

Since v3:
 - fix stupid build error: I missed local changes to berlin-bg4ct.c

Since v2:
 - introduce new berlin_pinctrl_probe_regmap() to avoid duplicated code
 - renaming such as s/urt/uart etc. but keep the group name as URT* to keep
   consistent with HW/ASIC

Since v1:
 - use generic name for pin functions
 - a new commit to add pinmux for uart0
 - correct pinctrl usage in dts


Jisheng Zhang (6):
  pinctrl: berlin: introduce berlin_pinctrl_probe_regmap()
  pinctrl: berlin: add the berlin4ct pinctrl driver
  arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs
  pinctrl: dt-binding: document berlin4ct SoC pinctrl
  arm64: dts: berlin4ct: add the pinctrl node
  arm64: dts: berlin4ct: add default pinmux for uart0

 .../devicetree/bindings/pinctrl/berlin,pinctrl.txt |   5 +-
 arch/arm64/Kconfig.platforms   |   1 +
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi |  22 +
 drivers/pinctrl/berlin/Kconfig |   5 +
 drivers/pinctrl/berlin/Makefile|   1 +
 drivers/pinctrl/berlin/berlin-bg4ct.c  | 503 +
 drivers/pinctrl/berlin/berlin.c|  26 +-
 drivers/pinctrl/berlin/berlin.h|   4 +
 8 files changed, 557 insertions(+), 10 deletions(-)
 create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c

-- 
2.6.1

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

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Peter Zijlstra]

On Thu, Oct 08, 2015 at 02:44:39PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 08, 2015 at 01:16:38PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 08, 2015 at 02:50:36PM +1100, Michael Ellerman wrote:
> > > On Wed, 2015-10-07 at 08:25 -0700, Paul E. McKenney wrote:
> > 
> > > > Currently, we do need smp_mb__after_unlock_lock() to be after the
> > > > acquisition on PPC -- putting it between the unlock and the lock
> > > > of course doesn't cut it for the cross-thread unlock/lock case.
> > 
> > This ^, that makes me think I don't understand
> > smp_mb__after_unlock_lock.
> > 
> > How is:
> > 
> > UNLOCK x
> > smp_mb__after_unlock_lock()
> > LOCK y
> > 
> > a problem? That's still a full barrier.
> 
> The problem is that I need smp_mb__after_unlock_lock() to give me
> transitivity even if the UNLOCK happened on one CPU and the LOCK
> on another.  For that to work, the smp_mb__after_unlock_lock() needs
> to be either immediately after the acquire (the current choice) or
> immediately before the release (which would also work from a purely
> technical viewpoint, but I much prefer the current choice).
> 
> Or am I missing your point?

So lots of little confusions added up to complete fail :-{

Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
forgot: but not against uninvolved CPUs) and RELEASE/ACQUIRE are
transitive (where I forgot: RELEASE/ACQUIRE _chains_ are transitive, but
again not against uninvolved CPUs).

Which leads me to think I would like to suggest alternative rules for
RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
partly responsible for my confusion).

 - RELEASE -> ACQUIRE is fully ordered (but not a full barrier) when
   they operate on the same variable and the ACQUIRE reads from the
   RELEASE. Notable, RELEASE/ACQUIRE are RCpc and lack transitivity.

 - RELEASE -> ACQUIRE can be upgraded to a full barrier (including
   transitivity) using smp_mb__release_acquire(), either before RELEASE
   or after ACQUIRE (but consistently [*]).

 - RELEASE -> ACQUIRE _chains_ (on shared variables) preserve causality,
   (because each link is fully ordered) but are not transitive.

And I think that in the past few weeks we've been using transitive
ambiguously, the definition we have in Documentation/memory-barriers.txt
is a _strong_ transitivity, where we can make guarantees about CPUs not
directly involved.

What we have here (due to RCpc) is a weak form of transitivity, which,
while it preserves the natural concept of causality, does not extend to
other CPUs.

So we could go around and call them 'strong' and 'weak' transitivity,
but I suspect its easier for everyone involved if we come up with
separate terms (less room for error if we accidentally omit the
'strong/weak' qualifier).


[*] Do we want to take that choice away and go for:
smp_mb__after_release_acquire() ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: Concurrency issue in sem_lock

[Felix Hübner]

Hi all,

I have just reported a concurrency issue in the implementation of
sem_lock, see https://bugzilla.kernel.org/show_bug.cgi?id=105651

Please set me to CC for answers/comments.


[1.] One line summary of the problem:

Concurrency issue in sem_lock

[2.] Full description of the problem/report:

In line 376 (file ipc/sem.c) sem_wait_array is called with pre condition
sma->complex_count!=0 resulting in an immediate return.

The following scenario is possible, allowing P0 and P1 to be in the
critical section (section between sem_lock und sem_unlock) at the same time:

P0 is a process performing up with semtimedop on single semaphore 1.
P1 is a process performing up with semtimedop on single semaphore 1.
P2 is a process performing down with semtimedop on semaphores 1 and 2.

start condition:

sma->complex_count=0

All line references apply to the file ipc/sem.c.

# P0 runs sem_lock up to line 332: if(sma->complex_count==0) evaluates
to true

static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
  int nsops)
{
struct sem *sem;

if (nsops != 1) {
...
}
sem = sma->sem_base + sops->sem_num;

if (sma->complex_count == 0) {

# P1 runs sem_lock up to line 329.

static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
  int nsops)
{
struct sem *sem;

if (nsops != 1) {
...
}

sem = sma->sem_base + sops->sem_num;

# P2 runs sem_lock to (including) line 310.

static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
  int nsops)
{
struct sem *sem;

if (nsops != 1) {
ipc_lock_object(>sem_perm);

sem_wait_array(sma);

# P0 does spin_lock(>lock); in line 336.

spin_lock(>lock);

# P2 performs rest of semtimedop, increments complex_count and ends up
in line 1961 and starts to sleep.

return -1;
}

  ##semtimedop:
locknum = sem_lock(sma, sops, nsops);

...

error = perform_atomic_semop(sma, );
if (error == 0) {
...
}
if (error <= 0)
...

if (nsops == 1) {
...
} else {
if (!sma->complex_count)
merge_queues(sma);

if (alter)
list_add_tail(, >pending_alter);
else
list_add_tail(, >pending_const);

sma->complex_count++;
}

queue.status = -EINTR;
queue.sleeper = current;

sleep_again:
__set_current_state(TASK_INTERRUPTIBLE);
sem_unlock(sma, locknum);
rcu_read_unlock();

if (timeout)
jiffies_left = schedule_timeout(jiffies_left);
else
schedule();

# P1 evaluates if(sem->complex_count==0) in line 331 and ends up in line
361.

if (sma->complex_count == 0) {
...
}

# P0 evaluates if(!spin_is_locked(>sem_perm.lock)) in line 339 and
ends up after line 346.

if (!spin_is_locked(>sem_perm.lock)) { 
ipc_smp_acquire__after_spin_is_unlocked();


# P1 performs ipc_lock_object(>sem_perm); line 362; it then
evaluates if(sma->complex_count==0) and executes the else statement,
calls sem_wait_array in line 376, which returns erroneously.

ipc_lock_object(>sem_perm);

if (sma->complex_count == 0) {
...
} else {
sem_wait_array(sma);

static void sem_wait_array(struct sem_array*sma)
{
int i;
struct sem *sem;

if (sma->complex_count)  {
return;
}   

return -1;
}

# P1 runs the rest of semtimedop and wakes P2 up in do_smart_update
(line 1911), update_queue and unlink_queue respectively. This reduces
complex_count.

locknum = sem_lock(sma, sops, nsops);
...
...
error = perform_atomic_semop(sma, );
if (error == 0) {
if (alter)
do_smart_update(sma, sops, nsops, 1, );

# P0 now evaluates if(sma->complex_count==0) in line 353 and is able to
enter the critical section, while P1 is still in do_smart_update().

if (sma->complex_count == 0) {
/* fast path successful! */
return sops->sem_num;
}   


Thanks to Manfred Spraul for his comments on the problem description.


[3.] Keywords (i.e., modules, networking, kernel):
IPC, sem_lock
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
4.3.0-rc4

[5.] Most recent 

[PATCH v3 3/5] ARM: sun5i: dt: Move uart3 pinctrl node to common DTSI

[Maxime Ripard]

The uart3 pins are shared between the A10s and A13, move the pinctrl node
to the common DTSI to avoid duplication.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 7 ---
 arch/arm/boot/dts/sun5i.dtsi  | 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 0fdabe8eb9e8..2ebd32f5bc6e 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -204,13 +204,6 @@
allwinner,pull = ;
};
 
-   uart3_pins_a: uart3@0 {
-   allwinner,pins = "PG9", "PG10";
-   allwinner,function = "uart3";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
-
emac_pins_a: emac0@0 {
allwinner,pins = "PA0", "PA1", "PA2",
"PA3", "PA4", "PA5", "PA6",
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 78b993abbaa3..433c83a321ca 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -529,6 +529,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   uart3_pins_a: uart3@0 {
+   allwinner,pins = "PG9", "PG10";
+   allwinner,function = "uart3";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
 
timer@01c20c00 {
-- 
2.5.3

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

[PATCH v3 1/5] ARM: sunxi: Add R8 support

[Maxime Ripard]

The R8 is a new Allwinner SoC based on the A13. While both are very
similar, there's still a few differences. Introduce a new compatible to
deal with them.

In order to have a consistent naming, instead of mentionning the allwinner
A series as the machine name, switch to sun4i/sun5i like what is done for
the other families.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
Acked-by: Stephen Boyd 
---
 Documentation/arm/sunxi/README  | 2 +-
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 3 ++-
 drivers/clk/sunxi/clk-sunxi.c   | 1 +
 4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index 5e38e1582f95..430d279a8df3 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -25,7 +25,7 @@ SunXi family
 + Datasheet
   
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
 
-  - Allwinner A13 (sun5i)
+  - Allwinner A13 / R8 (sun5i)
 + Datasheet
  
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
 + User Manual
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index 67da20539540..bb9b0faa919d 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -6,6 +6,7 @@ using one of the following compatible strings:
   allwinner,sun4i-a10
   allwinner,sun5i-a10s
   allwinner,sun5i-a13
+  allwinner,sun5i-r8
   allwinner,sun6i-a31
   allwinner,sun7i-a20
   allwinner,sun8i-a23
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 65bab2876343..8583a9ca86bd 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -26,10 +26,11 @@ static const char * const sunxi_board_dt_compat[] = {
"allwinner,sun4i-a10",
"allwinner,sun5i-a10s",
"allwinner,sun5i-a13",
+   "allwinner,sun5i-r8",
NULL,
 };
 
-DT_MACHINE_START(SUNXI_DT, "Allwinner A1X (Device Tree)")
+DT_MACHINE_START(SUNXI_DT, "Allwinner sun4i/sun5i Families")
.dt_compat  = sunxi_board_dt_compat,
.init_late  = sunxi_dt_cpufreq_init,
 MACHINE_END
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 413070d07b3f..9c79af0c03b2 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1196,6 +1196,7 @@ static void __init sun5i_init_clocks(struct device_node 
*node)
 }
 CLK_OF_DECLARE(sun5i_a10s_clk_init, "allwinner,sun5i-a10s", sun5i_init_clocks);
 CLK_OF_DECLARE(sun5i_a13_clk_init, "allwinner,sun5i-a13", sun5i_init_clocks);
+CLK_OF_DECLARE(sun5i_r8_clk_init, "allwinner,sun5i-r8", sun5i_init_clocks);
 CLK_OF_DECLARE(sun7i_a20_clk_init, "allwinner,sun7i-a20", sun5i_init_clocks);
 
 static const char *sun6i_critical_clocks[] __initdata = {
-- 
2.5.3

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

[PATCH v3 0/5] ARM: sunxi: Introduce CHIP support

[Maxime Ripard]

Hi,

Here is a serie introducing the support for the Allwinner R8 and the
Nextthing's CHIP.

Support is almost complete for the CHIP itself, the only missing part
for now is the WiFi chip that needs to be powered through two combined
regulators (AXP209's LDO3 and LDO4). The audio codec is also missing
since it's not already enabled in the DT.

Both these features will be addressed eventually.

Let me know what you think,
Maxime

Changes from v2:
  - Fixed whitespace issue
  - Changed DTSI include to R8
  - Removed i2c1 to be consitent with the other boards

Changes from v1:
  - Collected tags
  - Removed unused include files
  - Removed ipsout, dram and vcc regulators
  - Added USB power supply

Maxime Ripard (5):
  ARM: sunxi: Add R8 support
  ARM: sun5i: Add R8 DTSI
  ARM: sun5i: dt: Move uart3 pinctrl node to common DTSI
  ARM: sun5i: dt: Add UART3 CTS and RTS pins
  ARM: sun5i: Add C.H.I.P DTS

 Documentation/arm/sunxi/README  |   2 +-
 Documentation/devicetree/bindings/arm/sunxi.txt |   1 +
 arch/arm/boot/dts/Makefile  |   3 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi   |   7 -
 arch/arm/boot/dts/sun5i-r8-chip.dts | 213 
 arch/arm/boot/dts/sun5i-r8.dtsi |  59 +++
 arch/arm/boot/dts/sun5i.dtsi|  14 ++
 arch/arm/mach-sunxi/sunxi.c |   3 +-
 drivers/clk/sunxi/clk-sunxi.c   |   1 +
 9 files changed, 293 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
 create mode 100644 arch/arm/boot/dts/sun5i-r8.dtsi

-- 
2.5.3

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

[PATCH v3 4/5] ARM: sun5i: dt: Add UART3 CTS and RTS pins

[Maxime Ripard]

Add a separate pinctrl node for the UART3 CTS and RTS pins shared between
the A10s and A13.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 433c83a321ca..7d355e52efe2 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -536,6 +536,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   uart3_pins_cts_rts_a: uart3-cts-rts@0 {
+   allwinner,pins = "PG11", "PG12";
+   allwinner,function = "uart3";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};
 
timer@01c20c00 {
-- 
2.5.3

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

Re: [PATCH 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.

[Srinivas Kandagatla]

On 08/10/15 19:17, Stephen Boyd wrote:

On 10/08/2015 04:19 AM, Srinivas Kandagatla wrote:

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 85f7bee..d49ac37 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -233,6 +233,22 @@
status = "disabled";
};

+   /* BLSP1 QUP2 */


This comment is useless.


Absolutely.. :-)
will fix it in next version.

--srini



+   blsp_i2c2: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b6000 0x1000>;
+   interrupts = ;




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

Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

[Peter Zijlstra]

On Fri, Oct 09, 2015 at 10:45:32AM +0200, Paolo Bonzini wrote:
> So you need another smp_mb() after prepare_to_wait().  I'm not sure
> if it's needed also for your original tty report, but I think it is
> for https://lkml.org/lkml/2015/10/8/989 ("mei: fix waitqueue_active
> without memory barrier in mei drivers").
> 
> I wonder if it makes sense to introduce smp_mb__before_spin_lock()
> and smp_mb__after_spin_unlock().  On x86 the former could be a
> simple compiler barrier, and on s390 both of them could.  But that
> should be a separate patch.

Not having actually read or thought about the issue at hand, its
perfectly valid to pair an smp_mb() with either spin_lock() or
spin_unlock().

IOW. MB <-> {ACQUIRE, RELEASE} is a valid pairing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] MMC fixes for v.4.3 rc5

[Ulf Hansson]

Hi Linus,

Here are some mmc fixes intended for v4.3 rc5 and it's based on v4.3-rc4.
Details are as usual found in the signed tag. Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:

  Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

are available in the git repository at:

  git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.3-rc4

for you to fetch changes up to 88c6eb0e3b81a30514d21679735fa25d028c2299:

  mmc: sdhci-of-at91: use SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST
quirk (2015-10-08 19:55:05 +0200)


MMC host:
 - omap_hsmmc: Fix boot regressions for omap4430
 - omap_hsmmc: Fix legacy boot regression for omap3
 - sdhci-pxav3: Fix some clock issues for Armada 38x
 - sdhci-pxav3: Fix error handling at probe
 - sdhci-of-at91: Fix clock stabilization problem


Marcin Wojtas (1):
  mmc: sdhci-pxav3: fix error handling of armada_38x_quirks

Nadav Haklai (2):
  mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x
sdhci driver
  mmc: sdhci-pxav3: disable clock inversion for HS MMC cards

Tony Lindgren (2):
  Revert "mmc: host: omap_hsmmc: use regulator_is_enabled to find
pbias status"
  mmc: host: omap_hsmmc: Fix MMC for omap3 legacy booting

ludovic.desroc...@atmel.com (2):
  mmc: sdhci: add quirk SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST
  mmc: sdhci-of-at91: use SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk

 drivers/mmc/host/omap_hsmmc.c| 14 +-
 drivers/mmc/host/sdhci-of-at91.c |  1 +
 drivers/mmc/host/sdhci-pxav3.c   |  6 +-
 drivers/mmc/host/sdhci.c |  2 ++
 drivers/mmc/host/sdhci.h |  5 +
 5 files changed, 22 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] staging: android: ion: Add ion driver for Hi6220 SoC platform

[Dan Carpenter]

On Fri, Oct 09, 2015 at 11:53:32AM +0300, Dan Carpenter wrote:
> > +out:
> 
> Labels named "out" are bug prone because handling everything is harder
> than using named labels and unwinding one step at a time.  The bug here
> is that we don't call ion_device_destroy().
> 
> > +   for (i = 0; i < num_heaps; ++i)
> > +   ion_heap_destroy(heaps[i]);
> > +   return err;
> 
> Write it like this:
> 
> err_free_heaps:
>   for (i = 0; i < num_heaps; ++i)
>   ion_heap_destroy(heaps[i]);
> err_free_idev:
>   ion_device_destroy(idev);
> 
>   return err;
> 
> > +}
> > +
> > +static int hi6220_ion_remove(struct platform_device *pdev)
> > +{
> > +   int i;
> > +
> > +   ion_device_destroy(idev);
> > +   for (i = 0; i < num_heaps; i++) {
> > +   if (!heaps[i])
> > +   continue;
> 
> We don't really need this NULL check and it isn't there in the
> hi6220_ion_probe() unwind code.
> 
> > +   ion_heap_destroy(heaps[i]);
> > +   heaps[i] = NULL;
> > +   }
> > +

Really the unwind from probe() and the remove() function should have
similar code.  For example, is it important to set heaps[i] to NULL?
If so then we should do it in the probe function as well.  If not then
we could leave it out of the remove function.

Also the ion_device_destroy(idev) should be after freeing heaps in the
remove function.

regards,
dan carpenter

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

Re: [PATCH v4 2/6] pinctrl: berlin: add the berlin4ct pinctrl driver

[Antoine Tenart]

Hi Jisheng,

On Fri, Oct 09, 2015 at 04:17:05PM +0800, Jisheng Zhang wrote:
> diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
> index b18322b..c13f6d2 100644
> --- a/drivers/pinctrl/berlin/Kconfig
> +++ b/drivers/pinctrl/berlin/Kconfig
> @@ -17,4 +17,9 @@ config PINCTRL_BERLIN_BG2Q
>   bool
>   select PINCTRL_BERLIN
>  
> +config PINCTRL_BERLIN_BG4CT
> + depends on OF && (ARCH_BERLIN || COMPILE_TEST)
> + bool "Marvell berlin4ct pin controller driver"
> + select PINCTRL_BERLIN
> +
>  endif

This endif ends the following condition:

if ARCH_BERLIN
[...]

So the "depends on ARCH_BERLIN" here can be dropped. Also the
COMPILE_TEST can be moved as it isn't BG4CT specific and all other
Berlin pinctrl drivers would benefit from this.

So we would have something like:

if (ARCH_BERLIN || COMPILE_TEST)
[...]
endif

Finally you can move the OF dependency to the PINCTRL_BERLIN config as
all Berlin pinctrl drivers depends on it.

Thanks!

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node

[Kamezawa Hiroyuki]

On 2015/10/09 14:52, Jiang Liu wrote:

On 2015/10/9 4:20, Andrew Morton wrote:

On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes  
wrote:


On Wed, 19 Aug 2015, Patil, Kiran wrote:


Acked-by: Kiran Patil 


Where's the call to preempt_disable() to prevent kernels with preemption
from making numa_node_id() invalid during this iteration?


David asked this question twice, received no answer and now the patch
is in the maintainer tree, destined for mainline.

If I was asked this question I would respond

   The use of numa_mem_id() is racy and best-effort.  If the unlikely
   race occurs, the memory allocation will occur on the wrong node, the
   overall result being very slightly suboptimal performance.  The
   existing use of numa_node_id() suffers from the same issue.

But I'm not the person proposing the patch.  Please don't just ignore
reviewer comments!

Hi Andrew,
Apologize for the slow response due to personal reasons!
And thanks for answering the question from David. To be honest,
I didn't know how to answer this question before. Actually this
question has puzzled me for a long time when dealing with memory
hot-removal. For normal cases, it only causes sub-optimal memory
allocation if schedule event happens between querying NUMA node id
and calling alloc_pages_node(). But what happens if system run into
following execution sequence?
1) node = numa_mem_id();
2) memory hot-removal event triggers
2.1) remove affected memory
2.2) reset pgdat to zero if node becomes empty after memory removal


I'm sorry if I misunderstand something.
After commit b0dc3a342af36f95a68fe229b8f0f73552c5ca08, there is no memset().


3) alloc_pages_node(), which may access zero-ed pgdat structure.


?



I haven't found a mechanism to protect system from above sequence yet,
so puzzled for a long time already:(. Does stop_machine() protect
system from such a execution sequence?


To access pgdat, a pgdat's zone should be on per-pgdat-zonelist.
Now, __build_all_zonelists() is called under stop_machine(). That's the reason
why you're asking what stop_machine() does. And, as you know, stop_machine() is 
not
protecting anything. The caller may fallback into removed zone.

Then, let's think.

At first, please note "pgdat" is not removed (and cannot be removed),
accessing pgdat's memory will not cause segmentation fault.

Just contents are problem. At removal, zone's page related information
and pgdat's page related information is cleared.

alloc_pages uses zonelist/zoneref/cache to walk each zones without accessing
pgdat itself. I think accessing zonelist is safe because it's an array updated
by stop_machine().

So, the problem is alloc_pages() can work correctly even if zone contains no 
page.
I think it should work.

(Note: zones are included in pgdat. So, zeroing pgdat means zeroing zone and 
other
 structures. it will not work.)

So, what problem you see now ?
I'm sorry I can't chase old discusions.

Thanks,
-Kame















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

Re: crazy idea: big percpu lock (Re: task isolation)

[Peter Zijlstra]

On Thu, Oct 08, 2015 at 02:25:23PM -0700, Andy Lutomirski wrote:
> I want to propose a new primitive that might go a long way toward
> solving this issue.  The new primitive would be called the "big percpu
> lock".  

Never, ever, combine big and lock :-) You want small granular locks, big
locks are a guaranteed recipe for pain.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 43/46] sched/{fair,cpufreq_sched}: add reset_capacity interface

[Juri Lelli]

Hi Steve,

On 08/10/15 21:40, Steve Muckle wrote:
> Hi Juri,
> 
> On 07/07/2015 11:24 AM, Morten Rasmussen wrote:
>> From: Juri Lelli 
>>
>> When a CPU is going idle it is pointless to ask for an OPP update as we
>> would wake up another task only to ask for the same capacity we are already
>> running at (utilization gets moved to blocked_utilization).  We thus add
>> cpufreq_sched_reset_capacity() interface to just reset our current capacity
>> request without triggering any real update.  At wakeup we will use the
>> decayed utilization to select an appropriate OPP.
> ...
>> +void cpufreq_sched_reset_cap(int cpu)
>> +{
>> +per_cpu(pcpu_capacity, cpu) = 0;
>> +}
>> +
> ...
>> @@ -4427,9 +4427,13 @@ static void dequeue_task_fair(struct rq *rq, struct 
>> task_struct *p, int flags)
>>  if (sched_energy_freq() && task_sleep) {
>>  unsigned long req_cap = get_cpu_usage(cpu_of(rq));
>>  
>> -req_cap = req_cap * capacity_margin
>> ->> SCHED_CAPACITY_SHIFT;
>> -cpufreq_sched_set_cap(cpu_of(rq), req_cap);
>> +if (rq->cfs.nr_running) {
>> +req_cap = req_cap * capacity_margin
>> +>> SCHED_CAPACITY_SHIFT;
>> +cpufreq_sched_set_cap(cpu_of(rq), req_cap);
>> +} else {
>> +cpufreq_sched_reset_cap(cpu_of(rq));
>> +}
>>  }
> 
> Though I understand the initial stated motivation here (avoiding a
> redundant capacity request upon idle entry), releasing the CPU's
> capacity request altogether on idle seems like it could be a contentious
> policy decision.
> 
> An example to illustrate my concern:
> - 2 CPU single frequency domain topology
> - task A is a small frequently-running task on CPU0
> - task B is a heavier intermittent task running on CPU1
> 
> Task B is driving the frequency of the cluster high, but whenever it
> sleeps CPU1 becomes idle and the capacity request is dropped. If there's
> any activity on CPU0 that causes cpufreq_sched_set_cap() to be called
> (which is likely, given task A runs often) the cluster frequency will be
> lowered. Task B's performance will be impacted when it wakes up because
> initially the OPP will be insufficient. Power may or may not be

With the current implementation you are right: B's util will be decayed
and it will have to build it up again, loosing in performance. What
about we try to change this as discussed at Connect? At enqueue time we
use pre-decayed B's util, so that it will generate an OPP transition
at the required capacity on wakeup.

> impacted, depending on the characteristics of the workload and system,
> and whether energy is saved with the additional frequency scaling.
> 
> The decision of when a CPU's vote should be decayed or removed is more
> policy where I believe there's no single right answer and in the past,
> has been solved with tunables. The interactive governor's slack timer
> controls how long it will allow an idle CPU to request a frequency > fmin.
> 

Mmm, IMHO there is still a bit of space for trying to make the current
implementation better, before we give up and go to add a tunable :-).

> If the utilization of a long-idle CPU could be decayed by a different
> CPU in the system, perhaps it could take care of updating that CPU's vote?
> 

Yeah, that's exactly what we thought of as well. Actually we also tried
to do some sort of "fake" pre-decaying based on information coming from
set timers, but it didn't quite fix the issue. Decaying someone else's
stuff implies taking locks, I fear, and that is not good. However, I
agree that finding a clean way of properly update util of idle cpus
would be a better solution.

Thanks,

- Juri

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

Re: [PATCH 03/15] arm64: Introduce helpers for page table levels

[Suzuki K. Poulose]

On 08/10/15 18:28, Catalin Marinas wrote:

On Thu, Oct 08, 2015 at 06:22:34PM +0100, Suzuki K. Poulose wrote:

On 08/10/15 15:45, Christoffer Dall wrote:

On Wed, Oct 07, 2015 at 10:26:14AM +0100, Marc Zyngier wrote:

I just had a chat with Catalin, who did shed some light on this.
It all has to do with rounding up. What you would like to have here is:

#define ARM64_HW_PGTABLE_LEVELS(va_bits) DIV_ROUND_UP(va_bits - PAGE_SHIFT, 
PAGE_SHIFT - 3)

where (va_bits - PAGE_SHIFT) is the total number of bits we deal
with during a page table walk, and (PAGE_SHIFT - 3) is the number
of bits we deal with per level.

The clue is in how DIV_ROUND_UP is written:

#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))

which gives you Suzuki's magic formula.

I'd vote for the DIV_ROUND_UP(), which will make things a lot more readable.


Thanks for the explanation, I vote for DIV_ROUND_UP too.


Btw, DIV_ROUND_UP is defined in linux/kernel.h, including which in the required
headers breaks the build. I could add the definition of the same locally.


Or just keep the original magic formula and add the DIV_ROUND_UP one in
a comment.



OK, will keep proper documentation with the cryptic formula ;)

Suzuki

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

Re: [PATCH 2/4] i2c: rcar: enable RuntimePM before registering to the core

[Wolfram Sang]

> You forgot to call pm_runtime_disable() in the error path.
> I think some of your other patches suffer from the same issue.

Ouch! Thanks a lot, Geert!



signature.asc
Description: Digital signature

Re: [PATCHv12 25/37] mm, thp: remove infrastructure for handling splitting PMDs

[Kirill A. Shutemov]

On Thu, Oct 08, 2015 at 02:22:25PM +0530, Vineet Gupta wrote:
> On Tuesday 06 October 2015 08:53 PM, Kirill A. Shutemov wrote:
> > With new refcounting we don't need to mark PMDs splitting. Let's drop code
> > to handle this.
> > 
> 
> >  
> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> > index 29c57b2cb344..010a7e3f6ad1 100644
> > --- a/include/asm-generic/pgtable.h
> > +++ b/include/asm-generic/pgtable.h
> > @@ -184,11 +184,6 @@ static inline void pmdp_set_wrprotect(struct mm_struct 
> > *mm,
> >  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> >  #endif
> >  
> > -#ifndef __HAVE_ARCH_PMDP_SPLITTING_FLUSH
> > -extern void pmdp_splitting_flush(struct vm_area_struct *vma,
> > -unsigned long address, pmd_t *pmdp);
> > -#endif
> 
> 
> Hi Kirill,
> 
> While at it - you would also want to nuke
> 
> Documentation/features/vm/pmdp_splitting_flush/

Sure.

The patch below can be folded into this one.

diff --git a/Documentation/features/vm/pmdp_splitting_flush/arch-support.txt 
b/Documentation/features/vm/pmdp_splitting_flush/arch-support.txt
deleted file mode 100644
index 26f74b457e0b..
--- a/Documentation/features/vm/pmdp_splitting_flush/arch-support.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-#
-# Feature name:  pmdp_splitting_flush
-# Kconfig:   __HAVE_ARCH_PMDP_SPLITTING_FLUSH
-# description:   arch supports the pmdp_splitting_flush() VM API
-#
----
-| arch |status|
----
-|   alpha: | TODO |
-| arc: | TODO |
-| arm: |  ok  |
-|   arm64: |  ok  |
-|   avr32: | TODO |
-|blackfin: | TODO |
-| c6x: | TODO |
-|cris: | TODO |
-| frv: | TODO |
-|   h8300: | TODO |
-| hexagon: | TODO |
-|ia64: | TODO |
-|m32r: | TODO |
-|m68k: | TODO |
-|   metag: | TODO |
-|  microblaze: | TODO |
-|mips: |  ok  |
-| mn10300: | TODO |
-|   nios2: | TODO |
-|openrisc: | TODO |
-|  parisc: | TODO |
-| powerpc: |  ok  |
-|s390: |  ok  |
-|   score: | TODO |
-|  sh: | TODO |
-|   sparc: | TODO |
-|tile: | TODO |
-|  um: | TODO |
-|   unicore32: | TODO |
-| x86: |  ok  |
-|  xtensa: | TODO |
----
-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 0/6] KASAN for arm64

[Andrey Ryabinin]

On 10/08/2015 07:07 PM, Andrey Ryabinin wrote:
> 2015-10-08 18:11 GMT+03:00 Catalin Marinas :
>> On Thu, Oct 08, 2015 at 02:09:26PM +0200, Ard Biesheuvel wrote:
>>> On 8 October 2015 at 13:23, Andrey Ryabinin  wrote:
 On 10/08/2015 02:11 PM, Mark Rutland wrote:
> On Thu, Oct 08, 2015 at 01:36:09PM +0300, Andrey Ryabinin wrote:
>> 2015-10-07 13:04 GMT+03:00 Catalin Marinas :
>>> On Thu, Sep 17, 2015 at 12:38:06PM +0300, Andrey Ryabinin wrote:
 As usual patches available in git
   git://github.com/aryabinin/linux.git kasan/arm64v6

 Changes since v5:
  - Rebase on top of 4.3-rc1
  - Fixed EFI boot.
  - Updated Doc/features/KASAN.
>>>
>>> I tried to merge these patches (apart from the x86 one which is already
>>> merged) but it still doesn't boot on Juno as an EFI application.
>>>
>>
>> 4.3-rc1 was ok and 4.3-rc4 is not. Break caused by 0ce3cc008ec04
>> ("arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME
>> regions")
>> It introduced sort() call in efi_get_virtmap().
>> sort() is generic kernel function and it's instrumented, so we crash
>> when KASAN tries to access shadow in sort().
>
> I believe this is solved by Ard's stub isolation series [1,2], which
> will build a stub-specific copy of sort() and various other functions
> (see the arm-deps in [2]).
>
> So long as the stub is not built with ASAN, that should work.

 Thanks, this should help, as we already build the stub without ASAN 
 instrumentation.
>>>
>>> Indeed. I did not mention instrumentation in the commit log for those
>>> patches, but obviously, something like KASAN instrumentation cannot be
>>> tolerated in the stub since it makes assumptions about the memory
>>> layout
>>
>> I'll review your latest EFI stub isolation patches and try Kasan again
>> on top (most likely tomorrow).
> 
> You'd better wait for v7, because kasan patches will need some adjustment.
> Since stub is isolated,  we need to handle memcpy vs __memcpy stuff the same
> way as we do in x86. Now we also need to #undef memset/memcpy/memmove in ARM64
> (just like this was done for x86).
> 

Hm, I was wrong, we don't need that.

I thought the EFI stub isolation patches create a copy of mem*() functions in 
the stub,
but they are just create aliases with __efistub_ prefix.

We only need to create some more aliases for KASAN.
The following patch on top of the EFI stub isolation series works for me.


Signed-off-by: Andrey Ryabinin 
---
 arch/arm64/kernel/image.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index e083af0..6eb8fee 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -80,6 +80,12 @@ __efistub_strcmp = __pi_strcmp;
 __efistub_strncmp  = __pi_strncmp;
 __efistub___flush_dcache_area  = __pi___flush_dcache_area;
 
+#ifdef CONFIG_KASAN
+__efistub___memcpy = __pi_memcpy;
+__efistub___memmove= __pi_memmove;
+__efistub___memset = __pi_memset;
+#endif
+
 __efistub__text= _text;
 __efistub__end = _end;
 __efistub__edata   = _edata;
-- 
2.4.9






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

RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend

[Chen, Yu C]

Thanks Pavel !

Hi, Ingo,
do you have a bandwidth to help look at this version, 
since this bug has been on bugzilla for a while.
Thanks a lot.

Best Regards,
Yu

> -Original Message-
> From: Pavel Machek [mailto:pa...@ucw.cz]
> Sent: Thursday, September 17, 2015 1:30 PM
> To: Chen, Yu C
> Cc: r...@rjwysocki.net; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; b...@alien8.de; Zhang, Rui; linux...@vger.kernel.org;
> x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for
> suspend
> 
> On Thu 2015-08-27 11:18:27, Chen Yu wrote:
> > A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
> > that, after resumed from S3, CPU is running at a low speed.
> > After investigation, it is found that, BIOS has modified the value of
> > THERM_CONTROL register during S3, and changes it from 0 to 0x10, since
> > value of 0x10 means CPU can only get 25% of the Duty Cycle, this
> > triggers the problem.
> >
> > Here is a simple scenario to reproduce the issue:
> > 1.Boot up the system
> > 2.Get MSR with address 0x19a, it should be 0 3.Put the system into
> > sleep, then wake it up 4.Get MSR with address 0x19a, it should be
> > 0(actually it shows 0x10)
> >
> > Although this is a BIOS issue, it would be more robust for linux to
> > deal with this situation. This patch fixes this issue by introducing a
> > framework to save/restore specified MSR registers(THERM_CONTROL in
> > this case) for suspend/resume.
> >
> > When user encounters a problematic platform and needs to protect the
> > MSRs during suspending, he can simply add a quirk entry in
> > msr_save_dmi_table, and customizes MSR registers inside the quirk
> > callback, for example:
> >
> > u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
> >
> > and the quirk mechanism ensures that, once resumed from suspended,
> the
> > MSRs indicated by these IDs will be restored to their original values
> > before suspended.
> >
> > Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
> > common code path. And because the MSRs specified by the user might not
> > be available or readable in any situation, we use rdmsrl_safe to
> > safely save these MSRs.
> >
> > Tested-by: Marcin Kaszewski 
> > Signed-off-by: Chen Yu 
> 
> Acked-by: Pavel Machek 
> 
> --

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

Re: [RFC v2 2/6] PM / Domains: prepare for devices that might register a power state

[Marc Titinger]

On 08/10/2015 18:11, Lina Iyer wrote:

Hi Marc,

Thanks for rebasing on top of my latest series.

On Tue, Oct 06 2015 at 08:27 -0600, Marc Titinger wrote:

Devices may register an intermediate retention state into the domain upon


I may agree with the usability of dynamic adding a state to the domain,
but I dont see why a device attaching to a domain should bring about a
new domain state.


Hi Lina,

thanks a lot for taking the time to look into this. The initial 
discussion behind it was about to see how a device like a PMU, FPU, 
cache, or a Healthcheck IP in the same power domain than CPUs, with 
special retention states can be handled in a way 'unified' with CPUs.
Also I admit it is partly an attempt from us to create something useful 
out of the "collision" of Axel's multiple states and your 
CPUs-as-generic-power-domain-devices, hence the RFC!


Looking at Juno for instance, she currently has a platform-initiated 
mode implemented in the arm-trusted-firmware through psci as a 
cpuidle-driver. the menu governor will select a possibly deep c-state, 
but the last-man CPU and actual power state is known to ATF. Similarly 
my idea was to have a genpd-initiated mode so to say, where the actual 
power state results from the cpu-domain's governor choice based on 
possible retention states, and their latency.


A Health-check IP or Cache will not (to my current knowledge) have a 
driver calling runtime_put, but may have a retention state "D1_RET" with 
a off/on latency between CPU_SLEEP and CLUSTER_SLEEP, so that 
CLUSTER_SLEEP may be ruled out by the governor, but D1_RET is ok given 
the time slot available. Some platform code can be called so that the 
cluster goes to D1_RET in that case, upon the last-man CPU 
waiting-for-interrupt. Note that in the case of a Health-Check HIP, the 
state my actually be a working state (all CPUs power down, and time slot 
OK for sampling stuff).




A domain should define its power states, independent of the devices that
may attach. The way I see it, devices have their own idle states and
domains have their own. I do see a relationship between possible domain
states depending on the states of the individual devices in the domain.
For ex, a CPU domain can only be in a retention state (low voltage,
memory retained), if its CPU devices are in retention state, i.e, the
domain cannot be powered off; alternately, the domain may be in
retention or power down if the CPU devices are in power down state.

Could you elaborate on why this is a need?


Well, it may not be a need TBH, it is an attempt to have cluster-level 
devices act like hotplugged CPUs but with heterogeneous c-states and 
latencies. I hope it makes some sense :)


Thanks,
Marc.




Thanks,
Lina


attaching. Currently generic domain would register an array of states
upon
init. This patch prepares for later insertion (sort per depth, remove).

Signed-off-by: Marc Titinger 
---
drivers/base/power/domain.c | 189
+++-
include/linux/pm_domain.h   |  18 -
2 files changed, 97 insertions(+), 110 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 3e27a2b..e5f4c00b 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -19,6 +19,7 @@
#include 
#include 
#include 
+#include 

#define GENPD_RETRY_MAX_MS250/* Approximate */

@@ -50,12 +51,6 @@
__retval;\
})

-#define GENPD_MAX_NAME_SIZE 20
-
-static int pm_genpd_alloc_states_names(struct generic_pm_domain *genpd,
-   const struct genpd_power_state *st,
-   unsigned int st_count);
-
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);

@@ -1364,46 +1359,6 @@ static void genpd_free_dev_data(struct device
*dev,
dev_pm_put_subsys_data(dev);
}

-static int genpd_alloc_states_data(struct generic_pm_domain *genpd,
-   const struct genpd_power_state *st,
-   unsigned int st_count)
-{
-int ret = 0;
-unsigned int i;
-
-if (IS_ERR_OR_NULL(genpd)) {
-ret = -EINVAL;
-goto err;
-}
-
-if (!st || (st_count < 1)) {
-ret = -EINVAL;
-goto err;
-}
-
-/* Allocate the local memory to keep the states for this genpd */
-genpd->states = kcalloc(st_count, sizeof(*st), GFP_KERNEL);
-if (!genpd->states) {
-ret = -ENOMEM;
-goto err;
-}
-
-for (i = 0; i < st_count; i++) {
-genpd->states[i].power_on_latency_ns =
-st[i].power_on_latency_ns;
-genpd->states[i].power_off_latency_ns =
-st[i].power_off_latency_ns;
-}
-
-genpd->state_count = st_count;
-
-/* to save memory, Name allocation will happen if debug is
enabled */
-pm_genpd_alloc_states_names(genpd, st, st_count);
-
-err:
-return ret;
-}
-
/**
 * __pm_genpd_add_device - Add a device to an I/O PM domain.
 * @genpd: PM domain to add the 

[PATCH v2 3/4] i2c: s3c2410: enable RuntimePM before registering to the core

[Wolfram Sang]

From: Wolfram Sang 

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-s3c2410.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 50bfd8cef5f224..336e34e1ca597d 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1243,19 +1243,21 @@ static int s3c24xx_i2c_probe(struct platform_device 
*pdev)
i2c->adap.nr = i2c->pdata->bus_num;
i2c->adap.dev.of_node = pdev->dev.of_node;
 
+   platform_set_drvdata(pdev, i2c);
+
+   pm_runtime_enable(>dev);
+   pm_runtime_enable(>adap.dev);
+
ret = i2c_add_numbered_adapter(>adap);
if (ret < 0) {
dev_err(>dev, "failed to add bus to i2c core\n");
+   pm_runtime_disable(>adap.dev);
+   pm_runtime_disable(>dev);
s3c24xx_i2c_deregister_cpufreq(i2c);
clk_unprepare(i2c->clk);
return ret;
}
 
-   platform_set_drvdata(pdev, i2c);
-
-   pm_runtime_enable(>dev);
-   pm_runtime_enable(>adap.dev);
-
dev_info(>dev, "%s: S3C I2C adapter\n", dev_name(>adap.dev));
return 0;
 }
-- 
2.1.4

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

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

[Thomas Gleixner]

On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> > On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > > The difference is that with the one-week step the kernel and userspace
> > > still agree on the current time and it is always valid from the kernel
> > > point of view, absolute timers can be set, etc.
> > 
> > Ok, I can see that as an improvement, but it still seems to give
> > a false sense of safety, and I feel we really should not have any code
> > rely on this behavior.
> 
> Applications are not allowed to rely on system time being sane?
> To me the current behavior looks like the kernel is throwing the
> applications off a cliff, while it's the only thing that can fly :).

As Arnd said, you are creating a wrong sense of safety. They fall off
the cliff with your changes as well. The fall is just different. Think
about timeouts, user space overflows of time_t etc.

We need to fix all of it, no matter what.

Thanks,

tglx




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

Re: [PATCH V2 1/2] clk: imx6: Add SPDIF_GCLK clock in clock tree

[Shengjiu Wang]

On Thu, Sep 24, 2015 at 04:57:37AM -0700, Shawn Guo wrote:
> On Thu, Sep 24, 2015 at 01:43:24PM +0800, Shengjiu Wang wrote:
> > On Wed, Sep 23, 2015 at 08:33:41AM -0700, Shawn Guo wrote:
> > > On Tue, Sep 15, 2015 at 06:01:01PM +0800, Shengjiu Wang wrote:
> > > > As spdif driver will register SPDIF clock to regmap, regmap will do
> > > > clk_prepare in init function, so SPDIF clock is prepared in probe, then 
> > > > its
> > > > root clock (pll clock) is prepared also, which cause the arm can't enter
> > > > low power mode.
> > > 
> > > Can you help me understand why ARM cannot enter low power mode when pll
> > > clock is prepared?
> > > 
> > > Shawn
> > Hi Shawn
> > 
> >In i.mx clock framework, when pll clk is prepared, it will be powerup. 
> > when
> > enterring low power idle mode, the powerdown bit is checked, when pll is not
> > powerdown state, chip will not enter low power idle mode.
> 
> So this is not a SPDIF specific problem, and any device driver preparing
> its clock that is a child of pll clock will run into this problem,
> right?  If so, we should purchase a more generic solution than such
> device specific one.
> 
> Shawn
Hi shawn

SPDIF_GCLK is also spdif's clock, it use a same enable bit with SPDIF_ROOT_CLK,
We didn't separate them in clock tree before.

I can't find a generic solution. But anyway if there is a solution or not, I
think we'd better to separate them.

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

Re: [PATCH v2 08/12] mm: move some code around

[Kirill A. Shutemov]

On Tue, Sep 22, 2015 at 04:04:52PM +0530, Vineet Gupta wrote:
> This reduces/simplifies the diff for the next patch which moves THP
> specific code.
> 
> Signed-off-by: Vineet Gupta 

Okay, so you group pte-related helpers together, right?
It would be nice to mention it in commit message.

Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com

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

Re: [PATCH v6 0/6] KASAN for arm64

[Mark Rutland]

On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote:
[...]

> I thought the EFI stub isolation patches create a copy of mem*() functions in 
> the stub,
> but they are just create aliases with __efistub_ prefix.
> 
> We only need to create some more aliases for KASAN.
> The following patch on top of the EFI stub isolation series works for me.
> 
> 
> Signed-off-by: Andrey Ryabinin 
> ---
>  arch/arm64/kernel/image.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index e083af0..6eb8fee 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -80,6 +80,12 @@ __efistub_strcmp   = __pi_strcmp;
>  __efistub_strncmp= __pi_strncmp;
>  __efistub___flush_dcache_area= __pi___flush_dcache_area;
>  
> +#ifdef CONFIG_KASAN
> +__efistub___memcpy   = __pi_memcpy;
> +__efistub___memmove  = __pi_memmove;
> +__efistub___memset   = __pi_memset;
> +#endif

Ard's v4 stub isolation series has these aliases [1], as the stub
requires these aliases regardless of KASAN in order to link.

Thanks,
Mark.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/375708.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 09/12] mm,thp: reduce ifdef'ery for THP in generic code

[Kirill A. Shutemov]

On Tue, Sep 22, 2015 at 04:04:53PM +0530, Vineet Gupta wrote:
> - pgtable-generic.c: Fold individual #ifdef for each helper into a top
>   level #ifdef. Makes code more readable

Makes sense.

> - Per Andrew's suggestion removed the dummy implementations for !THP
>   in asm-generic/page-table.h to have build time failures vs. runtime.

I'm not sure it's a good idea. This can lead to unnecessary #ifdefs where
otherwise call to helper would be eliminated by compiler as dead code.

What about dummy helpers with BUILD_BUG()?

> Signed-off-by: Vineet Gupta 
> ---
>  include/asm-generic/pgtable.h | 49 
> ---
>  mm/pgtable-generic.c  | 24 +++--
>  2 files changed, 21 insertions(+), 52 deletions(-)
> 
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 29c57b2cb344..2112f4147816 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -30,9 +30,12 @@ extern int ptep_set_access_flags(struct vm_area_struct 
> *vma,
>  #endif
>  
>  #ifndef __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  extern int pmdp_set_access_flags(struct vm_area_struct *vma,
>unsigned long address, pmd_t *pmdp,
>pmd_t entry, int dirty);
> +
> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  #endif
>  
>  #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
> @@ -64,14 +67,6 @@ static inline int pmdp_test_and_clear_young(struct 
> vm_area_struct *vma,
>   set_pmd_at(vma->vm_mm, address, pmdp, pmd_mkold(pmd));
>   return r;
>  }
> -#else /* CONFIG_TRANSPARENT_HUGEPAGE */
> -static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,
> - unsigned long address,
> - pmd_t *pmdp)
> -{
> - BUG();
> - return 0;
> -}
>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  #endif
>  
> @@ -81,8 +76,21 @@ int ptep_clear_flush_young(struct vm_area_struct *vma,
>  #endif
>  
>  #ifndef __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH
> -int pmdp_clear_flush_young(struct vm_area_struct *vma,
> -unsigned long address, pmd_t *pmdp);
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +extern int pmdp_clear_flush_young(struct vm_area_struct *vma,
> +   unsigned long address, pmd_t *pmdp);
> +#else
> +/*
> + * Despite relevant to THP only, this API is called from generic rmap code
> + * under PageTransHuge(), hence needs a dummy implementation for !THP
> + */

Looks like a case I described above. BUILD_BUG_ON() should work fine here.

> +static inline int pmdp_clear_flush_young(struct vm_area_struct *vma,
> +  unsigned long address, pmd_t *pmdp)
> +{
> + BUG();
> + return 0;
> +}
> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  #endif

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

Re: [PATCH v2 00/12] THP support for ARC

[Kirill A. Shutemov]

On Fri, Oct 09, 2015 at 03:03:26PM +0530, Vineet Gupta wrote:
> On Thursday 01 October 2015 11:32 AM, Vineet Gupta wrote:
> > On Tuesday 22 September 2015 04:04 PM, Vineet Gupta wrote:
> >> > Hi,
> >> > 
> >> > This series brings THP support to ARC. It also introduces an optional new
> >> > thp hook for arches to possibly optimize the TLB flush in thp regime.
> >> > 
> >> > Please review !
> >> > 
> >> > Changes Since v1 [*]
> >> >- Rebased against v4.3-rc2
> >> >- Switched ARC pgtable_t to pte_t *   (Kiril)
> >> >- Removed stub implementations for(Andrew)
> >> >  pmdp_set_access_flags, pmdp_test_and_clear_young, pmdp_set_wrprotect,
> >> >  pmdp_collapse_flush, pmd_same
> >> > 
> >> > [*] 
> >> > http://lkml.kernel.org/r/1440666194-21478-1-git-send-email-vgu...@synopsys.com
> >> > 
> >> > Vineet Gupta (12):
> >> >   ARC: mm: switch pgtable_to to pte_t *
> >> >   ARC: mm: pte flags comsetic cleanups, comments
> >> >   ARC: mm: Introduce PTE_SPECIAL
> >> >   Documentation/features/vm: pte_special now supported by ARC
> >> >   ARCv2: mm: THP support
> >> >   ARCv2: mm: THP: boot validation/reporting
> >> >   Documentation/features/vm: THP now supported by ARC
> >> >   mm: move some code around
> >> >   mm,thp: reduce ifdef'ery for THP in generic code
> >> >   mm,thp: introduce flush_pmd_tlb_range
> >> >   ARCv2: mm: THP: Implement flush_pmd_tlb_range() optimization
> >> >   ARCv2: Add a DT which enables THP
> >> > 
> >> >  Documentation/features/vm/THP/arch-support.txt |  2 +-
> >> >  .../features/vm/pte_special/arch-support.txt   |  2 +-
> >> >  arch/arc/Kconfig   |  4 +
> >> >  arch/arc/boot/dts/hs_thp.dts   | 59 +
> >> >  arch/arc/include/asm/hugepage.h| 82 
> >> > ++
> >> >  arch/arc/include/asm/page.h|  5 +-
> >> >  arch/arc/include/asm/pgalloc.h |  6 +-
> >> >  arch/arc/include/asm/pgtable.h | 60 +++--
> >> >  arch/arc/mm/tlb.c  | 76 
> >> > -
> >> >  arch/arc/mm/tlbex.S| 21 +++--
> >> >  include/asm-generic/pgtable.h  | 49 ---
> >> >  mm/huge_memory.c   |  2 +-
> >> >  mm/pgtable-generic.c   | 99 
> >> > ++
> >> >  13 files changed, 345 insertions(+), 122 deletions(-)
> >> >  create mode 100644 arch/arc/boot/dts/hs_thp.dts
> >> >  create mode 100644 arch/arc/include/asm/hugepage.h
> > Andrew, Kirill, could you please review/ack the generic mm bits atleast so 
> > I can
> > proceed with moving the stuff into linux-next !
> 
> Ping 2 !

Sorry.

> Can I please get some acks on the generic mm bits. Some of the changes
> will likely collide Kirill's THP rework !

Could you check if it acctually collides?

> Given people rebase off of mmtomm would it be better if generic patches went 
> thru
> Andrew and probably included sooner for 4.4 target ?
> 
> -Vineet
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

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

Re: [PATCH] panic: release stale console lock to always get the logbuf printed out

[Vitaly Kuznetsov]

Andrew Morton  writes:

> On Thu, 08 Oct 2015 12:03:25 +0200 Vitaly Kuznetsov  
> wrote:
>
>> > If we picked up patch "kernel: Avoid softlockups in
>> > stop_machine() during heavy printing" from my series (it's completely
>> > independent, I've attached the latest version), the result would look less
>> > hacky to me (attached). Thoughts?
>> 
>> Haven't tested it but should also work...
>
> Well, I expect we'll be merging Jan's lockup-avoidance code fairly
> soon.  There's no point in solving the same problem twice.
>
> Sp please, do take a closer look at the proposed patches and if
> possible, runtime test them?

Sure, I'll take a look.

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

Re: [PATCH] panic: release stale console lock to always get the logbuf printed out

[Vitaly Kuznetsov]

Andrew Morton  writes:

> On Thu, 08 Oct 2015 11:51:13 +0200 Vitaly Kuznetsov  
> wrote:
>
>> > On Wed,  7 Oct 2015 19:02:22 +0200 Vitaly Kuznetsov  
>> > wrote:
>> >
>> >> In some cases we may end up killing the CPU holding the console lock
>> >> while still having valuable data in logbuf. E.g. I'm observing the
>> >> following:
>> >> - A crash is happening on one CPU and console_unlock() is being called on
>> >>   some other.
>> >> - console_unlock() tries to print out the buffer before releasing the lock
>> >>   and on slow console it takes time.
>> >> - in the meanwhile crashing CPU does lots of printk()-s with valuable data
>> >>   (which go to the logbuf) and sends IPIs to all other CPUs.
>> >> - console_unlock() finishes printing previous chunk and enables interrupts
>> >>   before trying to print out the rest, the CPU catches the IPI and never
>> >>   releases console lock.
>> >
>> > Why doesn't the lock-owning CPU release the console lock?  Because it
>> > was stopped by smp_send_stop() in panic()?
>> >
>> > I don't recall why we stop CPUs in panic(), and of course we didn't
>> > document the reason.  I guess it makes sense from the "what else can we
>> > do" point of view, but I wonder if we can just do it later on - that
>> > would fix this problem?
>> 
>> We don't know for how long should we wait for the other CPU to finish
>> the output and it can take some time. In case we're rebooting after a
>> short timeout we can still end up with something in the logbuf.
>
> I don't understand what you're saying here.
>
> If we move panic()'s call to smp_send_stop() so it occurs later in
> panic(), won't this result in this CPU's messages being properly
> displayed?

If some other CPU is printing, for how long do we need to wait before we
try to stop it? It can take *any* amount of time to print out the buffer
-- we can even reboot the host earlier.

> The currently-printing CPU will still be running and all
> the printks will proceed in the normal fashion?

It will be running till we reboot the host, and we need to make sure
there is nothing in the buffer when we do that. I see only two viable
options: make sure the crashing cpu prints out the buffer before we
reboot (natural serialization) or some sort of lock-waiting to make sure
the printing CPU is done with its job.

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

Re: [PATCH 4/9] net/can: can_dropped_invalid_skb can be boolean

[Marc Kleine-Budde]

On 10/08/2015 03:28 PM, Yaowei Bai wrote:
> This patch makes can_dropped_invalid_skb return bool due to this
> particular function only using either one or zero as its return
> value.
> 
> No functional change.
> 
> Signed-off-by: Yaowei Bai 

Acked-by: Marc Kleine-Budde 

Yaowei, feel free to send the CAN patch as part of your series directly
to David.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized

[Joerg Roedel]

On Tue, Oct 06, 2015 at 09:13:11PM +0800, Jiang Liu wrote:
>   We are on leave for Chinese National Holiday and has limited
> access to my working environment. It would be appreciated if you could
> help to send out a patch for it. Otherwise I will send out a patch
> within 2-3 days.

Okay, I just sent the patch.


Joerg

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

Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

[Paolo Bonzini]

On 09/10/2015 10:50, Peter Zijlstra wrote:
> Not having actually read or thought about the issue at hand, its
> perfectly valid to pair an smp_mb() with either spin_lock() or
> spin_unlock().
> 
> IOW. MB <-> {ACQUIRE, RELEASE} is a valid pairing.

In this case it's an smp_mb() (store-load barrier) being paired with
another smp_mb(), so spin_unlock()'s release is not enough.

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

[PATCH] x86/PCI: Don't alloc pcibios-irq when MSI is enabled

[Joerg Roedel]

From: Joerg Roedel 

The pcibios-irq and MSI both use dev->irq to store the IRQ
number. While the MSI code checks for that and frees the
pcibios-irq before overwriting dev->irq, the
pcibios_alloc_irq function does not.

Usually this is not a problem, as the pcibios-irq is
allocated before probe time of the device and the MSI irq is
allocted from the drivers probe path.

But there are PCI devices handled by the core kernel and not
by a standard pci driver, like the AMD IOMMU for example.
For the AMD IOMMU a normal pci device driver does not make
sense, because a driver can be forcibly unbound from its
device, which is not a good idea for an IOMMU.

Nevertheless the PCI core code tries to match the PCI device
implementing the AMD IOMMU against drivers, and
allocates/frees a pcibios IRQ every time it tries out a new
driver. This overwrites the dev->irq field set by
pci_enable_msi() and sets it to 0 in the end (because the
probe fails and the pcibios-irq is freed again).

On suspend/resume this breaks the kernel, because the irq
descriptor for irq 0 is NULL.

Fix this by not allocating a pcibios-irq when MSI is
already active. This also has the benefit, that a device
claimed by the core kernel can not be probed by a pci driver
later.

Cc: Jiang Liu 
Reported-by: Borislav Petkov 
Signed-off-by: Joerg Roedel 
---
 arch/x86/pci/common.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index dc78a4a..6254c06 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -675,6 +675,14 @@ int pcibios_add_device(struct pci_dev *dev)
 
 int pcibios_alloc_irq(struct pci_dev *dev)
 {
+   /*
+* If the PCI device was already claimed by core code and has
+* MSI enabled, probing of the pcibios irq will overwrite
+* dev->irq.  So bail out if MSI is already enabled.
+*/
+   if (pci_dev_msi_enabled(dev))
+   return -EBUSY;
+
return pcibios_enable_irq(dev);
 }
 
-- 
1.9.1

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

[PATCH v4 2/6] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Add the pin-controller driver for Marvell Berlin BG4CT SoC, with definition
of its groups and functions. This uses the core Berlin pinctrl driver.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/Kconfig|   5 +
 drivers/pinctrl/berlin/Makefile   |   1 +
 drivers/pinctrl/berlin/berlin-bg4ct.c | 503 ++
 3 files changed, 509 insertions(+)
 create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c

diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index b18322b..c13f6d2 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -17,4 +17,9 @@ config PINCTRL_BERLIN_BG2Q
bool
select PINCTRL_BERLIN
 
+config PINCTRL_BERLIN_BG4CT
+   depends on OF && (ARCH_BERLIN || COMPILE_TEST)
+   bool "Marvell berlin4ct pin controller driver"
+   select PINCTRL_BERLIN
+
 endif
diff --git a/drivers/pinctrl/berlin/Makefile b/drivers/pinctrl/berlin/Makefile
index deb0c6b..06f9402 100644
--- a/drivers/pinctrl/berlin/Makefile
+++ b/drivers/pinctrl/berlin/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PINCTRL_BERLIN)+= berlin.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2)   += berlin-bg2.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2CD) += berlin-bg2cd.o
 obj-$(CONFIG_PINCTRL_BERLIN_BG2Q)  += berlin-bg2q.o
+obj-$(CONFIG_PINCTRL_BERLIN_BG4CT) += berlin-bg4ct.o
diff --git a/drivers/pinctrl/berlin/berlin-bg4ct.c 
b/drivers/pinctrl/berlin/berlin-bg4ct.c
new file mode 100644
index 000..0917204
--- /dev/null
+++ b/drivers/pinctrl/berlin/berlin-bg4ct.c
@@ -0,0 +1,503 @@
+/*
+ * Marvell berlin4ct pinctrl driver
+ *
+ * Copyright (C) 2015 Marvell Technology Group Ltd.
+ *
+ * Author: Jisheng Zhang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "berlin.h"
+
+static const struct berlin_desc_group berlin4ct_soc_pinctrl_groups[] = {
+   BERLIN_PINCTRL_GROUP("EMMC_RSTn", 0x0, 0x3, 0x00,
+   BERLIN_PINCTRL_FUNCTION(0x0, "emmc"), /* RSTn */
+   BERLIN_PINCTRL_FUNCTION(0x1, "gpio")), /* GPIO47 */
+   BERLIN_PINCTRL_GROUP("NAND_IO0", 0x0, 0x3, 0x03,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO0 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD0 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* CLK */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO0 */
+   BERLIN_PINCTRL_GROUP("NAND_IO1", 0x0, 0x3, 0x06,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO1 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD1 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* CDn */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO1 */
+   BERLIN_PINCTRL_GROUP("NAND_IO2", 0x0, 0x3, 0x09,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO2 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD2 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT0 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO2 */
+   BERLIN_PINCTRL_GROUP("NAND_IO3", 0x0, 0x3, 0x0c,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO3 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXD3 */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT1 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO3 */
+   BERLIN_PINCTRL_GROUP("NAND_IO4", 0x0, 0x3, 0x0f,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO4 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXC */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT2 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO4 */
+   BERLIN_PINCTRL_GROUP("NAND_IO5", 0x0, 0x3, 0x12,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO5 */
+   BERLIN_PINCTRL_FUNCTION(0x1, "rgmii"), /* RXCTL */
+   BERLIN_PINCTRL_FUNCTION(0x2, "sd1"), /* DAT3 */
+   BERLIN_PINCTRL_FUNCTION(0x3, "gpio")), /* GPIO5 */
+   BERLIN_PINCTRL_GROUP("NAND_IO6", 0x0, 0x3, 0x15,
+   BERLIN_PINCTRL_FUNCTION(0x0, "nand"), /* IO6 */
+   

[PATCH v4 4/6] pinctrl: dt-binding: document berlin4ct SoC pinctrl

[Jisheng Zhang]

Add berlin4ct to existing berlin pinctrl device tree binding.

Signed-off-by: Jisheng Zhang 
---
 Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
index a8bb5e2..f8fa28c 100644
--- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
@@ -20,7 +20,10 @@ Required properties:
"marvell,berlin2cd-soc-pinctrl",
"marvell,berlin2cd-system-pinctrl",
"marvell,berlin2q-soc-pinctrl",
-   "marvell,berlin2q-system-pinctrl"
+   "marvell,berlin2q-system-pinctrl",
+   "marvell,berlin4ct-avio-pinctrl",
+   "marvell,berlin4ct-soc-pinctrl",
+   "marvell,berlin4ct-system-pinctrl"
 
 Required subnode-properties:
 - groups: a list of strings describing the group names.
-- 
2.6.1

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

[PATCH v4 1/6] pinctrl: berlin: introduce berlin_pinctrl_probe_regmap()

[Jisheng Zhang]

This is to prepare for the next berlin4ct support, where we won't use
simple-mfd any more.

Signed-off-by: Jisheng Zhang 
---
 drivers/pinctrl/berlin/berlin.c | 26 +-
 drivers/pinctrl/berlin/berlin.h |  4 
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
index f495806..898afa4 100644
--- a/drivers/pinctrl/berlin/berlin.c
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -292,20 +292,14 @@ static struct pinctrl_desc berlin_pctrl_desc = {
.owner  = THIS_MODULE,
 };
 
-int berlin_pinctrl_probe(struct platform_device *pdev,
-const struct berlin_pinctrl_desc *desc)
+int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
+   const struct berlin_pinctrl_desc *desc,
+   struct regmap *regmap)
 {
struct device *dev = >dev;
-   struct device_node *parent_np = of_get_parent(dev->of_node);
struct berlin_pinctrl *pctrl;
-   struct regmap *regmap;
int ret;
 
-   regmap = syscon_node_to_regmap(parent_np);
-   of_node_put(parent_np);
-   if (IS_ERR(regmap))
-   return PTR_ERR(regmap);
-
pctrl = devm_kzalloc(dev, sizeof(*pctrl), GFP_KERNEL);
if (!pctrl)
return -ENOMEM;
@@ -330,3 +324,17 @@ int berlin_pinctrl_probe(struct platform_device *pdev,
 
return 0;
 }
+
+int berlin_pinctrl_probe(struct platform_device *pdev,
+const struct berlin_pinctrl_desc *desc)
+{
+   struct device *dev = >dev;
+   struct device_node *parent_np = of_get_parent(dev->of_node);
+   struct regmap *regmap = syscon_node_to_regmap(parent_np);
+
+   of_node_put(parent_np);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   return berlin_pinctrl_probe_regmap(pdev, desc, regmap);
+}
diff --git a/drivers/pinctrl/berlin/berlin.h b/drivers/pinctrl/berlin/berlin.h
index e1aa841..dabbd2a 100644
--- a/drivers/pinctrl/berlin/berlin.h
+++ b/drivers/pinctrl/berlin/berlin.h
@@ -58,4 +58,8 @@ struct berlin_pinctrl_function {
 int berlin_pinctrl_probe(struct platform_device *pdev,
 const struct berlin_pinctrl_desc *desc);
 
+int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
+   const struct berlin_pinctrl_desc *desc,
+   struct regmap *regmap);
+
 #endif /* __PINCTRL_BERLIN_H */
-- 
2.6.1

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

[PATCH v4 5/6] arm64: dts: berlin4ct: add the pinctrl node

[Jisheng Zhang]

Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
index a3b5f1d..8e66355 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
@@ -225,6 +225,16 @@
};
};
 
+   soc_pinctrl: pin-controller@ea8000 {
+   compatible = "marvell,berlin4ct-soc-pinctrl";
+   reg = <0xea8000 0x14>;
+   };
+
+   avio_pinctrl: pin-controller@ea8400 {
+   compatible = "marvell,berlin4ct-avio-pinctrl";
+   reg = <0xea8400 0x8>;
+   };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -280,5 +290,10 @@
status = "disabled";
};
};
+
+   system_pinctrl: pin-controller@fe2200 {
+   compatible = "marvell,berlin4ct-system-pinctrl";
+   reg = <0xfe2200 0xc>;
+   };
};
 };
-- 
2.6.1

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

[GIT PULL] sound fixes for 4.3-rc5

[Takashi Iwai]

Linus,

please pull sound fixes for v4.3-rc5 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.3-rc5

The topmost commit is 601d62959d08a450d4666c728ddd2f47c5ba1cfe



sound fixes for 4.3-rc5

We see various small fixes, but nothing looks too scary, all are
small gentle bug fixes:
- Most of changes are for ASoC codecs: Realtek, SGTL5000, TAS2552,
  TLV320, WM8962
- A couple of dwc and imx-ssi fixes
- Usual oneliner HD-audio quirks
- An old emux synth code fix



Andreas Dannenberg (1):
  ASoC: tas2552: fix dBscale-min declaration

Benoît Thébaudeau (1):
  ASoC: imx-ssi: Fix DAI hardware signal inversions

Gianluca Renzi (2):
  ASoC: sgtl5000: fix error message output for MicBias voltage
  ASoC: sgtl5000: fix wrong register MIC_BIAS_VOLTAGE setup on probe

Jiada Wang (1):
  ASoC: wm8962: balance pm_runtime_enable

John Flatness (1):
  ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1

Lars-Peter Clausen (1):
  ASoC: db1200: Fix DAI link format for db1300 and db1550

Laura Abbott (1):
  ALSA: hda: Add dock support for ThinkPad T550

Mark Brown (1):
  MAINTAINERS: Remove wm97xx entry

Oder Chiou (1):
  ASoC: rt5645: Correct the naming and setting of ADC Boost Volume Control

Rick Mann (1):
  ASoC: tlv320aic3x: Prevent writing reserved registers on tlv320aic3104 
CODECs

Takashi Iwai (2):
  ALSA: hda - Disable power_save_node for IDT 92HD73xx chips
  ALSA: synth: Fix conflicting OSS device registration on AWE32

Yitian Bu (1):
  ASoC: dwc: correct irq clear method

yitian (1):
  ASoC: dwc: fix dma stop transferring issue

---
 MAINTAINERS|  9 -
 sound/pci/hda/patch_cirrus.c   |  1 +
 sound/pci/hda/patch_realtek.c  |  1 +
 sound/pci/hda/patch_sigmatel.c |  6 +-
 sound/soc/au1x/db1200.c|  4 
 sound/soc/codecs/rt5645.c  |  6 +++---
 sound/soc/codecs/rt5645.h  | 16 +---
 sound/soc/codecs/sgtl5000.c|  6 +++---
 sound/soc/codecs/tas2552.c |  2 +-
 sound/soc/codecs/tlv320aic3x.c | 19 +++
 sound/soc/codecs/wm8962.c  |  5 -
 sound/soc/dwc/designware_i2s.c | 19 ++-
 sound/soc/fsl/imx-ssi.c| 19 +--
 sound/synth/emux/emux_oss.c|  3 ++-
 14 files changed, 67 insertions(+), 49 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 797236befd27..60aacd88bd7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11378,15 +11378,6 @@ W: http://oops.ghostprotocols.net:81/blog
 S: Maintained
 F: drivers/net/wireless/wl3501*
 
-WM97XX TOUCHSCREEN DRIVERS
-M: Mark Brown 
-M: Liam Girdwood 
-L: linux-in...@vger.kernel.org
-W: https://github.com/CirrusLogic/linux-drivers/wiki
-S: Supported
-F: drivers/input/touchscreen/*wm97*
-F: include/linux/wm97xx.h
-
 WOLFSON MICROELECTRONICS DRIVERS
 L: patc...@opensource.wolfsonmicro.com
 T: git https://github.com/CirrusLogic/linux-drivers.git
diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index 584a0343ab0c..85813de26da8 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -633,6 +633,7 @@ static const struct snd_pci_quirk cs4208_mac_fixup_tbl[] = {
SND_PCI_QUIRK(0x106b, 0x5e00, "MacBookPro 11,2", CS4208_MBP11),
SND_PCI_QUIRK(0x106b, 0x7100, "MacBookAir 6,1", CS4208_MBA6),
SND_PCI_QUIRK(0x106b, 0x7200, "MacBookAir 6,2", CS4208_MBA6),
+   SND_PCI_QUIRK(0x106b, 0x7b00, "MacBookPro 12,1", CS4208_MBP11),
{} /* terminator */
 };
 
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index afec6dc9f91f..16b8dcba5c12 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5306,6 +5306,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x2212, "Thinkpad T440", 
ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2214, "Thinkpad X240", 
ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2215, "Thinkpad", 
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
+   SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", 
ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", 
ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
SND_PCI_QUIRK(0x17aa, 0x3978, "IdeaPad Y410P", ALC269_FIXUP_NO_SHUTUP),
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 9d947aef2c8b..def5cc8dff02 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -4520,7 +4520,11 @@ static int patch_stac92hd73xx(struct hda_codec *codec)
return err;
 
spec = codec->spec;
-   codec->power_save_node = 1;
+   /* enable power_save_node only for new 92HD89xx 

[PATCH 1/2] i2c: designware: add High-speed mode support

[wangxfdu]

From: Xiang Wang 

1. Add High-speed mode support in designware core
2. Add function i2c_dw_acpi_setup_speed to determine
the bus speed from ACPI table.

Signed-off-by: Xiang Wang 
---
 drivers/i2c/busses/i2c-designware-core.c | 88 
 drivers/i2c/busses/i2c-designware-core.h | 11 
 2 files changed, 99 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-core.c 
b/drivers/i2c/busses/i2c-designware-core.c
index 6f19a33..f5c0d18 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "i2c-designware-core.h"
 
 /*
@@ -42,6 +43,8 @@
 #define DW_IC_SS_SCL_LCNT  0x18
 #define DW_IC_FS_SCL_HCNT  0x1c
 #define DW_IC_FS_SCL_LCNT  0x20
+#define DW_IC_HS_SCL_HCNT  0x24
+#define DW_IC_HS_SCL_LCNT  0x28
 #define DW_IC_INTR_STAT0x2c
 #define DW_IC_INTR_MASK0x30
 #define DW_IC_RAW_INTR_STAT0x34
@@ -358,6 +361,16 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
dw_writel(dev, lcnt, DW_IC_FS_SCL_LCNT);
dev_dbg(dev->dev, "Fast-mode HCNT:LCNT = %d:%d\n", hcnt, lcnt);
 
+   if (dev->hs_hcnt && dev->hs_lcnt) {
+   hcnt = dev->hs_hcnt;
+   lcnt = dev->hs_lcnt;
+
+   dw_writel(dev, hcnt, DW_IC_HS_SCL_HCNT);
+   dw_writel(dev, lcnt, DW_IC_HS_SCL_LCNT);
+   dev_dbg(dev->dev, "High-speed mode HCNT:LCNT = %d:%d\n",
+   hcnt, lcnt);
+   }
+
/* Configure SDA Hold Time if required */
if (dev->sda_hold_time) {
reg = dw_readl(dev, DW_IC_COMP_VERSION);
@@ -381,6 +394,81 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
 }
 EXPORT_SYMBOL_GPL(i2c_dw_init);
 
+#ifdef CONFIG_ACPI
+static int i2c_dw_acpi_get_freq(struct acpi_resource *ares, void *data)
+{
+   struct dw_i2c_dev *i2c = data;
+   struct acpi_resource_i2c_serialbus *sb;
+   u32 i2c_speed;
+
+   if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
+   sb = >data.i2c_serial_bus;
+
+   if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
+   i2c_speed = sb->connection_speed;
+   if (i2c_speed == DW_STD_SPEED) {
+   i2c->master_cfg &= ~DW_IC_SPEED_MASK;
+   i2c->master_cfg |= DW_IC_CON_SPEED_STD;
+   } else if (i2c_speed == DW_FAST_SPEED) {
+   i2c->master_cfg &= ~DW_IC_SPEED_MASK;
+   i2c->master_cfg |= DW_IC_CON_SPEED_FAST;
+   } else if (i2c_speed == DW_HIGH_SPEED) {
+   i2c->master_cfg &= ~DW_IC_SPEED_MASK;
+   i2c->master_cfg |= DW_IC_CON_SPEED_HIGH;
+   } else {
+   dev_err(i2c->dev, "unsupported speed: %d\n",
+   i2c_speed);
+   }
+
+   dev_dbg(i2c->dev, "i2c device speed from acpi = %d\n",
+   i2c_speed);
+   }
+   }
+
+   return 1;
+}
+
+static acpi_status acpi_i2c_find_device_speed(acpi_handle handle, u32 level,
+   void *data, void **return_value)
+{
+   struct dw_i2c_dev *i2c = data;
+   struct list_head resource_list;
+   struct acpi_device *adev;
+
+   if (acpi_bus_get_device(handle, ))
+   return AE_OK;
+   if (acpi_bus_get_status(adev) || !adev->status.present)
+   return AE_OK;
+
+   INIT_LIST_HEAD(_list);
+   acpi_dev_get_resources(adev, _list,
+   i2c_dw_acpi_get_freq, i2c);
+   acpi_dev_free_resource_list(_list);
+
+   return AE_OK;
+}
+
+void i2c_dw_acpi_setup_speed(struct device *pdev, struct dw_i2c_dev *dev)
+{
+   acpi_handle handle = ACPI_HANDLE(pdev);
+   acpi_status status;
+
+   if (handle == NULL)
+   return;
+
+   /* Find I2C adapter bus frequency */
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
+acpi_i2c_find_device_speed, NULL,
+dev, NULL);
+   if (ACPI_FAILURE(status))
+   dev_warn(pdev, "failed to get I2C bus freq\n");
+}
+
+#else
+void i2c_dw_acpi_setup_speed(struct device *pdev, struct dw_i2c_dev *dev) {}
+#endif
+EXPORT_SYMBOL_GPL(i2c_dw_acpi_setup_speed);
+
 /*
  * Waiting for bus not busy
  */
diff --git a/drivers/i2c/busses/i2c-designware-core.h 
b/drivers/i2c/busses/i2c-designware-core.h
index 9630222..16f53d8 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -24,12 +24,17 @@
 
 
 #define DW_IC_CON_MASTER   0x1
+#define DW_IC_SPEED_MASK   0x6
 #define 

[PATCH v3 5/5] ARM: sun5i: Add C.H.I.P DTS

[Maxime Ripard]

The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
and two connectors to plug additional boards on top of it.

Signed-off-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/Makefile  |   3 +-
 arch/arm/boot/dts/sun5i-r8-chip.dts | 213 
 2 files changed, 215 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 342ab3116feb..bf165ed4e7fa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-q8-tablet.dtb \
-   sun5i-a13-utoo-p66.dtb
+   sun5i-a13-utoo-p66.dtb \
+   sun5i-r8-chip.dtb
 dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts 
b/arch/arm/boot/dts/sun5i-r8-chip.dts
new file mode 100644
index ..0d450a828372
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -0,0 +1,213 @@
+/*
+ * Copyright 2015 Free Electrons
+ * Copyright 2015 NextThing Co
+ *
+ * Maxime Ripard 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-r8.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "NextThing C.H.I.P.";
+   compatible = "nextthing,chip", "allwinner,sun5i-r8";
+
+   aliases {
+   i2c0 = 
+   i2c2 = 
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+
+   /*
+* The interrupt is routed through the "External Fast
+* Interrupt Request" pin (ball G13 of the module)
+* directly to the main interrupt controller, without
+* any other controller interfering.
+*/
+   interrupts = <0>;
+   };
+};
+
+#include "axp209.dtsi"
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   xio: gpio@38 {
+   compatible = "nxp,pcf8574a";
+   reg = <0x38>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <6 0 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   non-removable;

Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to allow consolidation

[Peter Zijlstra]

On Thu, Oct 08, 2015 at 05:10:21PM -0700, Paul E. McKenney wrote:
> > Note that there are rnp->lock acquires without the extra barrier though,
> > so you seem somewhat inconsistent with your own rule.
> > 
> > See for example:
> > 
> > rcu_dump_cpu_stacks()
> > print_other_cpu_stall()
> > print_cpu_stall()
> > 
> > (did not do an exhaustive scan, there might be more)
> > 
> > and yes, that is 'obvious' debug code and not critical to the correct
> > behaviour of the code, but it is a deviation from 'the rule'.
> 
> How about the following patch on top of yours?

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

Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

[Paolo Bonzini]

On 09/10/2015 02:35, Kosuke Tatsukawa wrote:
> async_pf_executekvm_vcpu_block
> 
> spin_lock(>async_pf.lock);
> if (waitqueue_active(>wq))
> /* The CPU might reorder the test for
>the waitqueue up here, before
>prior writes complete */
> prepare_to_wait(>wq, ,
>   TASK_INTERRUPTIBLE);
> /*if (kvm_vcpu_check_block(vcpu) < 0) */
>  /*if (kvm_arch_vcpu_runnable(vcpu)) { */
>   ...
>   return (vcpu->arch.mp_state == 
> KVM_MP_STATE_RUNNABLE &&
> !vcpu->arch.apf.halted)
> || 
> !list_empty_careful(>async_pf.done)
>  ...

The new memory barrier isn't "paired" with any other, and in
fact I think that the same issue exists on the other side: 
list_empty_careful(>async_pf.done) may be reordered up,
before the prepare_to_wait:

spin_lock(>async_pf.lock);
(vcpu->arch.mp_state == 
KVM_MP_STATE_RUNNABLE &&
!vcpu->arch.apf.halted)
|| 
!list_empty_careful(>async_pf.done)
...
prepare_to_wait(>wq, ,
  TASK_INTERRUPTIBLE);
/*if (kvm_vcpu_check_block(vcpu) < 0) */
 /*if (kvm_arch_vcpu_runnable(vcpu)) { */
  ...
 return 0;
list_add_tail(>link,
  >async_pf.done);
spin_unlock(>async_pf.lock);
waited = true;
schedule();
if (waitqueue_active(>wq))

So you need another smp_mb() after prepare_to_wait().  I'm not sure
if it's needed also for your original tty report, but I think it is
for https://lkml.org/lkml/2015/10/8/989 ("mei: fix waitqueue_active
without memory barrier in mei drivers").

I wonder if it makes sense to introduce smp_mb__before_spin_lock()
and smp_mb__after_spin_unlock().  On x86 the former could be a
simple compiler barrier, and on s390 both of them could.  But that
should be a separate patch.

Thanks,

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

Re: [RFC PATCH 1/2] ext4: Fix possible deadlock with local interrupts disabled and page-draining IPI

[Nikolay Borisov]

On 10/09/2015 11:41 AM, Gilad Ben-Yossef wrote:
> On Oct 8, 2015 18:31, "Nikolay Borisov"  wrote:
>>
>> Currently when bios are being finished in ext4_finish_bio this is done by
>> first disabling interrupts and then acquiring a bit_spin_lock.
> ...
>>
>> To fix the situation this patch changes the order in which the
>> bit_spin_lock and interrupts disabling occcurs. The exepected
>> effect is that even if a core is spinning on the bitlock it will
>> have its interrupts enabled, thus being able to respond to IPIs.
> 
> Are you sure this spin lock is never taken from interrupt context?

Good point.

I think indeed this fix is wrong as this lock is actually taken from
soft irq context as evident from this thread, which prompted me to write
the patch in the first place:
http://permalink.gmane.org/gmane.linux.kernel/2056730


> If it does an interrupt occurring after the lock is taken and before
> interrupts are disabled can deadlock .
> 
> Gilad
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] arm64: dts: apq8016-sbc: enable i2c buses on LS and HS

[Srinivas Kandagatla]

This patch enables i2c buses on low speed and high speed expansion
connectors on DB410C.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 3fc3be4..cd1d0b5 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -34,6 +34,21 @@
pinctrl-1 = <_uart2_sleep>;
};
 
+   i2c@78b6000 {
+   /* On Low speed expansion */
+   status = "okay";
+   };
+
+   i2c@78b8000 {
+   /* On High speed expansion */
+   status = "okay";
+   };
+
+   i2c@78ba000 {
+   /* On Low speed expansion */
+   status = "okay";
+   };
+
leds {
pinctrl-names = "default";
pinctrl-0 = <_leds>,
-- 
1.9.1

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

[PATCH v2 2/4] arm64: dts: qcom: Add msm8916 I2C nodes.

[Srinivas Kandagatla]

This patch adds missing support for i2c0 and i2c6, this support is
required to connect the i2c slaves on LS expansion on DB410c.

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 48 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  | 30 +++
 2 files changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index a6105d7..49ec55a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -265,6 +265,30 @@
};
};
 
+   i2c2_default: i2c2_default {
+   pinmux {
+   function = "blsp_i2c2";
+   pins = "gpio6", "gpio7";
+   };
+   pinconf {
+   pins = "gpio6", "gpio7";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
+   i2c2_sleep: i2c2_sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio6", "gpio7";
+   };
+   pinconf {
+   pins = "gpio6", "gpio7";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
i2c4_default: i2c4_default {
pinmux {
function = "blsp_i2c4";
@@ -289,6 +313,30 @@
};
};
 
+   i2c6_default: i2c6_default {
+   pinmux {
+   function = "blsp_i2c6";
+   pins = "gpio22", "gpio23";
+   };
+   pinconf {
+   pins = "gpio22", "gpio23";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
+   i2c6_sleep: i2c6_sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio22", "gpio23";
+   };
+   pinconf {
+   pins = "gpio22", "gpio23";
+   drive-strength = <2>;
+   bias-disable = <0>;
+   };
+   };
+
sdhc2_cd_pin {
sdc2_cd_on: cd_on {
pinmux {
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 85f7bee..2c86234 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -233,6 +233,21 @@
status = "disabled";
};
 
+   blsp_i2c2: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b6000 0x1000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_default>;
+   pinctrl-1 = <_sleep>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
blsp_i2c4: i2c@78b8000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0x78b8000 0x1000>;
@@ -248,6 +263,21 @@
status = "disabled";
};
 
+   blsp_i2c6: i2c@78ba000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78ba000 0x1000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP6_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_default>;
+   pinctrl-1 = <_sleep>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
sdhc_1: sdhci@07824000 {
compatible = "qcom,sdhci-msm-v4";
reg = <0x07824900 0x11c>, <0x07824000 0x800>;
-- 
1.9.1

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

[PATCH v2 4/4] arm64: dts: apq8016-sbc: enable spi buses on LS and HS

[Srinivas Kandagatla]

This patch enables spi buses on low speed and high speed expansion
connectors on DB410C

Signed-off-by: Srinivas Kandagatla 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index cd1d0b5..64b06d8 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -49,6 +49,16 @@
status = "okay";
};
 
+   spi@78b7000 {
+   /* On High speed expansion */
+   status = "okay";
+   };
+
+   spi@78b9000 {
+   /* On Low speed expansion */
+   status = "okay";
+   };
+
leds {
pinctrl-names = "default";
pinctrl-0 = <_leds>,
-- 
1.9.1

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

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 09/10/15 09:51, Bharat Kumar Gogada wrote:
>> On 09/10/15 06:11, Bharat Kumar Gogada wrote:
>> +struct nwl_msi {  /* struct nwl_msi - MSI information
 */
>> +  struct msi_controller chip; /* chip: MSI controller */
>
>> We're moving away from msi_controller altogether, as the kernel now
>> has all the necessary infrastructure to do this properly.
>
> Our current GIC version does not have separate msi controller (we
> are not using GICv2m or GICv3), so is it necessary to have separate
> msi controller node ? Please give me clarity on this.

 This has nothing to do with the version of the GIC you are using
 (XGene doesn't have GICv2m or v3 either). This is about reducing code
 duplication and having something that we can maintain. See also
 https://lkml.org/lkml/2015/9/20/193 for yet another example.

 I still plan to kill msi_controller, and I'd like to avoid more
 dependencies with it. MSI domains are the way to do it.

>>> Sorry previously I haven't configured my email client properly so resending.
>>
>> Thanks for doing so, much appreciated.
>>
>>> Since we don't have separate MSI controller, and our PCIe controller
>>> is handling MSI, is it necessary to create a separate MSI controller
>>> node because we don't have any 'reg' space.
>>
>> No, your PCI controller can perfectly be part of the PCIe node.
> You meant 'msi-controller' property to be part of PCIe node?

Yeah, sorry. Too early, not enough coffee.

>>
>>> Please let me know whether we require a separate msi file as suggested
>>> in your previous comments to separate MSI controller and PCIE
>>> controller in two files, if we don't have separate node. If we do not
>>> need a separate node do we need to embed MSI controller child node  in
>>> PCIe controller node itself, and what properties does this child node
>>> will require other than 'interrupts'.
>>
>> If you want to keep them in the same file, please at least have two separate
>> patches. These are two different functions, and they should be reviewed
>> separately.
>>
> What I meant is if we don't have separate msi node do we need separate file? 

That's up to you. Nodes and source code files don't have to match at all.

> If you meant msi controller to be part of same node then we will use single 
> file and will
> try to have two separate patches.

That's fine by me.

Thanks,

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

Re: [PATCH v4 5/6] arm64: dts: berlin4ct: add the pinctrl node

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:08PM +0800, Jisheng Zhang wrote:
> Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index a3b5f1d..8e66355 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -225,6 +225,16 @@
>   };
>   };
>  
> + soc_pinctrl: pin-controller@ea8000 {
> + compatible = "marvell,berlin4ct-soc-pinctrl";
> + reg = <0xea8000 0x14>;
> + };
> +
> + avio_pinctrl: pin-controller@ea8400 {
> + compatible = "marvell,berlin4ct-avio-pinctrl";
> + reg = <0xea8400 0x8>;
> + };
> +
>   apb@fc {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -280,5 +290,10 @@
>   status = "disabled";
>   };
>   };
> +
> + system_pinctrl: pin-controller@fe2200 {
> + compatible = "marvell,berlin4ct-system-pinctrl";
> + reg = <0xfe2200 0xc>;
> + };
>   };
>  };
> -- 
> 2.6.1
> 

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] arm64: dts: berlin4ct: add default pinmux for uart0

[Antoine Tenart]

On Fri, Oct 09, 2015 at 04:17:09PM +0800, Jisheng Zhang wrote:
> Add urt0 txd and rxd muxing setup in the dtsi because uart0 always uses
> them to work, no other possibilities.
> 
> Signed-off-by: Jisheng Zhang 

Acked-by: Antoine Tenart 

> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 8e66355..a4a1876 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -288,12 +288,19 @@
>   clocks = <>;
>   reg-shift = <2>;
>   status = "disabled";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";
>   };
>   };
>  
>   system_pinctrl: pin-controller@fe2200 {
>   compatible = "marvell,berlin4ct-system-pinctrl";
>   reg = <0xfe2200 0xc>;
> +
> + uart0_pmux: uart0-pmux {
> + groups = "SM_URT0_TXD", "SM_URT0_RXD";
> + function = "uart0";
> + };
>   };
>   };
>  };
> -- 
> 2.6.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: Re: Re: Re: Re: [PATCH v3] arm: Adding support for atomic half word exchange

[Will Deacon]

On Fri, Oct 09, 2015 at 02:41:54AM +, Sarbojit Ganguly wrote:
> Thank you Will, I will make the required corrections and mail it to
> patchesAtarm.linux.co.uk and mark [1] as "superseded".

Thanks. Also, you don't need to continually prepend "Re: " to your mail
subject every time you reply and/or update the patch. Doing so breaks
the email threading for everybody else.

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

Re: [RFC]: Possible race condition in kernel futex code

[Thomas Gleixner]

On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote:
> We did some tests with different compilers, kernel versions and kernel
> configs, with the following results:
> 
> Linux 3.12.48, x86_64_defconfig, GCC 4.6.1 :
> copy_user_generic_unrolled being used, so race condition possible
> Linux 3.12.48, x86_64_defconfig, GCC 4.9.1 :
> copy_user_generic_unrolled being used, so race condition possible
> Linux 4.2.3, x86_64_defconfig, GCC 4.6.1 : 32 bit read being used, no
> race condition
> Linux 4.2.3, x86_64_defconfig, GCC 4.9.1 : 32 bit read being used, no
> race condition
> 
> 
> Our idea to fix this problem is use an explicit 32 bit read in
> get_futex_value_locked() instead of using the generic function
> copy_from_user_inatomic() and hoping the compiler uses an atomic
> access and the right access size.

You cannot use an explicit 32bit read. We need an access which handles
the fault gracefully.

In current mainline this is done proper:

ret = __copy_from_user_inatomic(dst, src, size = sizeof(u32))

__copy_from_user_nocheck(dst, src, size)

   if (!__builtin_constant_p(size))
 return copy_user_generic(dst, (__force void *)src, size);

   size is constant so we end up in the switch case

   switch(size) {
   
   case 4:
__get_user_asm(*(u32 *)dst, (u32 __user *)src,
   ret, "l", "k", "=r", 4);
return ret;


In 3.12 this is different:

   __copy_from_user_inatomic()
copy_user_generic()
copy_user_generic_unrolled()

So this is only an issue for kernel versions < 3.13. It was fixed with

ff47ab4ff3cd: Add 1/2/4/8 byte optimization to 64bit 
__copy_{from,to}_user_inatomic

but nobody noticed that the race you described can happen, so it was
never backported to the stable kernels.

@stable: Can you please pick up ff47ab4ff3cd plus 

df90ca969035d x86, sparse: Do not force removal of __user when calling 
copy_to/from_user_nocheck()

for stable kernels <= 3.12?

If that's too much of churn, then I can come up with an explicit fix
for this. Let me know.

Thanks,

tglx


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

[RFC 0/3] eliminate potential race in string() (was: [PATCH] string: Improve the generic strlcpy() implementation)

[Rasmus Villemoes]

On Fri, Oct 09 2015, Rasmus Villemoes  wrote:

> It's hard not to agree with the overall "let's make it more robust if it
> can be done sanely+cheaply+cleanly". I was a bit skeptical about whether
> those three requirements could be met, since we'd have to do
> byte-by-byte traversal of the string, maybe-copying it to the output as
> we go along, but then right-alignment would require us to do a memmove,
> but not before we've done some complicated bookkeeping
> exercise. However, now that I read the source again, it seems that Al
> Viro already did that exercise when he added dentry(). So maybe it's
> doable without a net increase in LOC.

Something like this. The net increase is because I added a
comment. Passes the new printf test suite, but I'm not sure that's
thorough enough yet - still, it's better than nothing. There's also this
small bonus:

$ scripts/bloat-o-meter /tmp/vsprintf.o.{old,new}
add/remove: 1/0 grow/shrink: 0/2 up/down: 178/-245 (-67)
function old new   delta
widen_string.isra  - 178+178
string.isra  186 109 -77
dentry_name.isra 358 190-168


Rasmus Villemoes (3):
  lib/vsprintf.c: pull out padding code from dentry_name()
  lib/vsprintf.c: move string() below widen_string()
  lib/vsprintf.c: eliminate potential race in string()

 lib/vsprintf.c | 98 +++---
 1 file changed, 52 insertions(+), 46 deletions(-)

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

Re: [PATCH RFC 1/1] irqchip/GICv2m: Add support for multiple v2m frames

[Marc Zyngier]

Hi Duc,

On 08/10/15 08:48, Duc Dang wrote:
> GICv2m driver currently only supports single v2m frame. This
> patch extend this driver to support multiple v2m frames. All of
> the v2m frames will be own by a single MSI domain. Each PCIe node
> can specify msi-parent as the first frame of the v2m frame list
> to be able to use all available v2m frames for MSI interrupts.
> 
> This patch should be applied on top of patch 
> (irqchip/GICv2m: Add workaround for APM X-Gene GICv2m erratum):
> https://lkml.org/lkml/2015/10/6/922
> 
> Signed-off-by: Duc Dang 
> ---
>  drivers/irqchip/irq-gic-v2m.c | 221 
> ++
>  1 file changed, 159 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
> index 4c17c18..8ecaf9e 100644
> --- a/drivers/irqchip/irq-gic-v2m.c
> +++ b/drivers/irqchip/irq-gic-v2m.c
> @@ -51,13 +51,19 @@
>  #define GICV2M_NEEDS_SPI_OFFSET  0x0001
>  
>  struct v2m_data {
> - spinlock_t msi_cnt_lock;
>   struct resource res;/* GICv2m resource */
>   void __iomem *base; /* GICv2m virt address */
>   u32 spi_start;  /* The SPI number that MSIs start */
>   u32 nr_spis;/* The number of SPIs for MSIs */
> - unsigned long *bm;  /* MSI vector bitmap */
>   u32 flags;  /* v2m flags for specific implementation */
> + struct list_head list;  /* Link to other v2m frames */
> +};
> +
> +struct gicv2m_ctrlr {
> + spinlock_t v2m_ctrlr_lock;  /* Lock for all v2m frames */
> + u32 nr_vecs;/* Total MSI vectors */
> + unsigned long *bm;  /* MSI vector bitmap */
> + struct list_head v2m_frms;  /* List of v2m frames */
>  };
>  
>  static void gicv2m_mask_msi_irq(struct irq_data *d)
> @@ -98,11 +104,29 @@ static int gicv2m_set_affinity(struct irq_data *irq_data,
>   return ret;
>  }
>  
> +static struct v2m_data *irq_data_to_v2m_frm(struct irq_data *data,
> + struct gicv2m_ctrlr *v2m_ctrlr)
> +{
> + struct v2m_data *v2m;
> +
> + list_for_each_entry(v2m, _ctrlr->v2m_frms, list) {
> + if ((data->hwirq >= v2m->spi_start) &&
> + (data->hwirq < (v2m->spi_start + v2m->nr_spis)))
> + return v2m;
> + }
> +
> + return NULL;
> +}
> +
>  static void gicv2m_compose_msi_msg(struct irq_data *data, struct msi_msg 
> *msg)
>  {
> - struct v2m_data *v2m = irq_data_get_irq_chip_data(data);
> - phys_addr_t addr = v2m->res.start + V2M_MSI_SETSPI_NS;
> + struct gicv2m_ctrlr *v2m_ctrlr = irq_data_get_irq_chip_data(data);
> + struct v2m_data *v2m;
> + phys_addr_t addr;
>  
> + v2m = irq_data_to_v2m_frm(data, v2m_ctrlr);
> + WARN_ON(!v2m);
> + addr = v2m->res.start + V2M_MSI_SETSPI_NS;

At that particular point, I've stopped reading.

Pointlessly iterating over the frames when you can store the right one
in irq_data was bad enough, but having a WARN_ON() followed by a panic
is just not acceptable. Either you warn and avoid the crash, or you just
assume that the whole thing is sane and will never be inconsistent.

You are also changing the way this driver works, and not for the best.
I've just written something fairly similar, with the following diffstat:

 1 file changed, 76 insertions(+), 45 deletions(-)

The current infrastructure is sound, you just have to make use of it.

I've pushed the following (untested) patch:

https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/multi-v2m=45e35adb60087792626570ff21bb23ab0f67a6ac

Let me know if that works for you.

Thanks,

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

Re: [PATCH 2/3] staging: android: ion: Add ion driver for Hi6220 SoC platform

[xuyiping]

On 2015/10/8 15:55, Chen Feng wrote:

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
  drivers/staging/android/ion/Kconfig|   7 +
  drivers/staging/android/ion/Makefile   |   1 +
  drivers/staging/android/ion/hisilicon/Kconfig  |   5 +
  drivers/staging/android/ion/hisilicon/Makefile |   1 +
  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 201 +
  5 files changed, 215 insertions(+)
  create mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
  create mode 100644 drivers/staging/android/ion/hisilicon/Makefile
  create mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 3452346..19c1572 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -33,3 +33,10 @@ config ION_TEGRA
help
  Choose this option if you wish to use ion on an nVidia Tegra.

+config ION_HISI
+   tristate "Ion for Hisilicon"
+   depends on ARCH_HISI && ION
+   help
+ Choose this option if you wish to use ion on Hisilicon Platform.
+
+source "drivers/staging/android/ion/hisilicon/Kconfig"
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index b56fd2b..18cc2aa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -7,4 +7,5 @@ endif

  obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
  obj-$(CONFIG_ION_TEGRA) += tegra/
+obj-$(CONFIG_ION_HISI) += hisilicon/

diff --git a/drivers/staging/android/ion/hisilicon/Kconfig 
b/drivers/staging/android/ion/hisilicon/Kconfig
new file mode 100644
index 000..2b4bd07
--- /dev/null
+++ b/drivers/staging/android/ion/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config HI6220_ION
+bool "Hi6220 ION Driver"
+depends on ARCH_HISI && ION
+help
+  Build the Hisilicon Hi6220 ion driver.
diff --git a/drivers/staging/android/ion/hisilicon/Makefile 
b/drivers/staging/android/ion/hisilicon/Makefile
new file mode 100644
index 000..2a89414
--- /dev/null
+++ b/drivers/staging/android/ion/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
new file mode 100644
index 000..b7d39b8
--- /dev/null
+++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
@@ -0,0 +1,201 @@
+#define pr_fmt(fmt) "Ion: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../ion_priv.h"
+#include "../ion.h"
+
+struct hi6220_ion_type_table {
+   const char *name;
+   enum ion_heap_type type;
+};
+
+static struct hi6220_ion_type_table ion_type_table[] = {
+   {"ion_system", ION_HEAP_TYPE_SYSTEM},
+   {"ion_system_contig", ION_HEAP_TYPE_SYSTEM_CONTIG},
+   {"ion_carveout", ION_HEAP_TYPE_CARVEOUT},
+   {"ion_chunk", ION_HEAP_TYPE_CHUNK},
+   {"ion_dma", ION_HEAP_TYPE_DMA},
+   {"ion_custom", ION_HEAP_TYPE_CUSTOM},
+};
+
+static struct ion_device *idev;
+static int num_heaps;
+static struct ion_heap **heaps;
+static struct ion_platform_heap **heaps_data;
+
+static int get_type_by_name(const char *name, enum ion_heap_type *type)
+{
+   int i, n;
+
+   n = ARRAY_SIZE(ion_type_table);
+   for (i = 0; i < n; i++) {
+   if (strncmp(name, ion_type_table[i].name, strlen(name)))
+   continue;
+
+   *type = ion_type_table[i].type;
+   return 0;
+   }
+
+   return -1;
+}
+
+static int hi6220_set_platform_data(struct platform_device *pdev)
+{
+   unsigned int base;
+   unsigned int size;
+   unsigned int id;
+   const char *heap_name;
+   const char *type_name;
+   enum ion_heap_type type;
+   int ret;
+   struct device_node *np;
+   struct ion_platform_heap *p_data;
+   const struct device_node *dt_node = pdev->dev.of_node;
+   int index = 0;
+
+   for_each_child_of_node(dt_node, np)
+   num_heaps++;


indentation


+   heaps_data = devm_kzalloc(>dev,
+ sizeof(struct ion_platform_heap *) * 
num_heaps,
+ GFP_KERNEL);


check the result of malloc


+   for_each_child_of_node(dt_node, np) {
+   p_data = devm_kzalloc(>dev,
+ sizeof(struct ion_platform_heap),
+ GFP_KERNEL);


check the result of malloc


+   ret = of_property_read_string(np, "heap-name", _name);
+   if (ret < 0) {
+   pr_err("check the name of node %s\n", np->name);
+   continue;
+   }
+
+   ret = of_property_read_u32(np, "heap-id", );
+   if (ret < 0) {
+ 

Re: [PATCH v4 2/6] pinctrl: berlin: add the berlin4ct pinctrl driver

[Jisheng Zhang]

Hi Antoine,

On Fri, 9 Oct 2015 11:03:53 +0200
Antoine Tenart  wrote:

> Hi Jisheng,
> 
> On Fri, Oct 09, 2015 at 04:17:05PM +0800, Jisheng Zhang wrote:
> > diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
> > index b18322b..c13f6d2 100644
> > --- a/drivers/pinctrl/berlin/Kconfig
> > +++ b/drivers/pinctrl/berlin/Kconfig
> > @@ -17,4 +17,9 @@ config PINCTRL_BERLIN_BG2Q
> > bool
> > select PINCTRL_BERLIN
> >  
> > +config PINCTRL_BERLIN_BG4CT
> > +   depends on OF && (ARCH_BERLIN || COMPILE_TEST)
> > +   bool "Marvell berlin4ct pin controller driver"
> > +   select PINCTRL_BERLIN
> > +
> >  endif
> 
> This endif ends the following condition:
> 
>   if ARCH_BERLIN
>   [...]
> 
> So the "depends on ARCH_BERLIN" here can be dropped. Also the
> COMPILE_TEST can be moved as it isn't BG4CT specific and all other
> Berlin pinctrl drivers would benefit from this.
> 
> So we would have something like:
> 
>   if (ARCH_BERLIN || COMPILE_TEST)

Oh yeah! This is better.

>   [...]
>   endif
> 
> Finally you can move the OF dependency to the PINCTRL_BERLIN config as
> all Berlin pinctrl drivers depends on it.

PINCTRL_BERLIN isn't user visible and it's selected by PINCTRL_BERLIN_BG4CT. So
we may have the following random config case:

CONFIG_OF=n
CONFIG_PINCTRL_BERLIN_BG4CT=y

In this case, there will be build errors for we missed OF. So we have to
make PINCTRL_BERLIN_BG4CT depends on OF. What do you think? Or is there
better solution?

Thanks for kind review,
Jisheng

> 
> Thanks!
> 
> Antoine
> 

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

Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node

[Jiang Liu]

On 2015/10/9 17:08, Kamezawa Hiroyuki wrote:
> On 2015/10/09 14:52, Jiang Liu wrote:
>> On 2015/10/9 4:20, Andrew Morton wrote:
>>> On Wed, 19 Aug 2015 17:18:15 -0700 (PDT) David Rientjes
>>>  wrote:
>>>
 On Wed, 19 Aug 2015, Patil, Kiran wrote:

> Acked-by: Kiran Patil 

 Where's the call to preempt_disable() to prevent kernels with
 preemption
 from making numa_node_id() invalid during this iteration?
>>>
>>> David asked this question twice, received no answer and now the patch
>>> is in the maintainer tree, destined for mainline.
>>>
>>> If I was asked this question I would respond
>>>
>>>The use of numa_mem_id() is racy and best-effort.  If the unlikely
>>>race occurs, the memory allocation will occur on the wrong node, the
>>>overall result being very slightly suboptimal performance.  The
>>>existing use of numa_node_id() suffers from the same issue.
>>>
>>> But I'm not the person proposing the patch.  Please don't just ignore
>>> reviewer comments!
>> Hi Andrew,
>> Apologize for the slow response due to personal reasons!
>> And thanks for answering the question from David. To be honest,
>> I didn't know how to answer this question before. Actually this
>> question has puzzled me for a long time when dealing with memory
>> hot-removal. For normal cases, it only causes sub-optimal memory
>> allocation if schedule event happens between querying NUMA node id
>> and calling alloc_pages_node(). But what happens if system run into
>> following execution sequence?
>> 1) node = numa_mem_id();
>> 2) memory hot-removal event triggers
>> 2.1) remove affected memory
>> 2.2) reset pgdat to zero if node becomes empty after memory removal
> 
> I'm sorry if I misunderstand something.
> After commit b0dc3a342af36f95a68fe229b8f0f73552c5ca08, there is no
> memset().
Hi Kamezawa,
Thanks for the information. The commit solved the issue what
I was puzzling about. With this change applied, thing should work
as expected. Seems it would be better to enhance __build_all_zonelists()
to handle those offlined empty nodes too, but that really doesn't
make to much difference:)
Thanks for the info again!
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: crazy idea: big percpu lock (Re: task isolation)

[Thomas Gleixner]

On Thu, 8 Oct 2015, Andy Lutomirski wrote:
> I want to propose a new primitive that might go a long way toward
> solving this issue.  The new primitive would be called the "big percpu
> lock".

It took us 15+ years to get rid of the "Big Kernel Lock", so we really
don't want to add a new "Big XXX Lock". We have enough pain already
with preempt_disable() and local_irq_disable() which are basically
"Big CPU Locks".

Don't ever put BIG and LOCK into one context, really.

Thanks,

tglx


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

RE: [PATCH] [v4] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map

[Chen, Yu C]

Hi,Pavel,

> -Original Message-
> From: Pavel Machek [mailto:pa...@ucw.cz]
> Sent: Sunday, October 04, 2015 11:16 PM
> To: Chen, Yu C
> Cc: r...@rjwysocki.net; Brown, Len; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Zhang, Rui; j...@suse.com;
> joeyli.ker...@gmail.com; ying...@kernel.org; Ingo Molnar
> Subject: Re: [PATCH] [v4] PM / hibernate: Fix hibernation panic caused by
> inconsistent e820 map
> 
> Hi!
> > > > > 3) I'm not sure I understand the changelog correctly. What
> > > > > happens when BIOS reports less memory on hibernation? Will you
> > > > > magically remove memory from kernel at runtime? Will
> > > > > /proc/meminfo be invalid
> > > after resume?
> > > > > Will all the memory management tuning need fixing?
> > > > >
> > > > Oh, I did not notice it before. So deleting the logic of '
> > > > info->num_physpages != get_num_physpages()' is not suitable.
> > > > The subset relationship should not be considered in this patch.
> > >
> > > Ok. So... if you really want, you can add some messages like "hey,
> > > this is bios bug, maybe updating bios is a good idea".. but please
> > > lets keep the original logic.
> > >
> > OK. I see, I'll not change its original code.
> > So can I add a function here that checks if current BIOS  e820 map is
> > strictly the same as it was before S4?  If it is not the same, we will
> > print some warnnings , and if we panic later, we will print that , the panic
> reason might be due to broken BIOS.
> > I think I can archive this by putting  the e820_saved array  into
> > struct swsusp_info,  and pass it to second kernel:
> > struct swsusp_info will always occupy one page size, and has a lot of
> > extra space left, meanwhile the total size of e820 map will not exceed
> > the PAGE_SIZE currently, it's safe to put it in struct swsusp_info.
> >
> > And this does not need much changing of current code. What do you think?
> Thanks.
> 
> Can we simply add explanation printk() before the panic(), without any other
> changes?
OK, I can add a hook in panic, and print the possible panic reason.
(and to print(confirm the bug reason) the explanation, we might still need to 
do 
some comparison on e820 map, this small code can be added in 
arch/x86/power/hibernate_64/32.c,
this might be used for future possible e820 checking), is it suitable?

 Thanks !

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

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Will Deacon]

On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2015 at 02:44:39PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 08, 2015 at 01:16:38PM +0200, Peter Zijlstra wrote:
> > > On Thu, Oct 08, 2015 at 02:50:36PM +1100, Michael Ellerman wrote:
> > > > On Wed, 2015-10-07 at 08:25 -0700, Paul E. McKenney wrote:
> > > 
> > > > > Currently, we do need smp_mb__after_unlock_lock() to be after the
> > > > > acquisition on PPC -- putting it between the unlock and the lock
> > > > > of course doesn't cut it for the cross-thread unlock/lock case.
> > > 
> > > This ^, that makes me think I don't understand
> > > smp_mb__after_unlock_lock.
> > > 
> > > How is:
> > > 
> > >   UNLOCK x
> > >   smp_mb__after_unlock_lock()
> > >   LOCK y
> > > 
> > > a problem? That's still a full barrier.
> > 
> > The problem is that I need smp_mb__after_unlock_lock() to give me
> > transitivity even if the UNLOCK happened on one CPU and the LOCK
> > on another.  For that to work, the smp_mb__after_unlock_lock() needs
> > to be either immediately after the acquire (the current choice) or
> > immediately before the release (which would also work from a purely
> > technical viewpoint, but I much prefer the current choice).
> > 
> > Or am I missing your point?
> 
> So lots of little confusions added up to complete fail :-{
> 
> Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> forgot: but not against uninvolved CPUs) and RELEASE/ACQUIRE are
> transitive (where I forgot: RELEASE/ACQUIRE _chains_ are transitive, but
> again not against uninvolved CPUs).
> 
> Which leads me to think I would like to suggest alternative rules for
> RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> partly responsible for my confusion).

Yeah, sorry. I originally used the phrase "fully ordered" but changed it
to "full barrier", which has stronger transitivity (newly understood
definition) requirements that I didn't intend.

RELEASE -> ACQUIRE should be used for message passing between two CPUs
and not have ordering effects on other observers unless they're part of
the RELEASE -> ACQUIRE chain.

>  - RELEASE -> ACQUIRE is fully ordered (but not a full barrier) when
>they operate on the same variable and the ACQUIRE reads from the
>RELEASE. Notable, RELEASE/ACQUIRE are RCpc and lack transitivity.

Are we explicit about the difference between "fully ordered" and "full
barrier" somewhere else, because this looks like it will confuse people.

>  - RELEASE -> ACQUIRE can be upgraded to a full barrier (including
>transitivity) using smp_mb__release_acquire(), either before RELEASE
>or after ACQUIRE (but consistently [*]).

Hmm, but we don't actually need this for RELEASE -> ACQUIRE, afaict. This
is just needed for UNLOCK -> LOCK, and is exactly what RCU is currently
using (for PPC only).

Stepping back a second, I believe that there are three cases:


 RELEASE X -> ACQUIRE Y (same CPU)
   * Needs a barrier on TSO architectures for full ordering

 UNLOCK X -> LOCK Y (same CPU)
   * Needs a barrier on PPC for full ordering

 RELEASE X -> ACQUIRE X (different CPUs)
 UNLOCK X -> ACQUIRE X (different CPUs)
   * Fully ordered everywhere...
   * ... but needs a barrier on PPC to become a full barrier


so maybe it makes more sense to split out the local and inter-cpu ordering
with something like:

  smp_mb__after_release_acquire()
  smp_mb__after_release_acquire_local()

then the first one directly replaces smp_mb__after_unlock_lock, and is
only defined for PPC, whereas the second one is also defined for TSO archs.

>  - RELEASE -> ACQUIRE _chains_ (on shared variables) preserve causality,
>(because each link is fully ordered) but are not transitive.

Yup, and that's the same for UNLOCK -> LOCK, too.

> And I think that in the past few weeks we've been using transitive
> ambiguously, the definition we have in Documentation/memory-barriers.txt
> is a _strong_ transitivity, where we can make guarantees about CPUs not
> directly involved.
> 
> What we have here (due to RCpc) is a weak form of transitivity, which,
> while it preserves the natural concept of causality, does not extend to
> other CPUs.
> 
> So we could go around and call them 'strong' and 'weak' transitivity,
> but I suspect its easier for everyone involved if we come up with
> separate terms (less room for error if we accidentally omit the
> 'strong/weak' qualifier).

Surely the general case is message passing and so "transitivity" should
just refer to chains of RELEASE -> ACQUIRE? Then "strong transitivity"
could refer to the far more complicated (imo) case that is synonymous
with "full barrier".

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

[PATCH v2 4/4] spi: spi-coldfire-qspi: enable RuntimePM before registering to the core

[Wolfram Sang]

From: Wolfram Sang 

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail.

Signed-off-by: Wolfram Sang 
---
 drivers/spi/spi-coldfire-qspi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-coldfire-qspi.c b/drivers/spi/spi-coldfire-qspi.c
index 688956ff5095c2..23f6fffd75e111 100644
--- a/drivers/spi/spi-coldfire-qspi.c
+++ b/drivers/spi/spi-coldfire-qspi.c
@@ -420,19 +420,20 @@ static int mcfqspi_probe(struct platform_device *pdev)
master->auto_runtime_pm = true;
 
platform_set_drvdata(pdev, master);
+   pm_runtime_enable(>dev);
 
status = devm_spi_register_master(>dev, master);
if (status) {
dev_dbg(>dev, "spi_register_master failed\n");
goto fail2;
}
-   pm_runtime_enable(>dev);
 
dev_info(>dev, "Coldfire QSPI bus driver\n");
 
return 0;
 
 fail2:
+   pm_runtime_disable(>dev);
mcfqspi_cs_teardown(mcfqspi);
 fail1:
clk_disable(mcfqspi->clk);
-- 
2.1.4

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

Re: [PATCH 4/8] mmc: sdhci-pxav3: enable proper resuming on Armada 38x SoC

[Marcin Wojtas]

Hi Jisheng,


>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mbus");
>> + pxa->mbus_win_regs = devm_ioremap_resource(>dev, res);
>> + if (IS_ERR(pxa->mbus_win_regs)) {
>> + dev_err(mmc_dev(host->mmc),
>> + "failed to obtain MBus windows register base\n");
>
> devm_ioremap_resource() has warned us if it fails, so is it better to remove
> this dev_err() here?
>

Indeed, I'll remove this excessive verbosity.

>>   struct sdhci_host *host = dev_get_drvdata(dev);
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_pxa *pxa = pltfm_host->priv;
>> + struct device_node *np = dev->of_node;
>> +
>> + if (of_device_is_compatible(np, "marvell,armada-380-sdhci"))
>
> this would increase resume time especially those non armada-380-sdhci host
> although it's trivial. Is it better to check "if (pxa->mbus_win_regs)"?
>

Already implemented in v2.

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

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Will Deacon]

Hi Paul,

On Thu, Oct 08, 2015 at 03:17:16PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 08, 2015 at 01:59:38PM +0100, Will Deacon wrote:
> > I thought Paul was talking about something like this case:
> > 
> > CPU A CPU B  CPU C
> > foo = 1
> > UNLOCK x
> >   LOCK x
> >   (RELEASE) bar = 1
> >  ACQUIRE bar = 1
> >  READ_ONCE foo = 0
> 
> More like this:
> 
> CPU A CPU B   CPU C
> WRITE_ONCE(foo, 1);
> UNLOCK x
>   LOCK x
>   r1 = READ_ONCE(bar);
>   WRITE_ONCE(bar, 1);
>   smp_mb();
>   r2 = READ_ONCE(foo);
> 
> This can result in r1==0 && r2==0.

Thank you, that is extremely enlightening :)

> > I think we need a PPC litmus test illustrating the inter-thread, same
> > lock failure case when smp_mb__after_unlock_lock is not present so that
> > we can reason about this properly. Paul?
> 
> Please see above.  ;-)
> 
> The corresponding litmus tests are below.

How do people feel about including these in memory-barriers.txt? I find
them considerably easier to read than our current kernel code + list of
possible orderings + wall of text, but there's a good chance that my
brain has been corrupted from staring at this stuff for too long.

The only snag is the ppc assembly code, but it's not *too* horrific ;)

> PPC lock-2thread-WR-barrier.litmus
> ""
> (*
>  * Does 3.0 Linux-kernel Power lock-unlock provide local 
>  * barrier that orders prior stores against subsequent loads,
>  * if the unlock and lock happen on different threads?
>  * This version uses lwsync instead of isync.
>  *)
> (* 23-July-2013: ppcmem says "Sometimes" *)
> {
> l=1;
> 0:r1=1;  0:r4=x; 0:r10=0;  0:r12=l;
> 1:r1=1; 1:r3=42; 1:r4=x; 1:r5=y; 1:r10=0; 1:r11=0; 1:r12=l;
> 2:r1=1;  2:r4=x; 2:r5=y;
> }
>  P0 | P1 | P2;
>  stw r1,0(r4)   | lwarx r11,r10,r12  | stw r1,0(r5) ;
>  lwsync | cmpwi r11,0| lwsync   ;
>  stw r10,0(r12) | bne Fail1  | lwz r7,0(r4) ;
> | stwcx. r1,r10,r12  | ;
> | bne Fail1  | ;
> | isync  | ;
> | lwz r3,0(r5)   | ;
> | Fail1: | ;
> 
> 
> exists
> (1:r3=0 /\ 2:r7=0)

We could also include a link to the ppcmem/herd web frontends and your
lwn.net article. (ppcmem is already linked, but it's not obvious that
you can run litmus tests in your browser).

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

[PATCH] kvm: svm: Only propagate next_rip when guest supports it

[Joerg Roedel]

From: Joerg Roedel 

Currently we always write the next_rip of the shadow vmcb to
the guests vmcb when we emulate a vmexit. This could confuse
the guest when its cpuid indicated no support for the
next_rip feature.

Fix this by only propagating next_rip if the guest actually
supports it.

Cc: Bandan Das 
Cc: Dirk Mueller 
Tested-by: Dirk Mueller 
Signed-off-by: Joerg Roedel 
---
 arch/x86/kvm/cpuid.h | 21 +
 arch/x86/kvm/svm.c   |  4 +++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index dd05b9c..effca1f 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -133,4 +133,25 @@ static inline bool guest_cpuid_has_mpx(struct kvm_vcpu 
*vcpu)
best = kvm_find_cpuid_entry(vcpu, 7, 0);
return best && (best->ebx & bit(X86_FEATURE_MPX));
 }
+
+/*
+ * NRIPS is provided through cpuidfn 0x800a.edx bit 3
+ */
+#define BIT_NRIPS  3
+
+static inline bool guest_cpuid_has_nrips(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cpuid_entry2 *best;
+
+   best = kvm_find_cpuid_entry(vcpu, 0x800a, 0);
+
+   /*
+* NRIPS is a scattered cpuid feature, so we can't use
+* X86_FEATURE_NRIPS here (X86_FEATURE_NRIPS would be bit
+* position 8, not 3).
+*/
+   return best && (best->edx & bit(BIT_NRIPS));
+}
+#undef BIT_NRIPS
+
 #endif
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 2f9ed1f..4084b33 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2365,7 +2365,9 @@ static int nested_svm_vmexit(struct vcpu_svm *svm)
nested_vmcb->control.exit_info_2   = vmcb->control.exit_info_2;
nested_vmcb->control.exit_int_info = vmcb->control.exit_int_info;
nested_vmcb->control.exit_int_info_err = 
vmcb->control.exit_int_info_err;
-   nested_vmcb->control.next_rip  = vmcb->control.next_rip;
+
+   if (guest_cpuid_has_nrips(>vcpu))
+   nested_vmcb->control.next_rip  = vmcb->control.next_rip;
 
/*
 * If we emulate a VMRUN/#VMEXIT in the same host #vmexit cycle we have
-- 
1.9.1

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

Re: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

[Sjoerd Simons]

On Thu, 2015-10-08 at 16:41 +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 11:27:13 Sjoerd Simons wrote:
> > On Thu, 2015-10-08 at 10:37 +0200, Arnd Bergmann wrote:
> > > On Thursday 08 October 2015 16:46:27 Krzysztof Kozlowski wrote:
> > > > On 08.10.2015 16:41, Arnd Bergmann wrote:
> > > > > On Thursday 08 October 2015 03:48:36 Anand Moon wrote:
> > > > > > diff --git a/arch/arm/configs/exynos_defconfig
> > > > > > b/arch/arm/configs/exynos_defconfig
> > > > > > index 1ff2bfa..5d1937b 100644
> > > > > > --- a/arch/arm/configs/exynos_defconfig
> > > > > > +++ b/arch/arm/configs/exynos_defconfig
> > > > > > @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
> > > > > >  CONFIG_DM_CRYPT=m
> > > > > >  CONFIG_NETDEVICES=y
> > > > > >  CONFIG_SMSC911X=y
> > > > > > +CONFIG_USB_RTL8152=y
> > > > > >  CONFIG_USB_USBNET=y
> > > > > >  CONFIG_USB_NET_SMSC75XX=y
> > > > > >  CONFIG_USB_NET_SMSC95XX=y
> > > > > 
> > > > > Can we make that a loadable module for multi_v7_defconfig?
> > > > 
> > > > What about nfsroot boots? We were discussing this also here:
> > > > http://linux-arm-kernel.infradead.narkive.com/lG5g4hrB/patch-ar
> > > > m-mu
> > > > lti-v7-defconfig-enable-usb3503
> > > > 
> > > > and actually I would be happy to see a confirmed policy about
> > > > that.
> > > > Everything should be a module for multi_v7?
> > > 
> > > We try to make as much as possible modular here, and NFS root is
> > > a
> > > corner
> > > case: it's possible to do NFS root with an initramfs, but it's
> > > easier
> > > not
> > > to. Is it something you do a lot on this hardware?
> > 
> > It's a workflow thing though, not a hardware specific thing. I
> > personally tend to use NFS root quite often and so do various
> > colleagues irrespective of the hardware (and an XU4 is bound to
> > appear
> > on my desk someday). 
> > 
> > Now I personally really don't mind whether NFS root requires a
> > ramdisk
> > or not (though some consistency would be nice). However deciding it
> > on
> > a per device basis just makes everything quite fuzzy (e.g. my
> > recent
> > rockchip multi_v7 patchset first ended up in a similar discussion,
> > though v2 was merged without further comments when I indicated in
> > the
> > cover letter that i used the NFS root use-case as one of the
> > deciding
> > factors for y vs. m).
> > 
> > It would be really good to see someone put their foot down on the
> > general policy (e.g. the arm-soc maintainers?), such that this
> > discussion doesn't need to happen every time 
> 
> Yes, agreed, that what I'm trying to do here ;-)

I see, sorry I misunderstood what you were after.

> I realize that building things as modules is a hassle, it is so for
> some things more than for others, so I keep asking the question
> to everyone to find out what a good balance is to make as much as
> possible modules without hurting too much.

Fwiw, I don't find building modules overly cumbersome. Getting an
initramfs capable of moving on to an NFS root is mostly a one-time
thing (not unlike setting up the nfs root itself) and injecting modules
into it is relatively simple (doubly so if taking advantage of the
multiple cpio archive feature linux has). 

Interestingly, for me not building things as modules in multi_v7 tends
to cause more work as it hides a few categories of bugs that tend to
crop up once building distro kernels (e.g. missing module aliases,
missing module device table entries, implicitly relying on clocks being
active during probe as unused clocks only get turned of late in the
init sequence etc).

> Once we have a firm policy in place, we should probably change all
> the existing symbols.

++

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

Re: [RFC]: Possible race condition in kernel futex code

[Hans Zuidam]

Hi Thomas,

On 9 okt. 2015, at 11:06, Thomas Gleixner  wrote:
On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote:
>> We did some tests with different compilers, kernel versions and kernel
>> configs, with the following results:

> You cannot use an explicit 32bit read. We need an access which handles the 
> fault gracefully.

The reason for the explicit read suggestion is to avoid the 
_builtin_constant_p() in __copy_from_user_nocheck().  The GCC manual says that 
there may be situations where it returns 0 even though the argument is a 
constant.  Although none of the compiler/kernel combinations we have tried 
showed this happening, we think it is probably better to be safe than sorry.

With kind regards,
Hans Zuidam

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

Re: [RFC v2 3/6] PM / Domains: introduce power-states consistent with c-states.

[Marc Titinger]

On 08/10/2015 18:27, Lina Iyer wrote:

On Tue, Oct 06 2015 at 08:27 -0600, Marc Titinger wrote:

This patch allows cluster-level C-states to being soaked in as generic
domain power states, in order for the domain governor to chose the most
efficient power state compatible with the device constraints. Similarly,
devices can register power-states into the cluster domain, in a manner
consistent with c-states.


A domain power state as depicted in the DT is no different than the CPU
idle state. I think you can achieve this without adding another
compatible - arm,power-state.

yes, thats'a bit hacky, I was facing the genpd_lock'ing issue I believe 
you mentioned recently and lead to your simplification work in the case 
of CPUs. the power-state discrimination was to allow cpu-idle to call 
runtime_put/get only for those states where genpd is to call the 
platform code and select the optimal c-state. Eventually this 
discrimination would be useless. Alternatively I've been wondering if we 
could have one domain (and one lock) per CPU, and have a parent domain 
for the cluster.



I think I am still at loss trying to understand why a device is
populating the domain's power states.


With Juno, in this example the c-state 'cluster-sleep-0 ' is known from
each cluster generic domain, as the deepest sate.

cat /sys/kernel/debug/pm_genpd/*

 Domain State nameEnter (ns) / Exit (ns)
-
a53_pd   cluster-sleep-0  150 / 80
a57_pd   cluster-sleep-0  150 / 80

   domain  status pstate slaves
  /device  runtime status
---
a53_pd  on
   /devices/system/cpu/cpu0active
   /devices/system/cpu/cpu3suspended
   /devices/system/cpu/cpu4suspended
   /devices/system/cpu/cpu5suspended
   /devices/platform/D1suspended
a57_pd  cluster-sleep-0
   /devices/system/cpu/cpu1suspended
   /devices/system/cpu/cpu2suspended

Signed-off-by: Marc Titinger 
---
.../devicetree/bindings/arm/idle-states.txt|  21 -
.../devicetree/bindings/power/power_domain.txt |  29 ++
arch/arm64/boot/dts/arm/juno.dts   |  10 ++-
drivers/base/power/cpu-pd.c|   5 ++
drivers/base/power/domain.c| 100
+
include/linux/pm_domain.h  |   3 +
6 files changed, 163 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
b/Documentation/devicetree/bindings/arm/idle-states.txt
index a8274ea..18fdeaf 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -270,7 +270,8 @@ follows:
- compatible
Usage: Required
Value type: 
-Definition: Must be "arm,idle-state".
+Definition: Must be "arm,idle-state",
+or "arm,power-state" (see section 5)

- local-timer-stop
Usage: See definition
@@ -680,7 +681,23 @@ cpus {
};

===
-5 - References
+5 - power state
+===
+
+Device in a generic power domain may expose an intermediate retention
+state that can be opted to by the domain governor when the last-man
+CPU is powered off. Those power-states will not be entered by the
+cpuidle.ops based on a state index, but instead can be elected by the
+domain governor and entered to by the generic domain.
+

Agreed.


+ - compatible
+Usage: Required
+Value type: 
+Definition: Must be "arm,power-state".
+
+
+===
+6 - References
===

[1] ARM Linux Kernel documentation - CPUs bindings
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
index 0f8ed37..d437385 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,16 @@ Optional properties:
   specified by this binding. More details about power domain
specifier are
   available in the next section.

+ - power-states : a phandle of an idle-state that shall be soaked into a
+  generic domain power state.
+   CPU domains: Deep c-states that match a cluster power-off can be
delegated to the
+   generic power domain. Device other than CPUs may have register
intermediate
+   power states in the same domain. The domain governor can do a good
job in
+   electing 

Re: [PATCH v6 0/6] KASAN for arm64

[Andrey Ryabinin]

2015-10-09 12:48 GMT+03:00 Mark Rutland :
> On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote:
> [...]
>
>> I thought the EFI stub isolation patches create a copy of mem*() functions 
>> in the stub,
>> but they are just create aliases with __efistub_ prefix.
>>
>> We only need to create some more aliases for KASAN.
>> The following patch on top of the EFI stub isolation series works for me.
>>
>>
>> Signed-off-by: Andrey Ryabinin 
>> ---
>>  arch/arm64/kernel/image.h | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
>> index e083af0..6eb8fee 100644
>> --- a/arch/arm64/kernel/image.h
>> +++ b/arch/arm64/kernel/image.h
>> @@ -80,6 +80,12 @@ __efistub_strcmp   = __pi_strcmp;
>>  __efistub_strncmp= __pi_strncmp;
>>  __efistub___flush_dcache_area= __pi___flush_dcache_area;
>>
>> +#ifdef CONFIG_KASAN
>> +__efistub___memcpy   = __pi_memcpy;
>> +__efistub___memmove  = __pi_memmove;
>> +__efistub___memset   = __pi_memset;
>> +#endif
>
> Ard's v4 stub isolation series has these aliases [1], as the stub
> requires these aliases regardless of KASAN in order to link.

Stub isolation series has __efistub_memcpy, not __efistub___memcpy
(two additional '_').
The thing is, KASAN provides own implementation of memcpy() which
checks memory before access.
The original 'memcpy()' becomes __memcpy(), so we could still use it.
In code that not instrumented by KASAN (like the EFI stub) we replace
KASAN's memcpy() with the original __mempcy():
#define memcpy() __memcpy()

So with CONFIG_KASAN=y the EFI stub uses __memcpy, thus we need to
create the __efistub___memcpy alias.

>
> Thanks,
> Mark.
>
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/375708.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mfd: da9062-core: Rename get_device_type to da9062_get_device_type

[Axel Lin]

Rename get_device_type() to da9062_get_device_type().
This function is only used in this file so make it static.

Signed-off-by: Axel Lin 
---
 drivers/mfd/da9062-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index f80d947..a9ad024 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -198,7 +198,7 @@ static int da9062_clear_fault_log(struct da9062 *chip)
return ret;
 }
 
-int get_device_type(struct da9062 *chip)
+static int da9062_get_device_type(struct da9062 *chip)
 {
int device_id, variant_id, variant_mrc;
int ret;
@@ -466,7 +466,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
dev_warn(chip->dev, "Cannot clear fault log\n");
 
-   ret = get_device_type(chip);
+   ret = da9062_get_device_type(chip);
if (ret)
return ret;
 
-- 
2.1.4



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

Re: [PATCH v2] mmc: core: Fix init_card in 52Mhz

[Ulf Hansson]

[...]

>>> Then you need to remove the hw_reset test from mmc_test.  Refer:
>>>
>>> http://marc.info/?l=linux-mmc=144360165906544=2
>>>
>>
>> I realize that the test becomes a bit different, but I don't think it's 
>> useless.
>>
>> If we add a check for MMC_CAP_HW_RESET and verify that the
>> host->ops->hw_reset exists, then we can assume that the "hw_reset"
>> sequence has executed. And if mmc_init_card() fails, that would
>> probably mean that the reset also failed, right?
>
> In the test case, the card is in a working state.  Generally I would then
> expect reinitialization to work irrespective of whether or not the hardware
> is actually reset.

That's not always the case. I have seen many strange things happening
while trying to re-initialize/reset the card. :-)

>
> Here are some other options:
> 1. have mmc_test hook the host->ops->hw_reset() fn and do the 
> send_status
> itself.
> 2. have mmc_test set a flag on the card that it is being tested
> and only do the send_status if the flag is set

I assume that both 1) and 2) still means we need to manage the
scenario with re-tuning, which I rather would like us to prevent.

Unless we find a way to call mmc_set_initial_state() before doing the
reset, as that would disable re-tuning...

> 3. remove the send_status call and rename the mmc_test from "eMMC 
> hardware
> reset" to just "Reset test (doesn't check hw reset did reset)"

That's would work and perhaps this is the best way to go as we would
then also be able to use the test for SD-cards. Let's do this then!

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

Re: [PATCH 4/4] arm64: dts: apq8016-sbc: enable spi buses on LS and HS

[Srinivas Kandagatla]

On 08/10/15 19:16, Stephen Boyd wrote:

On 10/08/2015 04:19 AM, Srinivas Kandagatla wrote:

This patch enables spi buses on low speed and high speed expansion
connectors on DB410C

Signed-off-by: Srinivas Kandagatla 
---
  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 3581272..d872654 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -92,11 +92,21 @@
status = "okay";
  };

+_spi3 {
+   /* On High speed expansion */
+   status = "okay";
+};
+
  _i2c4 {
/* On High speed expansion */
status = "okay";
  };

+_spi5 {
+   /* On Low speed expansion */
+   status = "okay";
+};
+
  _i2c6 {
/* On Low speed expansion */
status = "okay";


We've been using absolute nodes to mark device nodes as status = "okay".
Can we keep doing that here please?


Sure, I will re-spin a new version.

--srini



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

Re: [PATCHv2] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

[Arnd Bergmann]

On Tuesday 06 October 2015 12:51:24 Arnd Bergmann wrote:
> 
> I think it makes sense to stick with the traditional definition
> of MINSIGSTKSZ == "the minimum amount that you will always need,
> add whatever you require yourself" and SIGSTKSZ == "Should be
> enough for a couple of function calls". If we want to be conservative
> in the kernel, using 8192 and 32768, to stay with the x4 ratio
> that everyone else uses would be my first pick, though I'm not
> particularly attached to those values.
> 
> 

On second thought, it really seems to late to make up our minds
about the size now that glibc has already established 5KB as the
minimum size. If we set it to 8KB/32KB, not just the testcase but
real applications would start failing when they use the 5KB
constant from glibc.

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

[PATCH v3 2/5] ARM: sun5i: Add R8 DTSI

[Maxime Ripard]

The R8 is very close to the A13, but it still has a few differences,
notably a composite output, which the A13 lacks.

Add a DTSI based on the A13's to hold those differences.

Signed-off-by: Maxime Ripard 
Reviewed-by: Chen-Yu Tsai 
Reviewed-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-r8.dtsi | 59 +
 1 file changed, 59 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun5i-r8.dtsi

diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
new file mode 100644
index ..0ef865601ac9
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-r8.dtsi
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2015 Free Electrons
+ * Copyright 2015 NextThing Co
+ *
+ * Maxime Ripard 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun5i-a13.dtsi"
+
+/ {
+   chosen {
+   framebuffer@1 {
+   compatible = "allwinner,simple-framebuffer",
+"simple-framebuffer";
+   allwinner,pipeline = "de_be0-lcd0-tve0";
+   clocks = < 1>, <_gates 34>, <_gates 36>,
+<_gates 44>;
+   status = "disabled";
+   };
+   };
+};
-- 
2.5.3

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