Re: [patch v2] mm, thp: add new defer+madvise defrag option

[Michal Hocko]

On Wed 11-01-17 08:35:27, Vlastimil Babka wrote:
> [+CC linux-api]
> 
> On 01/11/2017 01:15 AM, David Rientjes wrote:
> > There is no thp defrag option that currently allows MADV_HUGEPAGE regions 
> > to do direct compaction and reclaim while all other thp allocations simply 
> > trigger kswapd and kcompactd in the background and fail immediately.
> > 
> > The "defer" setting simply triggers background reclaim and compaction for 
> > all regions, regardless of MADV_HUGEPAGE, which makes it unusable for our 
> > userspace where MADV_HUGEPAGE is being used to indicate the application is 
> > willing to wait for work for thp memory to be available.
> > 
> > The "madvise" setting will do direct compaction and reclaim for these
> > MADV_HUGEPAGE regions, but does not trigger kswapd and kcompactd in the 
> > background for anybody else.
> > 
> > For reasonable usage, there needs to be a mesh between the two options.  
> > This patch introduces a fifth mode, "defer+madvise", that will do direct 
> > reclaim and compaction for MADV_HUGEPAGE regions and trigger background 
> > reclaim and compaction for everybody else so that hugepages may be 
> > available in the near future.
> > 
> > A proposal to allow direct reclaim and compaction for MADV_HUGEPAGE 
> > regions as part of the "defer" mode, making it a very powerful setting and 
> > avoids breaking userspace, was offered: 
> > http://marc.info/?t=14823661273.  This additional mode is a 
> > compromise.
> > 
> > A second proposal to allow both "defer" and "madvise" to be selected at
> > the same time was also offered: http://marc.info/?t=14835734531.
> > This is possible, but there was a concern that it might break existing
> > userspaces the parse the output of the defrag mode, so the fifth option
> > was introduced instead.
> > 
> > This patch also cleans up the helper function for storing to "enabled" 
> > and "defrag" since the former supports three modes while the latter 
> > supports five and triple_flag_store() was getting unnecessarily messy.
> > 
> > Signed-off-by: David Rientjes 
> 
> alloc_hugepage_direct_gfpmask() would have been IMHO simpler if a new
> internal flag wasn't added, and combination of two existing for defer
> and madvise used,

I agree with Vlastimil here. The patch can do without touching anything
outside of the sysfs handling.
-- 
Michal Hocko
SUSE Labs

Re: x86-64: Maintain 16-byte stack alignment

[Ard Biesheuvel]

On 12 January 2017 at 06:12, Herbert Xu  wrote:
> On Tue, Jan 10, 2017 at 05:30:48PM +, Ard Biesheuvel wrote:
>>
>> Apologies for introducing this breakage. It seemed like an obvious and
>> simple cleanup, so I didn't even bother to mention it in the commit
>> log, but if the kernel does not guarantee 16 byte alignment, I guess
>> we should revert to the old method. If SSE instructions are the only
>> ones that require this alignment, then I suppose not having a ABI
>> conforming stack pointer should not be an issue in general.
>
> BTW Ard, what is the stack alignment on ARM64?
>

[From memory] the arm64 ELF psABI mandates a 16 byte stack alignment
at function entry, and 8 byte alignment at all other times. This means
compiled code will typically preserve 16 byte alignment, and
__aligned(16) on a stack variable will likely not result in an
explicit alignment of the stack pointer *. But the arm64 ISA does not
have any load/store instructions that would trigger a misalignment
fault on an address that is 8 byte aligned but not 16 byte aligned, so
the situation is very different from x86 (assuming I am correct in
asserting that there are no failure modes resulting from a misaligned
stack other than this one and a potential performance hit)

* I didn't check whether the exception handling realigns the stack
pointer on nested exceptions (arm64 has separate IRQ stacks)

Re: [PATCH] pinctrl: amd: avoid maybe-uninitalized warning

[Shyam Sundar S K]

Hi Linus,

You have already added patch for the same "[PATCH] pinctrl: amd: fix 
compilation warning" and applied to one of your fixed branch.

Do you feel this patch needs to be taken ?

Thanks,
Shyam

On 1/12/2017 1:19 PM, Linus Walleij wrote:
> On Wed, Jan 11, 2017 at 3:36 PM, Arnd Bergmann  wrote:
> 
>> Since gpio_dev->hwbank_num is now a variable, the compiler cannot
>> figure out if pin_num is initialized at all:
>>
>> drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show':
>> drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
>>for (; i < pin_num; i++) {
>>^~~
>> drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized 
>> in this function [-Wmaybe-uninitialized]
>>
>> This adds a 'default' statement to make that case well-defined.
>>
>> Fixes: 3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO")
>> Signed-off-by: Arnd Bergmann 
> 
> Patch applied.
> 
> Yours,
> Linus Walleij
> 

Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree

[Michal Hocko]

On Thu 12-01-17 14:12:47, Minchan Kim wrote:
> Hello,
> 
> On Wed, Jan 11, 2017 at 04:52:39PM +0100, Michal Hocko wrote:
> > On Wed 11-01-17 08:52:50, Minchan Kim wrote:
> > [...]
> > > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct
> > > > if (!file && !total_swap_pages)
> > > > return false;
> > > >  
> > > > -   inactive = lruvec_lru_size(lruvec, file * LRU_FILE);
> > > > -   active = lruvec_lru_size(lruvec, file * LRU_FILE + LRU_ACTIVE);
> > > > +   total_inactive = inactive = lruvec_lru_size(lruvec, file * 
> > > > LRU_FILE);
> > > > +   total_active = active = lruvec_lru_size(lruvec, file * LRU_FILE 
> > > > + LRU_ACTIVE);
> > > >  
> > > 
> > > the decision of deactivating is based on eligible zone's LRU size,
> > > not whole zone so why should we need to get a trace of all zones's LRU?
> > 
> > Strictly speaking, the total_ counters are not necessary for making the
> > decision. I found reporting those numbers useful regardless because this
> > will give us also an information how large is the eligible portion of
> > the LRU list. We do not have any other tracepoint which would report
> > that.
> 
> The patch doesn't say anything why it's useful. Could you tell why it's
> useful and inactive_list_is_low should be right place?
> 
> Don't get me wrong, please. I don't want to bother you.
> I really don't want to add random stuff although it's tracepoint for
> debugging.

This doesn't sounds random to me. We simply do not have a full picture
on 32b systems without this information. Especially when memcgs are
involved and global numbers spread over different LRUs.
 
> > [...]
> > > > @@ -2223,7 +2228,7 @@ static void get_scan_count(struct lruvec
> > > >  * lruvec even if it has plenty of old anonymous pages unless 
> > > > the
> > > >  * system is under heavy pressure.
> > > >  */
> > > > -   if (!inactive_list_is_low(lruvec, true, sc) &&
> > > > +   if (!inactive_list_is_low(lruvec, true, sc, false) &&
> > > 
> > > Hmm, I was curious why you added trace boolean arguement and found it 
> > > here.
> > > Yes, here is not related to deactivation directly but couldn't we help to
> > > trace it unconditionally?
> > 
> > I've had it like that when I was debugging the mentioned bug and found
> > it a bit disturbing. It generated more output than I would like and it
> > wasn't really clear from which code path  this has been called from.
> 
> Indeed.
> 
> Personally, I want to move inactive_list_is_low in shrink_active_list
> and shrink_active_list calls inactive_list_is_low(, true),
> unconditionally so that it can make code simple/clear but cannot remove
> trace boolean variable , which what I want. So, it's okay if you love
> your version.

I am not sure I am following. Why is the additional parameter a problem?
-- 
Michal Hocko
SUSE Labs

Re: x86-64: Maintain 16-byte stack alignment

[Herbert Xu]

On Wed, Jan 11, 2017 at 11:51:10PM -0800, Andy Lutomirski wrote:
>
> The problem is that we have nasties like TRACE_IRQS_OFF.  Performance

I don't understand.  What's the issue with TRACE_IRQS_OFF? It should
be treated as any other function call.  That is, enter it with an
aligned stack, and the TRACE_IRQS_OFF code itself should ensure
the stack stays aligned before it calls down into C.
 
> But if we can't do this with automatic verification, then I'm not sure
> I want to do it at all.  The asm is already more precarious than I'd
> like, and having a code path that is misaligned is asking for obscure
> bugs down the road.

I understand the need for automated checks at this point in time.
 But longer term this is just part of the calling ABI.  After all,
we don't add checks everywhere to ensure people preserve rbx.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] ceph/iov_iter: fix bad iov_iter handling in ceph splice codepaths

[Al Viro]

On Tue, Jan 10, 2017 at 07:57:31AM -0500, Jeff Layton wrote:
> v2: fix bug in offset handling in iov_iter_pvec_size
> 
> xfstest generic/095 triggers soft lockups in kcephfs. Basically it uses
> fio to drive some I/O via vmsplice ane splice. Ceph then ends up trying
> to access an ITER_BVEC type iov_iter as a ITER_IOVEC one. That causes it
> to pick up a wrong offset and get stuck in an infinite loop while trying
> to populate the page array. dio_get_pagev_size has a similar problem.
> 
> To fix the first problem, add a new iov_iter helper to determine the
> offset into the page for the current segment and have ceph call that.
> I would just replace dio_get_pages_alloc with iov_iter_get_pages_alloc,
> but that will only return a single page at a time for ITER_BVEC and
> it's better to make larger requests when possible.
> 
> For the second problem, we simply replace it with a new helper that does
> what it does, but properly for all iov_iter types.
> 
> Since we're moving that into generic code, we can also utilize the
> iterate_all_kinds macro to simplify this. That means that we need to
> rework the logic a bit since we can't advance to the next vector while
> checking the current one.

Yecchhh...  That really looks like exposing way too low-level stuff instead
of coming up with saner primitive ;-/

Is page vector + offset in the first page + number of bytes really what
ceph wants?  Would e.g. an array of bio_vec be saner?  Because _that_
would make a lot more natural iov_iter_get_pages_alloc() analogue...

And yes, I realize that you have ->pages wired into the struct ceph_osd_request;
how painful would it be to have it switched to struct bio_vec array instead?

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

[zhangyi (F)]

on 2017/1/11 23:34, Theodore Ts'o wrote:
> On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote:
>>
>> (1) The file we want to unlink have many hard links, but only one dcache 
>> entry in memory.
>> (2) open this file, but it's inode->i_nlink read from disk was 1 (too low).
>> (3) some one call rename and drop it's i_nlink to zero.
>> (4) it's inode is still in use and do not destroy (not closed), at the same 
>> time,
>> some others open it's hard link and create a dcache entry.
>> (5) call rename again and it's i_nlink will still underflow and cause memory 
>> corruption.
> 
> Do you have reproducers that make it easy to reproduce situations like
> this?  (It shouldn't be hard to write, but if you have them already
> will save me some effort.  :-)
> 
> If we ever get passed an inode to ext4_file_open() where i_nlink is
> zero, we can declare the file system is corrupt by calling
> ext4_error() to report the problem.
> 
> Similarly, whenever we are passed a dentry pointing to an inode for
> link, unlink, rename, and other methods in the inode_operations
> structure, by definition the file system is corrupt, and again we
> should report this using ext4_error().
> 
> So I don't think we should think of this as adding "underflow
> protection"; instead we should think of it as adding more aggressive
> detection of file system inconsistencies.  If there is dentry which is
> valid, and pointing at an inode where n_links is zero, something has
> gone seriously wrong.  So we should call ext4_error() to report the
> file system inconsistency, and then return EFSCORRUPTED (aka EUCLEAN).
> 
> Since we would be doing this in a number of places, we should probably
> add an inline function:
> 
> static inline int ext4_validate_dentry(struct dentry *dentry);
> 
> which returns 0 if the dentry is valid, and calls ext4_error_inode()
> and returns -EFSCORRUPTED if the dentry points to an inode with a zero
> i_nlink.
> 

Thanks for your advice, it can detect file system inconsistency and reprot
error more effective. :-)

At the same time, I think other file systems may have the same problem, do
you think we should put these detections on the VFS layer? Thus other file
systems no need to do the same things, but the disadvantage is that we can
not call ext4_error to report ext4 inconsistency.

yi zhang

Re: x86-64: Maintain 16-byte stack alignment

[Herbert Xu]

On Thu, Jan 12, 2017 at 08:01:51AM +, Ard Biesheuvel wrote:
> 
> [From memory] the arm64 ELF psABI mandates a 16 byte stack alignment
> at function entry, and 8 byte alignment at all other times. This means
> compiled code will typically preserve 16 byte alignment, and
> __aligned(16) on a stack variable will likely not result in an
> explicit alignment of the stack pointer *. But the arm64 ISA does not
> have any load/store instructions that would trigger a misalignment
> fault on an address that is 8 byte aligned but not 16 byte aligned, so
> the situation is very different from x86 (assuming I am correct in
> asserting that there are no failure modes resulting from a misaligned
> stack other than this one and a potential performance hit)

OK, sounds like we're already using 16-byte aligned stacks on
ARM64.  So unless x86-64 stacks are much smaller, I don't see
the need to use 8-byte aligned stacks at least from a stack space
point-of-view.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/4 v3] Fixes and workarounds for dwc2 on HiKey board (rebased to synopsys-usb/next)

[Felipe Balbi]

Hi,

John Youn  writes:
> On 1/11/2017 4:22 PM, John Stultz wrote:
>> Just wanted to resend my patches for dwc2 controller on the
>> HiKey board for consideration for the 4.11 merge window.
>> 
>> This patchset is the same as v2, only rebased against
>> John's synopsys-usb/next branch.
>> 
>> This does still exclude my patchset[1] to add extcon support to
>> dwc2, which John Youn suspects a pending rework of the dwc2 fifo
>> init logic might make unnecssary.
>> 
>> thanks
>> -john
>> 
>> [1] 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2016_12_6_69=DgIBAg=DPL6_X_6JkXFx7AXWqB0tg=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA=6QmpEaovCIrw3iVcLB9lyZ2hPpxb_n6SWfdUDBIINFU=JoQtFGWd8y_xhRErt3j8U8uoUw_kq0AStxhqSPwEa3Q=
>>  
>> 
>> v2:
>> * Reworked goto logic in patch #2, as suggested by Vardan
>> v3:
>> * Rebased to synopsys-usb/next
>> 
>
> Thanks
>
> For this series:
> Acked-by: John Youn 

Do we need these in the -rc cycle?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 RESEND] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lukasz Majewski]

Dear All,

> Thierry, Jingoo,
> 
> Please respond to Lukasz.

Yes, your response is more than welcome... :-)

Thanks in advance,

Łukasz Majewski

> 
> On Mon, 26 Dec 2016, Lukasz Majewski wrote:
> 
> > The commit a55944ca82d2 
> > ("backlight: update bd state & fb_blank properties when necessary")
> > has posed some extra restrictions on blanking and unblanking frame
> > buffer device.
> > 
> > Unfortunately, pwm_bl driver's probe did not initialize members of
> > struct backlight_device necessary for further blank/unblank
> > operation.
> > 
> > This code in case of initial unblank of backlight device (default 
> > behaviour) sets use_count to 1 and marks this particular backlight
> > device as used by all available fb devices (since it is not known
> > during probe how much and which fb devices will be assigned).
> > 
> > Without this code, the backlight works properly until one tries to
> > blank it manually from sysfs with "echo 1
> > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > > were both set to 0, the logic at
> > fb_notifier_callback (@backlight.c) thought that we didn't turn on
> > (unblanked) the backlight device and refuses to disable (blank) it.
> > As a result we see garbage from fb displayed.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > The patch has been tested on i.MX6q with vanilla 4.9 kernel.
> > It applies on 4.10-rc1.
> > ---
> >  drivers/video/backlight/pwm_bl.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> > platform_device *pdev) struct pwm_bl_data *pb;
> > int initial_blank = FB_BLANK_UNBLANK;
> > struct pwm_args pargs;
> > -   int ret;
> > +   int ret, i;
> >  
> > if (!data) {
> > ret = pwm_backlight_parse_dt(>dev, );
> > @@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
> > platform_device *pdev) 
> > bl->props.brightness = data->dft_brightness;
> > bl->props.power = initial_blank;
> > +
> > +   if (initial_blank == FB_BLANK_UNBLANK) {
> > +   for (i = 0; i < FB_MAX; i++)
> > +   bl->fb_bl_on[i] = true;
> > +
> > +   bl->use_count = 1;
> > +   }
> > +
> > backlight_update_status(bl);
> >  
> > platform_set_drvdata(pdev, bl);
> 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

[Andrew Duggan]

On 01/11/2017 11:27 AM, Christopher Heiny wrote:

On Wed, 2017-01-11 at 18:48 +0100, Benjamin Tissoires wrote:

On Jan 11 2017 or thereabouts, Arnd Bergmann wrote:

On Wednesday, January 11, 2017 5:28:28 PM CET Benjamin Tissoires
wrote:

Yep, it was initially written that way, and IIRC there was some
issues
depending on how the drivers were compiled. For example, if
rmi4_core is
Y and some functions are m, you can't load the device initially,
so you
send a -EPROBE_DEFER, but how can you be sure that the function
will
ever be loaded?

I'm not sure if I understand your problem correctly, but normally
the way it's done is that the bus driver notifies user space that
a new device has appeared on the bus, and udev looks for the right
driver for the device, using a MODULE_DEVICE_TABLE list. Once the
driver gets loaded, it binds to the device.


I agree, but we never managed to make it properly working for RMI4.
See
https://lkml.org/lkml/2015/11/5/726 where we decided to switch to a
static list of functions. Maybe we did not try hard enough, but we
kept
the current bus/functions_as_drivers to be able to switch back to the
modular option,

Actually, long, long ago (well before I got yanked off the RMI4 driver
project for a 'short term emergency' two and a half years ago -
fortunately Andrew was more than able to take it over) it worked that
way.  If you had the bus, a physical driver, and the sensor driver
running, you could build the functions as modules and attach them via
udev or insert them later.

We had this working on the bench at one point, but fairly early in the
submission process seem to have just assumed it would keep working and
stopped regression testing on that feature.  There have been an whole
lot of changes since then, and somewhere along the line functions-as-
loadable-modules stopped working.  Since we weren't testing it anymore,
it wasn't caught.



We made the decision to disable support for function drivers as modules 
after running into a few technical challenges which happened during 
initialization. The priority was to get the driver upstreamed so we put 
off getting function drivers working as modules until there was a 
compelling reason to do so. But, we left the structure mostly intact if 
we decided to do so. Here are the messages which describe what we 
discovered at the time:


https://lkml.org/lkml/2015/11/10/92
https://lkml.org/lkml/2015/11/12/652

I'm basically coming to the same conclusion I had back then. Getting 
loadable modules for function drivers to work would add complexity for 
not a lot of benefit based on the current state of the driver and how it 
is currently being used. I'm also not sure we will reach the critical 
mass of function drivers where there is a significant benefit of not 
having to load them all.



Given that we need to have all the functions loaded during probe,
we
decided to switch to a monolithic rmi4_core driver that has
everything
it needs inside.

If everything is in one module, you can probably get rid of at
least part of the bus abstraction as well and just call the
functions
directly.

Agree, though that means we won't be able to switch back. In the
current
form it's overly engineered.

Well, I'm not sure I agree with that. :-)  More on that later in this
email.



Looking through the driver some more, I also find the
'rmi_driver rmi_physical_driver' concept very odd, you seem to
have a device on the bus that is actually just another
representation
of the parent device and that creates another set of devices for
the functions. Either I misunderstand what this is for, or you have

I think you have this right.


a candidate for cleanup there and once you remove it (by calling
rmi_driver_probe() instead of rmi_register_transport_device()
to oversimplify the idea), the actual probing for the function
drivers becomes much easier to do right.


Agree, that would simplify the code a lot. I just don't know how
important it is for other users of RMI4 to have a modular solution or
if
the monolithic approach is a consensus now. The modular solution is
currently disabled, but we can "always" switch back with a small
effort.

My opinion on this matter is that there is no need for the modular
functions, but others might have a different opinion.


Just to clarify, this is proposing that the rmi_physical device be 
removed and we just calling the equivalent functions from the context of 
the transport? Basically, what Bjorn suggested here last year:


https://lkml.org/lkml/2016/4/21/781

Andrew


The primary impetus for the original modular function design was to
allow phone/tablet/etc manufacturers to write their own handlers for
some functions without having to write the entire driver or hack up an
existing monolithic driver.  This simplifies engineering for the device
manufacturer a lot.

We also hoped that other peripheral manufacturers would pick up RMI4
for other sorts of sensors and devices - it is an open standard after
all.  However, this didn't 

Re: [PATCH] usb: dwc2: host: use true/false for boolean

[John Youn]

On 1/12/2017 7:53 AM, Nicholas Mc Guire wrote:
> For boolean variables true/false is preferred over 1/0 for readability.
> 
> Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
> ---
> Problem reported by scripts/coccinelle/misc/boolinit.cocci:
> ./drivers/usb/dwc2/hcd.c:5003:2-24: WARNING: Assignment of bool to 0/1
> ./drivers/usb/dwc2/hcd.c:3397:1-21: WARNING: Assignment of bool to 0/1
> ./drivers/usb/dwc2/hcd.c:3335:1-21: WARNING: Assignment of bool to 0/1
> ./drivers/usb/dwc2/hcd.c:2970:3-17: WARNING: Assignment of bool to 0/1
> ./drivers/usb/dwc2/hcd.c:2999:3-16: WARNING: Assignment of bool to 0/1
> ./drivers/usb/dwc2/hcd.c:3299:1-21: WARNING: Assignment of bool to 0/1
> 
> Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2
> 
> Patch is against 4.10-rc3 (localversion-next is next-20170112)
> 
>  drivers/usb/dwc2/hcd.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 9f66777..7467a37 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -2967,7 +2967,7 @@ static void dwc2_process_periodic_channels(struct 
> dwc2_hsotg *hsotg)
>   qspcavail = (tx_status & TXSTS_QSPCAVAIL_MASK) >>
>   TXSTS_QSPCAVAIL_SHIFT;
>   if (qspcavail == 0) {
> - no_queue_space = 1;
> + no_queue_space = true;
>   break;
>   }
>  
> @@ -2996,7 +2996,7 @@ static void dwc2_process_periodic_channels(struct 
> dwc2_hsotg *hsotg)
>   TXSTS_FSPCAVAIL_SHIFT;
>   status = dwc2_queue_transaction(hsotg, qh->channel, fspcavail);
>   if (status < 0) {
> - no_fifo_space = 1;
> + no_fifo_space = true;
>   break;
>   }
>  
> @@ -3296,7 +3296,7 @@ static void dwc2_wakeup_detected(unsigned long data)
>   dwc2_readl(hsotg->regs + HPRT0));
>  
>   dwc2_hcd_rem_wakeup(hsotg);
> - hsotg->bus_suspended = 0;
> + hsotg->bus_suspended = false;
>  
>   /* Change to L0 state */
>   hsotg->lx_state = DWC2_L0;
> @@ -3332,7 +3332,7 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
> u16 windex)
>   hprt0 |= HPRT0_SUSP;
>   dwc2_writel(hprt0, hsotg->regs + HPRT0);
>  
> - hsotg->bus_suspended = 1;
> + hsotg->bus_suspended = true;
>  
>   /*
>* If hibernation is supported, Phy clock will be suspended
> @@ -3394,7 +3394,7 @@ static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
>   hprt0 = dwc2_read_hprt0(hsotg);
>   hprt0 &= ~(HPRT0_RES | HPRT0_SUSP);
>   dwc2_writel(hprt0, hsotg->regs + HPRT0);
> - hsotg->bus_suspended = 0;
> + hsotg->bus_suspended = false;
>   spin_unlock_irqrestore(>lock, flags);
>  }
>  
> @@ -5000,7 +5000,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>   hsotg->dev->dma_mask == NULL) {
>   dev_warn(hsotg->dev,
>"dma_mask not set, disabling DMA\n");
> - hsotg->params.host_dma = 0;
> + hsotg->params.host_dma = false;
>   hsotg->params.dma_desc_enable = 0;
>   }
>  
> 

+Felipe

Acked-by: John Youn <johny...@synopsys.com>

This one also required fix-up for next.

Regards,
John

[PATCH] libnvdimm, namespace: fix pmem namespace leak, delete when size set to zero

[Dan Williams]

Commit 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple
pmem-namespaces per region") added support for establishing additional
pmem namespace beyond the seed device, similar to blk namespaces.
However, it neglected to delete the namespace when the size is set to
zero.

Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple 
pmem-namespaces per region")
Cc: 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/namespace_devs.c |   23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 6307088b375f..a518cb1b59d4 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -957,6 +957,7 @@ static ssize_t __size_store(struct device *dev, unsigned 
long long val)
 {
resource_size_t allocated = 0, available = 0;
struct nd_region *nd_region = to_nd_region(dev->parent);
+   struct nd_namespace_common *ndns = to_ndns(dev);
struct nd_mapping *nd_mapping;
struct nvdimm_drvdata *ndd;
struct nd_label_id label_id;
@@ -964,7 +965,7 @@ static ssize_t __size_store(struct device *dev, unsigned 
long long val)
u8 *uuid = NULL;
int rc, i;
 
-   if (dev->driver || to_ndns(dev)->claim)
+   if (dev->driver || ndns->claim)
return -EBUSY;
 
if (is_namespace_pmem(dev)) {
@@ -1034,20 +1035,16 @@ static ssize_t __size_store(struct device *dev, 
unsigned long long val)
 
nd_namespace_pmem_set_resource(nd_region, nspm,
val * nd_region->ndr_mappings);
-   } else if (is_namespace_blk(dev)) {
-   struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
-
-   /*
-* Try to delete the namespace if we deleted all of its
-* allocation, this is not the seed device for the
-* region, and it is not actively claimed by a btt
-* instance.
-*/
-   if (val == 0 && nd_region->ns_seed != dev
-   && !nsblk->common.claim)
-   nd_device_unregister(dev, ND_ASYNC);
}
 
