Re: [PATCH RFC net-next 1/2] tcp: Add DPIFL thin stream detection mechanism

[Bendik Rønning Opstad]

On Friday, October 23, 2015 02:44:14 PM Eric Dumazet wrote:
> On Fri, 2015-10-23 at 22:50 +0200, Bendik Rønning Opstad wrote:
> 
> >  
> > +/**
> > + * tcp_stream_is_thin_dpifl() - Tests if the stream is thin based on 
> > dynamic PIF
> > + *  limit
> > + * @tp: the tcp_sock struct
> > + *
> > + * Return: true if current packets in flight (PIF) count is lower than
> > + * the dynamic PIF limit, else false
> > + */
> > +static inline bool tcp_stream_is_thin_dpifl(const struct tcp_sock *tp)
> > +{
> > +   u64 dpif_lim = tp->srtt_us >> 3;
> > +   /* Div by is_thin_min_itt_lim, the minimum allowed ITT
> > +* (Inter-transmission time) in usecs.
> > +*/
> > +   do_div(dpif_lim, tp->thin_dpifl_itt_lower_bound);
> > +   return tcp_packets_in_flight(tp) < dpif_lim;
> > +}
> > +
> This is very strange :
> 
> You are using a do_div() while both operands are 32bits.  A regular
> divide would be ok :
> 
> u32 dpif_lim = (tp->srtt_us >> 3) / tp->thin_dpifl_itt_lower_bound;
> 
> But then, you can avoid the divide by using a multiply, less expensive :
> 
> return(u64)tcp_packets_in_flight(tp) * tp->thin_dpifl_itt_lower_bound 
> <
>   (tp->srtt_us >> 3);
> 

You are of course correct. Will fix this and use multiply. 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/

[PATCH] sched: fix incorrect wait time and wait count statistics

[Joonwoo Park]

At present scheduler resets task's wait start timestamp when the task
migrates to another rq.  This misleads scheduler itself into reporting
less wait time than actual by omitting time spent for waiting prior to
migration and also more wait count than actual by counting migration as
wait end event which can be seen by trace or /proc//sched with
CONFIG_SCHEDSTATS=y.

Carry forward migrating task's wait time prior to migration and don't
count migration as a wait end event to fix such statistics error.

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Joonwoo Park 
---
 kernel/sched/core.c  |  4 ++--
 kernel/sched/fair.c  | 41 -
 kernel/sched/sched.h |  2 ++
 3 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bcd214e..4f20895 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1069,7 +1069,7 @@ static struct rq *move_queued_task(struct rq *rq, struct 
task_struct *p, int new
 {
lockdep_assert_held(>lock);
 
-   dequeue_task(rq, p, 0);
+   dequeue_task(rq, p, DEQUEUE_MIGRATING);
p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, new_cpu);
raw_spin_unlock(>lock);
@@ -1079,7 +1079,7 @@ static struct rq *move_queued_task(struct rq *rq, struct 
task_struct *p, int new
raw_spin_lock(>lock);
BUG_ON(task_cpu(p) != new_cpu);
p->on_rq = TASK_ON_RQ_QUEUED;
-   enqueue_task(rq, p, 0);
+   enqueue_task(rq, p, ENQUEUE_MIGRATING);
check_preempt_curr(rq, p, 0);
 
return rq;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9a5e60f..53ec4d4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -738,27 +738,41 @@ static void update_curr_fair(struct rq *rq)
 }
 
 static inline void
-update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
+update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se,
+   bool migrating)
 {
-   schedstat_set(se->statistics.wait_start, rq_clock(rq_of(cfs_rq)));
+   schedstat_set(se->statistics.wait_start,
+   migrating &&
+   likely(rq_clock(rq_of(cfs_rq)) > se->statistics.wait_start) ?
+   rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start :
+   rq_clock(rq_of(cfs_rq)));
 }
 
 /*
  * Task is being enqueued - update stats:
  */
-static void update_stats_enqueue(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+static void update_stats_enqueue(struct cfs_rq *cfs_rq, struct sched_entity 
*se,
+bool migrating)
 {
/*
 * Are we enqueueing a waiting task? (for current tasks
 * a dequeue/enqueue event is a NOP)
 */
if (se != cfs_rq->curr)
-   update_stats_wait_start(cfs_rq, se);
+   update_stats_wait_start(cfs_rq, se, migrating);
 }
 
 static void
-update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
+update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se,
+ bool migrating)
 {
+   if (migrating) {
+   schedstat_set(se->statistics.wait_start,
+ rq_clock(rq_of(cfs_rq)) -
+ se->statistics.wait_start);
+   return;
+   }
+
schedstat_set(se->statistics.wait_max, max(se->statistics.wait_max,
rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start));
schedstat_set(se->statistics.wait_count, se->statistics.wait_count + 1);
@@ -774,14 +788,15 @@ update_stats_wait_end(struct cfs_rq *cfs_rq, struct 
sched_entity *se)
 }
 
 static inline void
-update_stats_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
+update_stats_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se,
+bool migrating)
 {
/*
 * Mark the end of the wait period if dequeueing a
 * waiting task:
 */
if (se != cfs_rq->curr)
-   update_stats_wait_end(cfs_rq, se);
+   update_stats_wait_end(cfs_rq, se, migrating);
 }
 
 /*
@@ -2960,7 +2975,7 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity 
*se, int flags)
enqueue_sleeper(cfs_rq, se);
}
 
-   update_stats_enqueue(cfs_rq, se);
+   update_stats_enqueue(cfs_rq, se, !!(flags & ENQUEUE_MIGRATING));
check_spread(cfs_rq, se);
if (se != cfs_rq->curr)
__enqueue_entity(cfs_rq, se);
@@ -3028,7 +3043,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity 
*se, int flags)
update_curr(cfs_rq);
dequeue_entity_load_avg(cfs_rq, se);
 
-   update_stats_dequeue(cfs_rq, se);
+   update_stats_dequeue(cfs_rq, se, !!(flags & DEQUEUE_MIGRATING));
if (flags & DEQUEUE_SLEEP) {
 #ifdef CONFIG_SCHEDSTATS
if (entity_is_task(se)) {
@@ -3114,7 +3129,7 @@ set_next_entity(struct cfs_rq *cfs_rq, struct 

Linux 4.3-rc7

[Linus Torvalds]

So it may still be Saturday at home, but with the Kernel Summit in
Korea coming up, I'm ahead of the curve in a +0900 timezone, and it's
Sunday here. So it's release day.

This rc breaks the "nicely shrinking and calming down" trend, largely
due to the fact that we had the networking fixes merged in rc7 (but
not in rc6). There's also a few other slightly larger pulls (ARM SoC
fixes, along with gpu, block layer and media fixes), and obviously all
the usual misc driver fixes etc. But the networking changes is what
makes it look a bit different from the previous rc.

And despite that slight increase in size, nothing looks particularly
worrisome, and this release cycle still seems to be going smoothly. As
already alluded to, next week is kernel summit, and with a lot of the
core maintainers being busy in Seoul, I'm assuming things stay calm
and unless anything odd happens, I'll do the final 4.3 next Sunday
(back in my usual timezone by then).

Shortlog appended for people who want to peruse the details.

  Linus

---

Abylay Ospan (1):
  [media] netup_unidvb: fix potential crash when spi is NULL

Achiad Shochat (1):
  net/mlx5e: Disable VLAN filter in promiscuous mode

Adam Richter (1):
  drm: fix mutex leak in drm_dp_get_mst_branch_device

Adam YH Lee (1):
  iio: adc: twl4030: Fix ADC[3:6] readings

Alex Deucher (3):
  drm/radeon/dpm: don't add pwm attributes if DPM is disabled
  drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
  drm/amdgpu: add missing dpm check for KV dpm late init

Alexandre Belloni (1):
  iio: mxs-lradc: Fix temperature offset

Alexei Starovoitov (1):
  bpf: clear sender_cpu before xmit

Alim Akhtar (1):
  ARM: dts: Fix audio card detection on Peach boards

Andrei Otcheretianski (1):
  iwlwifi: mvm: flush fw_dump_wk when mvm fails to start

Andrej Ota (1):
  via-rhine: fix VLAN receive handling regression.

Andrey Ryabinin (4):
  x86, kasan: Fix build failure on KASAN=y && KMEMCHECK=y kernels
  compiler, atomics, kasan: Provide READ_ONCE_NOCHECK()
  x86/mm, kasan: Silence KASAN warnings in get_wchan()
  lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y

Andrey Vagin (1):
  net/unix: fix logic about sk_peek_offset

Antti Palosaari (2):
  [media] rtl28xxu: fix control message flaws
  [media] m88ds3103: use own reg update_bits() implementation

Arad, Ronen (2):
  rtnetlink: fix gcc -Wconversion warning
  netlink: Trim skb to alloc size to avoid MSG_TRUNC

Arik Nemtsov (1):
  iwlwifi: mvm: init card correctly on ctkill exit check

Arnd Bergmann (4):
  mlxsw: fix warnings for big-endian 32-bit dma_addr_t
  nvme: fix 32-bit build warning
  ARM: pxa: fix pxa3xx DFI lockup hack
  KVM: arm: use GIC support unconditionally

Avraham Stern (1):
  iwlwifi: mvm: clear csa countdown when AP is stopped

Bard Liao (2):
  ASoC: rt298: correct index default value
  ASoC: rt298: fix wrong setting of gpio2_en

Carlo Caione (1):
  ARM: meson6: DTS: Fix wrong reg mapping and IRQ numbers

Carol L Soto (2):
  net/mlx4: Remove shared_ports variable at mlx4_enable_msi_x
  net/mlx4_core: Avoid failing the interrupts test

Cathy Avery (1):
  xen-blkfront: check for null drvdata in blkback_changed
(XenbusStateClosing)

Chaotian Jing (1):
  mmc: core: Fix init_card in 52Mhz

Charles Keepax (2):
  ASoC: Add info callback for SX_TLV controls
  ASoC: wm8904: Correct number of EQ registers

Chia-Sheng Chang (1):
  net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter

Chris Wilson (2):
  drm/i915: Flush pipecontrol post-sync writes
  drm/i915: Deny wrapping an userptr into a framebuffer

Christian Engelmayer (1):
  btrfs: fix possible leak in btrfs_ioctl_balance()

Christian Zander (1):
  iommu/vt-d: fix range computation when making room for large pages

Christoffer Dall (3):
  arm/arm64: KVM: Fix arch timer behavior for disabled interrupts
  arm/arm64: KVM: Clear map->active on pend/active clear
  arm/arm64: KVM: Fix disabled distributor operation

Christoph Hellwig (1):
  nvme: use an integer value to Linux errno values

Colin Ian King (1):
  [media] c8sectpfe: fix ininitialized error return on firmware load failure

Dan Carpenter (1):
  iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()

Daniel Borkmann (1):
  bpf: fix panic in SO_GET_FILTER with native ebpf programs

Daniel Bristot de Oliveira (1):
  sched, tracing: Stop/start critical timings around the idle=poll idle loop

Daniel Vetter (1):
  drm/i915: Fix kerneldoc for i915_gem_shrink_all

David Ahern (1):
  net: Fix vti use case with oif in dst lookups for IPv6

David B. Robins (1):
  net: usb: asix: Fix crash on skb alloc failure

David Henningsson (1):
  ALSA: hda - Fix inverted internal mic on Lenovo G50-80

David Howells (2):
  KEYS: Fix crash when attempt to garbage 

Re: Triggering non-integrity writeback from userspace

[Jan Kara]

  Hi,

On Thu 22-10-15 15:15:55, Andres Freund wrote:
> postgres regularly has to checkpoint data to disk to be able to free
> data from its journal. We currently use buffered IO and that's not
> going to change short term.
> 
> In a busy database this checkpointing process can write out a lot of
> data. Currently that frequently leads to massive latency spikes
> (c.f. 20140326191113.gf9...@alap3.anarazel.de) for other processed doing
> IO. These happen either when the kernel starts writeback or when, at the
> end of the checkpoint, we issue an fsync() on the datafiles.
> 
> One odd issue there is that the kernel tends to do writeback in a very
> irregular manner. Even if we write data at a constant rate writeback
> very often happens in bulk - not a good idea for preserving
> interactivity.
> 
> What we're preparing to do now is to regularly issue
> sync_file_range(SYNC_FILE_RANGE_WRITE) on a few blocks shortly after
> we've written them to to the OS. That way there's not too much dirty
> data in the page cache, so writeback won't cause latency spikes, and the
> fsync at the end doesn't have to write much if anything.
> 
> That improves things a lot.
> 
> But I still see latency spikes that shouldn't be there given the amount
> of IO. I'm wondering if that is related to the fact that
> SYNC_FILE_RANGE_WRITE ends up doing __filemap_fdatawrite_range with
> WB_SYNC_ALL specified. Given the the documentation for
> SYNC_FILE_RANGE_WRITE I did not expect that:
>  * SYNC_FILE_RANGE_WRITE: start writeout of all dirty pages in the range which
>  * are not presently under writeout.  This is an asynchronous flush-to-disk
>  * operation.  Not suitable for data integrity operations.
> 
> If I followed the code correctly - not a sure thing at all - that means
> bios are submitted with WRITE_SYNC specified. Not really what's needed
> in this case.
> 
> Now I think the docs are somewhat clear that SYNC_FILE_RANGE_WRITE isn't
> there for data integrity, but it might be that people rely on in
> nonetheless. so I'm loathe to suggest changing that. But I do wonder if
> there's a way non-integrity writeback triggering could be exposed to
> userspace. A new fadvise flags seems like a good way to do that -
> POSIX_FADV_DONTNEED actually does non-integrity writeback, but also does
> other things, so it's not suitable for us.

You are absolutely correct that sync_file_range() should issue writeback as
WB_SYNC_NONE and not wait for current writeback in progress. That was an
oversight introduced by commit ee53a891f474 (mm: do_sync_mapping_range
integrity fix) which changed do_sync_mapping_range() to use WB_SYNC_ALL
because it had other users which relied WB_SYNC_ALL semantics. Later that
got copied over to the current sync_file_range() implementation.

I think we should just revert to the very explicitely documented behavior
of sync_file_range(). I'll send a patch for that. Thanks for report.

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

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Linus Torvalds]

On Sun, Oct 25, 2015 at 11:18 AM, Tejun Heo  wrote:
>
> We definitely need to weigh the inputs from heavy users but also need
> to discern the actual problems which need to be solved from the
> specific mechanisms chosen to solve them.  Let's please keep the
> discussions technical.  That's the best way to reach a viable
> long-term solution which can benefit a lot wider audience in the long
> term.  Even though that might not be the path of least immediate
> resistance, I believe that google will be an eventual beneficiary too.

So here's a somewhat odd request I got to hear very recently (at
LinuxCon EU in Ireland)..

A least some game engine writers apparently would like to be able to
set scheduling priorities for threads within a single process, because
they may want te game as a whole to have a certain priority, but then
some of the threads are critical for latency and may want certain
guaranteed resources (eg audio or actual gameplay) while others are
very much background things (garbage collection etc).

I suspect that's a very non-google use. We apparently don't really
support that kind of per-thread model right now at all.

Do they want cgroups? Maybe not. You can apparently do something like
this under Windows and OS X, but not under Linux (and I'm reporting
second-hand here, I don't know the exact details). I'm just bringing
it up as a somewhat unusual non-server thing that is certainly very
relevant despite being different.

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

Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Jonathan Corbet]

On Sat, 24 Oct 2015 11:28:19 +0100
Grant Likely  wrote:

> I've been asked several versions of the same question, and also the
> annual "what does the TAB actually do?" question, so I'm going to try
> and answer them all in one email:

Great summary, Grant, thanks.

A few additions of my own...

- The Linux Foundation tends to ask TAB members if they can give talks at
  events.  Even more than free software development in general, TAB
  membership can be good if you don't like buying your own T-shirts!

- The TAB has been named in the kernel's "code of conflict" as the body
  that will receive complaints about harassment or other untoward
  behavior in our community and try to resolve them.  Thus far, no such
  complaints have been presented, but TAB members need to be prepared for
  that to happen.

- It has been my feeling for a fair while that the LF could make more use
  of the TAB and its expertise than happens currently.  Good TAB members
  might be those who are willing to let the LF know when they have an
  opinion on what the LF should be doing with and for the community.  As
  an example, some of us have been pushing for the TAB to help with the
  selection of technical talks at LF conferences; I *think* that we
  provided useful input for LCE this year.

That ties in to my last thought...in my time on the TAB, I've noticed
that most of the work tends to be done by a relatively small subset of
the members.  Perhaps every committee is like that, in the end.  A
successful TAB member, IMO, is one who is willing to make the time to not
just attend attend the meetings (which may be at less-than-convenient
times depending on where you live and travel), but also to commit to
putting some time into helping out when there's something to be done.

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

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Mike Galbraith]

On Sun, 2015-10-25 at 11:18 +0900, Tejun Heo wrote:
> Hello, Mike.
> 
> On Sat, Oct 24, 2015 at 06:36:07AM +0200, Mike Galbraith wrote:
> > On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote:
> > 
> > > It'd be a step back in usability only for users who have been using
> > > cgroups in fringing ways which can't be justified for ratification and
> > > we do want to actively filter those out.
> > 
> > Of all the cgroup signal currently in existence, seems the Google signal
> > has to have the most volume under the curve by a mile.  If you were to
> > filter that signal out, what remained would be a flat line of noise.
> 
> This is a weird direction to take the discussion, but let me provide a
> counter argument.

I don't think it's weird, it's just a thought wrt where pigeon holing
could lead:  If you filter out current users who do so in a manner you
consider to be in some way odd, when all the filtering is done, you may
find that you've filtered out the vast majority of current deployment.

> Google sure is an important user of the kernel and likely the most
> extensive user of cgroup.  At the same time, its kernel efforts are
> largely in service of a few very big internal customers which are in
> control of large part of the entire software stack.  The things that
> are important for general audience of the kernel in the long term
> don't necessarily coincide with what such efforts need or want.

I'm not at all sure of this, but I suspect that SUSE's gigabuck size
cgroup power user will land in the same "fringe" pigeon hole.  If so,
that would be another sizeable dent in volume.

My point is that these power users likely _are_ your general audience.
 
> I'd even venture to say as much as the inputs coming out of google are
> interesting and important, they're also a lot more prone to lock-in
> effects to short term solutions and status-quo given their priorities.
> This is not to denigrate google's kernel efforts but just to
> counter-balance "it's google" as a shortcut for proper technical
> discussions.
> 
> There are good reasons why cgroup is the design disaster as it is now
> and chasing each usage scenario and hack which provides the least
> immediate resistance without paying the effort to extract the actual
> requirements and common solutions is an important one.  It is critical
> to provide back-pressure for long-term thinking and solutions;
> otherwise, we're bound to repeat the errors and end up with something
> which everyone loves to hate.
> 
> We definitely need to weigh the inputs from heavy users but also need
> to discern the actual problems which need to be solved from the
> specific mechanisms chosen to solve them.  Let's please keep the
> discussions technical.

Sure, it was just a thought wrt "actively filter those out" and who all
"those" may end up being.

-Mike

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

Re: [PATCH] pci: Update VPD size with correct length

[Hannes Reinecke]

On 10/24/2015 02:52 AM, Alexander Duyck wrote:
> On 10/23/2015 02:09 AM, Hannes Reinecke wrote:
>> PCI-2.2 VPD entries have a maximum size of 32k, but might actually
>> be smaller than that. To figure out the actual size one has to read
>> the VPD area until the 'end marker' is reached.
>> Trying to read VPD data beyond that marker results in 'interesting'
>> effects, from simple read errors to crashing the card.
>> This path modifies the attribute size to the avialable VPD size.
>>
>> Signed-off-by: Hannes Reinecke 
>> ---
>>   drivers/pci/access.c | 29 +
>>   1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
>> index 6bc9b12..4f8208e 100644
>> --- a/drivers/pci/access.c
>> +++ b/drivers/pci/access.c
>> @@ -409,6 +409,34 @@ static int pci_vpd_f0_dev_check(struct pci_dev *dev)
>>   return ret;
>>   }
>>
>> +/**
>> + * pci_vpd_size - determine actual size of Vital Product Data
>> + * @dev:pci device struct
>> + * @old_size:current assumed size, also maximum allowed size
>> + *
>> + */
>> +size_t
>> +pci_vpd_pci22_size(struct pci_dev *dev, size_t old_size)
>> +{
>> +loff_t off = 0;
>> +unsigned char header[1+2];/* 1 byte tag, 2 bytes length */
>> +
>> +while (off < old_size && pci_read_vpd(dev, off, 1, header)) {
>> +if (header[0] == 0x78)/* End tag descriptor */
>> +return off + 1;
>> +if (header[0] & 0x80) {
>> +/* Large Resource Data Type Tag */
>> +if (pci_read_vpd(dev, off+1, 2, [1]) != 2)
>> +return off + 1;
>> +off += 3 + ((header[2] << 8) | header[1]);
>> +} else {
>> +/* Short Resource Data Type Tag */
>> +off += 1 + (header[0] & 0x07);
>> +}
>> +}
>> +return old_size;
>> +}
>> +
> 
> My understanding is that the end tag can have some data associated with
> it such as a checksum.  What you may want to look at doing is process
> long tag and short tag bits first.  Then you could do a mask and compare
> after and if ((header[0] & ~0x7) == 0x78) then you return off + 1.
> 
Ah. Oh. Hmm. Wasn't aware of that one.
Bjorn?

> Also I was wondering if you have looked at the cxgb4 network driver?
> They are using the vpd read/write calls to access their EEPROM and I
> assume they are doing so outside the actual VPD fields.
> 
As indicated; VPD page access is basically directly wired to the device.
So if the vendor chooses to do some extra magic there by all means let
him do so. This patch is meant for cards/vendors which (try) to adhere
to the PCI VPD specification, so our access to that should be
conformant, too.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] scsi: lpfc: Use kzalloc instead of kmalloc

[Matthew R. Ochs]

> On Oct 24, 2015, at 2:06 AM, Punit Vara  wrote:
> 
> This patch is to the lpfc_els.c which resolves following warning
> reported by coccicheck:
> 
> WARNING: kzalloc should be used for rdp_context, instead of
> kmalloc/memset
> 
> Signed-off-by: Punit Vara 