+   /*
+* Try to delete the namespace if we deleted all of its
+* allocation, this is not the seed device for the region, and
+* it is not actively claimed by a btt instance.
+*/
+   if (val == 0 && nd_region->ns_seed != dev && !ndns->claim)
+   nd_device_unregister(dev, ND_ASYNC);
+
return rc;
 }
 

Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying.

[Sergey Senozhatsky]

On (01/12/17 15:18), Petr Mladek wrote:
> On Mon 2016-12-26 20:34:07, Sergey Senozhatsky wrote:
> > console_trylock() used to always forbid rescheduling; but it got changed
> > like a yaer ago.
> > 
> > the other thing is... do we really need to console_conditional_schedule()
> > from fbcon_*()? console_unlock() does cond_resched() after every line it
> > prints. wouldn't that be enough?
> > 
> > so may be we can drop some of console_conditional_schedule()
> > call sites in fbcon. or update console_conditional_schedule()
> > function to always return the current preemption value, not the
> > one we saw in console_trylock().
> 
> I was curious if it makes sense to remove
> console_conditional_schedule() completely.

I was looking at this option at some point as well.

> In practice, it never allows rescheduling when the console driver
> is called via console_unlock(). It is since 2006 and the commit
> 78944e549d36673eb62 ("vt: printk: Fix framebuffer console
> triggering might_sleep assertion"). This commit added
> that
> 
>   console_may_schedule = 0;
>
> into console_unlock() before the console drivers are called.
> 
> 
> On the other hand, it seems that the rescheduling was always
> enabled when some console operations were called via
> tty_operations. For example:
> 
> struct tty_operations con_ops
> 
>   con_ops->con_write()
>   -> do_con_write()  #calls console_lock()
>-> do_con_trol()
> -> fbcon_scroll()
>  -> fbcon_redraw_move()
>   -> console_conditional_schedule()
> 
> , where console_lock() sets console_may_schedule = 1;
> 
> 
> A complete console scroll/redraw might take a while. The rescheduling
> would make sense => IMHO, we should keep console_conditional_schedule()
> or some alternative in the console drivers as well.
> 
> But I am afraid that we could not use the automatic detection.
> We are not able to detect preemption when CONFIG_PREEMPT_COUNT

can one actually have a preemptible kernel with !CONFIG_PREEMPT_COUNT?
how? it's not even possible to change CONFIG_PREEMPT_COUNT in menuconfig.
the option is automatically selected by PREEMPT. and if PREEMPT is not
selected then _cond_resched() is just "{ rcu_all_qs(); return 0; }"

...
> We cannot put the automatic detection into console_conditional_schedule().

why can't we?


> I am going to prepare a patch for this.

I'm on it.

-ss

Re: [PATCH v4 05/15] lockdep: Make check_prev_add can use a separate stack_trace

[Byungchul Park]

On Thu, Jan 12, 2017 at 05:16:43PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 09, 2016 at 02:12:01PM +0900, Byungchul Park wrote:
> > check_prev_add() saves a stack trace of the current. But crossrelease
> > feature needs to use a separate stack trace of another context in
> > check_prev_add(). So make it use a separate stack trace instead of one
> > of the current.
> > 
> 
> So I was thinking, can't we make check_prevs_add() create the stack
> trace unconditionally but record if we used it or not, and then return
> the entries when unused. All that is serialized by graph_lock anyway and
> that way we already pass a stack into check_prev_add() so we can easily
> pass in a different one.
> 
> I think that removes a bunch of tricky and avoids all the new tricky.

Looks very good.

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

[Dave Young]

On 01/13/17 at 10:21am, Dave Young wrote:
> On 01/13/17 at 12:11am, Nicolai Stange wrote:
> > On Fri, Jan 13 2017, Dave Young wrote:
> > 
> > > On 01/12/17 at 12:54pm, Nicolai Stange wrote:
> > >> On Thu, Jan 12 2017, Dave Young wrote:
> > >> 
> > >> > -void __init efi_bgrt_init(void)
> > >> > +void __init efi_bgrt_init(struct acpi_table_header *table)
> > >> >  {
> > >> > -  acpi_status status;
> > >> >void *image;
> > >> >struct bmp_header bmp_header;
> > >> >  
> > >> >if (acpi_disabled)
> > >> >return;
> > >> >  
> > >> > -  status = acpi_get_table("BGRT", 0,
> > >> > -  (struct acpi_table_header **)_tab);
> > >> > -  if (ACPI_FAILURE(status))
> > >> > -  return;
> > >> 
> > >> 
> > >> Not sure, but wouldn't it be safer to reverse the order of this 
> > >> assignment
> > >> 
> > >> > +  bgrt_tab = *(struct acpi_table_bgrt *)table;
> > >
> > > Nicolai, sorry, I'm not sure I understand the comment, is it about above 
> > > line?
> > > Could you elaborate a bit?
> > >
> > >> 
> > >> and this length check
> > >> 
> > >
> > > I also do not get this :(
> > 
> > Ah sorry, my point is this: the length check should perhaps be made
> > before doing the assignment to bgrt_tab because otherwise, we might end
> > up reading from invalid memory.
> > 
> > I.e. if (struct acpi_table_bgrt *)table->length < sizeof(bgrt_tab), then
> > 
> >   bgrt_tab = *(struct acpi_table_bgrt *)table;
> > 
> > would read past the table's end.
> > 
> > I'm not sure whether this is a real problem though -- that is, whether
> > this read could ever hit some unmapped memory.
> 
> Nicolai, thanks for the explanation. It make sense to move it to even later
> at the end of the function.

Indeed assignment should be after the length checking, but with another
tmp variable the assignment to global var can be moved to the end to
avoid clear the image_address field..

> 
> Thanks
> Dave

Re: x86-64: Maintain 16-byte stack alignment

[Andy Lutomirski]

On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf  wrote:
> On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf  wrote:
>> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
>> >>  wrote:
>> >> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf  
>> >> > wrote:
>> >> >>
>> >> >> Just to clarify, I think you're asking if, for versions of gcc which
>> >> >> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
>> >> >> functions to ensure their stacks are 16-byte aligned.
>> >> >>
>> >> >> It's certainly possible, but I don't see how that solves the problem.
>> >> >> The stack will still be misaligned by entry code.  Or am I missing
>> >> >> something?
>> >> >
>> >> > I think the argument is that we *could* try to align things, if we
>> >> > just had some tool that actually then verified that we aren't missing
>> >> > anything.
>> >> >
>> >> > I'm not entirely happy with checking the generated code, though,
>> >> > because as Ingo says, you have a 50:50 chance of just getting it right
>> >> > by mistake. So I'd much rather have some static tool that checks
>> >> > things at a code level (ie coccinelle or sparse).
>> >>
>> >> What I meant was checking the entry code to see if it aligns stack
>> >> frames, and good luck getting sparse to do that.  Hmm, getting 16-byte
>> >> alignment for real may actually be entirely a lost cause.  After all,
>> >> I think we have some inline functions that do asm volatile ("call
>> >> ..."), and I don't see any credible way of forcing alignment short of
>> >> generating an entirely new stack frame and aligning that.
>> >
>> > Actually we already found all such cases and fixed them by forcing a new
>> > stack frame, thanks to objtool.  For example, see 55a76b59b5fe.
>>
>> What I mean is: what guarantees that the stack is properly aligned for
>> the subroutine call?  gcc promises to set up a stack frame, but does
>> it promise that rsp will be properly aligned to call a C function?
>
> Yes, I did an experiment and you're right.  I had naively assumed that
> all stack frames would be aligned.

Just to check: did you do your experiment with -mpreferred-stack-boundary=4?

--Andy

Re: kvm: use-after-free in process_srcu

[Steve Rutherford]

I'm not that familiar with the kernel's workqueues, but this seems
like the classic "callback outlives the memory it references"
use-after-free, where the process_srcu callback is outliving struct
kvm (which contains the srcu_struct). If that's right, then calling
srcu_barrier (which should wait for all of the call_srcu callbacks to
complete, which are what enqueue the process_srcu callbacks) before
cleanup_srcu_struct in kvm_destroy_vm probably fixes this.

The corresponding patch to virt/kvm/kvm_main.c looks something like:
static void kvm_destroy_vm(struct kvm *kvm)
{
...
for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++)
kvm_free_memslots(kvm, kvm->memslots[i]);
+  srcu_barrier(>irq_srcu);
cleanup_srcu_struct(>irq_srcu);
+  srcu_barrier(>srcu);
cleanup_srcu_struct(>srcu);
...


Since we don't have a repro, this obviously won't be readily testable.
I find srcu subtle enough that I don't trust my reasoning fully (in
particular, I don't trust that waiting for all of the call_srcu
callbacks to complete also waits for all of the process_srcu
callbacks). Someone else know if that's the case?

Steve

On Sun, Dec 11, 2016 at 12:49 AM, Dmitry Vyukov  wrote:
> On Sun, Dec 11, 2016 at 9:40 AM, Vegard Nossum  
> wrote:
>> On 11 December 2016 at 07:46, Dmitry Vyukov  wrote:
>>> Hello,
>>>
>>> I am getting the following use-after-free reports while running
>>> syzkaller fuzzer.
>>> On commit 318c8932ddec5c1c26a4af0f3c053784841c598e (Dec 7).
>>> Unfortunately it is not reproducible, but all reports look sane and
>>> very similar, so I would assume that it is some hard to trigger race.
>>> In all cases the use-after-free offset within struct kvm is 344 bytes.
>>> This points to srcu field, which starts at 208 with size 360 (I have
>>> some debug configs enabled).
>> [...]
>>>  [  376.024345] [] __fput+0x34e/0x910 fs/file_table.c:208
>>>  [  376.024345] [] fput+0x1a/0x20 fs/file_table.c:244
>>
>> I've been hitting what I think is a struct file refcounting bug which
>> causes similar symptoms as you have here (the struct file is freed
>> while somebody still has an active reference to it).
>>
>>>  [  376.024345] [] task_work_run+0x1a0/0x280
>>> kernel/task_work.c:116
>>>  [  376.024345] [< inline >] exit_task_work 
>>> include/linux/task_work.h:21
>>>  [  376.024345] [] do_exit+0x1842/0x2650 kernel/exit.c:828
>>>  [  376.024345] [] do_group_exit+0x14e/0x420 
>>> kernel/exit.c:932
>>>  [  376.024345] [] get_signal+0x663/0x1880
>>> kernel/signal.c:2307
>>>  [  376.024345] [] do_signal+0xc5/0x2190
>>> arch/x86/kernel/signal.c:807
>>
>> Was this or any other process by any chance killed by the OOM killer?
>> That seems to be a pattern in the crashes I've seen. If not, do you
>> know what killed this process?
>
>
> Difficult to say as I can't reproduce them.
> I've looked at the logs I have and there are no OOM kills, only some
> kvm-related messages:
>
> [  372.188708] kvm [12528]: vcpu0, guest rIP: 0xfff0
> kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x2, nop
> [  372.321334] kvm [12528]: vcpu0, guest rIP: 0xfff0 unhandled wrmsr:
> 0x0 data 0x0
> [  372.426831] kvm [12593]: vcpu512, guest rIP: 0xfff0 unhandled
> wrmsr: 0x5 data 0x200
> [  372.646417] irq bypass consumer (token 880052f74780)
> registration fails: -16
> [  373.001273] pit: kvm: requested 1676 ns i8254 timer period limited
> to 50 ns
> [  375.541449] kvm [13011]: vcpu0, guest rIP: 0x11 unhandled
> wrmsr: 0x0 data 0x2
> [  376.005387] 
> ==
> [  376.024345] BUG: KASAN: use-after-free in process_srcu+0x27a/0x280
> at addr 88005e29a418
>
> [  720.214985] kvm: vcpu 0: requested 244148 ns lapic timer period
> limited to 50 ns
> [  720.271334] kvm: vcpu 0: requested 244148 ns lapic timer period
> limited to 50 ns
> [  720.567985] kvm_vm_ioctl_assign_device: host device not found
> [  721.094589] kvm [22114]: vcpu0, guest rIP: 0x2 unhandled wrmsr: 0x6 data 
> 0x8
> [  723.829467] 
> ==
> [  723.829467] BUG: KASAN: use-after-free in process_srcu+0x27a/0x280
> at addr 88005a4d10d8
>
> Logs capture ~3-4 seconds before the crash.
> However, syzkaller test processes tend to consume lots of memory from
> time to time and cause low memory conditions.
>
> Kills are usually caused by my test driver that kills test processes
> after short time.
>
> However, I do see other assorted bugs caused by kvm that are induced
> by OOM kills:
> https://groups.google.com/d/msg/syzkaller/ytVPh93HLnI/KhZdengZBwAJ

Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300

[Gautham R Shenoy]

On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote:
> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy" 
> > 
> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some
> > functions and variables had power9 in their names while some others
> > had arch300.
> >
> 
> I would prefer power9 to arch300
>


I don't have a strong preference for arch300 vs power9, will change it
to power9 if that looks better.

--
Thanks and Regards
gautham.

Re: [PATCH] power: reset: Add MAX77620 support

[Sebastian Reichel]

Hi Thierry,

I have a few comments inline.

On Thu, Jan 12, 2017 at 05:15:07PM +0100, Thierry Reding wrote:
> The Maxim MAX77620 PMIC has the ability to power off and restart the
> system. Add a driver that supports power off (via pm_power_off()) and
> restart (via arm_pm_restart() on 32-bit and 64-bit ARM).
> 
> Based on work by Chaitanya Bandi .
> 
> Cc: Chaitanya Bandi 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/power/reset/Kconfig |   6 ++
>  drivers/power/reset/Makefile|   1 +
>  drivers/power/reset/max77620-poweroff.c | 146 
> 
>  3 files changed, 153 insertions(+)
>  create mode 100644 drivers/power/reset/max77620-poweroff.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index abeb77217a21..f0d0c20632f8 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -98,6 +98,12 @@ config POWER_RESET_IMX
> say N here or disable in dts to make sure pm_power_off never be
> overwrote wrongly by this driver.
>  
> +config POWER_RESET_MAX77620
> + bool "Maxim MAX77620 PMIC power-off driver"
> + depends on MFD_MAX77620
> + help
> +   Power off and restart support for Maxim MAX77620 PMICs.
> +
>  config POWER_RESET_MSM
>   bool "Qualcomm MSM power-off driver"
>   depends on ARCH_QCOM
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 11dae3b56ff9..74511d2f037a 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
>  obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> +obj-$(CONFIG_POWER_RESET_MAX77620) += max77620-poweroff.o
>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
>  obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> diff --git a/drivers/power/reset/max77620-poweroff.c 
> b/drivers/power/reset/max77620-poweroff.c
> new file mode 100644
> index ..4f2682d10925
> --- /dev/null
> +++ b/drivers/power/reset/max77620-poweroff.c
> @@ -0,0 +1,146 @@
> +/*
> + * Power off driver for Maxim MAX77620 device.
> + *
> + * Copyright (c) 2014-2016, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * Based on work by Chaitanya Bandi .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
> + * whether express or implied; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> +#include 
> +#endif
> +
> +struct max77620_power {
> + struct regmap *regmap;
> + struct device *dev;
> +};
> +
> +static struct max77620_power *system_power_controller = NULL;
> +
> +static void max77620_pm_power_off(void)
> +{
> + struct max77620_power *power = system_power_controller;
> + unsigned int value;
> + int err;
> +
> + if (!power)
> + return;
> +
> + /* clear power key interrupts */
> + err = regmap_read(power->regmap, MAX77620_REG_ONOFFIRQ, );
> + if (err < 0)
> + dev_err(power->dev, "failed to clear power key interrupts: 
> %d\n", err);
> +
> + /* clear RTC interrupts */
> + /*
> + err = regmap_read(power->regmap, MAX77620_REG_RTCINT, );
> + if (err < 0)
> + dev_err(power->dev, "failed to clear RTC interrupts: %d\n", 
> err);
> + */
> +
> + /* clear TOP interrupts */
> + err = regmap_read(power->regmap, MAX77620_REG_IRQTOP, );
> + if (err < 0)
> + dev_err(power->dev, "failed to clear interrupts: %d\n", err);
> +
> + err = regmap_update_bits(power->regmap, MAX77620_REG_ONOFFCNFG2,
> +  MAX77620_ONOFFCNFG2_SFT_RST_WK, 0);
> + if (err < 0)
> + dev_err(power->dev, "failed to clear SFT_RST_WK: %d\n", err);
> +
> + err = regmap_update_bits(power->regmap, MAX77620_REG_ONOFFCNFG1,
> +  MAX77620_ONOFFCNFG1_SFT_RST,
> +  MAX77620_ONOFFCNFG1_SFT_RST);
> + if (err < 0)
> + dev_err(power->dev, "failed to set SFT_RST: %d\n", err);
> +}
> +
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> +static void max77620_pm_restart(enum reboot_mode mode, const char *cmd)
> +{
> + struct max77620_power *power = system_power_controller;
> + int err;
> +

Re: [PATCH 2/3] gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip

[Keerthy]

On Friday 13 January 2017 12:36 AM, Grygorii Strashko wrote:



On 01/11/2017 08:00 PM, Keerthy wrote:



On Wednesday 11 January 2017 11:23 PM, Grygorii Strashko wrote:



On 01/10/2017 11:00 PM, Keerthy wrote:

The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization and one IRQ domain.
So, the current GPIO's  opjects structure is:

 Davinci GPIO controller
 |-  --|
 ...|--- irq_domain (hwirq [0..143])
 |-  --|

Current driver creates one chip for every 32 GPIOs in a controller.
This was a limitation earlier now there is no need for that. Hence
redesigning the driver to create one gpio chip for all the ngpio
in the controller.

|-  --|--- irq_domain (hwirq [0..143]).

The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html


nice rework.


Thanks!





Signed-off-by: Keerthy 
---

Boot tested on Davinci platform.

 drivers/gpio/gpio-davinci.c| 127
+


[...]



 #ifdef CONFIG_OF_GPIO
-chips[i].chip.of_gpio_n_cells = 2;
-chips[i].chip.of_xlate = davinci_gpio_of_xlate;
-chips[i].chip.parent = dev;
-chips[i].chip.of_node = dev->of_node;
+chips->chip.of_gpio_n_cells = 2;
+chips->chip.of_xlate = davinci_gpio_of_xlate;


I think It's not necessary to have custom .xlate() and
it can be removed, then gpiolib will assign default one
of_gpio_simple_xlate().


Okay. Can i do that as a separate patch?


I think it's ok.






+chips->chip.parent = dev;
+chips->chip.of_node = dev->of_node;
 #endif
-spin_lock_init([i].lock);
-


[...]



 irq_set_chip_and_handler_name(irq, _irqchip,
handle_simple_irq,
 "davinci_gpio");
@@ -459,6 +468,7 @@ static int davinci_gpio_irq_setup(struct
platform_device *pdev)
 struct irq_domain*irq_domain = NULL;
 const struct of_device_id *match;
 struct irq_chip *irq_chip;
+struct davinci_gpio_irq_data *irqdata[MAX_BANKED_IRQS];


You declare irqdata as array here but it has not been used anywhere
except for assignment. Could you remove this array and MAX_BANKED_IRQS
define?


irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler,
 [gpio / 32]);
 irqdata[bank]);

That is hooked as data for each bank. As there is only one controller
now and the differentiating parameters per bank is the irqdata data
structure with the registers pointer and the bank number.
This structure makes it very easy in the irq handler to identify the
register sets that need to be modified and the bank irqs.


That I understood, but why do you need array here?





Seems you can just use struct davinci_gpio_irq_data *irqdata;


why can't you use (see below):
struct davinci_gpio_irq_data *irqdata;


Understood your comment now thanks for clarifying. I will do like you 
have suggested.





 gpio_get_irq_chip_cb_t gpio_get_irq_chip;

 /*
@@ -514,10 +524,8 @@ static int davinci_gpio_irq_setup(struct
platform_device *pdev)
  * IRQs, while the others use banked IRQs, would need some setup
  * tweaks to recognize hardware which can do that.
  */


[...]



@@ -567,8 +575,19 @@ static int davinci_gpio_irq_setup(struct
platform_device *pdev)
  * gpio irqs. Pass the irq bank's corresponding controller to
  * the chained irq handler.
  */
+irqdata[bank] = devm_kzalloc(>dev,
+ sizeof(struct
+davinci_gpio_irq_data),
+ GFP_KERNEL);


irqdata = devm_kzalloc(>dev,
sizeof(struct
davinci_gpio_irq_data),
 GFP_KERNEL);



Okay.


+if (!irqdata[bank])
+return -ENOMEM;
+
+irqdata[bank]->regs = g;
+irqdata[bank]->bank_num = bank;
+irqdata[bank]->chip = chips;
+
 irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler,
- [gpio / 32]);
+ irqdata[bank]);


 irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler,
 irqdata);



I will post the new set with the above changes.



[...]

linux-next: Tree for Jan 13

[Stephen Rothwell]

Hi all,

Changes since 20170112:

The akpm-current tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3176
 4027 files changed, 124734 insertions(+), 67998 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 251 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (e28ac1fc3129 Merge tag 'xfs-for-linus-4.10-rc4-1' of 
git://git.kernel.org/pub/scm/fs/xfs/xfs-linux)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (e51d5d02f688 ARCv2: IRQ: Call entry/exit 
functions for chained handlers in MCIP)
Merging arm-current/fixes (ddc37832a134 ARM: 8634/1: hw_breakpoint: blacklist 
Scorpion CPUs)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (69973b830859 Linux 4.9)
Merging sparc/master (4bbc84ffd137 sparc: use symbolic names for tsb indexing)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (7aa4865506a2 net: thunderx: acpi: fix LMAC initialization)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (bf99b4ded5f8 tcp: fix mark propagation with 
fwmark_reflect enabled)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (60f59ce02785 rtlwifi: rtl_usb: Fix missing 
entry in USB driver's private data)
Merging mac80211/master (c38c39bf7cc0 mac80211: Fix headroom allocation when 
forwarding mesh pkt)
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (27d3eef42093 Revert "PCI: Add runtime PM support 
for PCIe ports")
Merging driver-core.current/driver-core-linus (a121103c9228 Linux 4.10-rc3)
Merging tty.current/tty-linus (802c03881f29 sysrq: attach sysrq handler 
correctly for 32-bit kernel)
Merging usb.current/usb-linus (97f9c5f211d1 Merge tag 'usb-serial-4.10-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (43aef5c2ca90 usb: gadget: Fix copy/pasted error 
message)
Merging usb-serial-fixes/usb-linus (2d5a9c72d0c4 USB: serial: ch341: fix 
control-message error handling)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (a121103c9228 Linux 4.10-rc3)
Merging char-misc.current/char-misc-linus (c8a6a09c1c61 vme: Fix wrong pointer 
utilization in ca91cx42_slave_get)
Merging input-current/for-linus (1c3415a06b10 Input: elants_i2c - avoid divide 
by 0 errors on bad touchscreen data)
Merging crypto-current/master (07825f0acd85 crypto: aesni - Fix failure when 
built-in with modular pcbc)
Merging ide/master (da095587e6be Revert "ide: Fix interface 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

Hi Shawn,

On Fri, Jan 13, 2017 at 12:03 PM, Shawn Lin  wrote:

[...]

>
>> 2) root cause, in __mmc_switch, the process is   send CMD6 --> set DDR52
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first
>> set DDR_EN to config sdhc in ddr mode,
>> and then config the sd clock again.   Here it is, after CMD6 complete, we
>> find data0 still low, which means card
>> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc,
>> DDR_EN setting becomes active only when
>> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not
>> active, but software think DDR_EN already
>> active, and set the clock again to 49.5MHz, but actually the HW out put
>> the clock as 198MHz. So there is clock glitch.
>> This is the root cause--set DDR_EN when card is still busy.
>>
>
> Make sense. But it makes me more worried about the problem.
> Does it impact other controllers if changing timing settings when
> it's in busy state? It seems very likely possible. So I'm afraid
> that we now just break hs_ddr mode for your platform but on the
> contrary your case exposes this potention risk here. Thought?
>

Yes, i got the same concern as i replied in my last email.
Not sure if any other controllers exposes the same issue
since the kernel having this issue is quite new.

Regards
Dong Aisheng

>> The following method can fix this issue
>> a) change the HW behavior, DDR_EN setting becomes active at once no matter
>> what the state of the DATA and
>> CMD line are.   This can fix this issue, but our IC guys do not prefer
>> this, this method still not safe enough.
>>
>> b) add 1ms delay before DDR_EN to wait bus idle.  But we still not know
>> whether the time 1ms is appropriate. Better
>> to poll for busy before set DDR_EN.
>>
>> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's
>> patch do.
>>
>> Hi Aisheng,
>> Correct me if anything wrong.
>>
>> My suggestion is that,  in __mmc_switch(), move the mmc_set_timing() after
>> the function mmc_poll_for_busy().
>>
>>
>> Best Regards
>> Haibo Chen
>>
>>
>>
 if that can be done. So I will give Haibo/Dong etc a couple of more
 days to investigate, before applying Shawn Lin's fix for the core.
 Hope that approach is okay with all of you?

 Kind regards
 Uffe



>>>
>>>
>>> --
>>> Best Regards
>>> Shawn Lin
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* fix rookie mistake missing the main source file and docs

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay 
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

Re: [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined

[Abylay Ospan]

FYI,

here is my tree (based on linux-next):
https://github.com/aospan/linux-next-bcm4708-edgecore-ecw7220-l/commits/master

last patches adding defconfig and dts I'm using for this device. This
files are draft yet.

2017-01-12 19:22 GMT-05:00 Florian Fainelli :
> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>
>> [   19.053195] Unable to handle kernel NULL pointer dereference at
>> virtual address 0020
>> [] (of_n_addr_cells) from []
>> (iproc_pcie_setup+0x30c/0xce0)
>>
>> this patch adds sanity check to prevent crash.
>
> Humm, how can it not be defined based on your earlier comment that you
> are using this on NSP which is Device Tree exclusively? I would agree if
> this was seen on e.g: MIPS/BCMA (47xx).
>
>>
>> Signed-off-by: Abylay Ospan 
>> ---
>>  drivers/pci/host/pcie-iproc.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>> index 3ebc025..f2836a9 100644
>> --- a/drivers/pci/host/pcie-iproc.c
>> +++ b/drivers/pci/host/pcie-iproc.c
>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct 
>> of_pci_range_parser *parser,
>>   const int na = 3, ns = 2;
>>   int rlen;
>>
>> + if (!node)
>> + return -ENOENT;
>> +
>>   parser->node = node;
>>   parser->pna = of_n_addr_cells(node);
>>   parser->np = parser->pna + na + ns;
>>
>
>
> --
> Florian



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

[PATCH] x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc()

[Len Brown]

From: Len Brown 

The Intel Denverton microserver uses a 25 MHz TSC crystal,
so we can derive its exact * TSC frequency
using CPUID and some arithmetic, eg.

TSC: 1800 MHz (2500 Hz * 216 / 3 / 100)

* 'exact' is only as good as the crystal, which should be +/- 20ppm

Signed-off-by: Len Brown 
---
 arch/x86/kernel/tsc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46b2f41f8b05..b3e397a0f29d 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -694,6 +694,7 @@ unsigned long native_calibrate_tsc(void)
crystal_khz = 24000;/* 24.0 MHz */
break;
case INTEL_FAM6_SKYLAKE_X:
+   case INTEL_FAM6_ATOM_DENVERTON:
crystal_khz = 25000;/* 25.0 MHz */
break;
case INTEL_FAM6_ATOM_GOLDMONT:
-- 
2.11.0.161.g6610af872

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

[takafumi-sslab]

Thanks for your replying.

I understand this bug is more complicated than I expected.
I classify error cases under submit_extent_page() below

A: ENOMEM error at btrfs_bio_alloc() in submit_extent_page()
I first assumed this case and sent the mail.
When bio_ret is NULL, submit_extent_page() calls btrfs_bio_alloc().
Then, btrfs_bio_alloc() may fail and submit_extent_page() returns -ENOMEM.
In this case, bio_endio() is not called and the page's writeback bit 
remains.

So, there is a need to call end_page_writeback() in the error handling.

B: errors under submit_one_bio() of submit_extent_page()
Errors that occur under submit_one_bio() handles at bio_endio(), and 
bio_endio() would call end_page_writeback().


Therefore, as you mentioned in the last mail, simply adding 
end_page_writeback() like my last email and commit 55e3bd2e0c2e1 can 
conflict in the case of B.
To avoid such conflict, one easy solution is adding PageWriteback() 
check too.


How do you think of this solution?

Sincerely,

On 2016/12/22 15:20, Liu Bo wrote:

On Fri, Dec 16, 2016 at 03:41:50PM +0900, Takafumi Kubota wrote:

This is actually inspired by Filipe's patch(55e3bd2e0c2e1).

When submit_extent_page() in __extent_writepage_io() fails,
Btrfs misses clearing a writeback bit of the failed page.
This causes the false under-writeback page.
Then, another sync task hangs in filemap_fdatawait_range(),
because it waits the false under-writeback page.

CPU0CPU1

__extent_writepage_io()
   ret = submit_extent_page() // fail

   if (ret)
 SetPageError(page)
 // miss clearing the writeback bit

 sync()
   ...
   filemap_fdatawait_range()
 wait_on_page_writeback(page);
 // wait the false under-writeback page

Signed-off-by: Takafumi Kubota 
---
  fs/btrfs/extent_io.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e67723..ef9793b 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3443,8 +3443,10 @@ static noinline_for_stack int 
__extent_writepage_io(struct inode *inode,
 bdev, >bio, max_nr,
 end_bio_extent_writepage,
 0, 0, 0, false);
-   if (ret)
+   if (ret) {
SetPageError(page);
+   end_page_writeback(page);
+   }

OK...this could be complex as we don't know which part in
submit_extent_page gets the error, if the page has been added into bio
and bio_end would call end_page_writepage(page) as well, so whichever
comes later, the BUG() in end_page_writeback() would complain.

Looks like commit 55e3bd2e0c2e1 also has the same problem although I
gave it my reviewed-by.

Thanks,

-liubo

  
  		cur = cur + iosize;

pg_offset += iosize;
--
1.9.3

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


--
Keio University
System Software Laboratory
Takafumi Kubota
takafumi.kubota1...@sslab.ics.keio.jp

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Khalid Aziz]

On 01/12/2017 10:53 AM, Dave Hansen wrote:

On 01/12/2017 08:50 AM, Khalid Aziz wrote:

2. Any shared page that has ADI protection enabled on it, must stay ADI
protected across all processes sharing it.


Is that true?

What happens if a page with ADI tags set is accessed via a PTE without
the ADI enablement bit set?


ADI protection applies across all processes in terms of all of them must 
use the same tag to access the shared memory, but if a process accesses 
a shared page with TTE.mcde bit cleared, access will be granted.





COW creates an intersection of the two. It creates a new copy of the
shared data. It is a new data page and hence the process creating it
must be the one responsible for enabling ADI protection on it.


Do you mean that the application must be responsible?  Or the kernel
running in the context of the new process must be responsible?


It is also a copy of what was ADI protected data, so should it
inherit the protection instead?


I think the COW'd copy must inherit the VMA bit, the PTE bits, and the
tags on the cachelines.


I misspoke earlier. I had misinterpreted the results of test I ran.
Changing the tag on shared memory is allowed by memory controller. The
requirement is every one sharing the page must switch to the new tag or
else they get SIGSEGV.


I asked this in the last mail, but I guess I'll ask it again.  Please
answer this directly.

If we require that everyone coordinate their tags on the backing
physical memory, and we allow a lower-privileged program to access the
same data as a more-privileged one, then the lower-privilege app can
cause arbitrary crashes in the privileged application.

For instance, say sudo mmap()'s /etc/passwd and uses ADI tags to protect
the mapping.  Couldn't any other app in the system prevent sudo from
working?

How can we *EVER* allow tags to be set on non-writable mappings?


I understand your quetion better now. That is a very valid concern. 
Using ADI tags to prevent an unauthorized process from just reading data 
in memory, say an in-memory copy of database, is one of the use cases 
for ADI. This means there is a reasonable case to allow enabling ADI and 
setting tags even on non-writable mappings. On the other hand, if an 
unauthorized process manages to map the right memory pages in its 
address space, it can read them any way by not setting TTE.mcd.


Userspace app can set tag on any memory it has mapped in without 
requiring assistance from kernel. Can this problem be solved by not 
allowing setting TTE.mcd on non-writable mappings? Doesn't the same 
problem occur on writable mappings? If a privileged process mmap()'s a 
writable file with MAP_SHARED, enables ADI and sets tag on the mmap'd 
memory region, then another lower privilege process mmap's the same file 
writable (assuming file permissions allow it to), enables ADI and sets a 
different tag on it, the privileged process would get SIGSEGV when it 
tries to access the mmap'd file. Right?


Thanks,
Khalid

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

[Kefeng Wang]

On 2017/1/12 3:48, Jason Uy wrote:
> In the most common use case, the Synopsys DW UART driver does not
> set the set_termios callback function.  This prevents UPSTAT_AUTOCTS
> from being set when the UART flag CRTSCTS is set.  As a result, the
> driver will use software flow control as opposed to hardware flow
> control.
> 
> To fix the problem, the set_termios callback function is set to the
> DW specific function.  The logic to set UPSTAT_AUTOCTS is moved so
> that any clock error will not affect setting the hardware flow
> control.
> 
> Reviewed-by: Scott Branden 
> Reviewed-by: Ray Jui 
> Signed-off-by: Jason Uy 

Reviewed-by: Kefeng Wang 