Reviewed-by: Matthew R. Ochs 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: remove useless casting value returned by kmalloc to structure

[Matthew R. Ochs]

Reviewed-by: Matthew R. Ochs 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl

[Dmitry Torokhov]

Hi Benjamin,

On Tue, Aug 25, 2015 at 11:12:59AM -0400, Benjamin Tissoires wrote:
> +static int uinput_abs_setup(struct uinput_device *udev,
> + struct uinput_setup __user *arg, size_t size)
> +{
> + struct uinput_abs_setup setup = {};
> + struct input_dev *dev;
> +
> + if (size > sizeof(setup))
> + return -E2BIG;
> + if (udev->state == UIST_CREATED)
> + return -EINVAL;
> + if (copy_from_user(, arg, size))
> + return -EFAULT;
> + if (setup.code > ABS_MAX)
> + return -ERANGE;
> +
> + dev = udev->dev;
> +
> + input_alloc_absinfo(dev);
> + if (!dev->absinfo)
> + return -ENOMEM;
> +
> + set_bit(setup.code, dev->absbit);
> + dev->absinfo[setup.code] = setup.absinfo;
> +
> + /*
> +  * We restore the state to UIST_NEW_DEVICE because the user has to call
> +  * UI_DEV_SETUP in the last place before UI_DEV_CREATE to check the
> +  * validity of the absbits.
> +  */

Do we have to be this strict? It seems to me that with the new IOCTLs
you naturally want to use the new ioctl to setup the device, then adjust
various axes and bits and then validate everything.

Thanks.

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

[PATCH] pstore: drop file opened reference count

[Geliang Tang]

In my recent commit, I added '.owner = THIS_MODULE' in both
pstore_fs_type and pstore_file_operations to increase a reference count
when pstore filesystem is mounted and pstore file is opened.[1]

But, it's repetitive. There is no need to increase the opened reference
count. We only need to increase the mounted reference count. When a file
is opened, the filesystem can't be unmounted. Hence the pstore module
can't be unloaded either.

So I drop the opened reference count in this patch.

[1] https://lkml.org/lkml/2015/10/20/84

Signed-off-by: Geliang Tang 
---
Here is the reference count test:

$ sudo /sbin/insmod lib/zlib_deflate/zlib_deflate.ko
$ sudo /sbin/insmod fs/pstore/pstore.ko
$ lsmod
Module  Size  Used by
pstore 13301  0
zlib_deflate   20156  1 pstore

$ sudo mount -t pstore pstore /sys/fs/pstore
$ lsmod
Module  Size  Used by
pstore 13301  1
zlib_deflate   20156  1 pstore

$ sudo /sbin/insmod lib/reed_solomon/reed_solomon.ko
$ sudo /sbin/insmod fs/pstore/ramoops.ko mem_address=0x8000 
mem_size=0x4 ecc=1
$ lsmod
Module  Size  Used by
ramoops11156  0
reed_solomon5878  1 ramoops
pstore 13301  2 ramoops
zlib_deflate   20156  1 pstore

$ sudo rmmod ramoops
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  1
zlib_deflate   20156  1 pstore

$ tail -f /sys/fs/pstore/console-ramoops-0 &
[1] 4479
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  1
zlib_deflate   20156  1 pstore

$ sudo umount /sys/fs/pstore
umount: /sys/fs/pstore: target is busy
(In some cases useful info about processes that
 use the device is found by lsof(8) or fuser(1).)

$ kill -9 4479
[1]+  Killed  tail -f /sys/fs/pstore/console-ramoops-0
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  1
zlib_deflate   20156  1 pstore

$ sudo umount /sys/fs/pstore
$ lsmod
Module  Size  Used by
reed_solomon5878  0
pstore 13301  0
zlib_deflate   20156  1 pstore

$ sudo rmmod pstore
$ lsmod
Module  Size  Used by
reed_solomon5878  0
zlib_deflate   20156  0
---
 fs/pstore/inode.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 3586491..556b9ec 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -178,7 +178,6 @@ static loff_t pstore_file_llseek(struct file *file, loff_t 
off, int whence)
 }
 
 static const struct file_operations pstore_file_operations = {
-   .owner  = THIS_MODULE,
.open   = pstore_file_open,
.read   = pstore_file_read,
.llseek = pstore_file_llseek,
-- 
2.5.0


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

Re: [PATCH 1/2] pstore: check PSTORE_FLAGS_FRAGILE in pstore_unregister

[Geliang Tang]

On Fri, Oct 23, 2015 at 09:54:31AM -0700, Kees Cook wrote:
> On Fri, Oct 23, 2015 at 7:56 AM, Geliang Tang  wrote:
> > When PSTORE_FLAGS_FRAGILE flag is set, only kmsg is registered in
> > pstore_register. So, under these circumstances, only kmsg needs to
> > be unregistered in pstore_unregister.
> >
> > Signed-off-by: Geliang Tang 
> 
> Would it make more sense to have the pstore_unregister_* calls be
> defensive, like kfree() is? In other words, it would be safe to call
> them, even if they hadn't been registered?
> 
> Either way, I'm fine with this. Good catch!
> 
> -Kees
> 

Thanks for your reply.

pstore_unregister_* is defensive as you expected. I have tested it. it
is safe to call them if they haven't been registered. This won't cause
any trouble.

But logically, we should check this flag in pstore_unregister.

-Geliang Tang

> > ---
> >  fs/pstore/platform.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> > index 0aab920..7ad2038 100644
> > --- a/fs/pstore/platform.c
> > +++ b/fs/pstore/platform.c
> > @@ -496,9 +496,12 @@ EXPORT_SYMBOL_GPL(pstore_register);
> >
> >  void pstore_unregister(struct pstore_info *psi)
> >  {
> > -   pstore_unregister_pmsg();
> > -   pstore_unregister_ftrace();
> > -   pstore_unregister_console();
> > +   if ((psi->flags & PSTORE_FLAGS_FRAGILE) == 0) {
> > +   pstore_unregister_pmsg();
> > +   pstore_unregister_ftrace();
> > +   pstore_unregister_console();
> > +   }
> > +
> > pstore_unregister_kmsg();
> >
> > free_buf_for_compression();
> > --
> > 2.5.0
> >
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS Security

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

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Tejun Heo]

Hello, Mike.

On Sat, Oct 24, 2015 at 06:36:07AM +0200, Mike Galbraith wrote:
> On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote:
> 
> > It'd be a step back in usability only for users who have been using
> > cgroups in fringing ways which can't be justified for ratification and
> > we do want to actively filter those out.
> 
> Of all the cgroup signal currently in existence, seems the Google signal
> has to have the most volume under the curve by a mile.  If you were to
> filter that signal out, what remained would be a flat line of noise.

This is a weird direction to take the discussion, but let me provide a
counter argument.

Google sure is an important user of the kernel and likely the most
extensive user of cgroup.  At the same time, its kernel efforts are
largely in service of a few very big internal customers which are in
control of large part of the entire software stack.  The things that
are important for general audience of the kernel in the long term
don't necessarily coincide with what such efforts need or want.

I'd even venture to say as much as the inputs coming out of google are
interesting and important, they're also a lot more prone to lock-in
effects to short term solutions and status-quo given their priorities.
This is not to denigrate google's kernel efforts but just to
counter-balance "it's google" as a shortcut for proper technical
discussions.

There are good reasons why cgroup is the design disaster as it is now
and chasing each usage scenario and hack which provides the least
immediate resistance without paying the effort to extract the actual
requirements and common solutions is an important one.  It is critical
to provide back-pressure for long-term thinking and solutions;
otherwise, we're bound to repeat the errors and end up with something
which everyone loves to hate.

We definitely need to weigh the inputs from heavy users but also need
to discern the actual problems which need to be solved from the
specific mechanisms chosen to solve them.  Let's please keep the
discussions technical.  That's the best way to reach a viable
long-term solution which can benefit a lot wider audience in the long
term.  Even though that might not be the path of least immediate
resistance, I believe that google will be an eventual beneficiary too.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][v2] ACPI: Using correct irq when waiting for events

[Chen, Yu C]

This should not be a valid warning IMO, 
because PATCH 2/3 is  based on PATCH 1/3,
and the warning of implicit declaration is defined 
in PATCH 1/3.


> -Original Message-
> From: lkp
> Sent: Sunday, October 25, 2015 1:19 AM
> To: Chen, Yu C
> Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, Rui;
> Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org; Chen, Yu C; sta...@vger.kernel.org
> Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events
> 
> Hi Chen,
> 
> [auto build test ERROR on pm/linux-next -- if it's inappropriate base, please
> suggest rules for selecting the more suitable base]
> 
> url:https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using-
> correct-irq-when-waiting-for-events/20151025-010210
> config: x86_64-randconfig-x015-201543 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from drivers/acpi/osl.c:26:
>drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete':
> >> drivers/acpi/osl.c:1183:6: error: implicit declaration of function
> 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration]
>  if (acpi_sci_irq_valid())
>  ^
>include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
>  if (__builtin_constant_p((cond)) ? !!(cond) :   \
>^
> >> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if'
>  if (acpi_sci_irq_valid())
>  ^
> >> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared (first use in 
> >> this
> function)
>   synchronize_hardirq(acpi_sci_irq);
>   ^
>drivers/acpi/osl.c:1184:23: note: each undeclared identifier is reported 
> only
> once for each function it appears in
>cc1: some warnings being treated as errors
> 
> vim +/acpi_sci_irq_valid +1183 drivers/acpi/osl.c
> 
>   1177void acpi_os_wait_events_complete(void)
>   1178{
>   1179/*
>   1180 * Make sure the GPE handler or the fixed event handler 
> is
> not used
>   1181 * on another CPU after removal.
>   1182 */
> > 1183if (acpi_sci_irq_valid())
> > 1184synchronize_hardirq(acpi_sci_irq);
>   1185flush_workqueue(kacpid_wq);
>   1186flush_workqueue(kacpi_notify_wq);
>   1187}
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] ARM: dts: Enable Exynos RNG module

[Tobias Jakobi]

Hello Krzysztof,


Krzysztof Kozlowski wrote:
> On 20.10.2015 01:11, Tobias Jakobi wrote:
>> Hello Krzysztof,
>>
>> I can confirm that this also works on a Odroid-X2, so I guess it's safe
>> to enable the PRNG for all Exynos4412-based Odroid devices.
> 
> Sure, I can send a patch for that. I can test it later also on Odroid-U3.
Thanks already!



>> Any chance that you might also take a look at the other hwcrypto stuff
>> on the SoC ('samsung,exynos4210-secss' compatible)?
> 
> What do you mean? The s5p-sss driver already supports Device Tree.
The driver supports DT, but it doesn't really work.

I'm using the following DT entry to let the driver probe correctly:
https://github.com/tobiasjakobi/linux-odroid/commit/82c00cddb5cbf89fad994784c28c8125beae8e13

But the crypto self-test fails on boot:
alg: skcipher: encryption failed on test 1 for ecb-aes-s5p: ret=22


Another problems is that SSS and PRNG can't be used at the same time,
since they both use common hardware resources (I think it was IO).


With best wishes,
Tobias


> Best regards,
> Krzysztof
> 
>>
>> With best wishes,
>> Tobias
>>
>>
>> Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>>
>>> The patchset adds necessary clock from Security SubSystem (SSS)
>>> and enables the PRNG module of Exynos for Trats2 board.
>>>
>>> The first patch (clock) is required for other ones so please
>>> take everything in one step.
>>>
>>> The actual Device Tree support (and compatible) was sent in separate
>>> patch:
>>>  - https://patchwork.kernel.org/patch/7432891/
>>>  - http://marc.info/?l=linux-crypto-vger=144522952725052=2
>>>
>>> The device can be tested (after applying both patchsets) with:
>>> $ echo exynos > /sys/class/misc/hw_random/rng_current
>>> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>> Krzysztof Kozlowski (3):
>>>   clk: samsung: exynos4: Add SSS gate clock
>>>   ARM: dts: Add PRNG module for exynos4
>>>   ARM: dts: Enable PRNG module on exynos4412-trats2
>>>
>>>  arch/arm/boot/dts/exynos4.dtsi  | 8 
>>>  arch/arm/boot/dts/exynos4412-trats2.dts | 4 
>>>  drivers/clk/samsung/clk-exynos4.c   | 1 +
>>>  include/dt-bindings/clock/exynos4.h | 1 +
>>>  4 files changed, 14 insertions(+)
>>>
>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: fix a trivial typo

[Vinod Koul]

On Sun, Oct 18, 2015 at 11:31:10PM +0800, Geliang Tang wrote:
> s/regsiter/register/
> 
Applied, now

Please ensure the patches have right subsystem names. You can use git log on
that file/subsystem to find the convention used

I have fixed it up before applying

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

Re: [PATCH v6.2 1/1] Input: Add userio module

[Dmitry Torokhov]

Hi Stephen,

On Fri, Oct 23, 2015 at 04:47:46PM -0400, cp...@redhat.com wrote:
> From: Stephen Chandler Paul 
> 
> Debugging input devices, specifically laptop touchpads, can be tricky
> without having the physical device handy. Here we try to remedy that
> with userio. This module allows an application to connect to a character
> device provided by the kernel, and emulate any serio device. In
> combination with userspace programs that can record PS/2 devices and
> replay them through the /dev/userio device, this allows developers to
> debug driver issues on the PS/2 level with devices simply by requesting
> a recording from the user experiencing the issue without having to have
> the physical hardware in front of them.
> 
> Signed-off-by: Stephen Chandler Paul 
> Reviewed-by: David Herrmann 
> ---
>   Changes
> * Remove the if (!userio) { return -1; } check that somehow got left in.
> 
> Sorry this took so long! I was wondering why you hadn't replied yet, only to
> notice I only made this change on my own tree and never sent out a response
> patch. Oops.

Thank you for making all the changes.

> +
> +static ssize_t userio_char_read(struct file *file, char __user *user_buffer,
> + size_t count, loff_t *ppos)
> +{
> + struct userio_device *userio = file->private_data;
> + int ret;
> + size_t nonwrap_len, copylen;
> + unsigned char buf[USERIO_BUFSIZE];
> + unsigned long flags;
> +
> + if (!count)
> + return 0;

This is not quite right: read of size 0 should still check if there is
data in the buffer and return -EAGAIN for non-blocking descriptors.

I cooked a patch (below) that should adjust the read behavior (_+ a
coupe of formatting changes), please take a look.

Thanks!

-- 
Dmitry

userio - misc fixups

From: Dmitry Torokhov 

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/serio/Kconfig  |9 ++-
 drivers/input/serio/userio.c |  122 ++
 2 files changed, 70 insertions(+), 61 deletions(-)

diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 22b8b58..c3d05b4 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -293,10 +293,13 @@ config SERIO_SUN4I_PS2
  module will be called sun4i-ps2.
 
 config USERIO
-   tristate "Virtual serio device support"
+   tristate "User space serio port driver support"
help
- Say Y here if you want to emulate serio devices using the userio
- kernel module.
+ Say Y here if you want to support user level drivers for serio
+ subsystem accessible under char device 10:240 - /dev/userio. Using
+ this facility userspace programs can implement serio ports that
+ will be used by the standard in-kernel serio consumer drivers,
+ such as psmouse and atkbd.
 
  To compile this driver as a module, choose M here: the module will be
  called userio.
diff --git a/drivers/input/serio/userio.c b/drivers/input/serio/userio.c
index 7a89371..df1fd41 100644
--- a/drivers/input/serio/userio.c
+++ b/drivers/input/serio/userio.c
@@ -4,14 +4,14 @@
  * Copyright (C) 2015 Stephen Chandler Paul 
  *
  * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU Lesser General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
+ * under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
  *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
FITNESS
- * FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
- * details.
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser
+ * General Public License for more details.
  */
 
 #include 
@@ -27,14 +27,14 @@
 #include 
 #include 
 
-#define USERIO_NAME "userio"
-#define USERIO_BUFSIZE 16
+#define USERIO_NAME"userio"
+#define USERIO_BUFSIZE 16
 
 static struct miscdevice userio_misc;
 
 struct userio_device {
struct serio *serio;
-   struct mutex lock;
+   struct mutex mutex;
 
bool running;
 
@@ -81,7 +81,7 @@ static int userio_char_open(struct inode *inode, struct file 
*file)
if (!userio)
return -ENOMEM;
 
-   mutex_init(>lock);
+   mutex_init(>mutex);
spin_lock_init(>buf_lock);
init_waitqueue_head(>waitq);
 
@@ -103,12 +103,15 @@ static int userio_char_release(struct inode *inode, 
struct file *file)
 {
struct userio_device *userio = 

[PATCH 3/3] Staging: wilc1000: Remove boolean comparision

[Punit Vara]

This patch is to the host_interface.c file that fixes up following
warning reported by coccicheck:

WARNING: Comparison to bool

Boolean tests do not need explicit comparison to true or false

Signed-off-by: Punit Vara 
---
 drivers/staging/wilc1000/host_interface.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 38fead4..09a6c98 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1440,7 +1440,7 @@ static s32 Handle_RcvdNtwrkInfo(struct host_if_drv 
*hif_drv,
}
}
 
-   if (bNewNtwrkFound == true) {
+   if (bNewNtwrkFound) {
PRINT_D(HOSTINF_DBG, "New network found\n");
 
if (hif_drv->strWILC_UsrScanReq.u32RcvdChCount < 
MAX_NUM_SCANNED_NETWORKS) {
@@ -2714,7 +2714,7 @@ static void Handle_PowerManagement(struct host_if_drv 
*hif_drv,
 
strWID.id = (u16)WID_POWER_MANAGEMENT;
 
-   if (strPowerMgmtParam->enabled == true)
+   if (strPowerMgmtParam->enabled)
s8PowerMode = MIN_FAST_PS;
else
s8PowerMode = NO_POWERSAVE;
-- 
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 2/3] Staging: wilc1000: Remove comparision of field address to NULL

[Punit Vara]

This is patch to the linux_wlan file that fixes up following error
reported by coccicheck :

ERROR: test of a variable/field address

Signed-off-by: Punit Vara 
---
 drivers/staging/wilc1000/linux_wlan.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index b879b8b..1b0f89c 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -907,7 +907,7 @@ void wilc1000_wlan_deinit(struct wilc *nic)
disable_sdio_interrupt();
mutex_unlock(_linux_wlan->hif_cs);
 #endif
-   if (_linux_wlan->txq_event != NULL)
+   if (!(_linux_wlan->txq_event))
up(_linux_wlan->txq_event);
 
PRINT_D(INIT_DBG, "Deinitializing Threads\n");
@@ -969,10 +969,10 @@ static int wlan_deinit_locks(struct wilc *nic)
 {
PRINT_D(INIT_DBG, "De-Initializing Locks\n");
 
-   if (_linux_wlan->hif_cs != NULL)
+   if (!(_linux_wlan->hif_cs))
mutex_destroy(_linux_wlan->hif_cs);
 
-   if (_linux_wlan->rxq_cs != NULL)
+   if (!(_linux_wlan->rxq_cs))
mutex_destroy(_linux_wlan->rxq_cs);
 
return 0;
@@ -1037,7 +1037,7 @@ static void wlan_deinitialize_threads(struct wilc *nic)
g_linux_wlan->close = 1;
PRINT_D(INIT_DBG, "Deinitializing Threads\n");
 
-   if (_linux_wlan->txq_event != NULL)
+   if (!(_linux_wlan->txq_event))
up(_linux_wlan->txq_event);
 
if (g_linux_wlan->txq_thread != NULL) {
-- 
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 1/3] staging: wilc1000: Remove reference preceded by free

[Punit Vara]

This patch is to the wilc_wfi_cfgoperations.c file that fixes up
following error reported by coccicheck:

ERROR: reference preceded by free on line 1219

For (params->seq_len) <= 0 memory is already freed when
(params->seq_len) >0 then memory was alloted. So there is no need to use
kfree whenever params->seq_len <=0 remove it and place kfree inside
(params->seq_len) >0 condition.

Signed-off-by: Punit Vara 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index bcbf1bd..9b3cf04 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1216,11 +1216,10 @@ static int add_key(struct wiphy *wiphy, struct 
net_device *netdev, u8 key_index,
 
priv->wilc_ptk[key_index]->key = 
kmalloc(params->key_len, GFP_KERNEL);
 
-   kfree(priv->wilc_ptk[key_index]->seq);
-
-   if ((params->seq_len) > 0)
+   if ((params->seq_len) > 0) {
+   kfree(priv->wilc_ptk[key_index]->seq);
priv->wilc_ptk[key_index]->seq = 
kmalloc(params->seq_len, GFP_KERNEL);
-
+   }
if (INFO) {
for (i = 0; i < params->key_len; i++)
PRINT_INFO(CFG80211_DBG, 
"Adding pairwise key value[%d] = %x\n", i, params->key[i]);
-- 
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 0/3] Staging: wilc1000: Remove coccicheck warnings and error

[Punit Vara]

Punit Vara (3):
  staging: wilc1000: Remove reference preceded by free
  Staging: wilc1000: Remove comparision of field address to NULL
  Staging: wilc1000: Remove boolean comparision

 drivers/staging/wilc1000/host_interface.c | 4 ++--
 drivers/staging/wilc1000/linux_wlan.c | 8 
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 7 +++
 3 files changed, 9 insertions(+), 10 deletions(-)

-- 
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 v7] Input: Add userio module

[Dmitry Torokhov]

On Thu, Oct 08, 2015 at 07:20:59PM +0200, David Herrmann wrote:
> On Mon, Oct 5, 2015 at 5:55 PM,   wrote:
> > +static int userio_char_release(struct inode *inode, struct file *file)
> > +{
> > +   struct userio_device *userio = file->private_data;
> > +
> > +   /* Don't free the serio port here, serio_unregister_port() does
> > +* this for us */
> > +   if (userio->running)
> > +   serio_unregister_port(userio->serio);
> > +   else
> > +   kfree(userio->serio);
> > +
> > +   kfree(userio);
> 
> I'm not very familiar with the serio-subsystem, but is there a
> guarantee that .write() will not be called once unregistered? I can
> see that it's not scheduled by userio anymore, but maybe there's an
> async path that can trigger .write() callbacks. Dunno.. I'll leave
> that to Dmitry.

I think this is OK. When port is unregistered we the driver will be
disconnected from it, and is not supposed to call serio_write() anymore.
In fact, it should not access port after calling serio_close(). If it
keeps the pointer and uses it is a bug in the other driver; we can't
really do much about it.

Thanks.

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

Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Fri, Oct 23, 2015 at 07:11:56PM -0500, Andrew F. Davis wrote:
> On 10/23/2015 06:18 PM, Mark Brown wrote:

> >mt6397 doesn't do this, it doesn't have a compatible string at all (it's
> >doing what I'm recommending that you do).  The SPMI devices are
> >standalone devices, their parent device is actually functioning as a bus
> >controller here (it's really a microcontroller inside the SoC).  The
> >Palmas is part of how we realised this was a problem.

> mt6397: Documentation/devicetree/bindings/mfd/mt6397.txt
> Doing exactly what I'm doing,

Tbe binding document is buggy and doesn't reflect the code, there's no
compatible string in the driver.

> The Palmas is a great example of why this is a good idea, there are
> so many spins on this common base, and look how we can re-use sub-nodes:

There's no real reuse here, we have to have a table in both the MFD and
regulator listing every variant.  Remember that the only reason the user
is having to type most of those subnodes at all is that we pushed things
into the DT, if someone forgot to include one of the nodes in their
board DT then they won't be able to use the relevant feature even if
it's there.

> >The fact that the SoC DT is not distinct from the board DT is actually
> >one of the problems with the way we're using DT at the minute, it means
> >that DTBs are much less stable than they should be since we can enhance
> >support for SoCs but DTBs need regenerating to take advantage of it.  It
> >would be much better if the boards just referenced the SoC they use and
> >pulled in a separate definition of the SoC (DT overlays will make it
> >much more tractable to implement that if someone has time...).

> I figured this can already be done by keeping the SoC stuff in dtsi files?

That doesn't help with the above issue, include files get processed at
the time the binary is generated.

> Well I have to match the sub-devices on something, it's ether the node name
> or the compatible string, so they might have to get used to typing :)

No, that's not the case - remember, users don't have to write a new
driver every time they instantiate a device on a board.  They're going
to have to list the in-use regulators one way or another but if we have
the extra compatible for regulators they have to bind both the core
device (which is going to be required anyway due to the control bus) and
the subnode saying that it has regulators (which we knew anyway as soon
as we knew we had the core device).


signature.asc
Description: PGP signature

Re: [GIT PULL] On-demand device probing

[Mark Brown]

On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:

> Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues aren't if you're not directly having problems.

There's also the understanding people had that the order things get
bound changes the ordering for some of the other cases (perhaps it's a
good idea to do that, it seems likely to be sensible?).



signature.asc
Description: PGP signature

Re: lseek(fd, 0, SEEK_CUR) returns unexpected result for O_APPEND file on linux 2.6.32-431.29.2

[Theodore Ts'o]

On Sat, Oct 24, 2015 at 01:18:11AM +0100, Sigurd Næss wrote:
> Below is a description of a simple test case that causes lseek(fd, 0,
> SEEK_CUR) to return an unexpectedly small result on one of my
> computers, with linux 2.6.32-431.29.2, but none of the others. I'm
> posting it on the off chance that this is (or was) a kernel bug, and
> not some problem on my end.

The kernel versions you are mentioning are all RHEL kernel versions.
The problem doesn't reproduce on the latest mainline kernel.

Cheers,

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

piping core dump to a program escapes container

[Shayan Pooya]

I noticed the following core_pattern behavior in my linux box while
running docker containers. I am not sure if it is bug, but it is
inconsistent and not documented.

If the core_pattern is set on the host, the containers will observe
and use the pattern for dumping cores (there is no per cgroup
core_pattern). According to core(5) for setting core_pattern one can:

1. echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern
2. echo "|/bin/custom_core /tmp/cores/ %e %p " > /proc/sys/kernel/core_pattern

The former pattern evaluates the /tmp/cores path in the container's
filesystem namespace. Which means, the host does not see a core file
in /tmp/cores.

However, the latter evaluates the /bin/custom_core path in the global
filesystem namespace. Moreover, if /bin/core decides to write the core
to a path (/tmp/cores in this case as shown by the arg to
custom_core), the path will be evaluated in the global filesystem
namespace as well.

The latter behaviour is counter-intuitive and error-prone as the
container can fill up the core-file directory which it does not have
direct access to (which means the core is also not accessible for
debugging if someone only has access to the container).

Currently, I work around this issue by detecting that the process is
crashing from a container (by comparing the namespace pid to the
global pid) and refuse to dump the core if it is from a container.

Tested on Ubuntu (kernel 3.16) and Fedora (kernel 4.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] ASoC: wm9713: convert to regmap

[Robert Jarzmik]

Convert the Wolfson WM9713 to regmap API. This will leverage all the
regmap functions (debug, registers update, etc ...).

As a bonus, this will pave the path to gpio chip introduction, and
devicetree support.

Signed-off-by: Robert Jarzmik 
---
Since v1: fix suspend/resume (that specific part is not tested yet)
---
 sound/soc/codecs/Kconfig  |   1 +
 sound/soc/codecs/wm9713.c | 296 +++---
 2 files changed, 152 insertions(+), 145 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0c9733ecd17f..ba306f8f3717 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -879,6 +879,7 @@ config SND_SOC_WM9712
 
 config SND_SOC_WM9713
tristate
+   select REGMAP_AC97
 
 # Amp
 config SND_SOC_LM4857
diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
index 4083a5130cbd..49f2f41dc553 100644
--- a/sound/soc/codecs/wm9713.c
+++ b/sound/soc/codecs/wm9713.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,34 +40,6 @@ struct wm9713_priv {
struct mutex lock;
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec,
-   unsigned int reg);
-static int ac97_write(struct snd_soc_codec *codec,
-   unsigned int reg, unsigned int val);
-
-/*
- * WM9713 register cache
- * Reg 0x3c bit 15 is used by touch driver.
- */
-static const u16 wm9713_reg[] = {
-   0x6174, 0x8080, 0x8080, 0x8080,
-   0xc880, 0xe808, 0xe808, 0x0808,
-   0x00da, 0x8000, 0xd600, 0xaaa0,
-   0xaaa0, 0xaaa0, 0x, 0x,
-   0x0f0f, 0x0040, 0x, 0x7f00,
-   0x0405, 0x0410, 0xbb80, 0xbb80,
-   0x, 0xbb80, 0x, 0x4523,
-   0x, 0x2000, 0x7eff, 0x,
-   0x, 0x, 0x0080, 0x,
-   0x, 0x, 0xfffe, 0x,
-   0x, 0x, 0x, 0xfffe,
-   0x4000, 0x, 0x, 0x,
-   0xb032, 0x3e00, 0x, 0x,
-   0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x0006,
-   0x0001, 0x, 0x574d, 0x4c13,
-};
-
 #define HPL_MIXER 0
 #define HPR_MIXER 1
 
@@ -220,18 +193,15 @@ static int wm9713_voice_shutdown(struct 
snd_soc_dapm_widget *w,
 struct snd_kcontrol *kcontrol, int event)
 {
struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
-   u16 status, rate;
 
if (WARN_ON(event != SND_SOC_DAPM_PRE_PMD))
return -EINVAL;
 
/* Gracefully shut down the voice interface. */
-   status = ac97_read(codec, AC97_EXTENDED_MID) | 0x1000;
-   rate = ac97_read(codec, AC97_HANDSET_RATE) & 0xF0FF;
-   ac97_write(codec, AC97_HANDSET_RATE, rate | 0x0200);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0f00, 0x0200);
schedule_timeout_interruptible(msecs_to_jiffies(1));
-   ac97_write(codec, AC97_HANDSET_RATE, rate | 0x0F00);
-   ac97_write(codec, AC97_EXTENDED_MID, status);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0f00, 0x0f00);
+   snd_soc_update_bits(codec, AC97_EXTENDED_MID, 0x1000, 0x1000);
 
return 0;
 }
@@ -674,39 +644,97 @@ static const struct snd_soc_dapm_route wm9713_audio_map[] 
= {
{"Capture Mono Mux", "Right", "Right Capture Source"},
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec,
-   unsigned int reg)
+static bool wm9713_readable_reg(struct device *dev, unsigned int reg)
 {
-   struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
-   u16 *cache = codec->reg_cache;
-
-   if (reg == AC97_RESET || reg == AC97_GPIO_STATUS ||
-   reg == AC97_VENDOR_ID1 || reg == AC97_VENDOR_ID2 ||
-   reg == AC97_CD)
-   return soc_ac97_ops->read(wm9713->ac97, reg);
-   else {
-   reg = reg >> 1;
-
-   if (reg >= (ARRAY_SIZE(wm9713_reg)))
-   return -EIO;
-
-   return cache[reg];
+   switch (reg) {
+   case AC97_RESET ... AC97_PCM_SURR_DAC_RATE:
+   case AC97_PCM_LR_ADC_RATE:
+   case AC97_CENTER_LFE_MASTER:
+   case AC97_SPDIF ... AC97_LINE1_LEVEL:
+   case AC97_GPIO_CFG ... 0x5c:
+   case AC97_CODEC_CLASS_REV ... AC97_PCI_SID:
+   case 0x74 ... AC97_VENDOR_ID2:
+   return true;
+   default:
+   return false;
}
 }
 
-static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
-   unsigned int val)
+static bool wm9713_writeable_reg(struct device *dev, unsigned int reg)
 {
-   struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
+   switch (reg) {
+   case AC97_VENDOR_ID1:
+   case AC97_VENDOR_ID2:
+   return false;
+   default:
+   return wm9713_readable_reg(dev, reg);
+   }
+}
 
-   u16 *cache = codec->reg_cache;
-   soc_ac97_ops->write(wm9713->ac97, reg, val);
-   reg = reg >> 1;
-   if (reg < (ARRAY_SIZE(wm9713_reg)))
-   cache[reg] = 

Re: Triggering non-integrity writeback from userspace

[Dave Chinner]

On Thu, Oct 22, 2015 at 03:15:55PM +0200, Andres Freund wrote:
> Hi,
> 
> postgres regularly has to checkpoint data to disk to be able to free
> data from its journal. We currently use buffered IO and that's not
> going to change short term.
> 
> In a busy database this checkpointing process can write out a lot of
> data. Currently that frequently leads to massive latency spikes
> (c.f. 20140326191113.gf9...@alap3.anarazel.de) for other processed doing
> IO. These happen either when the kernel starts writeback or when, at the
> end of the checkpoint, we issue an fsync() on the datafiles.
> 
> One odd issue there is that the kernel tends to do writeback in a very
> irregular manner. Even if we write data at a constant rate writeback
> very often happens in bulk - not a good idea for preserving
> interactivity.
> 
> What we're preparing to do now is to regularly issue
> sync_file_range(SYNC_FILE_RANGE_WRITE) on a few blocks shortly after
> we've written them to to the OS. That way there's not too much dirty
> data in the page cache, so writeback won't cause latency spikes, and the
> fsync at the end doesn't have to write much if anything.
> 
> That improves things a lot.
> 
> But I still see latency spikes that shouldn't be there given the amount
> of IO. I'm wondering if that is related to the fact that
> SYNC_FILE_RANGE_WRITE ends up doing __filemap_fdatawrite_range with
> WB_SYNC_ALL specified. Given the the documentation for
> SYNC_FILE_RANGE_WRITE I did not expect that:
>  * SYNC_FILE_RANGE_WRITE: start writeout of all dirty pages in the range which
>  * are not presently under writeout.  This is an asynchronous flush-to-disk
>  * operation.  Not suitable for data integrity operations.

WB_SYNC_ALL is simply a method of saying "writeback all dirty pages
and don't skip any". That's part of a data integrity operation, but
it's not what results in data integrity being provided. It may cause
some latencies caused by blocking on locks or in the request queues,
so that's what I'd be looking for.

i.e. if the request queues are full, SYNC_FILE_RANGE_WRITE will
block until all the IO it has been requested to write has been
submitted to the request queues. Put simply: the IO is asynchronous
in that we don't wait for completion, but the IO submission is still
synchronous.

Data integrity operations require related file metadata (e.g. block
allocation trnascations) to be forced to the journal/disk, and a
device cache flush issued to ensure the data is on stable storage.
SYNC_FILE_RANGE_WRITE does neither of these things, and hence while
the IO might be the same pattern as a data integrity operation, it
does not provide such guarantees.

> If I followed the code correctly - not a sure thing at all - that means
> bios are submitted with WRITE_SYNC specified. Not really what's needed
> in this case.

That just allows the IO scheduler to classify them differently to
bulk background writeback. 

> Now I think the docs are somewhat clear that SYNC_FILE_RANGE_WRITE isn't
> there for data integrity, but it might be that people rely on in
> nonetheless. so I'm loathe to suggest changing that. But I do wonder if
> there's a way non-integrity writeback triggering could be exposed to
> userspace. A new fadvise flags seems like a good way to do that -
> POSIX_FADV_DONTNEED actually does non-integrity writeback, but also does
> other things, so it's not suitable for us.

You don't want to do writeback from the syscall, right? i.e. you'd
like to expire the inode behind the fd, and schedule background
writeback to run on it immediately?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: QUestion on x86_64 and i386 for settings of SS segment register

[Jeffrey Merkey]

Found the answer in ptrace.h -- the answer is no.  never mind.

Jeff

On 10/24/15, Jeffrey Merkey  wrote:
> I am updating the mdb kernel debugger on 4.2.4 and I noticed that
> user_mode_vm has been removed from the kernel sources for detecting
> user space memory addresses for purposes of loading the SS pointer.  I
> am using __KERNEL_DS presently.
>
> old code:
>
> if (user_mode_vm(regs))
> {
> sf->tSS = regs->ss;
> sf->tSP = regs->sp;
> } else {
>   sf->tSS = __KERNEL_DS;
>   sf->tSP = kernel_stack_pointer(regs);
> }
>
> is SS always assumed to be __KERNEL_DS in 4.2.4 for userspace stack
> addresses passed by pt_regs?
>
>
> Thanks
>
> Jeff
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

QUestion on x86_64 and i386 for settings of SS segment register

[Jeffrey Merkey]

I am updating the mdb kernel debugger on 4.2.4 and I noticed that
user_mode_vm has been removed from the kernel sources for detecting
user space memory addresses for purposes of loading the SS pointer.  I
am using __KERNEL_DS presently.

old code:

if (user_mode_vm(regs))
{
sf->tSS = regs->ss;
sf->tSP = regs->sp;
} else {
  sf->tSS = __KERNEL_DS;
  sf->tSP = kernel_stack_pointer(regs);
}

is SS always assumed to be __KERNEL_DS in 4.2.4 for userspace stack
addresses passed by pt_regs?


Thanks

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

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Doug Anderson]

Rob,

On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring  wrote:
> On 10/23/2015 01:28 PM, Douglas Anderson wrote:
>> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
>> has a hardware errata that causes everything to get confused when we get
>> a remote wakeup.  It appears that the "port reset" bit that's in the USB
>> phy (located in the rk3288 GRF) fixes things up and appears safe to do.
>>
>> This series of patches exports the "port reset" from the PHY and then
>> hooks it up to dwc2 through a quirk.
>>
>> I've tested this series atop a bit of a conglomeration of Heiko's github
>> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
>> usb-next merged in.
>>
>> These patches currently conflict with patches that I posted previously
>> to enable USB wakeup from S3, specifically:
>> * https://patchwork.kernel.org/patch/6727081/
>> * https://patchwork.kernel.org/patch/6727121/
>> ...those patches no longer apply anyway, so presumably they need to be
>> reposted and I can do so later atop these patches.
>>
>>
>> Douglas Anderson (4):
>>   phy: rockchip-usb: Support the PHY's "port reset"
>>   usb: dwc2: optionally assert phy "port reset" when waking up
>>   ARM: dts: rockchip: Enable the USB phys as reset providers on rk3288
>>   ARM: dts: rockchip: Point rk3288 dwc2 usb at phy port reset
>>
>>  .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  6 ++
>>  Documentation/devicetree/bindings/usb/dwc2.txt |  7 ++
>>  arch/arm/boot/dts/rk3288.dtsi  |  8 +++
>>  drivers/phy/phy-rockchip-usb.c | 74 
>> ++
>>  drivers/usb/dwc2/core.h|  5 ++
>>  drivers/usb/dwc2/core_intr.c   |  7 ++
>>  drivers/usb/dwc2/platform.c| 13 
>>  7 files changed, 120 insertions(+)
>
> A DT reset controller seems like a bit of an overkill here. I think this
> would be much more simple if we just add a phy reset hook to the phy
> subsystem.

Adding a reset hook in the PHY subsystem does seem like a reasonable
idea to me.  I was considering it in an earlier version of this series
that actually used a reset of the PHY to the fix the stuck dwc2.

...but I think that even if the phy subsystem had a reset hook it
wouldn't be the ideal solution here.  When we assert the PHY "port
reset" we're not actually fully resetting the PHY.  We're instead
doing some sort of a more minor "state machine" reset in the PHY.
This appears better (in my case) than resetting the whole PHY because
it doesn't force a de-enumeration / re-enumeration.  Exposing this
more minor reset as a PHY reset seems wrong to me.  ...and it also
precludes us later also exposing the more full reset through the PHY
framework if that later becomes useful.

...we could, of course, re-invent the reset framework (with string or
integral IDs so we can assert different types of resets) within the
PHY framework.  That doesn't seem ideal to me, but if that's what
others want to do then I guess it would be OK...

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

[PATCH] ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property

[Karsten Merker]

The MSI Primo81 has a display in portrait mode but a touchscreen
in landscape mode.  To have both of them use the same coordinate
system, the touchscreen-swapped-x-y property has to be set
for the touchscreen.

Signed-off-by: Karsten Merker 
---
 arch/arm/boot/dts/sun6i-a31s-primo81.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts 
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
index 2d4250b..68b479b 100644
--- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -83,6 +83,7 @@
reg = <0x5d>;
interrupt-parent = <>;
interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
+   touchscreen-swapped-x-y;
};
 };
 
-- 
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: [alsa-devel] [PATCH] ASoC: wm9713: convert to regmap

[kbuild test robot]

Hi Robert,

[auto build test ERROR on asoc/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Robert-Jarzmik/ASoC-wm9713-convert-to-regmap/20151025-042116
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/list.h:8:0,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from sound/soc/codecs/wm9713.c:19:
   sound/soc/codecs/wm9713.c: In function 'wm9713_soc_resume':
>> sound/soc/codecs/wm9713.c:1199:30: error: 'wm9713_reg' undeclared (first use 
>> in this function)
  for (i = 2; i < ARRAY_SIZE(wm9713_reg) << 1; i += 2) {
 ^
   include/linux/kernel.h:54:33: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
   sound/soc/codecs/wm9713.c:1199:30: note: each undeclared identifier is 
reported only once for each function it appears in
  for (i = 2; i < ARRAY_SIZE(wm9713_reg) << 1; i += 2) {
 ^
   include/linux/kernel.h:54:33: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
   In file included from include/linux/thread_info.h:11:0,
from include/asm-generic/preempt.h:4,
from arch/xtensa/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:64,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from sound/soc/codecs/wm9713.c:19:
   include/linux/bug.h:33:45: error: bit-field '' width not an 
integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
   ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^
>> sound/soc/codecs/wm9713.c:1199:19: note: in expansion of macro 'ARRAY_SIZE'
  for (i = 2; i < ARRAY_SIZE(wm9713_reg) << 1; i += 2) {
  ^

vim +/wm9713_reg +1199 sound/soc/codecs/wm9713.c

83ac08c084 Liam Girdwood 2008-02-15  1193   /* do we need to re-start the 
PLL ? */
c42f69bb06 Mark Brown2009-01-16  1194   if (wm9713->pll_in)
c42f69bb06 Mark Brown2009-01-16  1195   wm9713_set_pll(codec, 
0, wm9713->pll_in, 0);
83ac08c084 Liam Girdwood 2008-02-15  1196  
83ac08c084 Liam Girdwood 2008-02-15  1197   /* only synchronise the codec 
if warm reset failed */
83ac08c084 Liam Girdwood 2008-02-15  1198   if (ret == 0) {
83ac08c084 Liam Girdwood 2008-02-15 @1199   for (i = 2; i < 
ARRAY_SIZE(wm9713_reg) << 1; i += 2) {
83ac08c084 Liam Girdwood 2008-02-15  1200   if (i == 
AC97_POWERDOWN || i == AC97_EXTENDED_MID ||
83ac08c084 Liam Girdwood 2008-02-15  1201   i == 
AC97_EXTENDED_MSTATUS || i > 0x66)
83ac08c084 Liam Girdwood 2008-02-15  1202   
continue;

:: The code at line 1199 was first introduced by commit
:: 83ac08c0846bc6106d6c7fbb342eab02b32dd399 [ALSA] ASoC: WM9713 driver

:: TO: Liam Girdwood 
:: CC: Takashi Iwai 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [alsa-devel] [PATCH] ASoC: wm9713: convert to regmap

[kbuild test robot]

Hi Robert,

[auto build test ERROR on asoc/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Robert-Jarzmik/ASoC-wm9713-convert-to-regmap/20151025-042116
config: tile-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   sound/soc/codecs/wm9713.c: In function 'wm9713_soc_resume':
   sound/soc/codecs/wm9713.c:1199:19: error: 'wm9713_reg' undeclared (first use 
in this function)
   sound/soc/codecs/wm9713.c:1199:19: note: each undeclared identifier is 
reported only once for each function it appears in
>> sound/soc/codecs/wm9713.c:1199:19: error: negative width in bit-field 
>> ''

vim +1199 sound/soc/codecs/wm9713.c

83ac08c084 Liam Girdwood 2008-02-15  1193   /* do we need to re-start the 
PLL ? */
c42f69bb06 Mark Brown2009-01-16  1194   if (wm9713->pll_in)
c42f69bb06 Mark Brown2009-01-16  1195   wm9713_set_pll(codec, 
0, wm9713->pll_in, 0);
83ac08c084 Liam Girdwood 2008-02-15  1196  
83ac08c084 Liam Girdwood 2008-02-15  1197   /* only synchronise the codec 
if warm reset failed */
83ac08c084 Liam Girdwood 2008-02-15  1198   if (ret == 0) {
83ac08c084 Liam Girdwood 2008-02-15 @1199   for (i = 2; i < 
ARRAY_SIZE(wm9713_reg) << 1; i += 2) {
83ac08c084 Liam Girdwood 2008-02-15  1200   if (i == 
AC97_POWERDOWN || i == AC97_EXTENDED_MID ||
83ac08c084 Liam Girdwood 2008-02-15  1201   i == 
AC97_EXTENDED_MSTATUS || i > 0x66)
83ac08c084 Liam Girdwood 2008-02-15  1202   
continue;

:: The code at line 1199 was first introduced by commit
:: 83ac08c0846bc6106d6c7fbb342eab02b32dd399 [ALSA] ASoC: WM9713 driver

:: TO: Liam Girdwood 
:: CC: Takashi Iwai 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] ASoC: wm9713: convert to regmap

[Robert Jarzmik]

Convert the Wolfson WM9713 to regmap API. This will leverage all the
regmap functions (debug, registers update, etc ...).

As a bonus, this will pave the path to gpio chip introduction, and
devicetree support.

Signed-off-by: Robert Jarzmik 
---
 sound/soc/codecs/Kconfig  |   1 +
 sound/soc/codecs/wm9713.c | 284 --
 2 files changed, 147 insertions(+), 138 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0c9733ecd17f..ba306f8f3717 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -879,6 +879,7 @@ config SND_SOC_WM9712
 
 config SND_SOC_WM9713
tristate
+   select REGMAP_AC97
 
 # Amp
 config SND_SOC_LM4857
diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
index 4083a5130cbd..18f371b2add5 100644
--- a/sound/soc/codecs/wm9713.c
+++ b/sound/soc/codecs/wm9713.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,34 +40,6 @@ struct wm9713_priv {
struct mutex lock;
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec,
-   unsigned int reg);
-static int ac97_write(struct snd_soc_codec *codec,
-   unsigned int reg, unsigned int val);
-
-/*
- * WM9713 register cache
- * Reg 0x3c bit 15 is used by touch driver.
- */
-static const u16 wm9713_reg[] = {
-   0x6174, 0x8080, 0x8080, 0x8080,
-   0xc880, 0xe808, 0xe808, 0x0808,
-   0x00da, 0x8000, 0xd600, 0xaaa0,
-   0xaaa0, 0xaaa0, 0x, 0x,
-   0x0f0f, 0x0040, 0x, 0x7f00,
-   0x0405, 0x0410, 0xbb80, 0xbb80,
-   0x, 0xbb80, 0x, 0x4523,
-   0x, 0x2000, 0x7eff, 0x,
-   0x, 0x, 0x0080, 0x,
-   0x, 0x, 0xfffe, 0x,
-   0x, 0x, 0x, 0xfffe,
-   0x4000, 0x, 0x, 0x,
-   0xb032, 0x3e00, 0x, 0x,
-   0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x0006,
-   0x0001, 0x, 0x574d, 0x4c13,
-};
-
 #define HPL_MIXER 0
 #define HPR_MIXER 1
 
@@ -220,18 +193,15 @@ static int wm9713_voice_shutdown(struct 
snd_soc_dapm_widget *w,
 struct snd_kcontrol *kcontrol, int event)
 {
struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
-   u16 status, rate;
 
if (WARN_ON(event != SND_SOC_DAPM_PRE_PMD))
return -EINVAL;
 
/* Gracefully shut down the voice interface. */
-   status = ac97_read(codec, AC97_EXTENDED_MID) | 0x1000;
-   rate = ac97_read(codec, AC97_HANDSET_RATE) & 0xF0FF;
-   ac97_write(codec, AC97_HANDSET_RATE, rate | 0x0200);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0f00, 0x0200);
schedule_timeout_interruptible(msecs_to_jiffies(1));
-   ac97_write(codec, AC97_HANDSET_RATE, rate | 0x0F00);
-   ac97_write(codec, AC97_EXTENDED_MID, status);
+   snd_soc_update_bits(codec, AC97_HANDSET_RATE, 0x0f00, 0x0f00);
+   snd_soc_update_bits(codec, AC97_EXTENDED_MID, 0x1000, 0x1000);
 
return 0;
 }
@@ -674,39 +644,97 @@ static const struct snd_soc_dapm_route wm9713_audio_map[] 
= {
{"Capture Mono Mux", "Right", "Right Capture Source"},
 };
 
-static unsigned int ac97_read(struct snd_soc_codec *codec,
-   unsigned int reg)
+static bool wm9713_readable_reg(struct device *dev, unsigned int reg)
 {
-   struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
-   u16 *cache = codec->reg_cache;
-
-   if (reg == AC97_RESET || reg == AC97_GPIO_STATUS ||
-   reg == AC97_VENDOR_ID1 || reg == AC97_VENDOR_ID2 ||
-   reg == AC97_CD)
-   return soc_ac97_ops->read(wm9713->ac97, reg);
-   else {
-   reg = reg >> 1;
-
-   if (reg >= (ARRAY_SIZE(wm9713_reg)))
-   return -EIO;
-
-   return cache[reg];
+   switch (reg) {
+   case AC97_RESET ... AC97_PCM_SURR_DAC_RATE:
+   case AC97_PCM_LR_ADC_RATE:
+   case AC97_CENTER_LFE_MASTER:
+   case AC97_SPDIF ... AC97_LINE1_LEVEL:
+   case AC97_GPIO_CFG ... 0x5c:
+   case AC97_CODEC_CLASS_REV ... AC97_PCI_SID:
+   case 0x74 ... AC97_VENDOR_ID2:
+   return true;
+   default:
+   return false;
}
 }
 
-static int ac97_write(struct snd_soc_codec *codec, unsigned int reg,
-   unsigned int val)
+static bool wm9713_writeable_reg(struct device *dev, unsigned int reg)
 {
-   struct wm9713_priv *wm9713 = snd_soc_codec_get_drvdata(codec);
+   switch (reg) {
+   case AC97_VENDOR_ID1:
+   case AC97_VENDOR_ID2:
+   return false;
+   default:
+   return wm9713_readable_reg(dev, reg);
+   }
+}
 
-   u16 *cache = codec->reg_cache;
-   soc_ac97_ops->write(wm9713->ac97, reg, val);
-   reg = reg >> 1;
-   if (reg < (ARRAY_SIZE(wm9713_reg)))
-   cache[reg] = val;
+static const struct reg_default wm9713_reg_defaults[] = {
+   { 

Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade

[Jiri Kosina]

On Sat, 24 Oct 2015, Michele Baldessari wrote:

> The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
> to have the two distinct joysticks working.
> 
> Before the change:
> $ jstest /dev/input/js0
> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
> ...
> $ jstest /dev/input/js1
> jstest: No such file or directory
> 
> After the change:
> $ jstest /dev/input/js0
> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
> ...
> $ jstest /dev/input/js1
> Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
> ...
> 
> Signed-off-by: Michele Baldessari 

Adding Oliver to CC.

Oliver, how come that you didn't need this while working on the inigial 
Xin-Mo Dual Arcade support?

Thanks.

> ---
>  drivers/hid/usbhid/hid-quirks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 1dff8f0015ba..f69049314a2c 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -150,6 +150,7 @@ static const struct hid_blacklist {
>   { USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD, 
> HID_QUIRK_MULTI_INPUT },
>   { USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES, 
> HID_QUIRK_MULTI_INPUT },
>   { USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES, 
> HID_QUIRK_MULTI_INPUT },
> + { USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE, 
> HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
>  
>   { 0, 0 }
>  };
> -- 
> 2.5.0
> 

-- 
Jiri Kosina
SUSE Labs

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

Re: + signal-turn-dequeue_signal_lock-into-kernel_dequeue_signal.patch added to -mm tree

[Markus Pargmann]

Hi Oleg,

On Sat, Oct 24, 2015 at 09:48:26PM +0200, Oleg Nesterov wrote:
> Hi Markus,
> 
> s/mm-commits/lkml/
> 
> On 10/24, Markus Pargmann wrote:
> >
> > On Mon, Oct 05, 2015 at 02:19:27PM -0700, a...@linux-foundation.org wrote:
> > >
> > > Subject: signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
> > >
> > > 1. Rename dequeue_signal_lock() to kernel_dequeue_signal(). This
> > >matches another "for kthreads only" kernel_sigaction() helper.
> > >
> > > 2. Remove the "tsk" and "mask" arguments, they are always current
> > >and current->blocked. And it is simply wrong if tsk != current.
> > >
> > > 3. We could also remove the 3rd "siginfo_t *info" arg but it looks
> > >potentially useful. However we can simplify the callers if we
> > >change kernel_dequeue_signal() to accept info => NULL.
> > >
> > > 4. Remove _irqsave, it is never called from atomic context.
> >
> > I just realised that this patch will conflict with a fixup patch for nbd
> > that will be included in rc7.
> >
> > dcc909d90ccd (nbd: Add locking for tasks)
> >
> > I think there is basically one new instance of dequeue_signal_lock() that
> > needs to be replaced with kernel_dequeue_signal().
> 
> Thanks! I'll send *-fix.patch to Andrew.
> 
> But you know, dcc909d90ccd (nbd: Add locking for tasks) doesn't look exactly
> right at first glance, although I need to re-check tomorrow...

In which regard? Is the locking incorrect or am I doing something wrong
with the signal handling?

> 
> One question, can sock_xmit() be called from user space? Or it is only called
> by kthreads?

sock_xmit() can be called by a thread that entered from userspace. In
general the idea is that there are no pending signals when it leaves
into userspace again.

Best Regards,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: + signal-turn-dequeue_signal_lock-into-kernel_dequeue_signal.patch added to -mm tree

[Oleg Nesterov]

Hi Markus,

s/mm-commits/lkml/

On 10/24, Markus Pargmann wrote:
>
> On Mon, Oct 05, 2015 at 02:19:27PM -0700, a...@linux-foundation.org wrote:
> >
> > Subject: signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
> >
> > 1. Rename dequeue_signal_lock() to kernel_dequeue_signal(). This
> >matches another "for kthreads only" kernel_sigaction() helper.
> >
> > 2. Remove the "tsk" and "mask" arguments, they are always current
> >and current->blocked. And it is simply wrong if tsk != current.
> >
> > 3. We could also remove the 3rd "siginfo_t *info" arg but it looks
> >potentially useful. However we can simplify the callers if we
> >change kernel_dequeue_signal() to accept info => NULL.
> >
> > 4. Remove _irqsave, it is never called from atomic context.
>
> I just realised that this patch will conflict with a fixup patch for nbd
> that will be included in rc7.
>
> dcc909d90ccd (nbd: Add locking for tasks)
>
> I think there is basically one new instance of dequeue_signal_lock() that
> needs to be replaced with kernel_dequeue_signal().

Thanks! I'll send *-fix.patch to Andrew.

But you know, dcc909d90ccd (nbd: Add locking for tasks) doesn't look exactly
right at first glance, although I need to re-check tomorrow...

One question, can sock_xmit() be called from user space? Or it is only called
by kthreads?

Oleg.

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

MONEY GRAM

[MONEY GRAM INTL.]

--
MONEY GRAM SENT THE SUM OF $2900.00 TO YOU.WITH REF NO#:7682-4989,kindly
contact MR.PAUL HOWARD FOR MORE DETAILS,




Message sent using UebiMiau 2.7.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/

I NEED YOUR ASSISTANCE

I NEED YOUR ASSISTANCE.CAN YOU BE TRUSTED?IF YES CONTACT FOR MORE INFO
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[MODULE JOYDEV] Steering wheel Logitech Driving Force GT -> wrong number of axis, and wrong axis separation for throttle and brake

[Giuseppe Della Bianca]

Hi.

With steering wheel Logitech Driving Force GT are recognized wrong number of 
axis, and wrong axis separation for throttle and brake.

For example, the game torcs, requires throttle and brake on the same axis.


Fedora release 21 (Twenty One), Linux 4.1.8-100.fc21.x86_64

[ 3359.259057] usb 2-6: new full-speed USB device number 6 using ohci-pci
[ 3359.455081] usb 2-6: New USB device found, idVendor=046d, idProduct=c294
[ 3359.455094] usb 2-6: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[ 3359.455101] usb 2-6: Product: Driving Force GT
[ 3359.467680] input: Driving Force GT as 
/devices/pci:00/:00:02.0/usb2/2-6/2-6:1.0/0003:046D:C294.0007/input/input15
[ 3359.518729] logitech 0003:046D:C294.0007: input,hidraw3: USB HID v1.00 
Joystick [Driving Force GT] on usb-:00:02.0-6/input0
[ 3359.532116] usb 2-6: USB disconnect, device number 6
[ 3360.061052] usb 2-6: new full-speed USB device number 7 using ohci-pci
[ 3360.260081] usb 2-6: New USB device found, idVendor=046d, idProduct=c29a
[ 3360.260094] usb 2-6: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[ 3360.260102] usb 2-6: Product: Driving Force GT
[ 3360.282321] input: Driving Force GT as 
/devices/pci:00/:00:02.0/usb2/2-6/2-6:1.0/0003:046D:C29A.0008/input/input16
[ 3360.333728] logitech 0003:046D:C29A.0008: input,hidraw3: USB HID v1.11 
Joystick [Driving Force GT] on usb-:00:02.0-6/input0
[ 3360.333788] logitech 0003:046D:C29A.0008: Force feedback support for 
Logitech Gaming Wheels


Bus 002 Device 005: ID 046d:c29a Logitech, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize016
  idVendor   0x046d Logitech, Inc.
  idProduct  0xc29a 
  bcdDevice   13.27
  iManufacturer   0 
  iProduct2 Driving Force GT
  iSerial 0 
  bNumConfigurations  1


jscal -c /dev/input/js0 
Joystick has 5 axes and 21 buttons. 


# steering wheel calibration (right)
Move axis 0 to minimum position and push any button.


# throttle calibration (right)
Move axis 1 to minimum position and push any button.

# brake calibration (wrong, the brake calibration must be on axis 1, for 
example 255 (throttle), 0 (none), -255 (brake))
Move axis 2 to minimum position and push any button.


Regards.

Gdb

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: Update task->on_rq when tasks are moving between runqueues

[Olav Haugan]

Task->on_rq has three states:
0 - Task is not on runqueue (rq)
1 (TASK_ON_RQ_QUEUED) - Task is on rq
2 (TASK_ON_RQ_MIGRATING) - Task is on rq but in the process of being
migrated to another rq

When a task is moving between rqs task->on_rq state should be
TASK_ON_RQ_MIGRATING

Signed-off-by: Olav Haugan 
---
 kernel/sched/core.c | 2 ++
 kernel/sched/deadline.c | 4 
 kernel/sched/rt.c   | 4 
 3 files changed, 10 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 10a8faa..5c7b614 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1309,7 +1309,9 @@ static void __migrate_swap_task(struct task_struct *p, 
int cpu)
dst_rq = cpu_rq(cpu);
 
deactivate_task(src_rq, p, 0);
+   p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, cpu);
+   p->on_rq = TASK_ON_RQ_QUEUED;
activate_task(dst_rq, p, 0);
check_preempt_curr(dst_rq, p, 0);
} else {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc8f010..21297d7 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1547,7 +1547,9 @@ retry:
}
 
deactivate_task(rq, next_task, 0);
+   next_task->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(next_task, later_rq->cpu);
+   next_task->on_rq = TASK_ON_RQ_QUEUED;
activate_task(later_rq, next_task, 0);
ret = 1;
 
@@ -1635,7 +1637,9 @@ static void pull_dl_task(struct rq *this_rq)
resched = true;
 
deactivate_task(src_rq, p, 0);
+   p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, this_cpu);
+   p->on_rq = TASK_ON_RQ_QUEUED;
activate_task(this_rq, p, 0);
dmin = p->dl.deadline;
 
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d2ea593..0735040 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1790,7 +1790,9 @@ retry:
}
 
deactivate_task(rq, next_task, 0);
+   next_task->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(next_task, lowest_rq->cpu);
+   next_task->on_rq = TASK_ON_RQ_QUEUED;
activate_task(lowest_rq, next_task, 0);
ret = 1;
 
@@ -2044,7 +2046,9 @@ static void pull_rt_task(struct rq *this_rq)
resched = true;
 
deactivate_task(src_rq, p, 0);
+   p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, this_cpu);
+   p->on_rq = TASK_ON_RQ_QUEUED;
activate_task(this_rq, p, 0);
/*
 * We continue with the search, just in
-- 
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: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand  wrote:
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

Yep, once in a while people still stumble on obscure subsystems and drivers
not supporting probe deferral. Usually they don't fail with a big bang, so
everything seems fine.

E.g. last week's "of_mdiobus_register_phy() and deferred probe"
(https://lkml.org/lkml/2015/10/22/377).

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 2/3][v2] ACPI: Using correct irq when waiting for events

[kbuild test robot]

Hi Chen,

[auto build test ERROR on pm/linux-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using-correct-irq-when-waiting-for-events/20151025-010210
config: x86_64-randconfig-x015-201543 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from drivers/acpi/osl.c:26:
   drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete':
>> drivers/acpi/osl.c:1183:6: error: implicit declaration of function 
>> 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration]
 if (acpi_sci_irq_valid())
 ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
 if (__builtin_constant_p((cond)) ? !!(cond) :   \
   ^
>> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if'
 if (acpi_sci_irq_valid())
 ^
>> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared (first use in 
>> this function)
  synchronize_hardirq(acpi_sci_irq);
  ^
   drivers/acpi/osl.c:1184:23: note: each undeclared identifier is reported 
only once for each function it appears in
   cc1: some warnings being treated as errors

vim +/acpi_sci_irq_valid +1183 drivers/acpi/osl.c

  1177  void acpi_os_wait_events_complete(void)
  1178  {
  1179  /*
  1180   * Make sure the GPE handler or the fixed event handler is not 
used
  1181   * on another CPU after removal.
  1182   */
> 1183  if (acpi_sci_irq_valid())
> 1184  synchronize_hardirq(acpi_sci_irq);
  1185  flush_workqueue(kacpid_wq);
  1186  flush_workqueue(kacpi_notify_wq);
  1187  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

[Andrew F. Davis]

Using constants for pinctrl allows better readability and removes
redundancy with comments. AM33XX_IOPAD allows us to use part of the
pinctrl physical address as in the TRM instead of an offset.

Signed-off-by: Andrew F. Davis 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index eadbba3..346f529 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -36,32 +36,32 @@
 _pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
-   0x1b0 0x03  /* xdma_event_intr0, OMAP_MUX_MODE3 | 
AM33XX_PIN_OUTPUT */
-   0xa0 0x08   /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa4 0x08   /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa8 0x08   /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xac 0x08   /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb0 0x08   /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb4 0x08   /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb8 0x08   /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xbc 0x08   /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc0 0x08   /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc4 0x08   /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc8 0x08   /* lcd_data10.lcd_data10, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xcc 0x08   /* lcd_data11.lcd_data11, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd0 0x08   /* lcd_data12.lcd_data12, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd4 0x08   /* lcd_data13.lcd_data13, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd8 0x08   /* lcd_data14.lcd_data14, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xdc 0x08   /* lcd_data15.lcd_data15, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xe0 0x00   /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe4 0x00   /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe8 0x00   /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | 
AM33XX_PIN_OUTPUT */
-   0xec 0x00   /* lcd_ac_bias_en.lcd_ac_bias_en, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
+   AM33XX_IOPAD(0x9b0, (PIN_OUTPUT_PULLDOWN | MUX_MODE3))  
/* xdma_event_intr0 */
+   AM33XX_IOPAD(0x8a0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data0.lcd_data0 */
+   AM33XX_IOPAD(0x8a4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data1.lcd_data1 */
+   AM33XX_IOPAD(0x8a8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data2.lcd_data2 */
+   AM33XX_IOPAD(0x8ac, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data3.lcd_data3 */
+   AM33XX_IOPAD(0x8b0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data4.lcd_data4 */
+   AM33XX_IOPAD(0x8b4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data5.lcd_data5 */
+   AM33XX_IOPAD(0x8b8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data6.lcd_data6 */
+   AM33XX_IOPAD(0x8bc, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data7.lcd_data7 */
+   AM33XX_IOPAD(0x8c0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data8.lcd_data8 */
+   AM33XX_IOPAD(0x8c4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data9.lcd_data9 */
+   AM33XX_IOPAD(0x8c8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data10.lcd_data10 */
+   AM33XX_IOPAD(0x8cc, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data11.lcd_data11 */
+   AM33XX_IOPAD(0x8d0, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data12.lcd_data12 */
+   AM33XX_IOPAD(0x8d4, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data13.lcd_data13 */
+   AM33XX_IOPAD(0x8d8, (PIN_OUTPUT | MUX_MODE0))   
/* lcd_data14.lcd_data14 */
+   AM33XX_IOPAD(0x8dc, (PIN_OUTPUT | MUX_MODE0))   
/* 

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

[Chen Yu]

For ACPI compatible system, SCI(ACPI System Control
Interrupt) is used to wake the system up from suspend-to-idle.
Once the CPU is woken up by SCI, the interrupt handler will
firstly check if the 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
returned by acpi_gsi_to_irq as IRQD_WAKEUP_STATE, rather than
marking the acpi_gbl_FADT.sci_interrupt.

Cc:  # 3.18+
Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
---
 drivers/acpi/sleep.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 2f0d4db..3fe1fbe 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 (acpi_sci_irq_valid())
+   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 (acpi_sci_irq_valid())
+   disable_irq_wake(acpi_sci_irq);
acpi_enable_all_runtime_gpes();
 }
 
-- 
1.8.4.2

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

[PATCH 1/3][v2] ACPI: Using correct irq when uninstalling acpi irq handler

[Chen Yu]

Currently when system is trying to uninstall the acpi irq
handler, it uses the acpi_gbl_FADT.sci_interrupt directly.
But acpi irq handler is actually installed by mapped irq
in acpi_os_install_interrupt_handler, so this patch fixes
this problem by using the mapped irq returned from acpi_gsi_to_irq.

Cc:  # 2.6.39
Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
---
 drivers/acpi/osl.c   | 10 +++---
 include/linux/acpi.h |  6 ++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 739a4a6..64df9d4 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)
+acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
 {
-   if (irq != acpi_gbl_FADT.sci_interrupt)
+   if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
+   !acpi_sci_irq_valid())
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;
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 43856d1..1ae6ba0 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -193,6 +193,12 @@ int acpi_ioapic_registered(acpi_handle handle, u32 
gsi_base);
 void acpi_irq_stats_init(void);
 extern u32 acpi_irq_handled;
 extern u32 acpi_irq_not_handled;
+extern unsigned int acpi_sci_irq;
+#define INVALID_ACPI_IRQ   ((unsigned)-1)
+static inline bool acpi_sci_irq_valid(void)
+{
+   return acpi_sci_irq != INVALID_ACPI_IRQ;
+}
 
 extern int sbf_port;
 extern unsigned long acpi_realmode_flags;
-- 
1.8.4.2

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

[PATCH 2/3][v2] ACPI: Using correct irq when waiting for events

[Chen Yu]

When system is waiting for GPE/fixed event handler to finish,
it uses the acpi_gbl_FADT.sci_interrupt directly. However, we
should use mapped irq returned by acpi_gsi_to_irq for synchronize_hardirq.

Cc:  # 3.19+
Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
---
 drivers/acpi/osl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 64df9d4..45243a7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1184,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 (acpi_sci_irq_valid())
+   synchronize_hardirq(acpi_sci_irq);
flush_workqueue(kacpid_wq);
flush_workqueue(kacpi_notify_wq);
 }
-- 
1.8.4.2

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

[PATCH] leds: bcm6328: Handle default-state of LEDs correctly

[Simon Arlott]

The default-state handler assumes that the LED is active low and omits
use of the shift macro causing "keep" to misdetect the state.

Determine the brightness and then use the led set function to apply it.

Update the documentation to indicate that this driver works for the
BCM63168 (which has many active high LEDs) too.

Signed-off-by: Simon Arlott 
---
 .../devicetree/bindings/leds/leds-bcm6328.txt  |  2 +-
 drivers/leds/leds-bcm6328.c| 23 --
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt 
b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
index f9e36ad..d00260d 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
+++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt
@@ -1,6 +1,6 @@
 LEDs connected to Broadcom BCM6328 controller
 
-This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268.
+This controller is present on BCM6318, BCM6328, BCM6362, BCM63168 and BCM63268.
 In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
 However, on some devices there are Serial LEDs (LEDs connected to a 74x164
 controller), which can either be controlled by software (exporting the 74x164
diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c
index 1793727..771c171 100644
--- a/drivers/leds/leds-bcm6328.c
+++ b/drivers/leds/leds-bcm6328.c
@@ -259,7 +259,6 @@ static int bcm6328_led(struct device *dev, struct 
device_node *nc, u32 reg,
   unsigned long *blink_leds, unsigned long *blink_delay)
 {
struct bcm6328_led *led;
-   unsigned long flags;
const char *state;
int rc;
 
@@ -282,13 +281,12 @@ static int bcm6328_led(struct device *dev, struct 
device_node *nc, u32 reg,
NULL);
 
if (!of_property_read_string(nc, "default-state", )) {
-   spin_lock_irqsave(lock, flags);
if (!strcmp(state, "on")) {
led->cdev.brightness = LED_FULL;
-   bcm6328_led_mode(led, BCM6328_LED_MODE_ON);
} else if (!strcmp(state, "keep")) {
void __iomem *mode;
unsigned long val, shift;
+   unsigned long flags;
 
shift = bcm6328_pin2shift(led->pin);
if (shift / 16)
@@ -296,19 +294,24 @@ static int bcm6328_led(struct device *dev, struct 
device_node *nc, u32 reg,
else
mode = mem + BCM6328_REG_MODE_LO;
 
-   val = bcm6328_led_read(mode) >> (shift % 16);
+   spin_lock_irqsave(lock, flags);
+   val = bcm6328_led_read(mode);
+   spin_unlock_irqrestore(lock, flags);
+
+   val >>= BCM6328_LED_SHIFT(shift % 16);
val &= BCM6328_LED_MODE_MASK;
-   if (val == BCM6328_LED_MODE_ON)
+
+   dev_info(dev, "pin %lu = %08lx\n", led->pin, val);
+   if ((led->active_low && val == BCM6328_LED_MODE_ON) ||
+   (!led->active_low && val == BCM6328_LED_MODE_OFF))
led->cdev.brightness = LED_FULL;
-   else {
+   else
led->cdev.brightness = LED_OFF;
-   bcm6328_led_mode(led, BCM6328_LED_MODE_OFF);
-   }
} else {
led->cdev.brightness = LED_OFF;
-   bcm6328_led_mode(led, BCM6328_LED_MODE_OFF);
}
-   spin_unlock_irqrestore(lock, flags);
+
+   bcm6328_led_set(>cdev, led->cdev.brightness);
}
 
led->cdev.brightness_set = bcm6328_led_set;
-- 
2.1.4

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

[PATCH 0/3][v2] Fix incorrect using of acpi irq

[Chen Yu]

This series of patches are trying to convert codes who use
acpi_gbl_FADT.sci_interrupt incorrectly to use the right irq
mapped by acpi_gsi_to_irq.

Chen Yu (3):
  ACPI: Using correct irq when uninstalling acpi irq handler
  ACPI: Using correct irq when waiting for events
  ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle

 drivers/acpi/osl.c   | 14 +-
 drivers/acpi/sleep.c |  6 --
 include/linux/acpi.h |  6 ++
 3 files changed, 19 insertions(+), 7 deletions(-)

-- 
1.8.4.2

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

Re: [PATCH] gpio: add tps65218 gpio driver

[kbuild test robot]

Hi Nicolas,

[auto build test ERROR on gpio/for-next -- if it's inappropriate base, please 
suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Nicolas-Saenz-Julienne/gpio-add-tps65218-gpio-driver/20151024-003657
config: x86_64-randconfig-x002-201543 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpio/gpio-tps65218.c: In function 'tps65218_gpio_probe':
>> drivers/gpio/gpio-tps65218.c:175:26: error: 'struct gpio_chip' has no member 
>> named 'of_node'
 tps65218_gpio->gpio_chip.of_node = pdev->dev.of_node;
 ^

vim +175 drivers/gpio/gpio-tps65218.c

   169  if (!tps65218_gpio)
   170  return -ENOMEM;
   171  
   172  tps65218_gpio->tps65218 = tps65218;
   173  tps65218_gpio->gpio_chip = template_chip;
   174  tps65218_gpio->gpio_chip.dev = >dev;
 > 175  tps65218_gpio->gpio_chip.of_node = pdev->dev.of_node;
   176  
   177  ret = gpiochip_add(_gpio->gpio_chip);
   178  if (ret < 0) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Dan Williams]

On Tue, Oct 6, 2015 at 3:06 AM, Grant Likely  wrote:
> [Resending because I messed up the first one]
>
> The elections for five of the ten members of the Linux Foundation
> Technical Advisory Board (TAB) are held every year[1]. This year the
> election will be at the 2015 Kernel Summit in Seoul, South Korea
> (probably on the Monday, 26 October) and will be open to all attendees
> of both Kernel Summit and Korea Linux Forum.
>
> Anyone is eligible to stand for election, simply send your nomination to:
>
> tech-board-disc...@lists.linux-foundation.org
>
> We currently have 3 nominees for five places:
> Thomas Gleixner
> Greg Kroah-Hartman
> Stephen Hemminger

I'd like to stand for a TAB seat, please add me to the candidate list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/2] acpi: add acpi_preset_companion() stub

[Wolfram Sang]

On Fri, Oct 23, 2015 at 12:27:06PM -0700, Dustin Byford wrote:
> Add a stub for acpi_preset_companion().  Fixes build failures when
> acpi_preset_companion() is used and CONFIG_ACPI is not set.
> 
> Acked-by: Mika Westerberg 
> Signed-off-by: Dustin Byford 

Waiting for Rafael's ack here...

> ---
>  include/linux/acpi.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 43856d1..43b55e7 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -477,6 +477,11 @@ static inline bool has_acpi_companion(struct device *dev)
>   return false;
>  }
>  
> +static inline void acpi_preset_companion(struct device *dev,
> +  struct acpi_device *parent, u64 addr)
> +{
> +}
> +
>  static inline const char *acpi_dev_name(struct acpi_device *adev)
>  {
>   return NULL;
> -- 
> 2.1.4
> 


signature.asc
Description: Digital signature

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Rob Herring]

On 10/23/2015 01:28 PM, Douglas Anderson wrote:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup.  It appears that the "port reset" bit that's in the USB
> phy (located in the rk3288 GRF) fixes things up and appears safe to do.
> 
> This series of patches exports the "port reset" from the PHY and then
> hooks it up to dwc2 through a quirk.
> 
> I've tested this series atop a bit of a conglomeration of Heiko's github
> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
> usb-next merged in.
> 
> These patches currently conflict with patches that I posted previously
> to enable USB wakeup from S3, specifically:
> * https://patchwork.kernel.org/patch/6727081/
> * https://patchwork.kernel.org/patch/6727121/
> ...those patches no longer apply anyway, so presumably they need to be
> reposted and I can do so later atop these patches.
> 
> 
> Douglas Anderson (4):
>   phy: rockchip-usb: Support the PHY's "port reset"
>   usb: dwc2: optionally assert phy "port reset" when waking up
>   ARM: dts: rockchip: Enable the USB phys as reset providers on rk3288
>   ARM: dts: rockchip: Point rk3288 dwc2 usb at phy port reset
> 
>  .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  6 ++
>  Documentation/devicetree/bindings/usb/dwc2.txt |  7 ++
>  arch/arm/boot/dts/rk3288.dtsi  |  8 +++
>  drivers/phy/phy-rockchip-usb.c | 74 
> ++
>  drivers/usb/dwc2/core.h|  5 ++
>  drivers/usb/dwc2/core_intr.c   |  7 ++
>  drivers/usb/dwc2/platform.c| 13 
>  7 files changed, 120 insertions(+)

A DT reset controller seems like a bit of an overkill here. I think this
would be much more simple if we just add a phy reset hook to the phy
subsystem.

Rob

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

[Lan, Tianyu]

On 10/22/2015 5:14 AM, Alexander Duyck wrote:

Where is i being initialized?  It was here but you removed it.  Are you
using i without initializing it?


Sorry, the initialization was put into patch 10 by mistake. "i" is
assigned with "tx_ring->next_to_clean".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/12] IXGBEVF: Rework code of finding the end transmit desc of package

[Lan, Tianyu]

On 10/22/2015 8:58 PM, Michael S. Tsirkin wrote:

Do you really need to play the shifting games?
Can't you just reset everything and re-initialize the rings?
It's slower but way less intrusive.
Also removes the need to track writes into rings.


Shift ring is to avoid losing those packets in the ring.
This may cause some race condition and so I introduced a
lock to prevent such cases in the latter patch.
Yes, reset everything after migration can make thing easy.
But just like you said it would affect performance and loss
more packets. I can do a test later to get data about these
two way.

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

RE: [PATCH 1/3] ACPI: Using correct irq when uninstalling acpi irq handler

[Chen, Yu C]

Hi, Rafael

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Saturday, October 24, 2015 9:32 PM
> To: Chen, Yu C
> Cc: l...@kernel.org; Zhang, Rui; Zheng, Lv; linux-a...@vger.kernel.org;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Subject: Re: [PATCH 1/3] ACPI: Using correct irq when uninstalling acpi irq
> handler
> 
> On Thursday, October 22, 2015 08:03:08 PM Chen Yu wrote:
> > Currently when system is trying to uninstall the acpi irq handler, it
> > uses the acpi_gbl_FADT.sci_interrupt directly.
> > But acpi irq handler is actually installed by mapped irq in
> > acpi_os_install_interrupt_handler, so this patch fixes this problem by
> > using the mapped irq returned from acpi_gsi_to_irq.
> >
> > Cc:  # 2.6.39+
> > Acked-by: Lv Zheng 
> > Signed-off-by: Chen Yu 
> > ---
> >  drivers/acpi/osl.c   | 10 +++---
> >  include/linux/acpi.h |  3 +++
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index
> > 739a4a6..2e9eccf 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)
> > +acpi_status acpi_os_remove_interrupt_handler(u32 gsi,
> > +acpi_osd_handler handler)
> >  {
> > -   if (irq != acpi_gbl_FADT.sci_interrupt)
> > +   if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
> > +   IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> 
> The white space doesn't follow the kernel coding style, should be something
> like
> 
>   if ((gsi != acpi_gbl_FADT.sci_interrupt) ||
>   IS_INVALID_ACPI_IRQ(acpi_sci_irq))
> 
> (spaces instead of the second tab).
> 
Ah, got it, thanks.

> Another minor nit is that this probably is the only place you check the
> IS_INVALID_ACPI_IRQ(acpi_sci_irq) thing without logical negation and you
> only pass acpi_sci_irq to IS_INVALID_ACPI_IRQ() AFAICS.
> 
> It would be more straightforward to define something like acpi_sci_irq_valid()
> instead (see below) IMO.
> 
> > 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;
> >  }
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h index
> > 43856d1..bad159c 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -193,6 +193,9 @@ int acpi_ioapic_registered(acpi_handle handle, u32
> > gsi_base);  void acpi_irq_stats_init(void);  extern u32
> > acpi_irq_handled;  extern u32 acpi_irq_not_handled;
> > +extern unsigned int acpi_sci_irq;
> > +#define INVALID_ACPI_IRQ ((unsigned)-1)
> 
> #define INVALID_ACPI_IRQ  ((unsigned int)-1)
> 
> > +#define IS_INVALID_ACPI_IRQ(x) unlikely((x) == INVALID_ACPI_IRQ)
> 
> Maybe something like:
> 
>   static inline bool acpi_sci_irq_valid(void)
>   {
>   return acpi_sci_irq != INVALID_ACPI_IRQ;
>   }
> 
OK, will send out a version 2 with both another two patches modified.

Best Regards,
Yu

Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[John W. Linville]

Good write-up!  We should archive this for reference in future years!

John

On Sat, Oct 24, 2015 at 11:28:19AM +0100, Grant Likely wrote:
> [Including Rafael who also asked about what being a TAB member means]
> 
> On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart  wrote:
> > On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> > Is there a good description of what is expected of a TAB member? How much 
> > time
> > is involved? What makes a great TAB member?
> >
> > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
> >
> > I've read the charter and scanned some of the minutes, but I'd still like to
> > hear from some of the "incumbants". Specifically, what makes you successful 
> > as a
> > member of the TAB?
> 
> I've been asked several versions of the same question, and also the
> annual "what does the TAB actually do?" question, so I'm going to try
> and answer them all in one email:
> 
> As the name implies, the primary job of the TAB is to advise the Linux
> Foundation board of directors on technical, social and political
> issues regarding Linux and Open Source. Our job is to represent the
> views of Linux developers and to foster constructive communication
> between the Linux Foundation leadership and our community.
> 
> A natural by-product of this is that the TAB also acts in the
> background to identify and resolve issues for the Linux community
> before they become a problem. The TAB tends to be composed of well
> respected individuals with good connections throughout our community,
> and so we're in a good place to recognize who to talk to when an issue
> is raised.
> 
> Finally, there are a few projects that the TAB is directly responsible
> for. We make sure there is a planning committee for the Linux Plumbers
> conference every year. We run a 'buddy' program to help new Linux
> Foundation member companies learn how to be fine upstanding Linux
> citizens. We are the response team for any issues of harassment or
> abuse within the kernel community. In past years we coordinated the
> response to UEFI Secure Boot to ensure that Linux would not be locked
> out of the consumer PC market, and been active in helping member
> companies understand and be comfortable with the licencing obligations
> associated with Linux.
> 
> A good TAB member is well respected by the community, is a ready
> listener, is comfortable discussing both technical and social issues,
> and has a good understanding of how the Linux community works. Since
> the TAB deals with a wide range of issues, the ideal TAB candidate
> should be prepared to consider issues outside of their own area of
> expertise. Sometime the most important characteristic of a TAB member
> is recognizing when an issue is beyond their depth and go looking for
> the right person to consult.
> 
> Time commitment wise, The TAB meets once a month for a conference
> call, plus any additional time required to deal with TAB business.
> Once a year (6 months after the TAB general election) the TAB elects
> one member to serve as the chair, and the chair of the TAB is proposed
> to the Linux Foundation to serve as a Linux Foundation Director which
> has additional time requirements.
> 
> One last point, some issues addressed by the TAB are highly sensitive
> and any member can request a topic to be kept strictly confidential.
> We do this to protect the working relationship we have with industry
> bodies, and to protect the companies and individuals involved. Any
> prospective TAB member must be comfortable abiding by our
> confidentiality rules.
> 
> I hope this answers your questions.
> 
> g.
> ___
> Tech-board mailing list
> tech-bo...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/tech-board
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:perf/core] perf tools: Improve call graph documents and help messages

[Namhyung Kim]

Hi Ingo,

On Fri, Oct 23, 2015 at 6:03 PM, Ingo Molnar  wrote:
>
> * tip-bot for Namhyung Kim  wrote:
>
>> Commit-ID:  76a26549eb367f683fbb394b7246bef5dc665f8c
>> Gitweb: 
>> http://git.kernel.org/tip/76a26549eb367f683fbb394b7246bef5dc665f8c
>> Author: Namhyung Kim 
>> AuthorDate: Thu, 22 Oct 2015 23:28:32 +0900
>> Committer:  Arnaldo Carvalho de Melo 
>> CommitDate: Thu, 22 Oct 2015 16:23:19 -0300
>>
>> perf tools: Improve call graph documents and help messages
>>
>> The --call-graph option is complex so we should provide better guide for
>> users.  Also change help message to be consistent with config option
>> names.  Now perf top will show help like below:
>>
>>   $ perf top --call-graph
>> Error: option `call-graph' requires a value
>>
>>Usage: perf top []
>>
>>   --call-graph 
>> 
>>setup and enables call-graph (stack chain/backtrace):
>>
>>   record_mode:call graph recording mode (fp|dwarf|lbr)
>>   record_size:if record_mode is 'dwarf', max size of stack 
>> recording ()
>>   default: 8192 (bytes)
>>   print_type: call graph printing style 
>> (graph|flat|fractal|none)
>>   threshold:  minimum call graph inclusion threshold 
>> ()
>>   print_limit:maximum number of call graph entry ()
>>   order:  call graph order (caller|callee)
>>   sort_key:   call graph sort key (function|address)
>>   branch: include last branch info to call graph (branch)
>
> Btw., how is the last line to be interpreted? Is the 'branch' value 0/1? If 
> yes
> then the text should probably say so? Or does the string 'branch' have to be 
> used?

Yep, the string 'branch' should be used.

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/

[PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade

[Michele Baldessari]

The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
to have the two distinct joysticks working.

Before the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
jstest: No such file or directory

After the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...

Signed-off-by: Michele Baldessari 
---
 drivers/hid/usbhid/hid-quirks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1dff8f0015ba..f69049314a2c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -150,6 +150,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES, 
HID_QUIRK_MULTI_INPUT },
+   { USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE, 
HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },
 
{ 0, 0 }
 };
-- 
2.5.0

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

[PATCH 3/4] perf tools: Setup pager when printing usage and help

[Namhyung Kim]

It's annoying to see error or help message when command has many options
like in perf record, report or top.  So setup pager when print parser
error or help message - it should be OK since no UI is enabled at the
parsing time.  The usage_with_options() already disables it by calling
exit_browser() anyway.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/parse-options.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index b8d98229a8af..d98eb26d 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -7,6 +7,8 @@
 #define OPT_SHORT 1
 #define OPT_UNSET 2
 
+static struct strbuf error_buf = STRBUF_INIT;
+
 static int opterror(const struct option *opt, const char *reason, int flags)
 {
if (flags & OPT_SHORT)
@@ -540,9 +542,11 @@ int parse_options_subcommand(int argc, const char **argv, 
const struct option *o
exit(130);
default: /* PARSE_OPT_UNKNOWN */
if (ctx.argv[0][1] == '-') {
-   error("unknown option `%s'", ctx.argv[0] + 2);
+   strbuf_addf(_buf, "unknown option `%s'",
+   ctx.argv[0] + 2);
} else {
-   error("unknown switch `%c'", *ctx.opt);
+   strbuf_addf(_buf, "unknown switch `%c'",
+   *ctx.opt);
}
usage_with_options(usagestr, options);
}
@@ -711,6 +715,13 @@ int usage_with_options_internal(const char * const 
*usagestr,
if (!usagestr)
return PARSE_OPT_HELP;
 
+   setup_pager();
+
+   if (strbuf_avail(_buf)) {
+   fprintf(stderr, "  Error: %s\n", error_buf.buf);
+   strbuf_release(_buf);
+   }
+
fprintf(stderr, "\n Usage: %s\n", *usagestr++);
while (*usagestr && **usagestr)
fprintf(stderr, "or: %s\n", *usagestr++);
-- 
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/

[PATCH 4/4] perf tools: Introduce usage_with_options_msg()

[Namhyung Kim]

Now usage_with_options() setup a pager before printing message so normal
printf() or pr_err() will not be shown.  The usage_with_options_msg()
can be used to print some help message before usage strings.

Cc: Masami Hiramatsu 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-evlist.c |  4 ++--
 tools/perf/builtin-probe.c  | 20 
 tools/perf/builtin-record.c | 11 ++-
 tools/perf/builtin-sched.c  |  4 ++--
 tools/perf/builtin-script.c |  8 
 tools/perf/util/parse-options.c | 15 +++
 tools/perf/util/parse-options.h |  4 
 tools/perf/util/strbuf.c| 22 +++---
 tools/perf/util/strbuf.h|  2 ++
 9 files changed, 62 insertions(+), 28 deletions(-)

diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
index 695ec5a50cf2..f4d62510acbb 100644
--- a/tools/perf/builtin-evlist.c
+++ b/tools/perf/builtin-evlist.c
@@ -61,8 +61,8 @@ int cmd_evlist(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(evlist_usage, options);
 
if (details.event_group && (details.verbose || details.freq)) {
-   pr_err("--group option is not compatible with other options\n");
-   usage_with_options(evlist_usage, options);
+   usage_with_options_msg(evlist_usage, options,
+   "--group option is not compatible with other 
options\n");
}
 
return __cmd_evlist(input_name, );
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 530c3a28a58c..132afc97676c 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -528,12 +528,12 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
 PARSE_OPT_STOP_AT_NON_OPTION);
if (argc > 0) {
if (strcmp(argv[0], "-") == 0) {
-   pr_warning("  Error: '-' is not supported.\n");
-   usage_with_options(probe_usage, options);
+   usage_with_options_msg(probe_usage, options,
+   "'-' is not supported.\n");
}
if (params.command && params.command != 'a') {
-   pr_warning("  Error: another command except --add is 
set.\n");
-   usage_with_options(probe_usage, options);
+   usage_with_options_msg(probe_usage, options,
+   "another command except --add is set.\n");
}
ret = parse_probe_event_argv(argc, argv);
if (ret < 0) {
@@ -562,8 +562,10 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
switch (params.command) {
case 'l':
if (params.uprobes) {
-   pr_warning("  Error: Don't use --list with --exec.\n");
-   usage_with_options(probe_usage, options);
+   pr_err("  Error: Don't use --list with --exec.\n");
+   parse_options_usage(probe_usage, options, "l", true);
+   parse_options_usage(NULL, options, "x", true);
+   return -EINVAL;
}
ret = show_perf_probe_events(params.filter);
if (ret < 0)
@@ -603,8 +605,10 @@ __cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
case 'a':
/* Ensure the last given target is used */
if (params.target && !params.target_used) {
-   pr_warning("  Error: -x/-m must follow the probe 
definitions.\n");
-   usage_with_options(probe_usage, options);
+   pr_err("  Error: -x/-m must follow the probe 
definitions.\n");
+   parse_options_usage(probe_usage, options, "m", true);
+   parse_options_usage(NULL, options, "x", true);
+   return -EINVAL;
}
 
ret = perf_add_probe_events(params.events, params.nevents);
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2740d7a82ae8..de02267c73d8 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1135,14 +1135,15 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(record_usage, record_options);
 
if (nr_cgroups && !rec->opts.target.system_wide) {
-   ui__error("cgroup monitoring only available in"
- " system-wide mode\n");
-   usage_with_options(record_usage, record_options);
+   usage_with_options_msg(record_usage, record_options,
+   "cgroup monitoring only available in system-wide mode");
+
}
if (rec->opts.record_switch_events &&
!perf_can_record_switch_events()) {
-   

[PATCH 1/4] perf tools: Improve ambiguous option help message

[Namhyung Kim]

Currently if an option name is ambiguous it only prints first two
matched option names but no help.  It'd be better it could show all
possible names and help messages too.

Before:
  $ perf report --show
Error: Ambiguous option: show (could be --show-total-period or
--show-ref-call-graph)
   Usage: perf report []

After:
  $ perf report --show
Error: Ambiguous option: show (could be --show-total-period or
--show-ref-call-graph)
   Usage: perf report []

  -n, --show-nr-samples
  Show a column with the number of samples
  --showcpuutilization
  Show sample percentage for different cpu modes
  -I, --show-info Display extended information about perf.data file
  --show-total-period
  Show a column with the sum of periods
  --show-ref-call-graph
  Show callgraph from reference event

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/parse-options.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 22c2806bda98..b8d98229a8af 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -770,24 +770,23 @@ int parse_options_usage(const char * const *usagestr,
 opt:
for (  ; opts->type != OPTION_END; opts++) {
if (short_opt) {
-   if (opts->short_name == *optstr)
+   if (opts->short_name == *optstr) {
+   print_option_help(opts, 0);
break;
+   }
continue;
}
 
if (opts->long_name == NULL)
continue;
 
-   if (!prefixcmp(optstr, opts->long_name))
-   break;
-   if (!prefixcmp(optstr, "no-") &&
-   !prefixcmp(optstr + 3, opts->long_name))
-   break;
+   if (!prefixcmp(opts->long_name, optstr))
+   print_option_help(opts, 0);
+   if (!prefixcmp("no-", optstr) &&
+   !prefixcmp(opts->long_name, optstr + 3))
+   print_option_help(opts, 0);
}
 
-   if (opts->type != OPTION_END)
-   print_option_help(opts, 0);
-
return PARSE_OPT_HELP;
 }
 
-- 
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/

[PATCH 2/4] perf report: Rename to --show-cpu-utilization

[Namhyung Kim]

So that it can be more consistent with other --show-* options.  The old
name (--showcpuutilization) is provided only for compatibility.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-report.txt | 2 +-
 tools/perf/builtin-report.c  | 4 +++-
 tools/perf/util/parse-options.h  | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index ab1fd64e3627..5ce8da1e1256 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -29,7 +29,7 @@ OPTIONS
 --show-nr-samples::
Show the number of samples for each symbol
 
---showcpuutilization::
+--show-cpu-utilization::
 Show sample percentage for different cpu modes.
 
 -T::
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 50dd4d3d8667..2853ad2bd435 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -699,8 +699,10 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
   " Please refer the man page for the complete list."),
OPT_STRING('F', "fields", _order, "key[,keys...]",
   "output field(s): overhead, period, sample plus all of sort 
keys"),
-   OPT_BOOLEAN(0, "showcpuutilization", _conf.show_cpu_utilization,
+   OPT_BOOLEAN(0, "show-cpu-utilization", 
_conf.show_cpu_utilization,
"Show sample percentage for different cpu modes"),
+   OPT_BOOLEAN_FLAG(0, "showcpuutilization", 
_conf.show_cpu_utilization,
+   "Show sample percentage for different cpu modes", 
PARSE_OPT_HIDDEN),
OPT_STRING('p', "parent", _pattern, "regex",
   "regex filter to identify parent, see: '--sort parent'"),
OPT_BOOLEAN('x', "exclude-other", _conf.exclude_other,
diff --git a/tools/perf/util/parse-options.h b/tools/perf/util/parse-options.h
index 367d8b816cc7..182c86099330 100644
--- a/tools/perf/util/parse-options.h
+++ b/tools/perf/util/parse-options.h
@@ -111,6 +111,7 @@ struct option {
 #define OPT_GROUP(h){ .type = OPTION_GROUP, .help = (h) }
 #define OPT_BIT(s, l, v, h, b)  { .type = OPTION_BIT, .short_name = (s), 
.long_name = (l), .value = check_vtype(v, int *), .help = (h), .defval = (b) }
 #define OPT_BOOLEAN(s, l, v, h) { .type = OPTION_BOOLEAN, .short_name = 
(s), .long_name = (l), .value = check_vtype(v, bool *), .help = (h) }
+#define OPT_BOOLEAN_FLAG(s, l, v, h, f) { .type = OPTION_BOOLEAN, 
.short_name = (s), .long_name = (l), .value = check_vtype(v, bool *), .help = 
(h), .flags = (f) }
 #define OPT_BOOLEAN_SET(s, l, v, os, h) \
{ .type = OPTION_BOOLEAN, .short_name = (s), .long_name = (l), \
.value = check_vtype(v, bool *), .help = (h), \
-- 
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/

Re: [PATCH] mtd: spi-nor: fsl-quadspi: add big-endian support

[Fabio Estevam]

On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao  wrote:

>  /*
> + * R/W functions for big- or little-endian registers:
> + * The qSPI controller's endian is independent of the CPU core's endian.
> + * So far, although the CPU core is little-endian but the qSPI have two
> + * versions for big-endian and little-endian.
> + */
> +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem *addr)
> +{
> +   if (q->big_endian)
> +   iowrite32be(val, addr);
> +   else
> +   iowrite32(val, addr);
> +}

I suggest you to implement regmap support for this driver instead.

Take a look at drivers/watchdog/imx2_wdt.c for a reference.

Then you only need to pass 'big-endian' as a property for the qspi in
the .dtsi file and regmap core will take care of endianness.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

Florian Fainelli  writes:

 +static void nb8800_set_rx_mode(struct net_device *dev)
 +{
 +  struct nb8800_priv *priv = netdev_priv(dev);
 +  struct netdev_hw_addr *ha;
 +  int af_en;
 +
 +  if ((dev->flags & (IFF_PROMISC | IFF_ALLMULTI)) ||
 +  netdev_mc_count(dev) > 64)
>>>
>>> 64, that's pretty generous for a perfect match filter, nice.
>> 
>> That's bogus; I forgot to delete it.  The hardware uses a 64-entry hash
>> table, and whoever wrote the old driver apparently didn't understand how
>> it works.
>
> Might be best to put the interface in promiscuous mode until you have
> proper multicast support. Since this is for a Set-Top box chip, having
> proper multicast support still seems like something highly desirable.

The code below should work correctly with any number of multicast
addresses.

 +  phydev = phy_find_first(bus);
 +  if (!phydev || phy_read(phydev, MII_BMSR) <= 0) {
>>>
>>> What is this additional MII_MBSR read used for?
>> 
>> On one of my boards, phylib misdetects a phy on the second ethernet port
>> even though there is none.  Perhaps I should revisit that problem and
>> look for a better solution.
>
> I think that would be best, if you are currently using the Generic PHY
> driver, consider writing a specific driver which would take care of
> quirky behavior.

The problem is that there is no PHY, yet for some reason reading the ID
registers appears to succeed.

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

Re: [RFC Patch 05/12] IXGBE: Add new sysfs interface of "notify_vf"

[Lan, Tianyu]

On 10/22/2015 4:52 AM, Alexander Duyck wrote:

Also have you even considered the MSI-X configuration on the VF?  I
haven't seen anything anywhere that would have migrated the VF's MSI-X
configuration from BAR 3 on one system to the new system.


MSI-X migration is done by Hypervisor(Qemu).
Following link is my Qemu patch to do that.
http://marc.info/?l=kvm=144544706530484=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion

[Robert Jarzmik]

Robert Jarzmik  writes:

> This patch attempts to enhance the case of a transfer submitted multiple
> times, and where the cost of creating the descriptors chain is not
> negligible.
>
> This happens with big video buffers (several megabytes, ie. several
> thousands of linked descriptors in one scatter-gather list). In these
> cases, a video driver would want to do :
>  - tx = dmaengine_prep_slave_sg()
>  - dma_engine_submit(tx);
>  - dma_async_issue_pending()
>  - wait for video completion
>  - read video data (or not, skipping a frame is also possible)
>  - dma_engine_submit(tx)
>=> here, the descriptors chain recalculation will take time
>=> the dma coherent allocation over and over might create holes in
>   the dma pool, which is counter-productive.
>  - dma_async_issue_pending()
>  - etc ...
>
> In order to cope with this case, virt-dma is modified to prevent freeing
> the descriptors upon completion if DMA_CTRL_REUSE flag is set in the
> transfer.
>
> This patch is a respin of the former DMA_CTRL_ACK approach, which was
> reverted due to a regression in audio drivers.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: added doxygen commit to vchan_tx_desc_free

Hi Vinod,

Is this serie good for you or do you have remaining comments to be addressed ?

Cheers.

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

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

[Robert Jarzmik]

Robert Jarzmik  writes:

> Fix the error path where the video buffer wasn't allocated nor
> mapped. In this case, in the driver free path don't try to unmap memory
> which was not mapped in the first place.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v3: take into account the 2 paths possibilities to free_buffer()
Okay Guennadi, it's been enough time.
Could you you have another look at this serie please ?

Cheers.

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

[PATCH] printk: prevent userland from spoofing kernel messages

[Mathias Krause]

The following statement of ABI/testing/dev-kmsg is not quite right:

   It is not possible to inject messages from userspace with the
   facility number LOG_KERN (0), to make sure that the origin of the
   messages can always be reliably determined.

Userland actually can inject messages with a facility of 0 by abusing
the fact that the facility is stored in a u8 data type. By using a
facility which is a multiple of 256 the assignment of msg->facility in
log_store() implicitly truncates it to 0, i.e. LOG_KERN, allowing users
of /dev/kmsg to spoof kernel messages as shown below:

The following call...
   # printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
...leads to the following log entry (dmesg -x | tail -n 1):
   user  :emerg : [   66.137758] Kernel panic - not syncing: beer empty

However, this call...
   # printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
...leads to the slightly different log entry (note the kernel facility):
   kern  :emerg : [   74.177343] Kernel panic - not syncing: beer empty

Fix that by limiting the user provided facility to 8 bit right from the
beginning and catch the truncation early.

Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause 
Cc: Greg Kroah-Hartman 
Cc: Petr Mladek 
Cc: Alex Elder 
Cc: Joe Perches 
Cc: Kay Sievers 
---
Might be worth to apply to stable, too. Don't know. Prior to commit
7ff9554bb578 there was no facility so user injected messages had an implicit
facility for LOG_KERN. But commit 7ff9554bb578 explicitly mentions this
feature, so, dunno :/

 kernel/printk/printk.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 8f0324ef72ab..9982616ce712 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -269,6 +269,9 @@ static u32 clear_idx;
 #define PREFIX_MAX 32
 #define LOG_LINE_MAX   (1024 - PREFIX_MAX)
 
+#define LOG_LEVEL(v)   ((v) & 0x07)
+#define LOG_FACILITY(v)((v) >> 3 & 0xff)
+
 /* record buffer */
 #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
 #define LOG_ALIGN 4
@@ -611,7 +614,6 @@ struct devkmsg_user {
 static ssize_t devkmsg_write(struct kiocb *iocb, struct iov_iter *from)
 {
char *buf, *line;
-   int i;
int level = default_message_loglevel;
int facility = 1;   /* LOG_USER */
size_t len = iov_iter_count(from);
@@ -641,12 +643,13 @@ static ssize_t devkmsg_write(struct kiocb *iocb, struct 
iov_iter *from)
line = buf;
if (line[0] == '<') {
char *endp = NULL;
+   unsigned int u;
 
-   i = simple_strtoul(line+1, , 10);
+   u = simple_strtoul(line + 1, , 10);
if (endp && endp[0] == '>') {
-   level = i & 7;
-   if (i >> 3)
-   facility = i >> 3;
+   level = LOG_LEVEL(u);
+   if (LOG_FACILITY(u) != 0)
+   facility = LOG_FACILITY(u);
endp++;
len -= endp - line;
line = endp;
-- 
1.7.10.4

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

[net-next:master 1610/1613] net/tipc/link.c:176:5: sparse: symbol 'tipc_link_is_active' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
master
head:   687f079addba1ac7f97ce97080c2291bbe8c8dce
commit: c72fa872a23f03b2b9c17e88f3b0a8070924e5f1 [1610/1613] tipc: eliminate 
link's reference to owner node
reproduce:
# apt-get install sparse
git checkout c72fa872a23f03b2b9c17e88f3b0a8070924e5f1
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   net/tipc/link.c:166:6: sparse: symbol 'link_is_bc_sndlink' was not declared. 
Should it be static?
   net/tipc/link.c:171:6: sparse: symbol 'link_is_bc_rcvlink' was not declared. 
Should it be static?
>> net/tipc/link.c:176:5: sparse: symbol 'tipc_link_is_active' was not 
>> declared. Should it be static?
   net/tipc/link.c:648:6: sparse: symbol 'link_prepare_wakeup' was not 
declared. Should it be static?
   net/tipc/link.c:904:6: sparse: symbol 'tipc_link_advance_backlog' was not 
declared. Should it be static?
   net/tipc/link.c:980:5: sparse: symbol 'tipc_link_retrans' was not declared. 
Should it be static?
   net/tipc/link.c:1573:6: sparse: symbol 'tipc_link_build_bc_init_msg' was not 
declared. Should it be static?
   include/linux/rcupdate.h:305:9: sparse: context imbalance in 
'tipc_link_find_owner' - wrong count at exit
   net/tipc/link.c:1833:5: sparse: context imbalance in 'tipc_nl_link_set' - 
different lock contexts for basic block
   net/tipc/link.c:2070:5: sparse: context imbalance in 'tipc_nl_link_dump' - 
different lock contexts for basic block
   net/tipc/link.c:2141:5: sparse: context imbalance in 'tipc_nl_link_get' - 
different lock contexts for basic block
   net/tipc/link.c:2193:5: sparse: context imbalance in 
'tipc_nl_link_reset_stats' - different lock contexts for basic block

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process

[Rafael J. Wysocki]

On Saturday, October 24, 2015 11:28:19 AM Grant Likely wrote:
> [Including Rafael who also asked about what being a TAB member means]
> 
> On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart  wrote:
> > On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote:
> > Is there a good description of what is expected of a TAB member? How much 
> > time
> > is involved? What makes a great TAB member?
> >
> > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab
> >
> > I've read the charter and scanned some of the minutes, but I'd still like to
> > hear from some of the "incumbants". Specifically, what makes you successful 
> > as a
> > member of the TAB?
> 
> I've been asked several versions of the same question, and also the
> annual "what does the TAB actually do?" question, so I'm going to try
> and answer them all in one email:
> 
> As the name implies, the primary job of the TAB is to advise the Linux
> Foundation board of directors on technical, social and political
> issues regarding Linux and Open Source. Our job is to represent the
> views of Linux developers and to foster constructive communication
> between the Linux Foundation leadership and our community.
> 
> A natural by-product of this is that the TAB also acts in the
> background to identify and resolve issues for the Linux community
> before they become a problem. The TAB tends to be composed of well
> respected individuals with good connections throughout our community,
> and so we're in a good place to recognize who to talk to when an issue
> is raised.
> 
> Finally, there are a few projects that the TAB is directly responsible
> for. We make sure there is a planning committee for the Linux Plumbers
> conference every year. We run a 'buddy' program to help new Linux
> Foundation member companies learn how to be fine upstanding Linux
> citizens. We are the response team for any issues of harassment or
> abuse within the kernel community. In past years we coordinated the
> response to UEFI Secure Boot to ensure that Linux would not be locked
> out of the consumer PC market, and been active in helping member
> companies understand and be comfortable with the licencing obligations
> associated with Linux.
> 
> A good TAB member is well respected by the community, is a ready
> listener, is comfortable discussing both technical and social issues,
> and has a good understanding of how the Linux community works. Since
> the TAB deals with a wide range of issues, the ideal TAB candidate
> should be prepared to consider issues outside of their own area of
> expertise. Sometime the most important characteristic of a TAB member
> is recognizing when an issue is beyond their depth and go looking for
> the right person to consult.
> 
> Time commitment wise, The TAB meets once a month for a conference
> call, plus any additional time required to deal with TAB business.
> Once a year (6 months after the TAB general election) the TAB elects
> one member to serve as the chair, and the chair of the TAB is proposed
> to the Linux Foundation to serve as a Linux Foundation Director which
> has additional time requirements.
> 
> One last point, some issues addressed by the TAB are highly sensitive
> and any member can request a topic to be kept strictly confidential.
> We do this to protect the working relationship we have with industry
> bodies, and to protect the companies and individuals involved. Any
> prospective TAB member must be comfortable abiding by our
> confidentiality rules.
> 
> I hope this answers your questions.

It certainly does answer mine.

Thanks a lot,
Rafael

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

Re: [PATCH RFC] fsnotify: destroy marks with call_srcu instead of dedicated thread

[Jan Kara]

On Fri 23-10-15 15:06:59, Jeff Layton wrote:
> At the time that this code was originally written, call_srcu didn't
> exist, so this thread was required to ensure that we waited for that
> SRCU grace period to settle before finally freeing the object.
> 
> It does exist now however and we can much more efficiently use call_srcu
> to handle this. That also allows us to potentially use srcu_barrier
> to ensure that they are all of the callbacks have run before proceeding.
> In order to conserve space, we union the rcu_head with the g_list.
> 
> This will be necessary for nfsd which will allocate marks from a
> dedicated slabcache. We have to be able to ensure that all of the
> objects are destroyed before destroying the cache. That's fairly
> difficult to ensure with dedicated thread doing the destruction.

The patch looks good. Just one nit below:

> diff --git a/include/linux/fsnotify_backend.h 
> b/include/linux/fsnotify_backend.h
> index 533c4408529a..6b7e89f45aa4 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -220,7 +220,10 @@ struct fsnotify_mark {
>   /* List of marks by group->i_fsnotify_marks. Also reused for queueing
>* mark into destroy_list when it's waiting for the end of SRCU period
>* before it can be freed. [group->mark_mutex] */

Please update this comment to not speak about destroy_list. After that feel
free to add:

Reviewed-by: Jan Kara 

Honza

> - struct list_head g_list;
> + union {
> + struct list_head g_list;
> + struct rcu_head g_rcu;
> + };
>   /* Protects inode / mnt pointers, flags, masks */
>   spinlock_t lock;
>   /* List of marks for inode / vfsmount [obj_lock] */


Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] leds: bcm6358: add missing of_node_put

[Julia Lawall]

for_each_available_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_available_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-bcm6358.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-bcm6358.c b/drivers/leds/leds-bcm6358.c
index 7ea3526..82b4ee1 100644
--- a/drivers/leds/leds-bcm6358.c
+++ b/drivers/leds/leds-bcm6358.c
@@ -215,8 +215,10 @@ static int bcm6358_leds_probe(struct platform_device *pdev)
}
 
rc = bcm6358_led(dev, child, reg, mem, lock);
-   if (rc < 0)
+   if (rc < 0) {
+   of_node_put(child);
return rc;
+   }
}
 
return 0;

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

[PATCH 4/9] leds: 88pm860x: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
local idexpression n;
expression e,r;
@@

 for_each_child_of_node(r,n) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-88pm860x.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/leds/leds-88pm860x.c b/drivers/leds/leds-88pm860x.c
index 1497a09..7870840 100644
--- a/drivers/leds/leds-88pm860x.c
+++ b/drivers/leds/leds-88pm860x.c
@@ -142,6 +142,7 @@ static int pm860x_led_dt_init(struct platform_device *pdev,
of_property_read_u32(np, "marvell,88pm860x-iset",
 );
data->iset = PM8606_LED_CURRENT(iset);
+   of_node_put(np);
break;
}
}

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

[net-next:master 1605/1613] net/tipc/link.c:166:6: sparse: symbol 'link_is_bc_sndlink' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
master
head:   687f079addba1ac7f97ce97080c2291bbe8c8dce
commit: 5266698661401afc5e4a1a521cf9ba10724d10dd [1605/1613] tipc: let 
broadcast packet reception use new link receive function
reproduce:
# apt-get install sparse
git checkout 5266698661401afc5e4a1a521cf9ba10724d10dd
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> net/tipc/link.c:166:6: sparse: symbol 'link_is_bc_sndlink' was not declared. 
>> Should it be static?
>> net/tipc/link.c:171:6: sparse: symbol 'link_is_bc_rcvlink' was not declared. 
>> Should it be static?
   net/tipc/link.c:635:6: sparse: symbol 'link_prepare_wakeup' was not 
declared. Should it be static?
   net/tipc/link.c:891:6: sparse: symbol 'tipc_link_advance_backlog' was not 
declared. Should it be static?
   net/tipc/link.c:967:5: sparse: symbol 'tipc_link_retrans' was not declared. 
Should it be static?
>> net/tipc/link.c:1561:6: sparse: symbol 'tipc_link_build_bc_init_msg' was not 
>> declared. Should it be static?
   include/linux/rcupdate.h:305:9: sparse: context imbalance in 
'tipc_link_find_owner' - wrong count at exit
   net/tipc/link.c:1821:5: sparse: context imbalance in 'tipc_nl_link_set' - 
different lock contexts for basic block
   net/tipc/link.c:2058:5: sparse: context imbalance in 'tipc_nl_link_dump' - 
different lock contexts for basic block
   net/tipc/link.c:2129:5: sparse: context imbalance in 'tipc_nl_link_get' - 
different lock contexts for basic block
   net/tipc/link.c:2181:5: sparse: context imbalance in 
'tipc_nl_link_reset_stats' - different lock contexts for basic block
--
   net/tipc/node.c:144:18: sparse: symbol 'tipc_node_create' was not declared. 
Should it be static?
   net/tipc/node.c:831:6: sparse: symbol 'tipc_node_filter_pkt' was not 
declared. Should it be static?
>> net/tipc/node.c:1090:6: sparse: symbol 'tipc_node_bc_rcv' was not declared. 
>> Should it be static?
   net/tipc/node.c:237:5: sparse: context imbalance in 'tipc_node_add_conn' - 
different lock contexts for basic block
   net/tipc/node.c:268:6: sparse: context imbalance in 'tipc_node_remove_conn' 
- different lock contexts for basic block
   net/tipc/node.c:303:9: sparse: context imbalance in 'tipc_node_timeout' - 
different lock contexts for basic block
   net/tipc/node.c:383:13: sparse: context imbalance in 'tipc_node_link_up' - 
wrong count at exit
   net/tipc/node.c:463:13: sparse: context imbalance in 'tipc_node_link_down' - 
wrong count at exit
   net/tipc/node.c:497:6: sparse: context imbalance in 'tipc_node_check_dest' - 
wrong count at exit
   net/tipc/node.c:917:9: sparse: context imbalance in 'tipc_node_get_linkname' 
- different lock contexts for basic block
   net/tipc/node.c:935:9: sparse: context imbalance in 'tipc_node_unlock' - 
unexpected unlock
   net/tipc/node.c:1027:5: sparse: context imbalance in 'tipc_node_xmit' - 
wrong count at exit
>> net/tipc/node.c:1090:6: sparse: context imbalance in 'tipc_node_bc_rcv' - 
>> wrong count at exit
   net/tipc/node.c:1277:6: sparse: context imbalance in 'tipc_rcv' - different 
lock contexts for basic block
   net/tipc/node.c:1348:5: sparse: context imbalance in 'tipc_nl_node_dump' - 
different lock contexts for basic block

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/9] add missing of_node_put

[Julia Lawall]

The various for_each device_node iterators performs an of_node_get on each
iteration, so a break out of the loop requires an of_node_put.

The complete semantic patch that fixes this problem is
(http://coccinelle.lip6.fr):

// 
@r@
local idexpression n;
expression e1,e2;
iterator name for_each_node_by_name, for_each_node_by_type,
for_each_compatible_node, for_each_matching_node,
for_each_matching_node_and_match, for_each_child_of_node,
for_each_available_child_of_node, for_each_node_with_property;
iterator i;
statement S;
expression list [n1] es;
@@

(
(
for_each_node_by_name(n,e1) S
|
for_each_node_by_type(n,e1) S
|
for_each_compatible_node(n,e1,e2) S
|
for_each_matching_node(n,e1) S
|
for_each_matching_node_and_match(n,e1,e2) S
|
for_each_child_of_node(e1,n) S
|
for_each_available_child_of_node(e1,n) S
|
for_each_node_with_property(n,e1) S
)
&
i(es,n,...) S
)

@@
local idexpression r.n;
iterator r.i;
expression e;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
   return n;
|
+  of_node_put(n);
?  return ...;
)
   ...
 }

@@
local idexpression r.n;
iterator r.i;
expression e;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n

@@
local idexpression r.n;
iterator r.i;
expression e;
identifier l;
expression list [r.n1] es;
@@

 i(es,n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  goto l;
)
   ...
 }
...
l: ... when != n// 

---

 drivers/bluetooth/btmrvl_main.c  |5 -
 drivers/gpu/drm/tegra/dc.c   |4 +++-
 drivers/gpu/host1x/bus.c |4 +++-
 drivers/leds/leds-88pm860x.c |1 +
 drivers/leds/leds-bcm6328.c  |4 +++-
 drivers/leds/leds-bcm6358.c  |4 +++-
 drivers/leds/leds-powernv.c  |8 ++--
 drivers/pinctrl/pinctrl-at91.c   |5 -
 drivers/soc/ti/knav_qmss_queue.c |3 +++
 9 files changed, 30 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/9] drm/tegra: dc: add missing of_node_put

[Julia Lawall]

for_each_matching_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
local idexpression n;
expression e;
@@

 for_each_matching_node(n,...) {
   ...
(
   of_node_put(n);
|
   e = n
|
+  of_node_put(n);
?  break;
)
   ...
 }
... when != n
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/tegra/dc.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b4af4ab..f0e6f37 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1945,8 +1945,10 @@ static int tegra_dc_parse_dt(struct tegra_dc *dc)
 * cases where only a single display controller is used.
 */
for_each_matching_node(np, tegra_dc_of_match) {
-   if (np == dc->dev->of_node)
+   if (np == dc->dev->of_node) {
+   of_node_put(np);
break;
+   }
 
value++;
}

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

[PATCH 3/9] leds: bcm6328: add missing of_node_put

[Julia Lawall]

for_each_available_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_available_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-bcm6328.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c
index 18de094..c7ea5c6 100644
--- a/drivers/leds/leds-bcm6328.c
+++ b/drivers/leds/leds-bcm6328.c
@@ -403,8 +403,10 @@ static int bcm6328_leds_probe(struct platform_device *pdev)
rc = bcm6328_led(dev, child, reg, mem, lock,
 blink_leds, blink_delay);
 
-   if (rc < 0)
+   if (rc < 0) {
+   of_node_put(child);
return rc;
+   }
}
 
return 0;

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

Re: [PATCH v2 3/3] ACPI/APEI/EINJ: Allow memory error injection to NVDIMM

[Rafael J. Wysocki]

On Friday, October 23, 2015 12:53:59 PM Toshi Kani wrote:
> In the case of memory error injection, einj_error_inject() checks
> if a target address is regular RAM.  Update this check to add a call
> to region_intersects_pmem() to verify if a target address range is
> NVDIMM.  This allows injecting a memory error to both RAM and NVDIMM
> for testing.
> 
> Also, the current RAM check, page_is_ram(), is replaced with
> region_intersects_ram() so that it can verify a target address
> range with the requested size.
> 
> Signed-off-by: Toshi Kani 

This is fine by me, but adding RAS maintainers Tony and Boris.

Thanks,
Rafael


> ---
>  drivers/acpi/apei/einj.c |   12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
> index 0431883..ab55bbe 100644
> --- a/drivers/acpi/apei/einj.c
> +++ b/drivers/acpi/apei/einj.c
> @@ -519,7 +519,7 @@ static int einj_error_inject(u32 type, u32 flags, u64 
> param1, u64 param2,
>u64 param3, u64 param4)
>  {
>   int rc;
> - unsigned long pfn;
> + u64 base_addr, size;
>  
>   /* If user manually set "flags", make sure it is legal */
>   if (flags && (flags &
> @@ -545,10 +545,14 @@ static int einj_error_inject(u32 type, u32 flags, u64 
> param1, u64 param2,
>   /*
>* Disallow crazy address masks that give BIOS leeway to pick
>* injection address almost anywhere. Insist on page or
> -  * better granularity and that target address is normal RAM.
> +  * better granularity and that target address is normal RAM or
> +  * NVDIMM.
>*/
> - pfn = PFN_DOWN(param1 & param2);
> - if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
> + base_addr = param1 & param2;
> + size = (~param2) + 1;
> + if (((region_intersects_ram(base_addr, size) != REGION_INTERSECTS) &&
> +  (region_intersects_pmem(base_addr, size) != REGION_INTERSECTS)) ||
> + ((param2 & PAGE_MASK) != PAGE_MASK))
>   return -EINVAL;
>  
>  inject:

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] gpu: host1x: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/host1x/bus.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 4a99c64..c1795a2 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -82,8 +82,10 @@ static int host1x_device_parse_dt(struct host1x_device 
*device,
if (of_match_node(driver->subdevs, np) &&
of_device_is_available(np)) {
err = host1x_subdev_add(device, np);
-   if (err < 0)
+   if (err < 0) {
+   of_node_put(np);
return err;
+   }
}
}
 

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

[PATCH 1/9] powerpc/powernv: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/leds/leds-powernv.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index 2c5c5b1..1e75e1f 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -262,15 +262,19 @@ static int powernv_led_classdev(struct platform_device 
*pdev,
while ((cur = of_prop_next_string(p, cur)) != NULL) {
powernv_led = devm_kzalloc(dev, sizeof(*powernv_led),
   GFP_KERNEL);
-   if (!powernv_led)
+   if (!powernv_led) {
+   of_node_put(np);
return -ENOMEM;
+   }
 
powernv_led->common = powernv_led_common;
powernv_led->loc_code = (char *)np->name;
 
rc = powernv_led_create(dev, powernv_led, cur);
-   if (rc)
+   if (rc) {
+   of_node_put(np);
return rc;
+   }
} /* while end */
}
 

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

[PATCH 6/9] Bluetooth: btmrvl: add missing of_node_put

[Julia Lawall]

for_each_compatible_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression e;
local idexpression n;
@@

 for_each_compatible_node(n, ...) {
   ... when != of_node_put(n)
   when != e = n
(
   return n;
|
+  of_node_put(n);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/bluetooth/btmrvl_main.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 6ba2286..6af9173 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -516,14 +516,17 @@ static int btmrvl_check_device_tree(struct btmrvl_private 
*priv)
ret = of_property_read_u8_array(dt_node, "btmrvl,cal-data",
cal_data + BT_CAL_HDR_LEN,
BT_CAL_DATA_SIZE);
-   if (ret)
+   if (ret) {
+   of_node_put(dt_node);
return ret;
+   }
 
BT_DBG("Use cal data from device tree");
ret = btmrvl_download_cal_data(priv, cal_data,
   BT_CAL_DATA_SIZE);
if (ret) {
BT_ERR("Fail to download calibrate data");
+   of_node_put(dt_node);
return ret;
}
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] pinctrl: at91: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/pinctrl/pinctrl-at91.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index ce6e589..0d2fc0c 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1122,8 +1122,10 @@ static int at91_pinctrl_parse_functions(struct 
device_node *np,
func->groups[i] = child->name;
grp = >groups[grp_index++];
ret = at91_pinctrl_parse_groups(child, grp, info, i++);
-   if (ret)
+   if (ret) {
+   of_node_put(child);
return ret;
+   }
}
 
return 0;
@@ -1196,6 +1198,7 @@ static int at91_pinctrl_probe_dt(struct platform_device 
*pdev,
ret = at91_pinctrl_parse_functions(child, info, i++);
if (ret) {
dev_err(>dev, "failed to parse function\n");
+   of_node_put(child);
return ret;
}
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] soc: ti: knav_qmss_queue: add missing of_node_put

[Julia Lawall]

for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.

A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):

// 
@@
expression root,e;
local idexpression child;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
   when != e = child
(
   return child;
|
+  of_node_put(child);
?  return ...;
)
   ...
 }
// 

Signed-off-by: Julia Lawall 

---
 drivers/soc/ti/knav_qmss_queue.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 89789e2..6f3d12b 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1074,6 +1074,7 @@ static int knav_queue_setup_regions(struct knav_device 
*kdev,
region = devm_kzalloc(dev, sizeof(*region), GFP_KERNEL);
if (!region) {
dev_err(dev, "out of memory allocating region\n");
+   of_node_put(child);
return -ENOMEM;
}
 
@@ -1373,6 +1374,7 @@ static int knav_queue_init_qmgrs(struct knav_device *kdev,
qmgr = devm_kzalloc(dev, sizeof(*qmgr), GFP_KERNEL);
if (!qmgr) {
dev_err(dev, "out of memory allocating qmgr\n");
+   of_node_put(child);
return -ENOMEM;
}
 
@@ -1450,6 +1452,7 @@ static int knav_queue_init_pdsps(struct knav_device *kdev,
pdsp = devm_kzalloc(dev, sizeof(*pdsp), GFP_KERNEL);
if (!pdsp) {
dev_err(dev, "out of memory allocating pdsp\n");
+   of_node_put(child);
return -ENOMEM;
}
pdsp->name = knav_queue_find_name(child);

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

Re: [PATCH 5/5] block: enable dax for raw block devices

[Jan Kara]

On Fri 23-10-15 16:32:57, Dan Williams wrote:
> On Thu, Oct 22, 2015 at 2:08 PM, Jan Kara  wrote:
> > On Thu 22-10-15 16:05:46, Williams, Dan J wrote:
> [..]
> >> This text was aimed at the request from Ross to document the differences
> >> vs the generic_file_mmap() path.  Is the following incremental change
> >> more clear?
> >
> > Well, not really. I thought you'd just delete that paragraph :) The thing
> > is: When doing IO directly to the block device, it makes no sense to look
> > at a filesystem on top of it - hopefully there is none since you'd be
> > corrupting it. So the paragraph that would make sense to me would be:
> >
> >  * Finally, in contrast to filemap_page_mkwrite(), we don't bother calling
> >  * sb_start_pagefault(). There is no filesystem which could be frozen here
> >  * and when bdev gets frozen, IO gets blocked in the request queue.
> 
> I'm not following this assertion that "IO gets blocked in the request
> queue" when the device is frozen in the code.  As far as I can see
> outside of tracking the freeze depth count the request_queue does not
> check if the device is frozen.   freeze_bdev() is moot when no
> filesystem is a present.

Yes, how e.g. dm freezes devices when it wants to do a snapshot is that it
first calls freeze_bdev() (to stop fs when there is one) and then calls
blk_stop_queue() to block all the IO requests in the request queue. In this
sense freeze_bdev() is somewhat a misnomer since it doesn't make sure no IO
is submitted to the bdev.

> > But when spelled out like this, I've realized that with DAX, this blocking
> > of requests in the request queue doesn't really block the IO to the device.
> > So block device freezing (aka blk_queue_stop()) doesn't work reliably with
> > DAX. That should be fixed but it's not easy as the only way to do that
> > would be to hook into blk_stop_queue() and unmap (or at least
> > write-protect) all the mappings of the device. Ugh...
> 
> Again I'm missing how this is guaranteed in the non-DAX case.
> freeze_bdev() will sync_blockdev(), but it does nothing to prevent
> re-dirtying through raw device mmaps while the fs in frozen.  Should
> it?  That's at least a separate patch.

It doesn't have to - after blk_stop_queue() is called no IO is submitted to
the device and snapshotting happens in the level below bdev page cache so
we don't care about modifications happening there. But with DAX things are
different as we directly map device pages into page cache so we have to
make sure no modifications of page cache happen.

Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/12] PCI: Add virtfn_index for struct pci_device

[Lan, Tianyu]

On 10/22/2015 2:07 AM, Alexander Duyck wrote:

On 10/21/2015 09:37 AM, Lan Tianyu wrote:

Add "virtfn_index" member in the struct pci_device to record VF sequence
of PF. This will be used in the VF sysfs node handle.

Signed-off-by: Lan Tianyu 
---
  drivers/pci/iov.c   | 1 +
  include/linux/pci.h | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee0ebff..065b6bb 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -136,6 +136,7 @@ static int virtfn_add(struct pci_dev *dev, int id,
int reset)
  virtfn->physfn = pci_dev_get(dev);
  virtfn->is_virtfn = 1;
  virtfn->multifunction = 0;
+virtfn->virtfn_index = id;
  for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
  res = >resource[i + PCI_IOV_RESOURCES];
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8d..85c5531 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -356,6 +356,7 @@ struct pci_dev {
  unsigned intio_window_1k:1;/* Intel P2P bridge 1K I/O
windows */
  unsigned intirq_managed:1;
  pci_dev_flags_t dev_flags;
+unsigned intvirtfn_index;
  atomic_tenable_cnt;/* pci_enable_device has been called */
  u32saved_config_space[16]; /* config space saved at
suspend time */



Can't you just calculate the VF index based on the VF BDF number
combined with the information in the PF BDF number and VF
offset/stride?  Seems kind of pointless to add a variable that is only
used by one driver and is in a slowpath when you can just calculate it
pretty quickly.


Good suggestion. Will try it.



- Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: ds1307: Fix alarm programming for mcp794xx

[Nishanth Menon]

On 10/23/2015 01:29 AM, Tero Kristo wrote:
> mcp794xx alarm registers must be written in BCD format. However, the
> alarm programming logic neglected this by adding one to the value
> after bin2bcd conversion has been already done, writing bad values
> to month register in case the alarm being set is in October. In this
> case, the alarm month value becomes 0x0a instead of the expected 0x10.
> 
> Fix by moving the +1 addition within the bin2bcd call also.
> 
> Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for 
> mcp7941x chips")
> 
> Signed-off-by: Tero Kristo 

Nice catch.
Acked-by: Nishanth Menon 
> ---
>  drivers/rtc/rtc-ds1307.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index a705e64..188006c 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -718,9 +718,9 @@ static int mcp794xx_set_alarm(struct device *dev, struct 
> rtc_wkalrm *t)
>   regs[3] = bin2bcd(t->time.tm_sec);
>   regs[4] = bin2bcd(t->time.tm_min);
>   regs[5] = bin2bcd(t->time.tm_hour);
> - regs[6] = bin2bcd(t->time.tm_wday) + 1;
> + regs[6] = bin2bcd(t->time.tm_wday + 1);
>   regs[7] = bin2bcd(t->time.tm_mday);
> - regs[8] = bin2bcd(t->time.tm_mon) + 1;
> + regs[8] = bin2bcd(t->time.tm_mon + 1);
>  
>   /* Clear the alarm 0 interrupt flag. */
>   regs[6] &= ~MCP794XX_BIT_ALMX_IF;
> 


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

BUSINESS VORSCHLAG

[Mr chin sang]

BUSINESS VORSCHLAG



 Ich bin mit diesem Medium, um Sie über die Transaktion zur Abgabe
von $ 2150 (einundzwanzig Millionen fünfhunderttausend US-Dollar) auf
meinem Bank in China, Sie als Empfänger zu informieren. Es ist 100%
sicher, wobei der Finanzvorstand des verstorbenen Kunden.



 Bitte auf meine private E-Mail kontaktieren unter Für Fragen und
weitere Informationen.



 Mit freundlichen Grüßen,



 sang Chin

 e-mail: chinsan...@gmail.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 5/5] block: enable dax for raw block devices

[Jan Kara]

On Thu 22-10-15 23:41:27, Williams, Dan J wrote:
> On Thu, 2015-10-22 at 23:08 +0200, Jan Kara wrote:
> > On Thu 22-10-15 16:05:46, Williams, Dan J wrote:
> > > On Thu, 2015-10-22 at 11:35 +0200, Jan Kara wrote:
> > > > On Thu 22-10-15 02:42:11, Dan Williams wrote:
> > > > > If an application wants exclusive access to all of the persistent 
> > > > > memory
> > > > > provided by an NVDIMM namespace it can use this raw-block-dax facility
> > > > > to forgo establishing a filesystem.  This capability is targeted
> > > > > primarily to hypervisors wanting to provision persistent memory for
> > > > > guests.
> > > > > 
> > > > > Cc: Jan Kara 
> > > > > Cc: Jeff Moyer 
> > > > > Cc: Christoph Hellwig 
> > > > > Cc: Dave Chinner 
> > > > > Cc: Andrew Morton 
> > > > > Cc: Ross Zwisler 
> > > > > Signed-off-by: Dan Williams 
> > > > > ---
> > > > >  fs/block_dev.c |   54 
> > > > > +-
> > > > >  1 file changed, 53 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/fs/block_dev.c b/fs/block_dev.c
> > > > > index 3255dcec96b4..c27cd1a21a13 100644
> > > > > --- a/fs/block_dev.c
> > > > > +++ b/fs/block_dev.c
> > > > > @@ -1687,13 +1687,65 @@ static const struct address_space_operations 
> > > > > def_blk_aops = {
> > > > >   .is_dirty_writeback = buffer_check_dirty_writeback,
> > > > >  };
> > > > >  
> > > > > +#ifdef CONFIG_FS_DAX
> > > > > +/*
> > > > > + * In the raw block case we do not need to contend with truncation 
> > > > > nor
> > > > > + * unwritten file extents.  Without those concerns there is no need 
> > > > > for
> > > > > + * additional locking beyond the mmap_sem context that these routines
> > > > > + * are already executing under.
> > > > > + *
> > > > > + * Note, there is no protection if the block device is dynamically
> > > > > + * resized (partition grow/shrink) during a fault. A stable block 
> > > > > device
> > > > > + * size is already not enforced in the blkdev_direct_IO path.
> > > > > + *
> > > > > + * For DAX, it is the responsibility of the block device driver to
> > > > > + * ensure the whole-disk device size is stable while requests are in
> > > > > + * flight.
> > > > > + *
> > > > > + * Finally, these paths do not synchronize against freezing
> > > > > + * (sb_start_pagefault(), etc...) since bdev_sops does not support
> > > > > + * freezing.
> > > > 
> > > > Well, for devices freezing is handled directly in the block layer code
> > > > (blk_stop_queue()) since there's no need to put some metadata structures
> > > > into a consistent state. So the comment about bdev_sops is somewhat
> > > > strange.
> > > 
> > > This text was aimed at the request from Ross to document the differences
> > > vs the generic_file_mmap() path.  Is the following incremental change
> > > more clear?
> > 
> > Well, not really. I thought you'd just delete that paragraph :) The thing
> > is: When doing IO directly to the block device, it makes no sense to look
> > at a filesystem on top of it - hopefully there is none since you'd be
> > corrupting it. So the paragraph that would make sense to me would be:
> > 
> >  * Finally, in contrast to filemap_page_mkwrite(), we don't bother calling
> >  * sb_start_pagefault(). There is no filesystem which could be frozen here
> >  * and when bdev gets frozen, IO gets blocked in the request queue.
> > 
> > But when spelled out like this, I've realized that with DAX, this blocking
> > of requests in the request queue doesn't really block the IO to the device.
> > So block device freezing (aka blk_queue_stop()) doesn't work reliably with
> > DAX. That should be fixed but it's not easy as the only way to do that
> > would be to hook into blk_stop_queue() and unmap (or at least
> > write-protect) all the mappings of the device. Ugh...
> > 
> > Ugh2: Now I realized that DAX mmap isn't safe wrt fs freezing even for
> > filesystems since there's nothing which writeprotects pages that are
> > writeably mapped. In normal path, page writeback does this but that doesn't
> > happen for DAX. I remember we once talked about this but it got lost.
> > We need something like walk all filesystem inodes during fs freeze and
> > writeprotect all pages that are mapped. But that's going to be slow...
> 
> This sounds suspiciously like what I'm planning to do for the device
> teardown path when we've dynamically allocated struct page.  The backing
> memory for those pages is freed when the driver runs its ->remove()
> path, so we have to be sure there are no outstanding references to them.
> 
> My current proposal for the teardown case, that we might re-purpose for
> this freeze case, is below.  It relies on the percpu_ref in the
> request_queue to block new faults and then uses truncate_pagecache() to
> teardown mappings.  However, this assumes we've inserted pages into the
> address_space radix at fault, which we don't currently do...

Well, for the freeze case it is enough to call unmap_mapping_range() for
each 

Re: [PATCH v2 2/2] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[David Miller]

From: Mans Rullgard 
Date: Thu, 22 Oct 2015 17:28:50 +0100

> +static void nb8800_mac_tx(struct net_device *dev, int enable)
 ...
> +static void nb8800_mac_rx(struct net_device *dev, int enable)
 ...
> +static void nb8800_mac_af(struct net_device *dev, int enable)

Please use 'bool' and true/false for 'enable'.

> +static int nb8800_alloc_rx(struct net_device *dev, int i, int napi)

Likewise here for 'napi'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/22] of: add function to allow probing a device from a OF node

[Rafael J. Wysocki]

On Friday, October 23, 2015 08:54:19 AM Mark Brown wrote:
> 
> --7cm2iqirTL37Ot+N
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Thu, Oct 22, 2015 at 03:03:37PM +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 03:06, Rafael J. Wysocki  wrote:
> 
> > > Same question as from Greg: How does a subsystem know whether or not to 
> > > use
> > > this function?
> 
> > Maybe I don't understand the comment, but as the commit message says,
> > subsystems can use this when looking up resources for drivers. Or you
> > mean that this information should be in the API docs?
> 
> I'm pretty sure what he's suggesting here is changing to "should always"
> (ie, explain the situations when a subsystem would do this, including
> decision criteria if it's optional).

Right.

Thanks,
Rafael

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

Re: [PATCH V1 10/10] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization.

[Tomasz Nowicki]

On 10/24/2015 12:20 PM, Hanjun Guo wrote:

On 2015/10/15 22:05, Tomasz Nowicki wrote:

After refactoring DT code, we let ACPI to build ITS PCI MSI domain
and do requester ID to device ID translation using IORT table.

We have now full PCI MSI domain stack, thus we can enable ITS initialization
from GICv3 core driver for ACPI scenario.

Signed-off-by: Tomasz Nowicki 
---
  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 48 ++--
  drivers/irqchip/irq-gic-v3.c |  3 +-
  2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cfd35da..09ae2d8 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -15,6 +15,8 @@
   * along with this program.  If not, see .
   */

+#include 
+#include 
  #include 
  #include 
  #include 
@@ -59,8 +61,10 @@ static int its_pci_msi_vec_count(struct pci_dev *pdev)
  static int its_get_pci_alias(struct pci_dev *pdev, u16 alias, void *data)
  {
struct its_pci_alias *dev_alias = data;
+   u32 dev_id;

-   dev_alias->dev_id = alias;
+   dev_alias->dev_id = iort_find_pci_id(pdev, alias, _id) == 0 ?
+   dev_id : alias;


Hi tomasz, I think we need to re work this patch on top of tip/irq/core
which has support for "msi-map" and "mai-parent" property support.



Indeed, I will rebase after some more comments related to other patches 
in this series.


Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: sun4i-codec: use consistent names for PA controls

[Adam Sampson]

The power amplifier for the headphone output is called "the PA" and "the
headphone amplifier" in Allwinner's documentation for the A10 and A20.
sun4i-codec calls it "PA" in some places and "Pre-Amplifier" (which
isn't really accurate) in others, leading to user-visible controls with
different names referring to the same device.

When this driver implements audio input, it'll also need to expose
controls for the line and mic input preamps, so just referring to "the
Pre-Amplifier" will be ambiguous.

Change it to use "PA" consistently for the power amplifier.

Signed-off-by: Adam Sampson 
---
 sound/soc/sunxi/sun4i-codec.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index bcbf4da..ff3304d 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -2,6 +2,7 @@
  * Copyright 2014 Emilio López 
  * Copyright 2014 Jon Smirl 
  * Copyright 2015 Maxime Ripard 
+ * Copyright 2015 Adam Sampson 
  *
  * Based on the Allwinner SDK driver, released under the GPL.
  *
@@ -452,12 +453,12 @@ static const struct snd_soc_dapm_widget 
sun4i_codec_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("Mixer Enable", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_MIXEN, 0, NULL, 0),
 
-   /* Pre-Amplifier */
-   SND_SOC_DAPM_MIXER("Pre-Amplifier", SUN4I_CODEC_ADC_ACTL,
+   /* Headphone output power amplifier */
+   SND_SOC_DAPM_MIXER("PA", SUN4I_CODEC_ADC_ACTL,
   SUN4I_CODEC_ADC_ACTL_PA_EN, 0,
   sun4i_codec_pa_mixer_controls,
   ARRAY_SIZE(sun4i_codec_pa_mixer_controls)),
-   SND_SOC_DAPM_SWITCH("Pre-Amplifier Mute", SND_SOC_NOPM, 0, 0,
+   SND_SOC_DAPM_SWITCH("PA Mute", SND_SOC_NOPM, 0, 0,
_codec_pa_mute),
 
SND_SOC_DAPM_OUTPUT("HP Right"),
@@ -480,16 +481,16 @@ static const struct snd_soc_dapm_route 
sun4i_codec_dapm_routes[] = {
{ "Left Mixer", NULL, "Mixer Enable" },
{ "Left Mixer", "Left DAC Playback Switch", "Left DAC" },
 
-   /* Pre-Amplifier Mixer Routes */
-   { "Pre-Amplifier", "Mixer Playback Switch", "Left Mixer" },
-   { "Pre-Amplifier", "Mixer Playback Switch", "Right Mixer" },
-   { "Pre-Amplifier", "DAC Playback Switch", "Left DAC" },
-   { "Pre-Amplifier", "DAC Playback Switch", "Right DAC" },
+   /* PA Mixer Routes */
+   { "PA", "Mixer Playback Switch", "Left Mixer" },
+   { "PA", "Mixer Playback Switch", "Right Mixer" },
+   { "PA", "DAC Playback Switch", "Left DAC" },
+   { "PA", "DAC Playback Switch", "Right DAC" },
 
/* PA -> HP path */
-   { "Pre-Amplifier Mute", "Switch", "Pre-Amplifier" },
-   { "HP Right", NULL, "Pre-Amplifier Mute" },
-   { "HP Left", NULL, "Pre-Amplifier Mute" },
+   { "PA Mute", "Switch", "PA" },
+   { "HP Right", NULL, "PA Mute" },
+   { "HP Left", NULL, "PA Mute" },
 };
 
 static struct snd_soc_codec_driver sun4i_codec_codec = {
-- 
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] timeconst: update path in comment

[Nicholas Mc Guire]

On Thu, Oct 22, 2015 at 05:31:17PM +0200, Jason A. Donenfeld wrote:
> It's understandable nobody really cares about applying this patch,
> since it's mostly just cosmetic. But it would be nice to know that
> somebody out there cares about consistency like I do. It would also
> help out the next person who's debugging time things and says "where
> is that darn .bc file?".
>

seems like this was missed when things got moved into kernel/time
thanks for fixing this.
 
> On Tue, Jul 14, 2015 at 7:24 PM, Jason A. Donenfeld  wrote:
> > Signed-off-by: Jason A. Donenfeld 
> > ---
> >  kernel/time/timeconst.bc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst.bc
> > index c7388de..c486889 100644
> > --- a/kernel/time/timeconst.bc
> > +++ b/kernel/time/timeconst.bc
> > @@ -39,7 +39,7 @@ define fmuls(b,n,d) {
> >  }
> >
> >  define timeconst(hz) {
> > -   print "/* Automatically generated by kernel/timeconst.bc */\n"
> > +   print "/* Automatically generated by kernel/time/timeconst.bc */\n"
> > print "/* Time conversion constants for HZ == ", hz, " */\n"
> > print "\n"
> >
> > --
> > 2.4.5
> >

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

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird  wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>> 
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>  But that's moot currently because Greg believes that the time spent
>  probing devices at boot time could be reduced enough so that the order
>  in which devices are probed becomes irrelevant. IME that would have to
>  be under 200ms so that the user doesn't notice and that's unicorn-far
>  from any bootlog I have ever seen.
> >>>
> >>> But as no one has actually produced a bootlog, how do you know that?
> >>> Where exactly is your time being spent?  What driver is causing long
> >>> delays?  Why is the long-delay-drivers not being done in their own
> >>> thread?  And most importantly, why are you ignoring the work that people
> >>> did back in 2008 to solve the issue on other hardware platforms?
> >>>
>  Given that downstreams are already carrying as many hacks as they
>  could think of to speed total boot up, I think this is effectively
>  telling them to go away.
> >>>
> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> >>> solve-the-random-issue-i'm-having type patch by putting random calls in
> >>> semi-random subsystems all over the kernel.
> >>>
> >>> And when I ask for real data, you respond with the fact that you aren't
> >>> trying to speed up boot time here at all, so what am I supposed to think
> >>
> >> I also had the understanding that this patch series was about improving
> >> boot time.  But I was kindly corrected that the behavior change was
> >> getting the panel displaying stuff at an earlier point in the boot 
> >> sequence,
> >> _not_ completing the entire boot faster.
> >>
> >> The claim for the current series, in patch 0 in v7 is:
> >>
> >>With this series I get the kernel to output to the panel in 0.5s,
> >>instead of 2.8s.
> >
> > It's very common to want to get the display up before the
> > rest of the system.  So wanting to accelerate one part of the boot
> > at the expense to the rest of the system is a valid use case.
> > Deferred initcalls, which is out of tree primarily because it requires
> > the type of manual tweaking that Tomeu describes, specifically
> > addressed this issue.
> 
> Agreed and other folks will want other things up first. But it seems
> we are getting lucky with link order with the speed ups in this case.
> We need a way to specify priority of probing devices. If we have that
> piece, then all this plumbing can be used. A simple solution would be
> looking at stdout-path to get the console device to probe. That would
> be trivial to add on top of this. That may work for the display too,
> but you may not want the console on the display. That wouldn't work
> for CAN bus either, but then I'm not sure there is a generic solution
> for its requirements (respond within 50ms IIRC).

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary.  And this is not limited
to probing, as I have already said for a few times.  Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.

If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.

Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.

So perhaps it's better to start discussing about a solution for the general
issue?

Thanks,
Rafael

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

Re: [PATCH v6 03/22] of/platform: Point to struct device from device node

[Rafael J. Wysocki]

On Thursday, October 22, 2015 03:01:45 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:02, Rafael J. Wysocki  wrote:
> > On Monday, September 21, 2015 04:02:43 PM Tomeu Vizoso wrote:
> >> When adding platform and AMBA devices, set the device node's device
> >> member to point to it.
> >>
> >> This speeds lookups considerably and is safe because we only create one
> >> of these devices for any given device node.
> >>
> >> Signed-off-by: Tomeu Vizoso 
> >> ---
> >>
> >> Changes in v5:
> >> - Set the pointer to struct device also for AMBA devices
> >> - Unset the pointer to struct device when the platform device is about
> >>   to be unregistered
> >> - Increase the reference count of the device before returning from
> >>   of_find_device_by_node()
> >>
> >>  drivers/of/platform.c | 19 ++-
> >>  include/linux/of.h|  1 +
> >>  2 files changed, 11 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >> index 1001efaedcb8..408d89f1d124 100644
> >> --- a/drivers/of/platform.c
> >> +++ b/drivers/of/platform.c
> >> @@ -32,11 +32,6 @@ const struct of_device_id of_default_bus_match_table[] 
> >> = {
> >>   {} /* Empty terminated list */
> >>  };
> >>
> >> -static int of_dev_node_match(struct device *dev, void *data)
> >> -{
> >> - return dev->of_node == data;
> >> -}
> >> -
> >>  /**
> >>   * of_find_device_by_node - Find the platform_device associated with a 
> >> node
> >>   * @np: Pointer to device tree node
> >> @@ -45,10 +40,10 @@ static int of_dev_node_match(struct device *dev, void 
> >> *data)
> >>   */
> >>  struct platform_device *of_find_device_by_node(struct device_node *np)
> >>  {
> >> - struct device *dev;
> >> -
> >> - dev = bus_find_device(_bus_type, NULL, np, 
> >> of_dev_node_match);
> >> - return dev ? to_platform_device(dev) : NULL;
> >> + if (np->device && np->device->bus == _bus_type &&
> >> + get_device(np->device))
> >> + return to_platform_device(np->device);
> >> + return NULL;
> >>  }
> >>  EXPORT_SYMBOL(of_find_device_by_node);
> >>
> >> @@ -192,6 +187,8 @@ static struct platform_device 
> >> *of_platform_device_create_pdata(
> >>   goto err_clear_flag;
> >>   }
> >>
> >> + np->device = >dev;
> >> +
> >>   return dev;
> >>
> >>  err_clear_flag:
> >> @@ -272,6 +269,8 @@ static struct amba_device 
> >> *of_amba_device_create(struct device_node *node,
> >>   goto err_free;
> >>   }
> >>
> >> + node->device = >dev;
> >> +
> >>   return dev;
> >>
> >>  err_free:
> >> @@ -476,6 +475,8 @@ static int of_platform_device_destroy(struct device 
> >> *dev, void *data)
> >>   if (of_node_check_flag(dev->of_node, OF_POPULATED_BUS))
> >>   device_for_each_child(dev, NULL, of_platform_device_destroy);
> >>
> >> + dev->of_node->device = NULL;
> >> +
> >>   if (dev->bus == _bus_type)
> >>   platform_device_unregister(to_platform_device(dev));
> >>  #ifdef CONFIG_ARM_AMBA
> >> diff --git a/include/linux/of.h b/include/linux/of.h
> >> index 2194b8ca41f9..eb091be0f8ee 100644
> >> --- a/include/linux/of.h
> >> +++ b/include/linux/of.h
> >> @@ -52,6 +52,7 @@ struct device_node {
> >>   phandle phandle;
> >>   const char *full_name;
> >>   struct fwnode_handle fwnode;
> >> + struct device *device;
> >
> > There are cases in which multiple device objects point to the same 
> > device_node,
> > so is the single struct device pointer here really sufficient?
> 
> Only one struct device is registered for a given DT device node when
> the DT is scanned (otherwise, of_find_device_by_node wouldn't be
> safe).
> 
> If some driver makes a struct device to point to a device_node that
> already has a struct device associated with it, that's fine.

Well, once that has happened, your new device pointer in the given device_node
becomes useless.  Why exactly is that fine?

Thanks,
Rafael

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

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

[Rafael J. Wysocki]

On Thursday, October 22, 2015 03:03:37 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:06, Rafael J. Wysocki  wrote:
> > On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
> >> Walks the OF tree up and finds the closest ancestor that has a struct
> >> device associated with it, probing it if isn't bound to a driver yet.
> >>
> >> The above should ensure that the dependency represented by the passed OF
> >> node is available, because probing a device should cause its descendants
> >> to be probed as well (when they get registered).
> >>
> >> Subsystems can use this when looking up resources for drivers, to reduce
> >> the chances of deferred probes because of the probing order of devices.
> >>
> >> Signed-off-by: Tomeu Vizoso 
> >> ---
> >>
> >> Changes in v5:
> >> - Move the assignment to device_node->device for AMBA devices to another
> >>   commit.
> >> - Hold a reference to the struct device while it's in use in
> >>   of_device_probe().
> >>
> >> Changes in v4:
> >> - Rename of_platform_probe to of_device_probe
> >> - Use device_node.device instead of device_node.platform_dev
> >>
> >> Changes in v3:
> >> - Set and use device_node.platform_dev instead of reversing the logic to
> >>   find the platform device that encloses a device node.
> >> - Drop the fwnode API to probe firmware nodes and add OF-only API for
> >>   now. I think this same scheme could be used for machines with ACPI,
> >>   but I haven't been able to find one that had to defer its probes because
> >>   of the device probe order.
> >>
> >>  drivers/of/device.c   | 61 
> >> +++
> >>  include/linux/of_device.h |  3 +++
> >>  2 files changed, 64 insertions(+)
> >>
> >> diff --git a/drivers/of/device.c b/drivers/of/device.c
> >> index 8b91ea241b10..836be71fc90e 100644
> >> --- a/drivers/of/device.c
> >> +++ b/drivers/of/device.c
> >> @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, 
> >> struct kobj_uevent_env *env)
> >>
> >>   return 0;
> >>  }
> >> +
> >> +/**
> >> + * of_device_probe() - Probe device associated with OF node
> >> + * @np: node to probe
> >> + *
> >> + * Probe the device associated with the passed device node.
> >> + */
> >> +void of_device_probe(struct device_node *np)
> >
> > Same question as from Greg: How does a subsystem know whether or not to use
> > this function?
> 
> Maybe I don't understand the comment, but as the commit message says,
> subsystems can use this when looking up resources for drivers. Or you
> mean that this information should be in the API docs?

I'm not really sure this is the only case.

Most likely, you'd end up with that being called by every subsystem using DT
just in case.

And then each of those subsystems would need to call acpi_device_probe(), and
then another_platform_firmware_interface_device_probe() and so on.

Don't you see a problem here?

Thanks,
Rafael

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

Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices

[Rafael J. Wysocki]

On Thursday, October 22, 2015 04:27:10 PM Scott Wood wrote:
> On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 00:51, Scott Wood  wrote:
> > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
> > > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood 
> > > > wrote:
> > > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> > > > > > Instead of trying to match and probe platform and AMBA devices right
> > > > > > after each is registered, delay their probes until 
> > > > > > device_initcall_sync.
> > > > > > 
> > > > > > This means that devices will start probing once all built-in drivers
> > > > > > have registered, and after all platform and AMBA devices from the DT
> > > > > > have been registered already.
> > > > > > 
> > > > > > This allows us to prevent deferred probes by probing dependencies on
> > > > > > demand.
> > > > > > 
> > > > > > Signed-off-by: Tomeu Vizoso 
> > > > > > ---
> > > > > > 
> > > > > > Changes in v4:
> > > > > > - Also defer probes of AMBA devices registered from the DT as they 
> > > > > > can
> > > > > >   also request resources.
> > > > > > 
> > > > > >  drivers/of/platform.c | 11 ---
> > > > > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > > 
> > > > > This breaks arch/powerpc/sysdev/fsl_pci.c.  The PCI bus is an OF 
> > > > > platform
> > > > > device, and it must be probed before pcibios_init() which is a
> > > > > subsys_initcall(), or else the PCI bus never gets scanned.
> > > > 
> > > > Thanks for the report. This is probably getting dropped, but it could
> > > > be disabled for PPC.
> > > 
> > > I don't think that adding another arbitrary arch difference would be the
> > > right solution.
> > 
> > I think Rob meant temporarily disable it while things get fixed. At
> > least, 
> 
> So, what is the permanent fix for the swiotlb issue (or more generally, the 
> inability to have a late_initcall that runs after non-module, non-hotplug 
> platform devices have been probed)?
> 
> > I don't see any reason why PPC wouldn't benefit from this
> > series.
> 
> It's not clear to me what the benefit of this is at all, much less for PPC.   
> What is the fundamental problem with deferred probes?  In the cover letter 
> you say this change saves 2.3 seconds, but where is that time being consumed? 
>  Are the drivers taking too long in their probe function trying to initialize 
> and then deferring, rather than checking for dependencies up front?  Or are 
> there really so many devices and such a pessimal ordering that most of the 
> time is spent iterating through and reordering the list, with each defer 
> happening quickly?
> 
> Even if something different does need to be done at this level, forcing all 
> OF platform devices to be probed at the late_initcall level seems quite 
> intrusive.

Totally agreed.

> You limited it to OF because people complained that other things 
> will break.

Right.

And I'm not sure why that was regarded as a good enough reason to do it.

> Things still broke.

Yes, they did.

> Surely there's a better way to address the 
> problem.  Can't the delay be requested by drivers that might otherwise need 
> to defer (which could be done incrementally, focusing on the worst 
> performance problems), rather than enabling it for everything?

Well, I was suggesting to use an opt-in flag there, but I'm not sure if Tomeu
took that into consideration.

In any case, probing is just one aspect of a deeper issue, which is that
we have no way to represent functional dependencies between devices.

Thanks,
Rafael

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