> ---
>  drivers/tty/serial/8250/8250_dw.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_dw.c 
> b/drivers/tty/serial/8250/8250_dw.c
> index c89fafc..c89ae45 100644
> --- a/drivers/tty/serial/8250/8250_dw.c
> +++ b/drivers/tty/serial/8250/8250_dw.c
> @@ -248,11 +248,11 @@ static void dw8250_set_termios(struct uart_port *p, 
> struct ktermios *termios,
>   if (!ret)
>   p->uartclk = rate;
>  
> +out:
>   p->status &= ~UPSTAT_AUTOCTS;
>   if (termios->c_cflag & CRTSCTS)
>   p->status |= UPSTAT_AUTOCTS;
>  
> -out:
>   serial8250_do_set_termios(p, termios, old);
>  }
>  
> @@ -326,13 +326,11 @@ static void dw8250_quirks(struct uart_port *p, struct 
> dw8250_data *data)
>   p->serial_in = dw8250_serial_in32;
>   data->uart_16550_compatible = true;
>   }
> - p->set_termios = dw8250_set_termios;
>   }
>  
>   /* Platforms with iDMA */
>   if (platform_get_resource_byname(to_platform_device(p->dev),
>IORESOURCE_MEM, "lpss_priv")) {
> - p->set_termios = dw8250_set_termios;
>   data->dma.rx_param = p->dev->parent;
>   data->dma.tx_param = p->dev->parent;
>   data->dma.fn = dw8250_idma_filter;
> @@ -414,6 +412,7 @@ static int dw8250_probe(struct platform_device *pdev)
>   p->serial_in= dw8250_serial_in;
>   p->serial_out   = dw8250_serial_out;
>   p->set_ldisc= dw8250_set_ldisc;
> + p->set_termios  = dw8250_set_termios;
>  
>   p->membase = devm_ioremap(dev, regs->start, resource_size(regs));
>   if (!p->membase)
> 

Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree

[Minchan Kim]

Hello,

On Thu, Jan 12, 2017 at 10:10:17AM +0100, Michal Hocko wrote:
> On Thu 12-01-17 17:48:13, Minchan Kim wrote:
> > On Thu, Jan 12, 2017 at 09:15:54AM +0100, Michal Hocko wrote:
> > > On Thu 12-01-17 14:12:47, Minchan Kim wrote:
> > > > Hello,
> > > > 
> > > > On Wed, Jan 11, 2017 at 04:52:39PM +0100, Michal Hocko wrote:
> > > > > On Wed 11-01-17 08:52:50, Minchan Kim wrote:
> > > > > [...]
> > > > > > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct
> > > > > > >   if (!file && !total_swap_pages)
> > > > > > >   return false;
> > > > > > >  
> > > > > > > - inactive = lruvec_lru_size(lruvec, file * LRU_FILE);
> > > > > > > - active = lruvec_lru_size(lruvec, file * LRU_FILE + LRU_ACTIVE);
> > > > > > > + total_inactive = inactive = lruvec_lru_size(lruvec, file * 
> > > > > > > LRU_FILE);
> > > > > > > + total_active = active = lruvec_lru_size(lruvec, file * LRU_FILE 
> > > > > > > + LRU_ACTIVE);
> > > > > > >  
> > > > > > 
> > > > > > the decision of deactivating is based on eligible zone's LRU size,
> > > > > > not whole zone so why should we need to get a trace of all zones's 
> > > > > > LRU?
> > > > > 
> > > > > Strictly speaking, the total_ counters are not necessary for making 
> > > > > the
> > > > > decision. I found reporting those numbers useful regardless because 
> > > > > this
> > > > > will give us also an information how large is the eligible portion of
> > > > > the LRU list. We do not have any other tracepoint which would report
> > > > > that.
> > > > 
> > > > The patch doesn't say anything why it's useful. Could you tell why it's
> > > > useful and inactive_list_is_low should be right place?
> > > > 
> > > > Don't get me wrong, please. I don't want to bother you.
> > > > I really don't want to add random stuff although it's tracepoint for
> > > > debugging.
> > > 
> > > This doesn't sounds random to me. We simply do not have a full picture
> > > on 32b systems without this information. Especially when memcgs are
> > > involved and global numbers spread over different LRUs.
> > 
> > Could you elaborate it?
> 
> The problem with 32b systems is that you only can consider a part of the
> LRU for the lowmem requests. While we have global counters to see how
> much lowmem inactive/active pages we have, those get distributed to
> memcg LRUs. And that distribution is impossible to guess. So my thinking
> is that it can become a real head scratcher to realize why certain
> active LRUs are aged while others are not. This was the case when I was
> debugging the last issue which triggered all this. All of the sudden I
> have seen many invocations when inactive and active were zero which
> sounded weird, until I realized that those are memcg's lruvec which is
> what total numbers told me...

Hmm, it seems I miss something. AFAIU, what you need is just memcg
identifier, not all lru size. If it isn't, please tell more detail
usecase of all lru size in that particular tracepoint.

> 
> Later on I would like to add an memcg identifier to the vmscan
> tracepoints but I didn't get there yet.
>  
> > "
> > Currently we have tracepoints for both active and inactive LRU lists
> > reclaim but we do not have any which would tell us why we we decided to
> > age the active list.  Without that it is quite hard to diagnose
> > active/inactive lists balancing.  Add mm_vmscan_inactive_list_is_low
> > tracepoint to tell us this information.
> > "
> > 
> > Your description says "why we decided to age the active list".
> > So, what's needed?
> > 
> > >  
> > > > > [...]
> > > > > > > @@ -2223,7 +2228,7 @@ static void get_scan_count(struct lruvec
> > > > > > >* lruvec even if it has plenty of old anonymous pages unless 
> > > > > > > the
> > > > > > >* system is under heavy pressure.
> > > > > > >*/
> > > > > > > - if (!inactive_list_is_low(lruvec, true, sc) &&
> > > > > > > + if (!inactive_list_is_low(lruvec, true, sc, false) &&
> > > > > > 
> > > > > > Hmm, I was curious why you added trace boolean arguement and found 
> > > > > > it here.
> > > > > > Yes, here is not related to deactivation directly but couldn't we 
> > > > > > help to
> > > > > > trace it unconditionally?
> > > > > 
> > > > > I've had it like that when I was debugging the mentioned bug and found
> > > > > it a bit disturbing. It generated more output than I would like and it
> > > > > wasn't really clear from which code path  this has been called from.
> > > > 
> > > > Indeed.
> > > > 
> > > > Personally, I want to move inactive_list_is_low in shrink_active_list
> > > > and shrink_active_list calls inactive_list_is_low(, true),
> > > > unconditionally so that it can make code simple/clear but cannot remove
> > > > trace boolean variable , which what I want. So, it's okay if you love
> > > > your version.
> > > 
> > > I am not sure I am following. Why is the additional parameter a problem?
> > 
> > Well, to me, it's not a elegance. Is it? If we need such boolean variable
> > to control show the trace, it 

RE: [PATCH v8 1/1] crypto: add virtio-crypto driver

[Gonglei (Arei)]

> 
> On Thu, Jan 12, 2017 at 03:10:25PM +0100, Christian Borntraeger wrote:
> > On 01/10/2017 01:56 PM, Christian Borntraeger wrote:
> > > On 01/10/2017 01:36 PM, Gonglei (Arei) wrote:
> > >> Hi,
> > >>
> > >>>
> > >>> On 12/15/2016 03:03 AM, Gonglei wrote:
> > >>> [...]
> >  +
> >  +static struct crypto_alg virtio_crypto_algs[] = { {
> >  +  .cra_name = "cbc(aes)",
> >  +  .cra_driver_name = "virtio_crypto_aes_cbc",
> >  +  .cra_priority = 501,
> > >>>
> > >>>
> > >>> This is still higher than the hardware-accelerators (like intel aesni 
> > >>> or the
> > >>> s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported
> by the
> > >>> hardware virtualization and available to the guests. I do not see a way
> how
> > >>> virtio
> > >>> crypto can be faster than that (in the end it might be cpacf/aesni +
> overhead)
> > >>> instead it will very likely be slower.
> > >>> So we should use a number that is higher than software implementations
> but
> > >>> lower than the hw ones.
> > >>>
> > >>> Just grepping around, the software ones seem be be around 100 and the
> > >>> hardware
> > >>> ones around 200-400. So why was 150 not enough?
> > >>>
> > >> I didn't find a documentation about how we use the priority, and I 
> > >> assumed
> > >> people use virtio-crypto will configure hardware accelerators in the
> > >> host. So I choosed the number which bigger than aesni's priority.
> > >
> > > Yes, but the aesni driver will only bind if there is HW support in the 
> > > guest.
> > > And if aesni is available in the guest (or the s390 aes function from 
> > > cpacf)
> > > it will always be faster than the same in the host via virtio.So your 
> > > priority
> > > should be smaller.
> >
> >
> > any opinion on this?
> 
> Going forward, we might add an emulated aesni device and that might
> become slower than virtio. OTOH if or when this happens, we can solve it
> by adding a priority or a feature flag to virtio to raise its priority.
> 
> So I think I agree with Christian here, let's lower the priority.
> Gonglei, could you send a patch like this?
> 
OK, will do.

Thanks,
-Gonglei

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Finn Thain]

On Wed, 11 Jan 2017, Michael Schmitz wrote:

> What is still correct is that the IDE driver does use the interrupt 
> only, not the ST-DMA chip. And a single IDE interrupt can be correctly 
> assigned to IDE by looking at the status register.
> 
> With the SCSI (and IIRC also floppy) interrupts, we don't have direct 
> access to the status registers without disturbing the state of the DMA 
> though. Unless we know for definite that either chips have raised the 
> interrupt (and DMA ops are in flight), we must not touch the DMA chip at 
> all.
> 
> The case I'm worried about is both IDE and SCSI raising an interrupt. We 
> don't currently mask the IDE/ST-DMA interrupt so a stacked interrupt 
> must be processed in the same pass as the initial interrupt or it will 
> get dropped. We'd have to peek at the DMA registers to check the SCSI or 
> floppy interrupt status, and we just can't safely do that. So races of 
> this kind are currently prevented by including IDE in the IRQ locking 
> process.
> 
> Whether it's possible to mask the interrupt, do one pass, unmask and 
> process the second interrupt I don't know.

Would that require handling the SCSI DMA interrupt in the first pass? Or 
handling IDE first, and ensuring that the IDE handler does not access 
ST-DMA registers? What about FDC?

The atari_scsi handler accesses the ST-DMA registers; it can do so because 
it knows that any DMA must have completed -- it can infer this because a 
simultaneous pending interrupt from FDC or IDE is impossible due to 
stdma_lock().

Your suggestion would seem to allow other pending interrupts, hence the 
atari_scsi interrupt handler logic has to be tossed out. What logic would 
replace it?

If all else fails, perhaps we could inhibit DMA entirely when the new ATA 
driver is loaded. Then we can just dispatch the ST-DMA irq like a shared 
irq. I'm sure that atari_scsi can work without DMA. No idea about the FDC 
driver though (ataflop.c).

Another solution would be to dedicate the DMA function to atari_scsi, and 
then mask the FDC and IDE interrupts during each DMA transfer. But once 
again, this would mean changing the FDC driver to eliminate DMA, if that 
is possible. From the schematic it looks the the FDC chip, "AJAX", is 
another custom ...
http://dev-docs.atariforge.org/files/Falcon030_Schematic.pdf

Unfortunately my grasp of the ST hardware reflects my inability to read 
German; those who can may want to take a look at "ATARI Profibuch 
ST-STE-TT.pdf".

-- 

> Maybe Andreas does?
> 
> Cheers,
> 
>   Michael
> 
> 
> > it should be okay to use IDE at the same time as SCSI/Floppy which is 
> > what the new driver does (the old one is serialized operations by 
> > ST-DMA related IRQ handling magic).
> >
> > Also the comment itself may need some fixups as on Falcon it is SCSI 
> > not ACSI (according to the earlier comment in same file) and the old 
> > IDE host driver name is not falhd.c but falconide.c.
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R Institute Poland
> > Samsung Electronics
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions

[Daniel Kurtz]

According to [0], the contribution field for each cooling-device express
their relative power efficiency. Higher weights express higher power
efficiency.  Weighting is relative such that if each cooling device has a
weight of 1 they are considered equal. This is particularly useful in
heterogeneous systems where two cooling devices may perform the same kind
of compute, but with different efficiency.

[0] Documentation/thermal/power_allocator.txt

According to Mediatek IC designer, the power efficiency ratio between the
LITTLE core cluster (cooling-device cpu0) and big core cluster
(cooling-device cpu1) is around 3:1 (3072:1024).

Signed-off-by: Daniel Kurtz 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e702771f5c..9a3b0d20f7a8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -182,12 +182,12 @@
map@0 {
trip = <>;
cooling-device = < 0 0>;
-   contribution = <1024>;
+   contribution = <3072>;
};
map@1 {
trip = <>;
cooling-device = < 0 0>;
-   contribution = <2048>;
+   contribution = <1024>;
};
};
};
-- 
2.11.0.390.gc69c2f50cf-goog

Re: x86-64: Maintain 16-byte stack alignment

[Josh Poimboeuf]

On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf  wrote:
> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> >>  wrote:
> >> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf  
> >> > wrote:
> >> >>
> >> >> Just to clarify, I think you're asking if, for versions of gcc which
> >> >> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
> >> >> functions to ensure their stacks are 16-byte aligned.
> >> >>
> >> >> It's certainly possible, but I don't see how that solves the problem.
> >> >> The stack will still be misaligned by entry code.  Or am I missing
> >> >> something?
> >> >
> >> > I think the argument is that we *could* try to align things, if we
> >> > just had some tool that actually then verified that we aren't missing
> >> > anything.
> >> >
> >> > I'm not entirely happy with checking the generated code, though,
> >> > because as Ingo says, you have a 50:50 chance of just getting it right
> >> > by mistake. So I'd much rather have some static tool that checks
> >> > things at a code level (ie coccinelle or sparse).
> >>
> >> What I meant was checking the entry code to see if it aligns stack
> >> frames, and good luck getting sparse to do that.  Hmm, getting 16-byte
> >> alignment for real may actually be entirely a lost cause.  After all,
> >> I think we have some inline functions that do asm volatile ("call
> >> ..."), and I don't see any credible way of forcing alignment short of
> >> generating an entirely new stack frame and aligning that.
> >
> > Actually we already found all such cases and fixed them by forcing a new
> > stack frame, thanks to objtool.  For example, see 55a76b59b5fe.
> 
> What I mean is: what guarantees that the stack is properly aligned for
> the subroutine call?  gcc promises to set up a stack frame, but does
> it promise that rsp will be properly aligned to call a C function?

Yes, I did an experiment and you're right.  I had naively assumed that
all stack frames would be aligned.

-- 
Josh

RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, January 13, 2017 10:11 AM
> To: Ulf Hansson ; Clemens Gruber
> 
> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
> ; Adrian Hunter ; A.S.
> Dong ; linux-kernel@vger.kernel.org; Bough Chen
> ; Gary Bisson ;
> Fabio Estevam ; Shawn Guo 
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/13 0:51, Ulf Hansson wrote:
> > + Haibo, Gary, Fabio, Shawn Gou
> >
> > On 6 January 2017 at 16:56, Clemens Gruber
>  wrote:
> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
>  Hi,
> 
>  with the current mainline 4.10-rc2 kernel, I can no longer boot
>  from the eMMC on my i.MX6Q board.
> 
>  Details:
>  The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
>  supports eMMC 4.41 features and we did not implement voltage
>  switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
>  of the mmc-ddr or mmc-hs
>  options) to the device tree. The bus-width is 8.
> 
>  With 4.9 the board booted fine, now with the current mainline 4.10
>  tree, I get the following (repeating) errors at boot:
> 
>  [4.326834] Waiting for root device /dev/mmcblk0p2...
>  [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>  [   14.569619] sdhci: === REGISTER DUMP
> (mmc0)===
>  [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>  [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>  [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>  [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>  [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>  [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>  [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>  [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>  [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>  [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>  [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>
> >>> it shows you always fail to get resp of sending status within the
> >>> expected period of time.
> >>>
> >>>
>  [   14.639682] sdhci: Host ctl2: 0x
>  [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>  [   14.649447] sdhci:
> ===
> 
>  This repeats a few times, then more information is shown at the bottom:
> 
>  [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>  [   86.899615] sdhci: === REGISTER DUMP
> (mmc0)===
>  [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>  [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>  [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>  [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>  [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>  [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>  [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>  [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>  [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>  [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>  [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>  [   86.969668] sdhci: Host ctl2: 0x
>  [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>  [   86.979433] sdhci:
> ===
>  [   86.986356] mmc0: switch to bus width 8 ddr failed
>  [   86.991163] mmc0: error -110 whilst initialising MMC card
>  [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> 
>  --
> 
>  After looking through the latest commits to mmc/core, I found the
>  culprit:
>  Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:
> Update
>  CMD13 polling policy when switch to HS DDR mode")
> 
>  Reverting it fixes the problem. But I am unsure if that's the right
>  course of action?
> 
>  Feel free to send me patches for testing!
> >>>
> >>> By looking the changes itself, it should be good from the view of spec.
> >>> Maybe you could try the patch below, but don't beat me if that
> >>> doesn't help at all. :)
> >>>
> >>> --- a/drivers/mmc/core/mmc.c
> >>> +++ b/drivers/mmc/core/mmc.c
> >>> @@ -1074,7 +1074,7 @@ 

[RESEND PATCH] usb: hcd: initialize hcd->flags to 0 when rm hcd

[William Wu]

From: William wu 

On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.

If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.

[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus 
number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, 
disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@fe80: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [] dump_backtrace+0x0/0x160
[173.603596] [] show_stack+0x20/0x28
[173.603623] [] dump_stack+0x90/0xb0
[173.603650] [] __report_bad_irq+0x48/0xe8
[173.603674] [] note_interrupt+0x1e8/0x28c
[173.603698] [] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [] handle_irq_event+0x4c/0x7c
[173.603748] [] handle_fasteoi_irq+0xb4/0x124
[173.603777] [] generic_handle_irq+0x30/0x44
[173.603804] [] __handle_domain_irq+0x90/0xbc
[173.603827] [] gic_handle_irq+0xcc/0x188
...
[173.604500] [] el1_irq+0x80/0xf8
[173.604530] [] cpu_startup_entry+0x38/0x3cc
[173.604558] [] rest_init+0x8c/0x94
[173.604585] [] start_kernel+0x3d0/0x3fc
[173.604607] [<00b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [] usb_hcd_irq
[173.604673] Disabling IRQ #228

Signed-off-by: William wu 
Acked-by: Roger Quadros 
---
 drivers/usb/core/hcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 479e223..612fab6 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -3017,6 +3017,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
 
usb_put_invalidate_rhdev(hcd);
+   hcd->flags = 0;
 }
 EXPORT_SYMBOL_GPL(usb_remove_hcd);
 
-- 
2.7.4

Re: Problem on SCTP

[Sun Paul]

Packet to SERVER (from router to SERVER)[ Source IP: 192.168.206.83,
Destination IP: 192.168.206.66. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]



No. Time  SourceSPort
Destination   Protocol DPort  Length Info
  DSCP
  2 2017-01-06 08:52:49.662321192.168.206.8350001
192.168.206.66SCTP 3868   98 INIT
  CS0

Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan  6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
 ..0.     = LG bit: Globally unique
address (factory default)
 ...0     = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
 ..0.     = LG bit: Globally unique
address (factory default)
 ...0     = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100  = Version: 4
 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
 00.. = Differentiated Services Codepoint: Default (0)
 ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x (0)
Flags: 0x02 (Don't Fragment)
0...  = Reserved bit: Not set
.1..  = Don't fragment: Set
..0.  = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)

On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul  wrote:
> Hi All
>
> below is the packet trace in text format.
>
>
> Packet received (From client to router)  [ Source IP: 192.168.206.83,
> Destination IP: 192.168.206.65. the IPv4 address parameter is
> 192.168.206.83 and 192.168.1.83 ]
> ==
>
> No. Time  SourceSPort
> Destination   Protocol DPort  Length Info
>   DSCP
>   1 2017-01-06 08:52:49.662142192.168.206.8350001
> 192.168.206.65SCTP 3868   98 INIT
>   CS0
>
> Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
> Encapsulation type: Ethernet (1)
> Arrival Time: Jan  6, 2017 16:52:49.662142000 Malay Peninsula Standard 
> Time
> [Time shift for this packet: 0.0 seconds]
> Epoch Time: 1483692769.662142000 seconds
> [Time delta from previous captured frame: 0.0 seconds]
> [Time delta from previous displayed frame: 0.0 seconds]
> [Time since reference or first frame: 0.0 seconds]
> Frame Number: 1
> Frame Length: 98 bytes (784 bits)
> Capture Length: 98 bytes (784 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: eth:ethertype:ip:sctp]
> Ethernet II, Src: RealtekU_54:81:87 (52:54:00:54:81:87), Dst:
> Vmware_81:41:6b (00:50:56:81:41:6b)
> Destination: Vmware_81:41:6b (00:50:56:81:41:6b)
> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>  ..0.     = LG bit: Globally unique
> address (factory default)
>  ...0     = IG bit: Individual address (unicast)
> Source: RealtekU_54:81:87 (52:54:00:54:81:87)
> Address: RealtekU_54:81:87 (52:54:00:54:81:87)
>  ..1.     = LG bit: Locally administered
> address (this is NOT the factory default)
>  ...0     = IG bit: Individual address 

Re: Problem on SCTP

[Sun Paul]

Packet to SERVER (From router to SERVER)  [ Source IP: 192.168.206.83,
Destination IP: 192.168.206.66. the IPv4 address parameter is
192.168.206.83 and 192.168.1.83 ]



No. Time  SourceSPort
Destination   Protocol DPort  Length Info
  DSCP
  2 2017-01-06 08:52:49.662321192.168.206.8350001
192.168.206.66SCTP 3868   98 INIT
  CS0

Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan  6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1483692769.662321000 seconds
[Time delta from previous captured frame: 0.000179000 seconds]
[Time delta from previous displayed frame: 0.000179000 seconds]
[Time since reference or first frame: 0.000179000 seconds]
Frame Number: 2
Frame Length: 98 bytes (784 bits)
Capture Length: 98 bytes (784 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:sctp]
Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
 ..0.     = LG bit: Globally unique
address (factory default)
 ...0     = IG bit: Individual address (unicast)
Source: Vmware_81:41:6b (00:50:56:81:41:6b)
Address: Vmware_81:41:6b (00:50:56:81:41:6b)
 ..0.     = LG bit: Globally unique
address (factory default)
 ...0     = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
0100  = Version: 4
 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
 00.. = Differentiated Services Codepoint: Default (0)
 ..10 = Explicit Congestion Notification: ECN-Capable
Transport codepoint '10' (2)
Total Length: 84
Identification: 0x (0)
Flags: 0x02 (Don't Fragment)
0...  = Reserved bit: Not set
.1..  = Don't fragment: Set
..0.  = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: SCTP (132)
Header checksum: 0x1d3d [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.206.83
Destination: 192.168.206.66
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
Port: 3868 (3868)
Source port: 50001
Destination port: 3868
Verification tag: 0x
[Assocation index: 0]
Checksum: 0xa9a86d3f (not verified)

INIT chunk (Outbound streams: 3000, inbound streams: 3000)
Chunk type: INIT (1)
0...  = Bit: Stop processing of the packet
.0..  = Bit: Do not report
Chunk flags: 0x00
Chunk length: 52
Initiate tag: 0xe79f40cb
Advertised receiver window credit (a_rwnd): 62464
Number of outbound streams: 3000
Number of inbound streams: 3000
Initial TSN: 176990880
IPv4 address parameter (Address: 192.168.206.83)
Parameter type: IPv4 address (0x0005)
0...    = Bit: Stop processing of chunk
.0..    = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.206.83
IPv4 address parameter (Address: 192.168.1.83)
Parameter type: IPv4 address (0x0005)
0...    = Bit: Stop processing of chunk
.0..    = Bit: Do not report
Parameter length: 8
IP Version 4 address: 192.168.1.83
Supported address types parameter (Supported types: IPv6, IPv4)
Parameter type: Supported address types (0x000c)
0...    = Bit: Stop processing of chunk
.0..    = Bit: Do not report
Parameter length: 8
Supported address type: IPv6 address (6)
Supported address type: IPv4 address (5)
ECN parameter
Parameter type: ECN (0x8000)
1...    = Bit: Skip parameter and continue
processing of the chunk
.0..    = Bit: Do not report
Parameter length: 4
Forward TSN supported parameter
Parameter type: Forward TSN supported (0xc000)
1...    = Bit: Skip parameter and continue
processing of the chunk
.1..    = Bit: Do report
Parameter length: 4

On Fri, Jan 13, 2017 at 11:27 AM, Sun Paul 

Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300

[Oliver O'Halloran]

On Fri, Jan 13, 2017 at 2:44 PM, Gautham R Shenoy
 wrote:
> On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote:
>> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
>> > From: "Gautham R. Shenoy" 
>> >
>> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some
>> > functions and variables had power9 in their names while some others
>> > had arch300.
>> >
>>
>> I would prefer power9 to arch300
>>
>
>
> I don't have a strong preference for arch300 vs power9, will change it
> to power9 if that looks better.

Personally I think we should be as descriptive as possible and use
power_9_arch_300_the_bikeshed_is_red_dammit.

Oliver

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/13 11:12, Bough Chen wrote:

-Original Message-
From: Shawn Lin [mailto:shawn@rock-chips.com]
Sent: Friday, January 13, 2017 10:11 AM
To: Ulf Hansson ; Clemens Gruber

Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
; Adrian Hunter ; A.S.
Dong ; linux-kernel@vger.kernel.org; Bough Chen
; Gary Bisson ;
Fabio Estevam ; Shawn Guo 
Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed

On 2017/1/13 0:51, Ulf Hansson wrote:

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber

 wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot
from the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
supports eMMC 4.41 features and we did not implement voltage
switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10
tree, I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP

(mmc0)===

[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci:

===


This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP

(mmc0)===

[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci:

===

[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:

Update

CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that
doesn't help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card

*card)

   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n", @@
-1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = 

Re: getting oom/stalls for ltp test cpuset01 with latest/4.9 kernel

[Ganapatrao Kulkarni]

On Thu, Jan 12, 2017 at 4:40 PM, Vlastimil Babka  wrote:
> On 01/11/2017 05:46 PM, Michal Hocko wrote:
>>
>> On Wed 11-01-17 21:52:29, Ganapatrao Kulkarni wrote:
>>
>>> [ 2398.169391] Node 1 Normal: 951*4kB (UME) 1308*8kB (UME) 1034*16kB
>>> (UME) 742*32kB (UME) 581*64kB (UME) 450*128kB (UME) 362*256kB (UME)
>>> 275*512kB (ME) 189*1024kB (UM) 117*2048kB (ME) 2742*4096kB (M) = 12047196kB
>>
>>
>> Most of the memblocks are marked Unmovable (except for the 4MB bloks)
>
>
> No, UME here means that e.g. 4kB blocks are available on unmovable, movable
> and reclaimable lists.
>
>> which shouldn't matter because we can fallback to unmovable blocks for
>> movable allocation AFAIR so we shouldn't really fail the request. I
>> really fail to see what is going on there but it smells really
>> suspicious.
>
>
> Perhaps there's something wrong with zonelists and we are skipping the Node
> 1 Normal zone. Or there's some race with cpuset operations (but can't see
> how).
>
> The question is, how reproducible is this? And what exactly the test
> cpuset01 does? Is it doing multiple things in a loop that could be reduced
> to a single testcase?

IIUC, this test does node change to  cpuset.mems in loop in parent
process in loop and child processes(equal to no of cpus) keeps on
allocation and freeing
10 pages till the execution time is over.
more details at
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/cpuset/cpuset01.c

thanks
Ganapat

>
>

Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature

[Byungchul Park]

On Fri, Jan 13, 2017 at 12:39:04PM +0800, Lai Jiangshan wrote:
> > +
> > +/*
> > + * No contention. Irq disable is only required.
> > + */
> > +static int same_context_plock(struct pend_lock *plock)
> > +{
> > +   struct task_struct *curr = current;
> > +   int cpu = smp_processor_id();
> > +
> > +   /* In the case of hardirq context */
> > +   if (curr->hardirq_context) {
> > +   if (plock->hardirq_id != per_cpu(hardirq_id, cpu) ||
> > +   plock->hardirq_context != curr->hardirq_context)
> > +   return 0;
> > +   /* In the case of softriq context */
> > +   } else if (curr->softirq_context) {
> > +   if (plock->softirq_id != per_cpu(softirq_id, cpu) ||
> > +   plock->softirq_context != curr->softirq_context)
> > +   return 0;
> > +   /* In the case of process context */
> > +   } else {
> > +   if (plock->hardirq_context != 0 ||
> > +   plock->softirq_context != 0)
> > +   return 0;
> > +   }
> > +   return 1;
> > +}
> >
> 
> I have not read the code yet...
> but different work functions in workqueues are different "contexts" IMO,
> does commit operation work well in work functions?

Hello,

Yes. I also think it should be considered since each work might be run in
different context from another, thanks to concurrency support of workqueue.
I will reflect it.

Thanks,
Byungchul

Re: [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined

[Abylay Ospan]

Hi Florian,

> Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
> should fill in of_nodes accordingly, if not, that's a bug that must be
> fixed at the BCMA layer.

yes, this is a source of the problem. Devices allocated in
'bcma_bus_scan' but of_node doesn't assigned.
Is some code missing in drivers/bcma/ which should assign of_node ?

I can suggest following "hacky" patch for this (works for me):

Author: Abylay Ospan 
Date:   Fri Jan 13 07:24:13 2017 +0300

bcma: force assign 'of_node' for devices on the bus

prevent other code to fail if no 'of_node' defined

Signed-off-by: Abylay Ospan 

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 2c1798e..4fe1c92 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -301,6 +301,11 @@ void bcma_init_bus(struct bcma_bus *bus)
 static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
 {
int err;
+   struct device * dev;
+
+   dev = bcma_bus_get_host_dev(bus);
+   if (dev && !core->dev.of_node)
+   core->dev.of_node = dev->of_node;


if it's ok I will send this patch in separate email.

>
>>
>>>

 Signed-off-by: Abylay Ospan 
 ---
  drivers/pci/host/pcie-iproc.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
 index 3ebc025..f2836a9 100644
 --- a/drivers/pci/host/pcie-iproc.c
 +++ b/drivers/pci/host/pcie-iproc.c
 @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct 
 of_pci_range_parser *parser,
 const int na = 3, ns = 2;
 int rlen;

 +   if (!node)
 +   return -ENOENT;
 +
 parser->node = node;
 parser->pna = of_n_addr_cells(node);
 parser->np = parser->pna + na + ns;

>>>
>>>
>
>
> --
> Florian



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

arm64: dts: mt8173: add node for thermal calibration

[Dawei Chien]

From: "dawei.ch...@mediatek.com" 

Add this for supporting thermal calibration by e-fuse data.

Signed-off-by: Dawei Chien 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..adfac1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -401,6 +401,11 @@
efuse: efuse@10206000 {
compatible = "mediatek,mt8173-efuse";
reg = <0 0x10206000 0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   thermal_calibration: calib@528 {
+   reg = <0x528 0xc>;
+   };
};
 
apmixedsys: clock-controller@10209000 {
@@ -574,6 +579,8 @@
resets = < MT8173_PERI_THERM_SW_RST>;
mediatek,auxadc = <>;
mediatek,apmixedsys = <>;
+   nvmem-cells = <_calibration>;
+   nvmem-cell-names = "calibration-data";
};
 
nor_flash: spi@1100d000 {
-- 
1.9.1

Re: blk_queue_bounce_limit() broken for mask=0xffffffff on 64bit archs

[Ming Lei]

Hi,

On Tue, Jan 10, 2017 at 4:48 AM, Nikita Yushchenko
 wrote:
> Hi
>
> There is a use cases when architecture is 64-bit but hardware supports
> only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host.
>
> For such cases, it looks proper to call blk_queue_bounce_limit() with
> mask set to 0x - thus making block layer to use bounce buffers
> for any addresses beyond 4G.  To support that, architecture provides
> GFP_DMA zone that covers exactly low 4G on arm64.
>
> However setting this limit does not work:
>
>   if (b_pfn < (min_t(u64, 0xUL, BLK_BOUNCE_HIGH) >> PAGE_SHIFT))
>   dma = 1;
>
> When mask is 0x that condition is false

That should have been true in your case, since the b_pfn is smaller than
0x.

>
>   q->limits.bounce_pfn = max(max_low_pfn, b_pfn);
>
> this line is executed and replaces any limit with end of memory (on
> 64bit arch all memory is low).

I don't understand why max() is used? And why not min()?

Looks the above line just disables bounce for 64bit arch, doesn't it?

Thanks,
Ming

>
>
> Not sure how to fix this properly. Any hints?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Ming Lei

Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage

[Kevin Hilman]

Jerome Brunet  writes:

> OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
> MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
> the Tx path). The problem seems to come from the phy Rx path, entering the
> LPI state.
>
> Disabling EEE advertisement on the phy prevent this feature to be
> negociated with the link partner and solve the issue.
>
> Signed-off-by: Jerome Brunet 
> ---
>
> This patch is based on Linus recent master branch [0]
> This patch depends on the series [1] which has been merged in this branch.
>
> 0: ba6d973f78eb ("Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 1: 
> http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbru...@baylibre.com
>Fix integration of eee-broken-modes
>
>  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbeacd330..d8933e9e9a5a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -147,6 +147,18 @@
>   status = "okay";
>   pinctrl-0 = <_rgmii_pins>;
>   pinctrl-names = "default";
> + phy-handle = <_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy@0 {
> + reg = <0>;
> + eee-broken-1000t;
> + };
> + };

There's already an MDIO node in the meson-gx.dtsi (using the same
compatible), shouldn't you just override that and add the new
properties?

What would make things easier is if the names were like Martin used in
his reset patch, so that when I merge them together it's not a major
conflict.

Thanks,

Kevin

[1] https://patchwork.kernel.org/patch/9459409/

Re: [lustre-devel] [PATCH 1/2] Fixed signedness check

[Dilger, Andreas]

On Dec 26, 2016, at 08:43, Guillermo O. Freschi  wrote:
> 
> Was `unsigned int`, but `enum`s are signed.

Interesting that GCC didn't complain that the itree_overlap_cb() function
signature didn't match the argument prototype for interval_search():

  typedef enum interval_iter (*interval_callback_t)(struct interval_node *node,
void *args);

In the end it is a somewhat cosmetic fix, because the only enum values
(1, 2) were unsigned, but good to be consistent.  Thanks for the fix.

> Signed-off-by: Guillermo O. Freschi 

Reviewed-by: Andreas Dilger 

> ---
> drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c 
> b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
> index a4a291acb659..f4cbc89b4f24 100644
> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
> @@ -1148,7 +1148,7 @@ static int lock_matches(struct ldlm_lock *lock, struct 
> lock_match_data *data)
>   return INTERVAL_ITER_STOP;
> }
> 
> -static unsigned int itree_overlap_cb(struct interval_node *in, void *args)
> +static enum interval_iter itree_overlap_cb(struct interval_node *in, void 
> *args)
> {
>   struct ldlm_interval *node = to_ldlm_interval(in);
>   struct lock_match_data *data = args;
> -- 
> 2.11.0
> 
> ___
> lustre-devel mailing list
> lustre-de...@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[Woody Suwalski]

Pavel Machek wrote:

Hi!


I used to have two cpus, and Thinkpad X60 should have two cores, but I
only see one on 4.10-rc1. This machine went through many
suspend/resume cycles. When backups finish, I'll try -rc2.

Whoever did it, he seems to have returned the cpu in -rc3. All seems
to be good now.
Pavel

Actually since you have mentioned - I have checked my x60 - same problem 
- only one CPU. However I was running 4.8.13 with uptime 33 days, 
multiple sleep/wake-ups.
Installed a current EOL 4.8.17 and rebooted - I see 2 CPUs. So the issue 
is older then 4.10 kernel, and I suspect it is the CPU hotplug / wakeup 
related...


Woody

Re: [tpmdd-devel] [PATCH RFC v2 3/5] tpm: infrastructure for TPM spaces

[James Bottomley]

On Thu, 2017-01-12 at 19:46 +0200, Jarkko Sakkinen wrote:
> @@ -189,6 +190,12 @@ struct tpm_chip *tpm_chip_alloc(struct device
> *pdev,
>   chip->cdev.owner = THIS_MODULE;
>   chip->cdev.kobj.parent = >dev.kobj;
> 
> + chip->work_space.context_buf = kzalloc(PAGE_SIZE,
> GFP_KERNEL);
> + if (!chip->work_space.context_buf) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +

I think the work_buf handling can be greatly simplified by making it a
pointer to the space: it's only usable between tpm2_prepare_space() and
tpm2_commit_space() which are protected by the chip mutex, so there's
no need for it to exist outside of these calls (i.e. it can be NULL).

Doing it this way also saves the allocation and copying overhead of
work_space.

The patch below can be folded to effect this.

James

---

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 13cac09..770a8c0 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -131,7 +131,6 @@ static void tpm_dev_release(struct device *dev)
mutex_unlock(_lock);
 
kfree(chip->log.bios_event_log);
-   kfree(chip->work_space.context_buf);
kfree(chip);
 }
 
@@ -206,12 +205,6 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
chip->cdev.kobj.parent = >dev.kobj;
chip->cdevrm.kobj.parent = >devrm.kobj;
 
-   chip->work_space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
-   if (!chip->work_space.context_buf) {
-   rc = -ENOMEM;
-   goto out;
-   }
-
return chip;
 
 out:
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 8009ed4..adf7810 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -211,7 +211,7 @@ struct tpm_chip {
char ppi_version[TPM_PPI_VERSION_LEN + 1];
 #endif /* CONFIG_ACPI */
 
-   struct tpm_space work_space;
+   struct tpm_space *work_space;
u32 nr_commands;
u32 *cc_attrs_tbl;
 };
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index 44e5501..285361e 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -27,7 +27,7 @@ enum tpm2_handle_types {
 
 static void tpm2_flush_space(struct tpm_chip *chip)
 {
-   struct tpm_space *space = >work_space;
+   struct tpm_space *space = chip->work_space;
int i;
 
for (i = 0; i < ARRAY_SIZE(space->context_tbl); i++)
@@ -45,7 +45,7 @@ struct tpm2_context {
 
 static int tpm2_load_space(struct tpm_chip *chip)
 {
-   struct tpm_space *space = >work_space;
+   struct tpm_space *space = chip->work_space;
struct tpm2_context *ctx;
struct tpm_buf buf;
int i;
@@ -99,7 +99,7 @@ static int tpm2_load_space(struct tpm_chip *chip)
 
 static int tpm2_map_command(struct tpm_chip *chip, u32 cc, u8 *cmd, size_t len)
 {
-   struct tpm_space *space = >work_space;
+   struct tpm_space *space = chip->work_space;
unsigned int nr_handles;
u32 vhandle;
u32 phandle;
@@ -147,9 +147,7 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct 
tpm_space *space,
if (!space)
return 0;
 
-   memcpy(>work_space.context_tbl, >context_tbl,
-  sizeof(space->context_tbl));
-   memcpy(chip->work_space.context_buf, space->context_buf, PAGE_SIZE);
+   chip->work_space = space;
 
rc = tpm2_load_space(chip);
if (rc)
@@ -164,7 +162,7 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct 
tpm_space *space,
 
 static int tpm2_map_response(struct tpm_chip *chip, u32 cc, u8 *rsp, size_t 
len)
 {
-   struct tpm_space *space = >work_space;
+   struct tpm_space *space = chip->work_space;
u32 phandle;
u32 vhandle;
u32 attrs;
@@ -222,7 +220,7 @@ static int tpm2_map_response(struct tpm_chip *chip, u32 cc, 
u8 *rsp, size_t len)
 
 static int tpm2_save_space(struct tpm_chip *chip)
 {
-   struct tpm_space *space = >work_space;
+   struct tpm_space *space = chip->work_space;
struct tpm_buf buf;
int i;
int j;
@@ -295,9 +293,7 @@ int tpm2_commit_space(struct tpm_chip *chip, struct 
tpm_space *space,
if (rc)
return rc;
 
-   memcpy(>context_tbl, >work_space.context_tbl,
-  sizeof(space->context_tbl));
-   memcpy(space->context_buf, chip->work_space.context_buf, PAGE_SIZE);
+   chip->work_space = NULL;
 
return 0;
 }

Re: [PATCH v20 0/4] Mediatek MT8173 CMDQ support

[Horng-Shyang Liao]

On Wed, 2017-01-04 at 11:06 +0800, HS Liao wrote:
> Hi,
> 
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
> 
> These patches have a build dependency on top of v4.10-rc2.
> 
> Changes since v19:
>  - rebase to v4.10-rc2
> 
> Best regards,
> HS Liao
> 
> HS Liao (4):
>   dt-bindings: soc: Add documentation for the MediaTek GCE unit
>   mailbox: mediatek: Add Mediatek CMDQ driver
>   arm64: dts: mt8173: Add GCE node
>   soc: mediatek: Add Mediatek CMDQ helper
> 
>  .../devicetree/bindings/mailbox/mtk-gce.txt|  43 ++
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  10 +
>  drivers/mailbox/Kconfig|  10 +
>  drivers/mailbox/Makefile   |   2 +
>  drivers/mailbox/mtk-cmdq-mailbox.c | 596 
> +
>  drivers/soc/mediatek/Kconfig   |  12 +
>  drivers/soc/mediatek/Makefile  |   1 +
>  drivers/soc/mediatek/mtk-cmdq-helper.c | 310 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h   |  75 +++
>  include/linux/soc/mediatek/mtk-cmdq.h  | 174 ++
>  10 files changed, 1233 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
>  create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
>  create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
>  create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
>  create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
> 

Hi Jassi, Matthias,

Sorry to disturb you.
Do you have any further comments on CMDQ v20?

Thanks.
HS

Re: x86-64: Maintain 16-byte stack alignment

[Andy Lutomirski]

On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf  wrote:
> On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
>> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
>>  wrote:
>> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf  
>> > wrote:
>> >>
>> >> Just to clarify, I think you're asking if, for versions of gcc which
>> >> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
>> >> functions to ensure their stacks are 16-byte aligned.
>> >>
>> >> It's certainly possible, but I don't see how that solves the problem.
>> >> The stack will still be misaligned by entry code.  Or am I missing
>> >> something?
>> >
>> > I think the argument is that we *could* try to align things, if we
>> > just had some tool that actually then verified that we aren't missing
>> > anything.
>> >
>> > I'm not entirely happy with checking the generated code, though,
>> > because as Ingo says, you have a 50:50 chance of just getting it right
>> > by mistake. So I'd much rather have some static tool that checks
>> > things at a code level (ie coccinelle or sparse).
>>
>> What I meant was checking the entry code to see if it aligns stack
>> frames, and good luck getting sparse to do that.  Hmm, getting 16-byte
>> alignment for real may actually be entirely a lost cause.  After all,
>> I think we have some inline functions that do asm volatile ("call
>> ..."), and I don't see any credible way of forcing alignment short of
>> generating an entirely new stack frame and aligning that.
>
> Actually we already found all such cases and fixed them by forcing a new
> stack frame, thanks to objtool.  For example, see 55a76b59b5fe.

What I mean is: what guarantees that the stack is properly aligned for
the subroutine call?  gcc promises to set up a stack frame, but does
it promise that rsp will be properly aligned to call a C function?

Re: [PATCH] partially revert "xen: Remove event channel notification through Xen PCI platform device"

[Stefano Stabellini]

On Thu, 12 Jan 2017, Boris Ostrovsky wrote:
> On 01/12/2017 04:33 PM, Stefano Stabellini wrote:
> > On Thu, 12 Jan 2017, Boris Ostrovsky wrote:
> >> On 01/11/2017 06:36 PM, Stefano Stabellini wrote:
> >>> The following commit:
> >>>
> >>> commit 72a9b186292d98494f26cfd24a1621796209
> >>> Author: KarimAllah Ahmed 
> >>> Date:   Fri Aug 26 23:55:36 2016 +0200
> >>>
> >>> xen: Remove event channel notification through Xen PCI platform device
> 
> Can you also replace this with
> 
> "Commit 72a9b186292d ("xen: Remove event channel notification through
> Xen PCI platform device")" ... ?

Too late. But if you are Ok with the patch, please fix the message while
committing.

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

[Dave Young]

On 01/13/17 at 12:11am, Nicolai Stange wrote:
> On Fri, Jan 13 2017, Dave Young wrote:
> 
> > On 01/12/17 at 12:54pm, Nicolai Stange wrote:
> >> On Thu, Jan 12 2017, Dave Young wrote:
> >> 
> >> > -void __init efi_bgrt_init(void)
> >> > +void __init efi_bgrt_init(struct acpi_table_header *table)
> >> >  {
> >> > -acpi_status status;
> >> >  void *image;
> >> >  struct bmp_header bmp_header;
> >> >  
> >> >  if (acpi_disabled)
> >> >  return;
> >> >  
> >> > -status = acpi_get_table("BGRT", 0,
> >> > -(struct acpi_table_header **)_tab);
> >> > -if (ACPI_FAILURE(status))
> >> > -return;
> >> 
> >> 
> >> Not sure, but wouldn't it be safer to reverse the order of this assignment
> >> 
> >> > +bgrt_tab = *(struct acpi_table_bgrt *)table;
> >
> > Nicolai, sorry, I'm not sure I understand the comment, is it about above 
> > line?
> > Could you elaborate a bit?
> >
> >> 
> >> and this length check
> >> 
> >
> > I also do not get this :(
> 
> Ah sorry, my point is this: the length check should perhaps be made
> before doing the assignment to bgrt_tab because otherwise, we might end
> up reading from invalid memory.
> 
> I.e. if (struct acpi_table_bgrt *)table->length < sizeof(bgrt_tab), then
> 
>   bgrt_tab = *(struct acpi_table_bgrt *)table;
> 
> would read past the table's end.
> 
> I'm not sure whether this is a real problem though -- that is, whether
> this read could ever hit some unmapped memory.

Nicolai, thanks for the explanation. It make sense to move it to even later
at the end of the function.

Thanks
Dave

RE: [PATCH v2 1/4] ASoC: rt5660: Add ACPI support

[Bard Liao]

> -Original Message-
> From: Shrirang Bagul [mailto:shrirang.ba...@canonical.com]
> Sent: Thursday, January 12, 2017 8:01 PM
> To: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org; Bard Liao; Oder Chiou; Liam Girdwood; Mark
> Brown; Jaroslav Kysela; Takashi Iwai
> Subject: [PATCH v2 1/4] ASoC: rt5660: Add ACPI support
> 
> On Dell IoT Gateways, RT5660 codec is available with ACPI ID 10EC3277.
> Also, GPIO's are only available by index, so we register mappings to allow
> machine drivers to access them by name.
> 
> Signed-off-by: Shrirang Bagul 
> ---
> +static const struct acpi_gpio_params audio_wake_intr_gpio =
> { RT5660_GPIO_WAKE_INTR, 0, false };
> +static const struct acpi_gpio_params lineout_mute_gpio =
> { RT5660_GPIO_LINEOUT_MUTE, 0, true };
> +
> +static const struct acpi_gpio_mapping byt_rt5660_gpios[] = {
> + { "audio-wake-intr-gpios", _wake_intr_gpio, 1 },
> + { "lineout-mute-gpios", _mute_gpio, 1 },
> + { NULL },
> +};
> +

I am thinking if it is more suitable to move the gpio params to
machine driver? They are not codec's gpios and are only used
by machine driver. 

> --
> 2.9.3

[PATCH v3] ocfs2/journal: fix umount hang after flushing journal failure

[Changwei Ge]

Hi Joseph,

Do you think my last version of patch to fix umount hang after journal
flushing failure is OK?

If so, I 'd like to ask Andrew's help to merge this patch into his test
tree.


Thanks,

Br.

Changwei



From 686b52ee2f06395c53e36e2c7515c276dc7541fb Mon Sep 17 00:00:00 2001
From: Changwei Ge 
Date: Wed, 11 Jan 2017 09:05:35 +0800
Subject: [PATCH] fix umount hang after journal flushing failure

Signed-off-by: Changwei Ge 
---
 fs/ocfs2/journal.c |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c
index a244f14..5f3c862 100644
--- a/fs/ocfs2/journal.c
+++ b/fs/ocfs2/journal.c
@@ -2315,6 +2315,24 @@ static int ocfs2_commit_thread(void *arg)
 "commit_thread: %u transactions pending on "
 "shutdown\n",
 atomic_read(>j_num_trans));
+
+   if (status < 0) {
+   mlog(ML_ERROR, "journal is already abort
and cannot be "
+"flushed any more. So ignore
the pending "
+"transactions to avoid blocking
ocfs2 unmount.\n");
+   /*
+* This may a litte hacky, however, no
chance
+* for ocfs2/journal to decrease this
variable
+* thourgh commit-thread. I have to do so to
+* avoid umount hang after journal flushing
+* failure. Since jounral has been
marked ABORT
+* within jbd2_journal_flush, commit
cache will
+* never do any real work to flush
journal to
+* disk.Set it to ZERO so that umount will
+* continue during shutting down journal
+*/
+   atomic_set(>j_num_trans, 0);
+   }
}
}

--
1.7.9.5

-
本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!

[PATCH] usb: host: xhci: plat: check hcc_params after add hcd

[William Wu]

From: William wu 

The commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them") move add hcd to the end of
probe, this cause hcc_params uninitiated, because xHCI
driver sets hcc_params in xhci_gen_setup() called from
usb_add_hcd().

This patch checks the Maximum Primary Stream Array Size
in the hcc_params register after add hcd.

Signed-off-by: William wu 
---
 drivers/usb/host/xhci-plat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ddfab30..52ce697 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -232,9 +232,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(>dev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
 
-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
hcd->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
if (IS_ERR(hcd->usb_phy)) {
ret = PTR_ERR(hcd->usb_phy);
@@ -255,6 +252,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
 
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
return 0;
 
 
-- 
2.7.4

Re: linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

On Thu, 12 Jan 2017 15:33:53 -0800 Andrew Morton  
wrote:
>
> I'll drop
> 
> ocfs2-dlmglue-prepare-tracking-logic-to-avoid-recursive-cluster-lock.patch
> and
> ocfs2-fix-deadlocks-when-taking-inode-lock-at-vfs-entry-points.patch

I removed them from linux-next today.

-- 
Cheers,
Stephen Rothwell

[PATCH] libfc: Fix variable name in fc_set_wwpn

[Fam Zheng]

The parameter name should be wwpn instead of wwnn.

Signed-off-by: Fam Zheng 
---
 include/scsi/libfc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
index 96dd0b3..da5033d 100644
--- a/include/scsi/libfc.h
+++ b/include/scsi/libfc.h
@@ -809,11 +809,11 @@ static inline void fc_set_wwnn(struct fc_lport *lport, 
u64 wwnn)
 /**
  * fc_set_wwpn() - Set the World Wide Port Name of a local port
  * @lport: The local port whose WWPN is to be set
- * @wwnn:  The new WWPN
+ * @wwpn:  The new WWPN
  */
-static inline void fc_set_wwpn(struct fc_lport *lport, u64 wwnn)
+static inline void fc_set_wwpn(struct fc_lport *lport, u64 wwpn)
 {
-   lport->wwpn = wwnn;
+   lport->wwpn = wwpn;
 }
 
 /**
-- 
2.9.3

Re: [RFC] [PATCH] audit: log 32-bit socketcalls

[Richard Guy Briggs]

On 2017-01-12 16:32, Paul Moore wrote:
> On Thu, Jan 12, 2017 at 7:36 AM, Richard Guy Briggs  wrote:
> > 32-bit socketcalls were not being logged by audit on x86_64 systems.
> > Log them.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/14
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  net/compat.c |   18 --
> >  1 files changed, 16 insertions(+), 2 deletions(-)
> 
> You should CC netdev on this patch; I'd also mention that you are
> simply duplicating the normal socketcall() auditing in the compat
> version (the only real difference being the argument size handling
> workaround).

D'ho! Completely forgot about netdev.

I thought of mentioning the size handling in the description, but
figured it was somewhat obvious right in the code.  I'll add a comment.

> > diff --git a/net/compat.c b/net/compat.c
> > index 1cd2ec0..86cacab 100644
> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -22,6 +22,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include 
> > @@ -781,14 +782,27 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct 
> > compat_mmsghdr __user *, mmsg,
> >
> >  COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> >  {
> > +   unsigned int len, i;
> > int ret;
> > -   u32 a[6];
> > +   u32 a[AUDITSC_ARGS];
> > +   unsigned long aa[AUDITSC_ARGS];
> > u32 a0, a1;
> >
> > if (call < SYS_SOCKET || call > SYS_SENDMMSG)
> > return -EINVAL;
> > -   if (copy_from_user(a, args, nas[call]))
> > +   len = nas[call];
> > +   if (len > sizeof(a))
> > +   return -EINVAL;
> > +
> > +   if (copy_from_user(a, args, len))
> > return -EFAULT;
> > +
> > +   for (i=0; i < len/sizeof(a[0]); i++)
> > +   aa[i] = (unsigned long)a[i];
> 
> It will be interesting to see if you get push back on this loop
> outside of audit_socketcall(); folks may want to see it wrapped up
> inside a audit_socketcall_compat() (or similar) function so it isn't
> needlessly called in a number of cases.  However, considering it is
> compat code, and not the common case it may be okay.

I thought about this, and was thinking a check of !audit_dummy_context()
here might be a solution, but audit_socketcall_compat is a much cleaner
idea.  I did also consider that it is compat code that won't have a lot
of performance nerds screaming, but that's no excuse...

> > +   ret = audit_socketcall(len/sizeof(a[0]), aa);
> > +   if (ret)
> > +   return ret;
> > +
> > a0 = a[0];
> > a1 = a[1];
> >
> > --
> > 1.7.1
> 
> -- 
> paul moore
> www.paul-moore.com

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[PATCH V2 1/6] gpio: davinci: Remove gpio2regs function to accommodate multi instances

[Keerthy]

gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.

Signed-off-by: Keerthy 
---

Changes in v2:

  * Added a comment to explain divide by 2 logic for register sets.

 drivers/gpio/gpio-davinci.c | 35 +++
 1 file changed, 11 insertions(+), 24 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 163f81e..bb47de3 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -43,25 +43,7 @@ struct davinci_gpio_regs {
 #define MAX_LABEL_SIZE 20
 
 static void __iomem *gpio_base;
-
-static struct davinci_gpio_regs __iomem *gpio2regs(unsigned gpio)
-{
-   void __iomem *ptr;
-
-   if (gpio < 32 * 1)
-   ptr = gpio_base + 0x10;
-   else if (gpio < 32 * 2)
-   ptr = gpio_base + 0x38;
-   else if (gpio < 32 * 3)
-   ptr = gpio_base + 0x60;
-   else if (gpio < 32 * 4)
-   ptr = gpio_base + 0x88;
-   else if (gpio < 32 * 5)
-   ptr = gpio_base + 0xb0;
-   else
-   ptr = NULL;
-   return ptr;
-}
+static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
 
 static inline struct davinci_gpio_regs __iomem *irq2regs(struct irq_data *d)
 {
@@ -262,7 +244,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 #endif
spin_lock_init([i].lock);
 
-   regs = gpio2regs(base);
+   regs = gpio_base + offset_array[i];
if (!regs)
return -ENXIO;
chips[i].regs = regs;
@@ -417,7 +399,9 @@ static int gpio_irq_type_unbanked(struct irq_data *data, 
unsigned trigger)
 davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hw)
 {
-   struct davinci_gpio_regs __iomem *g = gpio2regs(hw);
+   struct davinci_gpio_controller *chips =
+   (struct davinci_gpio_controller *)d->host_data;
+   struct davinci_gpio_regs __iomem *g = chips[hw / 32].regs;
 
irq_set_chip_and_handler_name(irq, _irqchip, handle_simple_irq,
"davinci_gpio");
@@ -554,7 +538,7 @@ static int davinci_gpio_irq_setup(struct platform_device 
*pdev)
irq_chip->irq_set_type = gpio_irq_type_unbanked;
 
/* default trigger: both edges */
-   g = gpio2regs(0);
+   g = chips[0].regs;
writel_relaxed(~0, >set_falling);
writel_relaxed(~0, >set_rising);
 
@@ -573,8 +557,11 @@ static int davinci_gpio_irq_setup(struct platform_device 
*pdev)
 * then chain through our own handler.
 */
for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) {
-   /* disabled by default, enabled only as needed */
-   g = gpio2regs(gpio);
+   /* disabled by default, enabled only as needed
+* There are register sets for 32 GPIOs. 2 banks of 16
+* GPIOs are covered by each set of registers hence divide by 2
+*/
+   g = chips[bank / 2].regs;
writel_relaxed(~0, >clr_falling);
writel_relaxed(~0, >clr_rising);
 
-- 
1.9.1

[PATCH V2 6/6] gpio: davinci: Remove redundant macros

[Keerthy]

Some of the macros were needed as per old driver design.
With the current implementation they are unwanted. Hence remove
them.

Signed-off-by: Keerthy 
---
 include/linux/platform_data/gpio-davinci.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/include/linux/platform_data/gpio-davinci.h 
b/include/linux/platform_data/gpio-davinci.h
index 90ae19c..f922601 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -45,14 +45,6 @@ struct davinci_gpio_controller {
unsigned intbase;
 };
 
-/*
- * basic gpio routines
- */
-#defineGPIO(X) (X) /* 0 <= X <= (DAVINCI_N_GPIO - 1) */
-
-/* Convert GPIO signal to GPIO pin number */
-#define GPIO_TO_PIN(bank, gpio)(16 * (bank) + (gpio))
-
 static inline u32 __gpio_mask(unsigned gpio)
 {
return 1 << (gpio % 32);
-- 
1.9.1

[PATCH V2 3/6] gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip

[Keerthy]

The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization and one IRQ domain.
So, the current GPIO's  opjects structure is:

 Davinci GPIO controller
 |-  --|
 ...|--- irq_domain (hwirq [0..143])
 |-  --|

Current driver creates one chip for every 32 GPIOs in a controller.
This was a limitation earlier now there is no need for that. Hence
redesigning the driver to create one gpio chip for all the ngpio
in the controller.

|-  --|--- irq_domain (hwirq [0..143]).

The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html

Signed-off-by: Keerthy 
---

Changes in v2:

  * Optimized irqdata allocation logic to use a single pointer
instead of array of pointers.
  * Removed a redundant Macro.
  * Used __gpio_mask instead of hardcoding every single time.
  * MAX_BANKS changed to MAX_REGS_BANKS

 drivers/gpio/gpio-davinci.c| 127 +
 include/linux/platform_data/gpio-davinci.h |  12 ++-
 2 files changed, 83 insertions(+), 56 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index bb47de3..a527e88 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -63,11 +63,13 @@ static inline int __davinci_direction(struct gpio_chip 
*chip,
unsigned offset, bool out, int value)
 {
struct davinci_gpio_controller *d = gpiochip_get_data(chip);
-   struct davinci_gpio_regs __iomem *g = d->regs;
+   struct davinci_gpio_regs __iomem *g;
unsigned long flags;
u32 temp;
-   u32 mask = 1 << offset;
+   int bank = offset / 32;
+   u32 mask = __gpio_mask(offset);
 
+   g = d->regs[bank];
spin_lock_irqsave(>lock, flags);
temp = readl_relaxed(>dir);
if (out) {
@@ -103,9 +105,12 @@ static int davinci_direction_in(struct gpio_chip *chip, 
unsigned offset)
 static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
struct davinci_gpio_controller *d = gpiochip_get_data(chip);
-   struct davinci_gpio_regs __iomem *g = d->regs;
+   struct davinci_gpio_regs __iomem *g;
+   int bank = offset / 32;
 
-   return !!((1 << offset) & readl_relaxed(>in_data));
+   g = d->regs[bank];
+
+   return !!(__gpio_mask(offset) & readl_relaxed(>in_data));
 }
 
 /*
@@ -115,9 +120,13 @@ static int davinci_gpio_get(struct gpio_chip *chip, 
unsigned offset)
 davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
struct davinci_gpio_controller *d = gpiochip_get_data(chip);
-   struct davinci_gpio_regs __iomem *g = d->regs;
+   struct davinci_gpio_regs __iomem *g;
+   int bank = offset / 32;
 
-   writel_relaxed((1 << offset), value ? >set_data : >clr_data);
+   g = d->regs[bank];
+
+   writel_relaxed(__gpio_mask(offset),
+  value ? >set_data : >clr_data);
 }
 
 static struct davinci_gpio_platform_data *
@@ -165,7 +174,7 @@ static int davinci_gpio_of_xlate(struct gpio_chip *gc,
if (gpiospec->args[0] > pdata->ngpio)
return -EINVAL;
 
-   if (gc != [gpiospec->args[0] / 32].chip)
+   if (gc != >chip)
return -EINVAL;
 
if (flags)
@@ -177,11 +186,11 @@ static int davinci_gpio_of_xlate(struct gpio_chip *gc,
 
 static int davinci_gpio_probe(struct platform_device *pdev)
 {
-   int i, base;
+   static int ctrl_num;
+   int gpio, bank;
unsigned ngpio, nbank;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
-   struct davinci_gpio_regs __iomem *regs;
struct device *dev = >dev;
struct resource *res;
char label[MAX_LABEL_SIZE];
@@ -220,38 +229,30 @@ static int davinci_gpio_probe(struct platform_device 
*pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
 
-   for (i = 0, base = 0; base < ngpio; i++, base += 32) {
-   snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", i);
-   chips[i].chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
-   if (!chips[i].chip.label)
+   snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
+   chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
+   if (!chips->chip.label)
return -ENOMEM;
 
-   chips[i].chip.direction_input = davinci_direction_in;
-   chips[i].chip.get = davinci_gpio_get;
-   chips[i].chip.direction_output = davinci_direction_out;
-   chips[i].chip.set = davinci_gpio_set;
+   chips->chip.direction_input = davinci_direction_in;
+   chips->chip.get = davinci_gpio_get;
+   chips->chip.direction_output = 

[PATCH V2 4/6] gpio: davinci: Add support for multiple GPIO controllers

[Keerthy]

Update GPIO driver to support Multiple GPIO controllers by updating
the base of subsequent GPIO chips with total of previous chips
gpio count so that gpio_add_chip gets unique numbers.

Signed-off-by: Keerthy 
---
 drivers/gpio/gpio-davinci.c| 4 +++-
 include/linux/platform_data/gpio-davinci.h | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index a527e88..2a5ae04 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -186,7 +186,7 @@ static int davinci_gpio_of_xlate(struct gpio_chip *gc,
 
 static int davinci_gpio_probe(struct platform_device *pdev)
 {
-   static int ctrl_num;
+   static int ctrl_num, bank_base;
int gpio, bank;
unsigned ngpio, nbank;
struct davinci_gpio_controller *chips;
@@ -240,6 +240,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.set = davinci_gpio_set;
 
chips->chip.ngpio = ngpio;
+   chips->chip.base = bank_base;
 
 #ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
@@ -248,6 +249,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.of_node = dev->of_node;
 #endif
spin_lock_init(>lock);
+   bank_base += ngpio;
 
for (gpio = 0, bank = 0; gpio < ngpio; gpio += 32, bank++)
chips->regs[bank] = gpio_base + offset_array[bank];
diff --git a/include/linux/platform_data/gpio-davinci.h 
b/include/linux/platform_data/gpio-davinci.h
index c62a943..90ae19c 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -42,6 +42,7 @@ struct davinci_gpio_controller {
void __iomem*regs[MAX_REGS_BANKS];
int gpio_unbanked;
unsigned intbase_irq;
+   unsigned intbase;
 };
 
 /*
-- 
1.9.1

[PATCH V2 0/6] gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip

[Keerthy]

The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization and one IRQ domain.
So, the current GPIO's  opjects structure is:

 Davinci GPIO controller
 |-  --|
 ...|--- irq_domain (hwirq [0..143])
 |-  --|

Current driver creates one chip for every 32 GPIOs in a controller.
This was a limitation earlier now there is no need for that. Hence
redesigning the driver to create one gpio chip for all the ngpio
in the controller.

|-  --|--- irq_domain (hwirq [0..143]).

The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html

The series is posted on top of: 

https://lkml.org/lkml/2017/1/4/94

Changes in v2:

  * Optimized the re-design patch.
  * Added couple of code clean ups after the re-design.
  * Included v2 of https://patchwork.ozlabs.org/patch/710855/ 

Keerthy (6):
  gpio: davinci: Remove gpio2regs function to accommodate multi
instances
  gpio: davinci: Remove unwanted blank line
  gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip
  gpio: davinci: Add support for multiple GPIO controllers
  gpio: davinci: Remove custom .xlate
  gpio: davinci: Remove redundant macros

 drivers/gpio/gpio-davinci.c| 174 +
 include/linux/platform_data/gpio-davinci.h |  20 ++--
 2 files changed, 90 insertions(+), 104 deletions(-)

-- 
1.9.1

[PATCH V2 5/6] gpio: davinci: Remove custom .xlate

[Keerthy]

With the current redesign of driver it's not necessary to have
custom .xlate() as the gpiolib will assign default of_gpio_simple_xlate().

Suggested-by: Grygorii Strashko 
Signed-off-by: Keerthy 
---
 drivers/gpio/gpio-davinci.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 2a5ae04..86b4950 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -163,27 +163,6 @@ static int davinci_gpio_get(struct gpio_chip *chip, 
unsigned offset)
return NULL;
 }
 
-#ifdef CONFIG_OF_GPIO
-static int davinci_gpio_of_xlate(struct gpio_chip *gc,
-const struct of_phandle_args *gpiospec,
-u32 *flags)
-{
-   struct davinci_gpio_controller *chips = dev_get_drvdata(gc->parent);
-   struct davinci_gpio_platform_data *pdata = dev_get_platdata(gc->parent);
-
-   if (gpiospec->args[0] > pdata->ngpio)
-   return -EINVAL;
-
-   if (gc != >chip)
-   return -EINVAL;
-
-   if (flags)
-   *flags = gpiospec->args[1];
-
-   return gpiospec->args[0] % 32;
-}
-#endif
-
 static int davinci_gpio_probe(struct platform_device *pdev)
 {
static int ctrl_num, bank_base;
@@ -244,7 +223,6 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 
 #ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
-   chips->chip.of_xlate = davinci_gpio_of_xlate;
chips->chip.parent = dev;
chips->chip.of_node = dev->of_node;
 #endif
-- 
1.9.1

[PATCH V2 2/6] gpio: davinci: Remove unwanted blank line

[Keerthy]

Remove redundant blank line.

Signed-off-by: Keerthy 
---
 include/linux/platform_data/gpio-davinci.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/platform_data/gpio-davinci.h 
b/include/linux/platform_data/gpio-davinci.h
index 44ca530..18127c4 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -26,7 +26,6 @@ struct davinci_gpio_platform_data {
u32 gpio_unbanked;
 };
 
-
 struct davinci_gpio_controller {
struct gpio_chipchip;
struct irq_domain   *irq_domain;
-- 
1.9.1

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Fri, Jan 13, 2017 at 11:12 AM, Bough Chen  wrote:
>> -Original Message-
>> From: Shawn Lin [mailto:shawn@rock-chips.com]
>> Sent: Friday, January 13, 2017 10:11 AM
>> To: Ulf Hansson ; Clemens Gruber
>> 
>> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
>> ; Adrian Hunter ; A.S.
>> Dong ; linux-kernel@vger.kernel.org; Bough Chen
>> ; Gary Bisson ;
>> Fabio Estevam ; Shawn Guo 
>> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>>
>> On 2017/1/13 0:51, Ulf Hansson wrote:
>> > + Haibo, Gary, Fabio, Shawn Gou
>> >
>> > On 6 January 2017 at 16:56, Clemens Gruber
>>  wrote:
>> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
>>  Hi,
>> 
>>  with the current mainline 4.10-rc2 kernel, I can no longer boot
>>  from the eMMC on my i.MX6Q board.
>> 
>>  Details:
>>  The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
>>  supports eMMC 4.41 features and we did not implement voltage
>>  switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
>>  of the mmc-ddr or mmc-hs
>>  options) to the device tree. The bus-width is 8.
>> 
>>  With 4.9 the board booted fine, now with the current mainline 4.10
>>  tree, I get the following (repeating) errors at boot:
>> 
>>  [4.326834] Waiting for root device /dev/mmcblk0p2...
>>  [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>>  [   14.569619] sdhci: === REGISTER DUMP
>> (mmc0)===
>>  [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>>  [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>>  [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>>  [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>>  [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>>  [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>>  [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>>  [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>  [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>>  [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>>  [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> >>>
>> >>> it shows you always fail to get resp of sending status within the
>> >>> expected period of time.
>> >>>
>> >>>
>>  [   14.639682] sdhci: Host ctl2: 0x
>>  [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>>  [   14.649447] sdhci:
>> ===
>> 
>>  This repeats a few times, then more information is shown at the bottom:
>> 
>>  [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>>  [   86.899615] sdhci: === REGISTER DUMP
>> (mmc0)===
>>  [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>>  [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>>  [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>>  [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>>  [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>>  [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>>  [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>>  [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>  [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>>  [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>>  [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>  [   86.969668] sdhci: Host ctl2: 0x
>>  [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>>  [   86.979433] sdhci:
>> ===
>>  [   86.986356] mmc0: switch to bus width 8 ddr failed
>>  [   86.991163] mmc0: error -110 whilst initialising MMC card
>>  [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>> 
>>  --
>> 
>>  After looking through the latest commits to mmc/core, I found the
>>  culprit:
>>  Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:
>> Update
>>  CMD13 polling policy when switch to HS DDR mode")
>> 
>>  Reverting it fixes the problem. But I am unsure if that's the right
>>  course of action?
>> 
>>  Feel free to send me patches for testing!
>> >>>
>> >>> By looking the changes itself, it should be good from the view of spec.
>> >>> Maybe you could try the 

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren 
Cc: Ulf Hansson 
Signed-off-by: Matt Ranostay 
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay 
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev = dev;
+   pwrseq->pwrseq.ops = _pwrseq_sd8787_ops;
+   pwrseq->pwrseq.owner = THIS_MODULE;
+   platform_set_drvdata(pdev, pwrseq);
+
+  

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* fix rookie mistake missing the main source file and docs

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[git pull] Input updates for 4.10-rc3

[Dmitry Torokhov]

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem - small driver fixups.

Changelog:
-

Andy Shevchenko (1):
  Input: adxl34x - make it enumerable in ACPI environment

Aniroop Mathur (1):
  Input: synaptics_i2c - change msleep to usleep_range for small msecs

Corentin Labbe (1):
  Input: joydev - remove unused linux/miscdevice.h include

Dmitry Torokhov (1):
  Input: synaptics-rmi4 - fix F03 build error when serio is module

Guenter Roeck (1):
  Input: elants_i2c - avoid divide by 0 errors on bad touchscreen data

Marcos Paulo de Souza (1):
  Input: i8042 - add Pegatron touchpad to noloop table

Paul Donohue (1):
  Input: ALPS - fix TrackStick Y axis handling for SS5 hardware

Pavel Rojtberg (1):
  Input: xpad - use correct product id for x360w controllers


Diffstat:


 drivers/input/joydev.c | 1 -
 drivers/input/joystick/xpad.c  | 6 ++
 drivers/input/misc/adxl34x-i2c.c   | 4 +---
 drivers/input/mouse/alps.h | 2 +-
 drivers/input/mouse/synaptics_i2c.c| 4 ++--
 drivers/input/rmi4/Kconfig | 3 ++-
 drivers/input/serio/i8042-x86ia64io.h  | 6 ++
 drivers/input/touchscreen/elants_i2c.c | 4 ++--
 8 files changed, 20 insertions(+), 10 deletions(-)

-- 
Dmitry

Re: blk_queue_bounce_limit() broken for mask=0xffffffff on 64bit archs

[Nikita Yushchenko]

>> There is a use cases when architecture is 64-bit but hardware supports
>> only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host.
>>
>> For such cases, it looks proper to call blk_queue_bounce_limit() with
>> mask set to 0x - thus making block layer to use bounce buffers
>> for any addresses beyond 4G.  To support that, architecture provides
>> GFP_DMA zone that covers exactly low 4G on arm64.
>>
>> However setting this limit does not work:
>>
>>   if (b_pfn < (min_t(u64, 0xUL, BLK_BOUNCE_HIGH) >> PAGE_SHIFT))
>>   dma = 1;
>>
>> When mask is 0x that condition is false
> 
> That should have been true in your case, since the b_pfn is smaller than
> 0x.

b_pfn is exactly 0xUL >> SHIFT, thus contition is false

>>   q->limits.bounce_pfn = max(max_low_pfn, b_pfn);
>>
>> this line is executed and replaces any limit with end of memory (on
>> 64bit arch all memory is low).
> 
> I don't understand why max() is used? And why not min()?
> 
> Looks the above line just disables bounce for 64bit arch, doesn't it?

Effectively yes. And I don't understand logic behind this code.

Nikita

[PATCH] fuse: clear FR_PENDING flag when moving requests out of pending queue

[Tahsin Erdogan]

fuse_abort_conn() moves requests from pending list to a temporary list
before canceling them. This operation races with request_wait_answer()
which also tries to remove the request after it gets a fatal signal. It
checks FR_PENDING flag to determine whether the request is still in the
pending list.

Make fuse_abort_conn() clear FR_PENDING flag so that request_wait_answer()
does not remove the request from temporary list.

This bug manifests itself as a panic that looks like this:

 general protection fault:  [#1] SMP
 CPU: 2 PID: 1888 Comm: fusexmp Not tainted 4.9.0-rc8+ #47
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
 task: 88023616a100 task.stack: c90001c2
 RIP: 0010:[]  []
end_requests+0x5f/0x90
 RSP: 0018:c90001c23b78  EFLAGS: 00010246
 RAX: dead0200 RBX:  RCX: 0010e447a7df
 RDX: 8802331dc000 RSI: 8802331dc190 RDI: 8802336d7800
 RBP: c90001c23b98 R08:  R09: 
 R10: 880235c2b778 R11: 880235a22910 R12: 8802331dc190
 R13: c90001c23bc8 R14: 8802336d7800 R15: 8802331166a0
 FS:  () GS:88023fd0()
knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 00b3c1c8 CR3: 01008000 CR4: 06e0
 Stack:
  8802336d7800 8802336d7878 8802331166a0 8802336d7800
  c90001c23c00 804d77d8 8802336d7d60 8802336d7800
  c90001c23bb8 c90001c23bb8 c90001c23bc8 c90001c23bc8
 Call Trace:
  [] fuse_abort_conn+0x2a8/0x310
  [] fuse_dev_release+0x59/0x90
  [] __fput+0x9d/0x1d0
  [] fput+0x9/0x10
  [] task_work_run+0x7e/0xa0
  [] do_exit+0x27b/0xa60
  [] do_group_exit+0x3a/0xa0
  [] get_signal+0x1aa/0x5b0
  [] ? __wake_up_common+0x80/0x80
  [] do_signal+0x23/0x660
  [] ? fuse_dev_read+0x4f/0x60
  [] exit_to_usermode_loop+0x34/0x6b
  [] syscall_return_slowpath+0x55/0x60
  [] entry_SYSCALL_64_fastpath+0x92/0x94
 Code: 84 24 9c 00 00 00 99 ff ff ff f0 41 80 64 24 30 7f f0 41 80 64 24
31 fe 49 8b 44 24 08 49 8b 14 24 4c 89 e6 4c 89 f7 48 89 42 08 <48> 89
10 4d 89 24 24 4d 89 64 24 08 e8 d0 fd ff ff 49 8b 45 00
 RIP  [] end_requests+0x5f/0x90
  RSP 
 ---[ end trace 7da3774b682d0b94 ]---

Signed-off-by: Tahsin Erdogan 
---
 fs/fuse/dev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 70ea57c7b6bb..4e06a27ed7f8 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -2025,7 +2025,6 @@ static void end_requests(struct fuse_conn *fc, struct 
list_head *head)
struct fuse_req *req;
req = list_entry(head->next, struct fuse_req, list);
req->out.h.error = -ECONNABORTED;
-   clear_bit(FR_PENDING, >flags);
clear_bit(FR_SENT, >flags);
list_del_init(>list);
request_end(fc, req);
@@ -2103,6 +2102,8 @@ void fuse_abort_conn(struct fuse_conn *fc)
spin_lock(>waitq.lock);
fiq->connected = 0;
list_splice_init(>pending, _end2);
+   list_for_each_entry(req, _end2, list)
+   clear_bit(FR_PENDING, >flags);
while (forget_pending(fiq))
kfree(dequeue_forget(fiq, 1, NULL));
wake_up_all_locked(>waitq);
-- 
2.11.0.390.gc69c2f50cf-goog

Re: [PATCH] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

[Boris Ostrovsky]

> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index e8a9ea7..a822606 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -155,7 +155,6 @@ static __init int xen_init_spinlocks_jump(void)
>   if (!xen_domain())
>   return 0;
>  
> - static_key_slow_inc(_ticketlocks_enabled);
>   return 0;
>  }
>  early_initcall(xen_init_spinlocks_jump);


Looks that with this change there is not much left of
xen_init_spinlocks_jump() and so it can be removed.

-boris

Re: [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai 
Date: Wed, 11 Jan 2017 23:17:17 +

> @@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int 
> budget)
>   napi_complete(napi);
>  
>   RING_FINAL_CHECK_FOR_RESPONSES(>rx, more_to_do);
> - if (more_to_do)
> +
> + /* If there is more work to do or could not allocate
> +  * rx buffers, re-enable polling.
> +  */
> + if (more_to_do || err != 0)
>   napi_schedule(napi);

Just polling endlessly in a loop retrying the SKB allocation over and over
again until it succeeds is not very nice behavior.

You already have that refill timer, so please use that to retry instead
of wasting cpu cycles looping in NAPI poll.

Thanks.

[PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts

[David Lechner]

This adds a device tree definition file for LEGO MINDSTORMS EV3.

What is working:

* Pin muxing
* Pinconf
* GPIOs
* MicroSD card reader
* UART on input port 1
* Buttons
* LEDs
* Poweroff/reset
* Flash memory
* EEPROM
* USB host port
* USB peripheral port

What is not working/to be added later:

* Speaker - have patch submitted to get pwm-beeper working - maybe someday
  it will have a real sound driver that uses PRU
* A/DC chip - have driver submitted and accepted - waiting for ack on
  device tree bindings
* Display - waiting for "simple DRM" to be mainlined
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver as
  well as PRU UART and PRU I2C drivers
* Battery indication - needs new power supply driver

Note on flash partitions:

These partitions are based on the official EV3 firmware from LEGO. It is
expected that most users of the mainline kernel on EV3 will be booting from
an SD card while retaining the official firmware in the flash memory.
Furthermore, the official firmware uses an ancient U-Boot (2009) that has
no device tree support. So, it makes sense to have this partition table in
the EV3 device tree file. In the unlikely case that anyone does create their
own firmware image with different partitioning, they can use a modern
U-Boot in their own firmware image that modifies the device tree with the
custom partitions.

Signed-off-by: David Lechner 
---

v3 changes:
* required defconfig patches have been picked up in linux-davinci tree, so this
  is the only patch left in the series
* Added aliases node for consistent naming of serial ports
* Added memory node
* Removed nodes that are not finalized yet
* Renamed button labels to match EV3 users manual

v2 changes:
* Dropped defconfig patches that have already been pick up
* Added some new defconfig patches
* Updated device tree file based on feedback and new available bindings
  * Renamed file to include da850- prefix
  * Changed button labels
  * Fixed LED names
  * Added beeper device for sound
  * Added regulators for USB and A/DC
  * Removed unused pinmux nodes
  * Added pinconf for buttons
  * Enabled pwms
  * Used preferred bindings for flash partitions
  * Added A/DC spi device
  * Enabled USB

 arch/arm/boot/dts/Makefile   |   3 +-
 arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++
 2 files changed, 315 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b7..1a19e7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -130,7 +130,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
-   da850-evm.dtb
+   da850-evm.dtb \
+   da850-lego-ev3.dtb
 dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
 dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts 
b/arch/arm/boot/dts/da850-lego-ev3.dts
new file mode 100644
index 000..7aaf902
--- /dev/null
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -0,0 +1,313 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2017 David Lechner 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation, version 2.
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include 
+
+#include "da850.dtsi"
+
+/ {
+   compatible = "lego,ev3", "ti,da850";
+   model = "LEGO MINDSTORMS EV3";
+
+   aliases {
+   serial1 = 
+   };
+
+   memory@c000 {
+   device_type = "memory";
+   reg = <0xc000 0x0400>;
+   };
+
+   /*
+* The buttons on the EV3 are mapped to keyboard keys.
+*/
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   label = "EV3 Brick Buttons";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>, <_bias>;
+
+   center {
+   label = "Center";
+   linux,code = ;
+   gpios = < 29 GPIO_ACTIVE_HIGH>;
+   };
+
+   left {
+   label = "Left";
+   linux,code = ;
+   gpios = < 102 GPIO_ACTIVE_HIGH>;
+   };
+
+   back {
+   label = "Back";
+   linux,code = ;
+   gpios = < 106 GPIO_ACTIVE_HIGH>;
+   };
+
+   right {
+   label = "Right";
+   linux,code = ;
+   gpios = < 124 GPIO_ACTIVE_HIGH>;
+   };
+
+   down {
+

Re: [PATCH RFC v2 5/5] tpm2: expose resource manager via a device link /dev/tpms

[Jarkko Sakkinen]

On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote:
> From: James Bottomley 
> 
> Currently the Resource Manager (RM) is not exposed to userspace.  Make
> this exposure via a separate device, which can now be opened multiple
> times because each read/write transaction goes separately via the RM.
> 
> Concurrency is protected by the chip->tpm_mutex for each read/write
> transaction separately.  The TPM is cleared of all transient objects
> by the time the mutex is dropped, so there should be no interference
> between the kernel and userspace.
> 
> Signed-off-by: James Bottomley 

I think you should talk about TPM spaces here.

> ---
>  drivers/char/tpm/Makefile|  2 +-
>  drivers/char/tpm/tpm-chip.c  | 54 ++---
>  drivers/char/tpm/tpm-interface.c | 13 +++--
>  drivers/char/tpm/tpm.h   |  6 +++--
>  drivers/char/tpm/tpms-dev.c  | 57 
> 
>  5 files changed, 124 insertions(+), 8 deletions(-)
>  create mode 100644 drivers/char/tpm/tpms-dev.c
> 
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index 13ff5da..e50d768 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -3,7 +3,7 @@
>  #
>  obj-$(CONFIG_TCG_TPM) += tpm.o
>  tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o tpm-chip.o tpm2-cmd.o \
> -  tpm_eventlog.o tpm2-space.o tpm-dev-common.o
> +  tpm_eventlog.o tpm2-space.o tpm-dev-common.o tpms-dev.o
>  tpm-$(CONFIG_ACPI) += tpm_ppi.o tpm_acpi.o
>  tpm-$(CONFIG_OF) += tpm_of.o
>  obj-$(CONFIG_TCG_TIS_CORE) += tpm_tis_core.o
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 993b9ae..0d2be04 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -33,6 +33,7 @@ DEFINE_IDR(dev_nums_idr);
>  static DEFINE_MUTEX(idr_lock);
>  
>  struct class *tpm_class;
> +struct class *tpm_rm_class;

They belong to the same device class.

>  dev_t tpm_devt;

But they should have different major device numbers.

/Jarkko

Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc

[David Miller]

From: Shannon Nelson 
Date: Thu, 12 Jan 2017 12:56:08 -0800

> 
> 
> On 1/12/2017 12:41 PM, David Miller wrote:
>> From: Shannon Nelson 
>> Date: Thu, 12 Jan 2017 12:30:38 -0800
>>
>>> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
 On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:

>
> I suspect that someplace, somebody is casting val to an int * or
> something like that.

 Then that would be the bug. Can we root cause this please ?


>>>
>>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>>>
>>>  struct in6_addr *buf = (struct in6_addr *) tmp.val;
>>
>> Oh yeah, that's it.  I didn't notice that at all.
>>
> 
> It looked to me like swapping the data fields would be the easiest and
> least impactive way to fix this.  I didn't want to mess with the
> logic. I'm certainly open to other suggestions.

Given the nature of the problem, your fix is probably fine.

Eric, any objections?

Re: [PATCH 04/10] blk-mq: un-export blk_mq_free_hctx_request()

[Bart Van Assche]

On Wed, 2017-01-11 at 14:39 -0700, Jens Axboe wrote:
> It's only used in blk-mq, kill it from the main exported header
> and kill the symbol export as well.

Reviewed-by: Bart Van Assche 

[PATCH v2] partially revert "xen: Remove event channel notification through Xen PCI platform device"

[Stefano Stabellini]

The following commit:

commit 72a9b186292d98494f26cfd24a1621796209
Author: KarimAllah Ahmed 
Date:   Fri Aug 26 23:55:36 2016 +0200

xen: Remove event channel notification through Xen PCI platform device

broke Linux when booting as Dom0 on Xen in a nested Xen environment (Xen
installed inside a Xen VM). In this scenario, Linux is a PV guest, but
at the same time it uses the platform-pci driver to receive
notifications from L0 Xen. vector callbacks are not available because L1
Xen doesn't allow them.

Partially revert the offending commit, by restoring IRQ based
notifications for PV guests only. I restored only the code which is
strictly needed and replaced the xen_have_vector_callback checks within
it with xen_pv_domain() checks.

Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- in code comment
- use HVM_CALLBACK_VIA_TYPE_SHIFT
---

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index b59c9455..549c618 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -42,6 +42,7 @@
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
+static uint64_t callback_via;
 
 static unsigned long alloc_xen_mmio(unsigned long len)
 {
@@ -54,6 +55,51 @@ static unsigned long alloc_xen_mmio(unsigned long len)
return addr;
 }
 
+static uint64_t get_callback_via(struct pci_dev *pdev)
+{
+   u8 pin;
+   int irq;
+
+   irq = pdev->irq;
+   if (irq < 16)
+   return irq; /* ISA IRQ */
+
+   pin = pdev->pin;
+
+   /* We don't know the GSI. Specify the PCI INTx line instead. */
+   return ((uint64_t)0x01 << HVM_CALLBACK_VIA_TYPE_SHIFT) | /* PCI INTx 
identifier */
+   ((uint64_t)pci_domain_nr(pdev->bus) << 32) |
+   ((uint64_t)pdev->bus->number << 16) |
+   ((uint64_t)(pdev->devfn & 0xff) << 8) |
+   ((uint64_t)(pin - 1) & 3);
+}
+
+static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id)
+{
+   xen_hvm_evtchn_do_upcall();
+   return IRQ_HANDLED;
+}
+
+static int xen_allocate_irq(struct pci_dev *pdev)
+{
+   return request_irq(pdev->irq, do_hvm_evtchn_intr,
+   IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
+   "xen-platform-pci", pdev);
+}
+
+static int platform_pci_resume(struct pci_dev *pdev)
+{
+   int err;
+   if (!xen_pv_domain())
+   return 0;
+   err = xen_set_callback_via(callback_via);
+   if (err) {
+   dev_err(>dev, "platform_pci_resume failure!\n");
+   return err;
+   }
+   return 0;
+}
+
 static int platform_pci_probe(struct pci_dev *pdev,
  const struct pci_device_id *ent)
 {
@@ -92,6 +138,28 @@ static int platform_pci_probe(struct pci_dev *pdev,
platform_mmio = mmio_addr;
platform_mmiolen = mmio_len;
 
+   /* 
+* Xen HVM guests always use the vector callback mechanism.
+* L1 Dom0 in a nested Xen environment is a PV guest inside in an
+* HVM environment. It needs the platform-pci driver to get
+* notifications from L0 Xen, but it cannot use the vector callback
+* as it is not exported by L1 Xen.
+*/
+   if (xen_pv_domain()) {
+   ret = xen_allocate_irq(pdev);
+   if (ret) {
+   dev_warn(>dev, "request_irq failed err=%d\n", 
ret);
+   goto out;
+   }
+   callback_via = get_callback_via(pdev);
+   ret = xen_set_callback_via(callback_via);
+   if (ret) {
+   dev_warn(>dev, "Unable to set the evtchn callback 
"
+"err=%d\n", ret);
+   goto out;
+   }
+   }
+
max_nr_gframes = gnttab_max_grant_frames();
grant_frames = alloc_xen_mmio(PAGE_SIZE * max_nr_gframes);
ret = gnttab_setup_auto_xlat_frames(grant_frames);
@@ -123,6 +191,9 @@ static int platform_pci_probe(struct pci_dev *pdev,
.name =   DRV_NAME,
.probe =  platform_pci_probe,
.id_table =   platform_pci_tbl,
+#ifdef CONFIG_PM
+   .resume_early =   platform_pci_resume,
+#endif
 };
 
 static int __init platform_pci_init(void)

Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

[Dave Young]

On 01/12/17 at 12:54pm, Nicolai Stange wrote:
> On Thu, Jan 12 2017, Dave Young wrote:
> 
> > -void __init efi_bgrt_init(void)
> > +void __init efi_bgrt_init(struct acpi_table_header *table)
> >  {
> > -   acpi_status status;
> > void *image;
> > struct bmp_header bmp_header;
> >  
> > if (acpi_disabled)
> > return;
> >  
> > -   status = acpi_get_table("BGRT", 0,
> > -   (struct acpi_table_header **)_tab);
> > -   if (ACPI_FAILURE(status))
> > -   return;
> 
> 
> Not sure, but wouldn't it be safer to reverse the order of this assignment
> 
> > +   bgrt_tab = *(struct acpi_table_bgrt *)table;

Nicolai, sorry, I'm not sure I understand the comment, is it about above line?
Could you elaborate a bit?

> 
> and this length check
> 

I also do not get this :(

> > -   if (bgrt_tab->header.length < sizeof(*bgrt_tab)) {
> > +   if (bgrt_tab.header.length < sizeof(bgrt_tab)) {
> > pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
> > -  bgrt_tab->header.length, sizeof(*bgrt_tab));
> > +  bgrt_tab.header.length, sizeof(bgrt_tab));
> > return;
> > }
> 
> ?
> 
> Also, from here on, all error paths should zero out
> bgrt_tab.image_address (or so) to signal failure to bgrt_init():
> bgrt_init() now checks for !bgrt_tab.image_address whereas before it had
> tested bgrt_image and the latter used to be set at the very end of
> efi_bgrt_init().
> 

Will do, thanks!

> 
> > -   if (bgrt_tab->version != 1) {
> > +   if (bgrt_tab.version != 1) {
> > pr_notice("Ignoring BGRT: invalid version %u (expected 1)\n",
> > -  bgrt_tab->version);
> > +  bgrt_tab.version);
> > return;
> > }
> > -   if (bgrt_tab->status & 0xfe) {
> > +   if (bgrt_tab.status & 0xfe) {
> > pr_notice("Ignoring BGRT: reserved status bits are non-zero 
> > %u\n",
> > -  bgrt_tab->status);
> > +  bgrt_tab.status);
> > return;
> > }
> > -   if (bgrt_tab->image_type != 0) {
> > +   if (bgrt_tab.image_type != 0) {
> > pr_notice("Ignoring BGRT: invalid image type %u (expected 0)\n",
> > -  bgrt_tab->image_type);
> > +  bgrt_tab.image_type);
> > return;
> > }
> > -   if (!bgrt_tab->image_address) {
> > +   if (!bgrt_tab.image_address) {
> > pr_notice("Ignoring BGRT: null image address\n");
> > return;
> > }
> >  
> > -   image = memremap(bgrt_tab->image_address, sizeof(bmp_header), 
> > MEMREMAP_WB);
> > +   image = early_memremap(bgrt_tab.image_address, sizeof(bmp_header));
> > if (!image) {
> > pr_notice("Ignoring BGRT: failed to map image header memory\n");
> > return;
> > }
> >  
> > memcpy(_header, image, sizeof(bmp_header));
> > -   memunmap(image);
> > +   early_memunmap(image, sizeof(bmp_header));
> > if (bmp_header.id != 0x4d42) {
> > pr_notice("Ignoring BGRT: Incorrect BMP magic number 0x%x 
> > (expected 0x4d42)\n",
> > bmp_header.id);
> > @@ -82,12 +77,5 @@ void __init efi_bgrt_init(void)
> > }
> > bgrt_image_size = bmp_header.size;
> >  
> > -   bgrt_image = memremap(bgrt_tab->image_address, bmp_header.size, 
> > MEMREMAP_WB);
> > -   if (!bgrt_image) {
> > -   pr_notice("Ignoring BGRT: failed to map image memory\n");
> > -   bgrt_image = NULL;
> > -   return;
> > -   }
> > -
> > -   efi_mem_reserve(bgrt_tab->image_address, bgrt_image_size);
> > +   efi_mem_reserve(bgrt_tab.image_address, bgrt_image_size);
> >  }
> > --- linux-x86.orig/drivers/acpi/bgrt.c
> > +++ linux-x86/drivers/acpi/bgrt.c
> > @@ -15,40 +15,41 @@
> >  #include 
> >  #include 
> >  
> > +static void *bgrt_image;
> 
> [...]
> 
> > @@ -84,9 +85,17 @@ static int __init bgrt_init(void)
> >  {
> > int ret;
> >  
> > -   if (!bgrt_image)
> > +   if (!bgrt_tab.image_address)
> > return -ENODEV;
> >  
> > +   bgrt_image = memremap(bgrt_tab.image_address, bgrt_image_size,
> > + MEMREMAP_WB);
> > +   if (!bgrt_image) {
> > +   pr_notice("Ignoring BGRT: failed to map image memory\n");
> > +   bgrt_image = NULL;
> > +   return -ENOMEM;
> > +   }
> > +
> > bin_attr_image.private = bgrt_image;
> > bin_attr_image.size = bgrt_image_size;
> >  
> 
> Thanks,
> 
> Nicolai

Thanks
Dave

Re: [PATCH 1/4] staging: android/ion: Fix line over 80 characters

[Bogdan Purcareata]

On Thu, Jan 12, 2017 at 11:56 AM, Greg KH  wrote:
> On Thu, Jan 12, 2017 at 12:32:26PM +0300, Dan Carpenter wrote:
>> On Thu, Jan 12, 2017 at 09:54:16AM +0200, Bogdan Purcareata wrote:
>> > Signed-off-by: Bogdan Purcareata 
>>
>> All staging patches need a changelog, no matter how trivial.
>
> s/staging//g  :)

Will send a v2 with the changes.

Thank you!
Bogdan

[PATCH v2 00/18] FSI device driver introduction

[christopher . lee . bostic]

From: Chris Bostic 

Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.

This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.

In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.

The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.

The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.

Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.

This patch set does not include extended FSI function such as:
*  Hub master support
*  Cascaded master support
*  Application layer hot plug notification
*  Application layer FSI bus status interface

Common FSI terminology:

* Master
Controller of the FSI bus.  Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.

* Slave
The receiver or target of a master initiated transaction.  The slave
cannot initiate communications on a bus and must respond to any
master requests for data.

* CFAM
Stands for Common Field replaceable unit Access Macro.  A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.

* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.

* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.


Chris Bostic (8):
  drivers/fsi: Kick off master scan via sysfs
  drivers/fsi: Set up links for slave communication
  drivers/fsi: Set slave SMODE to init communication
  drivers/fsi: Remove all scanned devices during master unregister
  drivers/fsi: Add FSI bus documentation
  drivers/fsi: Add documentation for GPIO based FSI master
  drivers/fsi: Document FSI master sysfs files in ABI
  drivers/fsi: Add GPIO based FSI master

Jeremy Kerr (10):
  drivers/fsi: Add empty fsi bus definitions
  drivers/fsi: Add device & driver definitions
  drivers/fsi: add driver to device matches
  drivers/fsi: Add fsi master definition
  drivers/fsi: Add slave definition
  drivers/fsi: Add empty master scan
  drivers/fsi: Add FSI crc calculators to library
  drivers/fsi: Implement slave initialisation
  drivers/fsi: scan slaves & register devices
  drivers/fsi: Add device read/write/peek functions

Changes for v2:
- Change from atomic global for master number to ida simple
  interface.
- Add valid pointer checks on register and unregister utils.
- Move CRC calculation utilities out of driver to lib path.
- Clean up white space issues.
- Remove added list management of master devices and use
  instead the device_for_each_child method available in the
  bus.
- Add new patch to document FSI bus functionality.
- Add new patch documenting FSI gpio master.
- Rearrage patch set to have documentation earlier than code
  implementing it.
- Document all comptible strings used in device tree bindings.
- Elaborate documentation definition of FSI GPIO master.
- Describe in more detail what each GPIO FSI master pin is for.
- Re-order compatible strings in example binding so that most
  specific device comes first.
- Indicate proper activation order of all FSI GPIO master pins.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example bindings individually.
- Add new patch documenting sysfs-bus-fsi attributes.
- Merge FSI GPIO master init into probe function.
- Set pin initial values at time of pin request.
- Assign value of master->master.dev at probe time.
- Use get_optional interfac for all optional GPIO pins.


 Documentation/ABI/testing/sysfs-bus-fsi|   6 +
 .../devicetree/bindings/fsi/fsi-master-gpio.txt|  71 +++
 Documentation/devicetree/bindings/fsi/fsi.txt  |  54 +++
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/fsi/Kconfig|  23 +
 drivers/fsi/Makefile   |   3 +
 drivers/fsi/fsi-core.c

Re: [PATCH 10/10] blk-mq-sched: allow setting of default IO scheduler

[Bart Van Assche]

On Wed, 2017-01-11 at 14:40 -0700, Jens Axboe wrote:
> Add Kconfig entries to manage what devices get assigned an MQ
> scheduler, and add a blk-mq flag for drivers to opt out of scheduling.
> The latter is useful for admin type queues that still allocate a blk-mq
> queue and tag set, but aren't use for normal IO.

Reviewed-by: Bart Van Assche 

Re: [PATCH 07/10] blk-mq: abstract out helpers for allocating/freeing tag maps

[Jens Axboe]

On Thu, Jan 12 2017, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 14:40 -0700, Jens Axboe wrote:
> > @@ -2392,12 +2425,12 @@ int blk_mq_alloc_tag_set(struct blk_mq_tag_set *set)
> > if (set->nr_hw_queues > nr_cpu_ids)
> > set->nr_hw_queues = nr_cpu_ids;
> >  
> > +   ret = -ENOMEM;
> > set->tags = kzalloc_node(nr_cpu_ids * sizeof(struct blk_mq_tags *),
> >  GFP_KERNEL, set->numa_node);
> > if (!set->tags)
> > return -ENOMEM;
> >  
> > -   ret = -ENOMEM;
> > set->mq_map = kzalloc_node(sizeof(*set->mq_map) * nr_cpu_ids,
> > GFP_KERNEL, set->numa_node);
> > if (!set->mq_map)
> 
> Not that it matters to me, but this change probably isn't needed?

Huh oops no, I'll move that back where it belongs.

-- 
Jens Axboe

[PATCH v2 02/18] drivers/fsi: add driver to device matches

[christopher . lee . bostic]

From: Jeremy Kerr 

Driver bind to devices based on the engine types & (optional) versions.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Chris Bostic 
---
 drivers/fsi/fsi-core.c | 21 +
 include/linux/fsi.h| 21 +++--
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 3e45306..3d55bd5 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -19,8 +19,29 @@
 
 /* FSI core & Linux bus type definitions */
 
+static int fsi_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct fsi_device *fsi_dev = to_fsi_dev(dev);
+   struct fsi_driver *fsi_drv = to_fsi_drv(drv);
+   const struct fsi_device_id *id;
+
+   if (!fsi_drv->id_table)
+   return 0;
+
+   for (id = fsi_drv->id_table; id->engine_type; id++) {
+   if (id->engine_type != fsi_dev->engine_type)
+   continue;
+   if (id->version == FSI_VERSION_ANY ||
+   id->version == fsi_dev->version)
+   return 1;
+   }
+
+   return 0;
+}
+
 struct bus_type fsi_bus_type = {
.name   = "fsi",
+   .match  = fsi_bus_match,
 };
 EXPORT_SYMBOL_GPL(fsi_bus_type);
 
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index f73886a..273cbf6 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -18,11 +18,28 @@
 #include 
 
 struct fsi_device {
-   struct device dev;
+   struct device   dev;
+   u8  engine_type;
+   u8  version;
 };
 
+struct fsi_device_id {
+   u8  engine_type;
+   u8  version;
+};
+
+#define FSI_VERSION_ANY0
+
+#define FSI_DEVICE(t) \
+   .engine_type = (t), .version = FSI_VERSION_ANY,
+
+#define FSI_DEVICE_VERSIONED(t, v) \
+   .engine_type = (t), .version = (v),
+
+
 struct fsi_driver {
-   struct device_driver drv;
+   struct device_driverdrv;
+   const struct fsi_device_id  *id_table;
 };
 
 #define to_fsi_dev(devp) container_of(devp, struct fsi_device, dev)
-- 
1.8.2.2

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

[Al Viro]

On Thu, Jan 12, 2017 at 10:37:18PM +, Al Viro wrote:
> On Thu, Jan 12, 2017 at 02:26:42PM -0800, Linus Torvalds wrote:
> > On Thu, Jan 12, 2017 at 12:26 PM, Alan J. Wylie  wrote:
> > >
> > > Strace shows that the processes are hanging in write() and read() calls.
> > 
> > If this is splice-related, I'm assuming that they aren't actually the
> > two ends of the same pipe, and there is somebody doing splice in the
> > middle.
> > 
> > I'm not seeing that process. I'm assuming it's systemd.  Can you try
> > to find it and strace that one too? Because that middle man is likely
> > the one that has problems (and is not able to splice from one pipe to
> > the other).
> > 
> > Ugh. That one commit has had a lot of bugs in it already. We do not
> > have good splice test coverage, because almost nobody uses it.
> 
> FWIW, I would really like to know what kind of files had been involved.
> There are two paths that can lead to default_file_splice_read():
> splice_direct_to_actor() -> do_splice_to() -> default_file_splice_read() and
> do_splice() -> do_splice_to() -> default_file_splice_read().
> 
> The former only gets there for regular files and block devices.  The latter
> is guaranteed that file is not a pipe.  So
>   * not a socket (have ->splice_read() of their own)
>   * not a pipe or FIFO (neither path allows those)
>   * not a block device (have ->splice_read() of their own)
>   * not a regular file on a normal local fs (ditto)
> 
> So what is it called for in that reproducer?

PS: what about the /proc/mounts contents?  If it's something 9p-backed kvm,
your bisect might have been caught on the bug I'd mentioned - if the breakage
you are seeing in 4.9.3 has started after that commit and before the
backport of the fix, your bisect could converge there.  Does the
reproducer trigger on 523ac9afc73a + cherry-pick of 8e54cadab447?

[patch v2] mm, memcg: do not retry precharge charges

[David Rientjes]

When memory.move_charge_at_immigrate is enabled and precharges are
depleted during move, mem_cgroup_move_charge_pte_range() will attempt to
increase the size of the precharge.

This can be allowed to do reclaim, but should not call the oom killer to
oom kill a process.  It's better to fail the attach rather than oom kill
a process attached to the memcg hierarchy.

Prevent precharges from ever looping by setting __GFP_NORETRY.  This was
probably the intention of the GFP_KERNEL & ~__GFP_NORETRY, which is
pointless as written.

Fixes: 0029e19ebf84 ("mm: memcontrol: remove explicit OOM parameter in charge 
path")
Signed-off-by: David Rientjes 
---
 mm/memcontrol.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4353,9 +4353,12 @@ static int mem_cgroup_do_precharge(unsigned long count)
return ret;
}
 
-   /* Try charges one by one with reclaim */
+   /*
+* Try charges one by one with reclaim, but do not retry.  This avoids
+* calling the oom killer when the precharge should just fail.
+*/
while (count--) {
-   ret = try_charge(mc.to, GFP_KERNEL & ~__GFP_NORETRY, 1);
+   ret = try_charge(mc.to, GFP_KERNEL | __GFP_NORETRY, 1);
if (ret)
return ret;
mc.precharge++;

Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn

[Alan J. Wylie]

at 14:26 on Thu 12-Jan-2017 Linus Torvalds (torva...@linux-foundation.org) 
wrote:

> > Strace shows that the processes are hanging in write() and read() calls.
> 
> If this is splice-related, I'm assuming that they aren't actually the
> two ends of the same pipe, and there is somebody doing splice in the
> middle.
> 
> I'm not seeing that process. I'm assuming it's systemd.  Can you try
> to find it and strace that one too?

strace -f -o /var/tmp/strace.txt systemd-nspawn -q -D /work/chroot.32 
--register=no date

full output at
https://wylie.me.uk/tmp/strace.txt

last few lines are:

13766 execve("/bin/date", ["date"], [/* 7 vars */] 
...
13766 close(2)  = 0
13766 exit_group(0) = ?
13766 +++ exited with 0 +++
13761 <... epoll_wait resumed> [{EPOLLIN, {u32=3843638720, 
u64=94179591538112}}], 7, -1) = 1
13761 clock_gettime(CLOCK_BOOTTIME, {9780, 528425388}) = 0
13761 read(13, 
"\21\0\0\0\0\0\0\0\1\0\0\0\3065\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 128) = 
128
13761 epoll_ctl(11, EPOLL_CTL_DEL, 1, NULL) = 0
13761 epoll_ctl(11, EPOLL_CTL_DEL, 5, NULL) = 0
13761 signalfd4(13, [INT TERM CHLD], 8, SFD_CLOEXEC|SFD_NONBLOCK) = 13
13761 fcntl(0, F_GETFL) = 0 (flags O_RDONLY)
13761 fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY)
13761 kill(13766, SIGKILL)  = 0
13761 waitid(P_PID, 13766, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13766, 
si_uid=0, si_status=0, si_utime=0, si_stime=0}, WEXITED, NULL) = 0
13761 close(6)  = 0
13761 close(7)  = 0
13761 close(8)  = 0
13761 close(9)  = 0
13761 close(18) = 0
13761 close(16) = 0
13761 close(14) = 0
13761 close(10) = 0
13761 copy_file_range(5, NULL, 1, NULL, 9223372036854775807, 0) = -1 EXDEV 
(Invalid cross-device link)
13761 sendfile(1, 5, NULL, 9223372036854775807) = -1 EINVAL (Invalid argument)
13761 splice(5, NULL, 1, NULL, 9223372036854775807, 0) = -1 EAGAIN (Resource 
temporarily unavailable)
13761 open("/run/systemd/nspawn/propagate/chroot.32", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 6
13761 fstatfs(6, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=1020327, 
f_bfree=1015931, f_bavail=1015931, f_files=1020327, f_ffree=1019297, f_fsid={0, 
0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV}) = 0
13761 fstat(6, {st_mode=S_IFDIR|0600, st_size=40, ...}) = 0
13761 fcntl(6, F_GETFL) = 0x78800 (flags 
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME)
13761 fcntl(6, F_SETFD, FD_CLOEXEC) = 0
13761 getdents(6, /* 2 entries */, 32768) = 48
13761 getdents(6, /* 0 entries */, 32768) = 0
13761 close(6)  = 0
13761 rmdir("/run/systemd/nspawn/propagate/chroot.32") = 0
13761 unlink("/work/.#chroot.32.lck")   = 0
13761 close(3)  = 0
13761 unlink("/run/systemd/nspawn/locks/inode-65035:24641537") = 0
13761 close(4)  = 0
13761 close(5)  = 0
13761 exit_group(0) = ?
13761 +++ exited with 0 +++

I'm off to bed now with a stinking head cold I'm afraid.

-- 
Alan J. Wylie  http://www.wylie.me.uk/

Dance like no-one's watching. / Encrypt like everyone is.
Security is inversely proportional to convenience

Re: [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/12/2017 12:17 PM, David Miller wrote:

From: Vineeth Remanan Pillai 
Date: Wed, 11 Jan 2017 23:17:17 +


@@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int 
budget)
napi_complete(napi);
  
  		RING_FINAL_CHECK_FOR_RESPONSES(>rx, more_to_do);

-   if (more_to_do)
+
+   /* If there is more work to do or could not allocate
+* rx buffers, re-enable polling.
+*/
+   if (more_to_do || err != 0)
napi_schedule(napi);

Just polling endlessly in a loop retrying the SKB allocation over and over
again until it succeeds is not very nice behavior.

You already have that refill timer, so please use that to retry instead
of wasting cpu cycles looping in NAPI poll.

Thanks Dave for the inputs.
On further look, I think I can fix it much simpler by correcting the 
test condition

for minimum slots for pushing requests. Existing test is like this:


/* Not enough requests? Try again later. */
   if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
mod_timer(>rx_refill_timer, jiffies + (HZ/10));
return;
}


Actually the above check counts more than the newly created request slots
as it counts from rsp_cons. The actual count should be the difference 
between
new req_prod and old req_prod(in the queue). If skbs cannot be created, 
this
count remains small and hence we would schedule the timer. So the fix 
could be:


/* Not enough requests? Try again later. */
-   if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+   if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {


I have done some initial testing to verify the fix. Will send out v2 
patch after couple

more round of testing.

Thanks,
Vineeth

Re: [PATCH] can: Fix kernel panic at security_sock_rcv_skb

[Eric Dumazet]

On Thu, 2017-01-12 at 14:40 -0800, william.c.robe...@intel.com wrote:
> From: Zhang Yanmin 
> 
> The patch is for fix the below kernel panic:
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [] selinux_socket_sock_rcv_skb+0x65/0x2a0

Same patch was sent earlier, and we gave a feedback on it.

Adding synchronize_rcu() calls is a step backward.

https://patchwork.ozlabs.org/patch/714446/

Re: [PATCH V2] usb: dwc2: host: fix Wmaybe-uninitialized warning

[John Youn]

On 1/12/2017 8:32 AM, Nicholas Mc Guire wrote:
> Uninitialized char* causes a sparse build-warning, fix it up by
> initializing it to NULL.
> 
> Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
> ---
> 
> V2: add missing change-log as requested by Greg Kroah-Hartman 
> <gre...@linuxfoundation.org> 
> 
> Problem reported by sparse
> drivers/usb/dwc2/hcd.c: In function 'dwc2_dump_urb_info':
> ./include/linux/dynamic_debug.h:134:3: warning: 'pipetype' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>__dynamic_dev_dbg(, dev, fmt, \
>^
> drivers/usb/dwc2/hcd.c:4492:8: note: 'pipetype' was declared here
>   char *pipetype;
> ^
> Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2=m +
> CONFIG_USB_DWC2_VERBOSE=y
> 
> Patch is against 4.10-rc3 (localversion-next is next-20170112)
> 
>  drivers/usb/dwc2/hcd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 911c3b3..9f66777 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -4489,8 +4489,8 @@ static void dwc2_dump_urb_info(struct usb_hcd *hcd, 
> struct urb *urb,
>  {
>  #ifdef VERBOSE_DEBUG
>   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> - char *pipetype;
> - char *speed;
> + char *pipetype = NULL;
> + char *speed = NULL;
>  
>   dev_vdbg(hsotg->dev, "%s, urb %p\n", fn_name, urb);
>   dev_vdbg(hsotg->dev, "  Device address: %d\n",
> 

+Felipe

Acked-by: John Youn <johny...@synopsys.com>

John

Re: [PATCH] usb: dwc2: host: use msleep() for long delays

[John Youn]

On 1/12/2017 7:52 AM, Nicholas Mc Guire wrote:
> ulseep_range() uses hrtimers and provides no advantage over msleep()
> for larger delays. Fix up the 20+ ms delays here passing the adjusted "min"
> value to msleep(). This helps reduce the load on the hrtimer subsystem.
> 
> Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
> ---
> 
> Patch was compile tested with: x86_64_defconfig + CONFIG_USB_DWC2
> (1 sparse and 6 coccinelle warning - preparing separate patches for that)
> 
> Patch is against 4.10-rc3 (localversion-next is next-20170112)
> 
>  drivers/usb/dwc2/hcd.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 911c3b3..37ee72d 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -2150,7 +2150,7 @@ static int dwc2_hcd_endpoint_disable(struct dwc2_hsotg 
> *hsotg,
>   }
>  
>   spin_unlock_irqrestore(>lock, flags);
> - usleep_range(2, 4);
> + msleep(20);
>   spin_lock_irqsave(>lock, flags);
>   qh = ep->hcpriv;
>   if (!qh) {
> @@ -3240,7 +3240,7 @@ static void dwc2_conn_id_status_change(struct 
> work_struct *work)
>"Waiting for Peripheral Mode, Mode=%s\n",
>dwc2_is_host_mode(hsotg) ? "Host" :
>"Peripheral");
> - usleep_range(2, 4);
> + msleep(20);
>   if (++count > 250)
>   break;
>   }
> @@ -3261,7 +3261,7 @@ static void dwc2_conn_id_status_change(struct 
> work_struct *work)
>   dev_info(hsotg->dev, "Waiting for Host Mode, Mode=%s\n",
>dwc2_is_host_mode(hsotg) ?
>"Host" : "Peripheral");
> - usleep_range(2, 4);
> + msleep(20);
>   if (++count > 250)
>   break;
>   }
> @@ -3354,7 +3354,7 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, 
> u16 windex)
>  
>   spin_unlock_irqrestore(>lock, flags);
>  
> - usleep_range(20, 25);
> + msleep(200);
>   } else {
>   spin_unlock_irqrestore(>lock, flags);
>   }
> @@ -3378,7 +3378,7 @@ static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
>   pcgctl &= ~PCGCTL_STOPPCLK;
>   dwc2_writel(pcgctl, hsotg->regs + PCGCTL);
>   spin_unlock_irqrestore(>lock, flags);
> - usleep_range(2, 4);
> + msleep(20);
>   spin_lock_irqsave(>lock, flags);
>   }
>  
> @@ -3691,7 +3691,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
> *hsotg, u16 typereq,
>   }
>  
>   /* Clear reset bit in 10ms (FS/LS) or 50ms (HS) */
> - usleep_range(5, 7);
> + msleep(50);
>   hprt0 &= ~HPRT0_RST;
>   dwc2_writel(hprt0, hsotg->regs + HPRT0);
>   hsotg->lx_state = DWC2_L0; /* Now back to On state */
> 

+Felipe

Acked-by: John Youn <johny...@synopsys.com>

I've also fixed this up locally to apply against recent dwc2 patches
for next.

Hi Felipe,

If/when you queue the pending dwc2 patches on testing/next I can
resend this to you.

Regards,
John

Re: [PATCHv5 3/8] rtc: add STM32 RTC driver

[Alexandre Belloni]

On 11/01/2017 at 14:46:43 +0100, Amelie Delaunay wrote :
> This patch adds support for the STM32 RTC.
> 
> Signed-off-by: Amelie Delaunay 
> ---
>  drivers/rtc/Kconfig |  11 +
>  drivers/rtc/Makefile|   1 +
>  drivers/rtc/rtc-stm32.c | 727 
> 
>  3 files changed, 739 insertions(+)
>  create mode 100644 drivers/rtc/rtc-stm32.c
> 

This didn't apply cleanly, please check rtc-next. I don't think I made
any mistake as the issue was only in Kconfig. You probably based your
patches on 4.9 instead of 4.10-rc1.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCHv3 2/8] dt-bindings: document the STM32 RTC bindings

[Alexandre Belloni]

On 05/01/2017 at 14:43:23 +0100, Amelie Delaunay wrote :
> This patch adds documentation of device tree bindings for the STM32 RTC.
> 
> Signed-off-by: Amelie Delaunay 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/rtc/st,stm32-rtc.txt   | 27 
> ++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants

[Dilger, Andreas]

> On Jan 12, 2017, at 08:37, Michal Hocko  wrote:
> 
> From: Michal Hocko 
> 
> There are many code paths opencoding kvmalloc. Let's use the helper
> instead. The main difference to kvmalloc is that those users are usually
> not considering all the aspects of the memory allocator. E.g. allocation
> requests < 64kB are basically never failing and invoke OOM killer to
> satisfy the allocation. This sounds too disruptive for something that
> has a reasonable fallback - the vmalloc. On the other hand those
> requests might fallback to vmalloc even when the memory allocator would
> succeed after several more reclaim/compaction attempts previously. There
> is no guarantee something like that happens though.
> 
> This patch converts many of those places to kv[mz]alloc* helpers because
> they are more conservative.
> 
> Signed-off-by: Michal Hocko 

Lustre part can be
Acked-by: Andreas Dilger 

[snip]

> diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-mem.c 
> b/drivers/staging/lustre/lnet/libcfs/linux/linux-mem.c
> index a6a76a681ea9..8f638267e704 100644
> --- a/drivers/staging/lustre/lnet/libcfs/linux/linux-mem.c
> +++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-mem.c
> @@ -45,15 +45,6 @@ EXPORT_SYMBOL(libcfs_kvzalloc);
> void *libcfs_kvzalloc_cpt(struct cfs_cpt_table *cptab, int cpt, size_t size,
> gfp_t flags)
> {
> - void *ret;
> -
> - ret = kzalloc_node(size, flags | __GFP_NOWARN,
> -cfs_cpt_spread_node(cptab, cpt));
> - if (!ret) {
> - WARN_ON(!(flags & (__GFP_FS | __GFP_HIGH)));
> - ret = vmalloc_node(size, cfs_cpt_spread_node(cptab, cpt));
> - }
> -
> - return ret;
> + return kvzalloc_node(size, flags, cfs_cpt_spread_node(cptab, cpt));
> }
> EXPORT_SYMBOL(libcfs_kvzalloc_cpt);

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Rob Gardner]

On 01/12/2017 05:22 PM, Khalid Aziz wrote:

On 01/12/2017 10:53 AM, Dave Hansen wrote:

On 01/12/2017 08:50 AM, Khalid Aziz wrote:

2. Any shared page that has ADI protection enabled on it, must stay ADI
protected across all processes sharing it.


Is that true?

What happens if a page with ADI tags set is accessed via a PTE without
the ADI enablement bit set?


ADI protection applies across all processes in terms of all of them 
must use the same tag to access the shared memory, but if a process 
accesses a shared page with TTE.mcde bit cleared, access will be granted.





COW creates an intersection of the two. It creates a new copy of the
shared data. It is a new data page and hence the process creating it
must be the one responsible for enabling ADI protection on it.


Do you mean that the application must be responsible?  Or the kernel
running in the context of the new process must be responsible?


It is also a copy of what was ADI protected data, so should it
inherit the protection instead?


I think the COW'd copy must inherit the VMA bit, the PTE bits, and the
tags on the cachelines.


I misspoke earlier. I had misinterpreted the results of test I ran.
Changing the tag on shared memory is allowed by memory controller. The
requirement is every one sharing the page must switch to the new tag or
else they get SIGSEGV.


I asked this in the last mail, but I guess I'll ask it again. Please
answer this directly.

If we require that everyone coordinate their tags on the backing
physical memory, and we allow a lower-privileged program to access the
same data as a more-privileged one, then the lower-privilege app can
cause arbitrary crashes in the privileged application.

For instance, say sudo mmap()'s /etc/passwd and uses ADI tags to protect
the mapping.  Couldn't any other app in the system prevent sudo from
working?

How can we *EVER* allow tags to be set on non-writable mappings?


I don't think you can write a tag to memory if you don't have write 
access in the TTE. Writing a tag requires a store instruction, and if 
the machine is at all sane, this will fault if you don't have write access.


Rob





I understand your quetion better now. That is a very valid concern. 
Using ADI tags to prevent an unauthorized process from just reading 
data in memory, say an in-memory copy of database, is one of the use 
cases for ADI. This means there is a reasonable case to allow enabling 
ADI and setting tags even on non-writable mappings. On the other hand, 
if an unauthorized process manages to map the right memory pages in 
its address space, it can read them any way by not setting TTE.mcd.


Userspace app can set tag on any memory it has mapped in without 
requiring assistance from kernel. Can this problem be solved by not 
allowing setting TTE.mcd on non-writable mappings? Doesn't the same 
problem occur on writable mappings? If a privileged process mmap()'s a 
writable file with MAP_SHARED, enables ADI and sets tag on the mmap'd 
memory region, then another lower privilege process mmap's the same 
file writable (assuming file permissions allow it to), enables ADI and 
sets a different tag on it, the privileged process would get SIGSEGV 
when it tries to access the mmap'd file. Right?

[PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

[Paul E. McKenney]

The current preemptible RCU implementation goes through three phases
during bootup.  In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running.  During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending).  In the third and final phase, RCU is fully operational and
everything works normally.

This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase.

This commit accomplishes this by setting a flag from the existing
rcu_scheduler_starting() function which causes all synchronous grace
periods to take the expedited path.  The expedited path now checks this
flag, using the requesting task to drive the expedited grace period
forward during the mid-boot phase.  Finally, this flag is updated by a
core_initcall() function named rcu_exp_runtime_mode(), which causes the
runtime codepaths to be used.

Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.

Reported-by: "Zheng, Lv" 
Reported-by: Borislav Petkov 
Signed-off-by: Paul E. McKenney 

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 321f9ed552a9..01f71e1d2e94 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -444,6 +444,10 @@ bool __rcu_is_watching(void);
 #error "Unknown RCU implementation specified to kernel configuration"
 #endif
 
+#define RCU_SCHEDULER_INACTIVE 0
+#define RCU_SCHEDULER_INIT 1
+#define RCU_SCHEDULER_RUNNING  2
+
 /*
  * init_rcu_head_on_stack()/destroy_rcu_head_on_stack() are needed for dynamic
  * initialization and destruction of rcu_head on the stack. rcu_head structures
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 80adef7d4c3d..0d6ff3e471be 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -136,6 +136,7 @@ int rcu_jiffies_till_stall_check(void);
 #define TPS(x)  tracepoint_string(x)
 
 void rcu_early_boot_tests(void);
+void rcu_test_sync_prims(void);
 
 /*
  * This function really isn't for public consumption, but RCU is special in
diff --git a/kernel/rcu/tiny_plugin.h b/kernel/rcu/tiny_plugin.h
index 196f0302e2f4..e3953bdee383 100644
--- a/kernel/rcu/tiny_plugin.h
+++ b/kernel/rcu/tiny_plugin.h
@@ -65,7 +65,7 @@ EXPORT_SYMBOL_GPL(rcu_scheduler_active);
 void __init rcu_scheduler_starting(void)
 {
WARN_ON(nr_context_switches() > 0);
-   rcu_scheduler_active = 1;
+   rcu_scheduler_active = RCU_SCHEDULER_RUNNING;
 }
 
 #endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 96c52e43f7ca..7bcce4607863 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -127,13 +127,16 @@ int rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total 
# rcu_nodes in use. */
 int sysctl_panic_on_rcu_stall __read_mostly;
 
 /*
- * The rcu_scheduler_active variable transitions from zero to one just
- * before the first task is spawned.  So when this variable is zero, RCU
+ * The rcu_scheduler_active variable transitions from
+ * RCU_SCHEDULER_INACTIVE to RCU_SCHEDULER_INIT just before the first
+ * task is spawned.  So when this variable is RCU_SCHEDULER_INACTIVE, RCU
  * can assume that there is but one task, allowing RCU to (for example)
  * optimize synchronize_rcu() to a simple barrier().  When this variable
  * is one, RCU must actually do all the hard work required to detect real
  * grace periods.  This variable is also used to suppress boot-time false
- * positives from lockdep-RCU error checking.
+ * positives from lockdep-RCU error checking.  Finally, this variable
+ * transitions from RCU_SCHEDULER_INIT to RCU_SCHEDULER_RUNNING after RCU
+ * is fully initialized, including all of its tasks having been spawned.
  */
 int rcu_scheduler_active __read_mostly;
 EXPORT_SYMBOL_GPL(rcu_scheduler_active);
@@ -3980,18 +3983,22 @@ static int __init rcu_spawn_gp_kthread(void)
 early_initcall(rcu_spawn_gp_kthread);
 
 /*
- * This function is invoked towards the end of the scheduler's initialization
- * process.  Before this is called, the idle task might contain
- * RCU read-side critical sections (during which time, this idle
- * task is booting the system).  After this function is called, the
- * idle tasks are prohibited from containing RCU read-side critical
- * sections.  This function also enables RCU lockdep checking.
+ * This function is invoked towards the end of the scheduler's
+ * initialization process.  Before this is called, the idle task might
+ * contain 

Re: [PATCH] usb: hcd: initialize hcd->flags to 0 when rm hcd

[wlf]

Hi Roger，

在 2017年01月12日 23:38, Roger Quadros 写道:

On 12/01/17 17:33, Alan Stern wrote:

On Thu, 12 Jan 2017, Roger Quadros wrote:


William,

On 12/01/17 14:03, William Wu wrote:

From: William wu 

On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.

If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.

[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus 
number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, 
disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@fe80: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [] dump_backtrace+0x0/0x160
[173.603596] [] show_stack+0x20/0x28
[173.603623] [] dump_stack+0x90/0xb0
[173.603650] [] __report_bad_irq+0x48/0xe8
[173.603674] [] note_interrupt+0x1e8/0x28c
[173.603698] [] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [] handle_irq_event+0x4c/0x7c
[173.603748] [] handle_fasteoi_irq+0xb4/0x124
[173.603777] [] generic_handle_irq+0x30/0x44
[173.603804] [] __handle_domain_irq+0x90/0xbc
[173.603827] [] gic_handle_irq+0xcc/0x188
...
[173.604500] [] el1_irq+0x80/0xf8
[173.604530] [] cpu_startup_entry+0x38/0x3cc
[173.604558] [] rest_init+0x8c/0x94
[173.604585] [] start_kernel+0x3d0/0x3fc
[173.604607] [<00b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [] usb_hcd_irq
[173.604673] Disabling IRQ #228

Signed-off-by: William wu 
Signed-off-by: William wu 
---
  drivers/usb/core/hcd.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 479e223..612fab6 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -3017,6 +3017,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
}
  
  	usb_put_invalidate_rhdev(hcd);

+   hcd->flags = 0;
  }
  EXPORT_SYMBOL_GPL(usb_remove_hcd);
  


I suggest to initialize hcd->flags to 0 in usb_add_hcd() instead.

cheers,
-roger

Roger, didn't you originally propose this very same patch in

http://marc.info/?l=linux-usb=146556415503583=2

(and of course, the earlier versions before v10)?  What happened to it?

Alan, You are right. That patch got lost in the ML. Looks like I didn't push it 
hard enough
and then forgot about it. Sorry.

William,

You don't need to do any changes. My earlier version was clearing the flag
in usb_add_hcd() and I guess Alan suggested to move it to usb_remove_hcd().

So your patch is good.
You can add my.

Acked-by: Roger Quadros 

cheers,
-roger

Thanks very much for your suggestion，I  will add acked-by immediately.

linux-next: build warning after merge of the rtc tree

[Stephen Rothwell]

Hi Alexandre,

After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

In file included from drivers/rtc/rtc-stm32.c:14:0:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
drivers/rtc/rtc-stm32.c:653:51: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
  regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
   ^
include/linux/regmap.h:73:42: note: in definition of macro 'regmap_update_bits'
  regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
  ^
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_remove':
drivers/rtc/rtc-stm32.c:675:51: warning: large integer implicitly truncated to 
unsigned type [-Woverflow]
  regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
   ^
include/linux/regmap.h:73:42: note: in definition of macro 'regmap_update_bits'
  regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
  ^

Introduced by commit

  4e64350f42e2 ("rtc: add STM32 RTC driver")

-- 
Cheers,
Stephen Rothwell