Re: [PATCH] sdhci: Add quirk and device tree parameter to force SD test mode

2016-08-24 Thread Adrian Hunter
On 24/08/16 01:14, Zach Brown wrote:
> On Tue, Aug 23, 2016 at 09:22:29AM +0300, Adrian Hunter wrote:
>> On 23/08/16 01:55, Zach Brown wrote:
>>> From: Jaeden Amero 
>>>
>>> On some devices, CD is broken so that we must force the SDHCI into test
>>> mode and set CD, so that it always detects an SD card as present.
>>>
>>> In order to get a device with broken CD working, we had previously
>>> always set the SDHCI into test mode. Unfortunately, this had the side
>>> effect of making all SD cards used with our Linux kernels undetectable
>>> and non-removable.
>>>
>>> By making this "SD test mode" setting optional via a quirk, we can avoid
>>> this side effect for devices other than the device with broken CD.
>>> Additionally, we add a device parameter to sdhci-pltfm to allow all
>>> SDHCI drivers to enable this quirk.
>>
>> Generally new quirks are not acceptable, but I don't see how test mode helps
>> very much since you still don't get any card detection events.  If you
>> really need test mode, please explain more about how it helps (as opposed to
>> polling for example).
>>
>>
> 
> Polling doesnt work in our case, since the issue lies with the SD controller
> itself. The SD controller in xilinx zynq devices requires the CDn signal to
> work. http://www.xilinx.com/support/answers/61064.html We have a situation 
> where the controller requires the signal, but we can't use any of our pins to
> supply it. With test mode we can get the controller into a state where it 
> works
> despite not having the signal.
> 

Doesn't sound like something we need in sdhci.c.  Have you considered adding
it to the driver, perhaps using the ->reset() callback?



Re: Why do we need reset_control_get_optional() ?

2016-08-24 Thread Masahiro Yamada
Hi Philipp,

2016-08-16 23:36 GMT+09:00 Masahiro Yamada :
> Hi Philipp, Arnd.
>
>
>
> 2016-08-09 1:39 GMT+09:00 Philipp Zabel :
>> Am Freitag, den 05.08.2016, 17:50 +0200 schrieb Arnd Bergmann:
>>> On Thursday, July 28, 2016 1:00:49 PM CEST Philipp Zabel wrote:
>>> > Am Donnerstag, den 28.07.2016, 19:52 +0900 schrieb Masahiro Yamada:
>>>
>>> > > > In my experimental patch, I make the _optional functions
>>> > > > return NULL if no "resets" property is provided but return
>>> > > > an error if there are reset lines but the subsystem is
>>> > > > disabled, i.e. an optional reset must be used if it's in the
>>> > > > DT, but can be ignored otherwise.
>>> > >
>>> > > I do not like this idea.
>>> > >
>>> > > reset_control_get() (or variants) should not return NULL, it is 
>>> > > ambiguous.
>>> > > It should return ERR_PTR(-ENOENT) if no "resets" property.
>>> > >
>>> > > I only want two types for functions that return a pointer.
>>> > >
>>> > > [1] return a valid pointer on success, or return NULL on failure
>>> > > (for example, kmalloc())
>>> > > [2] return a valid pointer on success, or return error pointer on 
>>> > > failure
>>> > >(many of _register() functions)
>>> > >
>>> > > Mixing [1] and [2] will be a mess.
>>>
>>> Ah, right. I was thinking only of the case where the reset subsystem
>>> is completely disabled here, so returning NULL could be considered
>>> a valid return code that can in turn be passed into the other
>>> functions.
>>>
>>> However, I agree that returning NULL as a valid result from
>>> ..._get_optional() would be bad style, so let's drop my idea
>>> there.
>>>
>>> > I too would prefer to keep that as-is. The reset_control_get_optional
>>> > stub could return -ENOENT if there is no resets device tree property.
>>>
>>> Now I'm also confused about what we really need
>>> reset_control_get_optional() for, and which error codes the callers
>>> are supposed to check.
>>>
>>> This is the matrix I think you mean for _get_optional:
>>>
>> [...]
>>> CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP
>>> CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT
>>
>> ^^ I didn't consider this distiction.
>>
>>> Is this what you had in mind? If so, what is the value of the
>>> added runtime warning for reset_control_get? Any caller of that
>>> function would already check for errors, the only difference
>>> I see is that callers of _optional can ignore -ENOENT.
>>
>> My initial motivation was to make it as hard as possible to misconfigure
>> the kernel, which is why I initially didn't want stubs for the
>> non-optional variant. Of course that would cause build failures and/or
>> reduced compile test coverage, so we added the stubs and the warning to
>> make it obvious when a misconfigured kernel is running: on a kernel with
>> RESET_CONTROLLER=n drivers that use reset_control_get are expected to
>> build, but they are not expected to work. I suppose the same is the case
>> for _optional, if the dt entry is present, so maybe we should drop
>> reset_control_get_optional and add always a warning in case of
>> -EOPNOTSUPP.
>> I don't want all drivers to have to differentiate between -EOPNOTSUPP
>> and -ENOENT error codes, only current reset_control_get_optional users
>> have to do that.
>
>
> I've posted a patch to drop reset_control_get_optional;
> https://patchwork.kernel.org/patch/9284063/
>
> Could you check if it works?
>
> If we go this way, my patch
> 289363fd99a17d6249ee1373541f1da43cbb22c5
> in your reset/next branch is completely useless.
>
> As the commits in the reset-subsystem do not appear
> even in linux-next until they are pulled into the ASOC tree,
> how about dropping 289363fd and turning around?
>


If you want to take time for this topic,
how about dropping 289363fd99a17d6249ee1373541f1da43cbb22c5
("reset: add WARN_ON(1) to non-optional reset_control_get variants")
for now?


I noticed some reset consumers already started dropping _optional,
while their reset lines should be really optional.

See
commit d0e08b0077f49e209bc90305ddf1ca434ac6cc0e
commit 62d9694a003dba585026df36c181e3ca930aeafc

Even generic drivers such as ehci-platform.c / ohci-platform.c
opted out of _optional.


If commit 289363fd99a17d6249ee1373541f1da43cbb22c5 is merged,
users of the generic drivers but without reset-controller
will start to complain about the WARN_ON(1)  sooner or later.


-- 
Best Regards
Masahiro Yamada


[PATCH] ASoC: tas5086: fix typo: "Inavlid" -> "Invalid"

2016-08-24 Thread Colin King
From: Colin Ian King 

trivial typo fix in dev_err message

Signed-off-by: Colin Ian King 
---
 sound/soc/codecs/tas5086.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c
index c297b9f..b7de857 100644
--- a/sound/soc/codecs/tas5086.c
+++ b/sound/soc/codecs/tas5086.c
@@ -387,7 +387,7 @@ static int tas5086_hw_params(struct snd_pcm_substream 
*substream,
val = index_in_array(tas5086_ratios, ARRAY_SIZE(tas5086_ratios),
 priv->mclk / priv->rate);
if (val < 0) {
-   dev_err(codec->dev, "Inavlid MCLK / Fs ratio\n");
+   dev_err(codec->dev, "Invalid MCLK / Fs ratio\n");
return -EINVAL;
}
 
-- 
2.9.3



Re: OOM detection regressions since 4.7

2016-08-24 Thread Joonsoo Kim
Looks like my mail client eat my reply so I resend.

On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote:
> On Tue 23-08-16 13:52:45, Joonsoo Kim wrote:
> [...]
> > Hello, Michal.
> > 
> > I agree with partial revert but revert should be a different form.
> > Below change try to reuse should_compact_retry() version for
> > !CONFIG_COMPACTION but it turned out that it also causes regression in
> > Markus report [1].
> 
> I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high
> order workloads that calling any change in that behavior a regression
> is little bit exaggerated. Disabling compaction should have a very
> strong reason. I haven't heard any so far. I am even wondering whether
> there is a legitimate reason for that these days.
> 
> > Theoretical reason for this regression is that it would stop retry
> > even if there are enough lru pages. It only checks if freepage
> > excesses min watermark or not for retry decision. To prevent
> > pre-mature OOM killer, we need to keep allocation loop when there are
> > enough lru pages. So, logic should be something like that.
> > 
> > should_compact_retry()
> > {
> > for_each_zone_zonelist_nodemask {
> > available = zone_reclaimable_pages(zone);
> > available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
> > if (__zone_watermark_ok(zone, *0*, min_wmark_pages(zone),
> > ac_classzone_idx(ac), alloc_flags, available))
> > return true;
> > 
> > }
> > }
> > 
> > I suggested it before and current situation looks like it is indeed
> > needed.
> 
> this just opens doors for an unbounded reclaim/threshing becacause
> you can reclaim as much as you like and there is no guarantee of a
> forward progress. The reason why !COMPACTION should_compact_retry only
> checks for the min_wmark without the reclaimable bias is that this will
> guarantee a retry if we are failing due to high order wmark check rather
> than a lack of memory. This condition is guaranteed to converge and the
> probability of the unbounded reclaim is much more reduced.

In case of a lack of memory with a lot of reclaimable lru pages, why 
do we stop reclaim/compaction?

With your partial reverting patch, allocation logic would be like as
following.

Assume following situation:
o a lot of reclaimable lru pages
o no order-2 freepage
o not enough order-0 freepage for min watermark
o order-2 allocation

1. order-2 allocation failed due to min watermark
2. go to reclaim/compaction
3. reclaim some pages (maybe SWAP_CLUSTER_MAX (32) pages) but still
min watermark isn't met for order-0
4. compaction is skipped due to not enough freepage
5. should_reclaim_retry() returns false because min watermark for
order-2 page isn't met
6. should_compact_retry() returns false because min watermark for
order-0 page isn't met
6. allocation is failed without any retry and OOM is invoked.

Is it what you want?

And, please elaborate more on how your logic guarantee to converge.
After order-0 freepage exceed min watermark, there is no way to stop
reclaim/threshing. Number of freepage just increase monotonically and
retry cannot be stopped until order-2 allocation succeed. Am I missing
something?


> > And, I still think that your OOM detection rework has some flaws.
> >
> > 1) It doesn't consider freeable objects that can be freed by shrink_slab().
> > There are many subsystems that cache many objects and they will be
> > freed by shrink_slab() interface. But, you don't account them when
> > making the OOM decision.
> 
> I fully rely on the reclaim and compaction feedback. And that is the
> place where we should strive for improvements. So if we are growing way
> too many slab objects we should take care about that in the slab reclaim
> which is tightly coupled with the LRU reclaim rather than up the layer
> in the page allocator.

No. slab shrink logic which is tightly coupled with the LRU reclaim
totally makes sense. What doesn't makes sense is the way of using
these functionality and utilizing these freebacks on your OOM
detection rework.

For example, compaction will do it's best with current resource. But,
as I said before, compaction will be more powerful if the system has
more free memory. Your logic just guarantee to give it to minimum
amount of free memory to run so I don't think it's result is
reliable to determine if we are in OOM or not.

And, your logic doesn't consider how many pages can be freed by slab
shrink. As I said before, there would exist high order reclaimable
page or we can make high order freepage by actual free.

Most importantly, I think that it is fundamentally impossible to
anticipate if we can make high order freepage or not by snapshot of
information about number of freeable page. So, your logic rely on
compaction but there are many types of pages that cannot be migrated
by compaction but can be reclaimed. So, fully relying on compaction
result for OOM decision wo

Re: OOM detection regressions since 4.7

2016-08-24 Thread Michal Hocko
On Wed 24-08-16 14:01:57, Joonsoo Kim wrote:
> Looks like my mail client eat my reply so I resend.
> 
> On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote:
> > On Tue 23-08-16 13:52:45, Joonsoo Kim wrote:
> > [...]
> > > Hello, Michal.
> > > 
> > > I agree with partial revert but revert should be a different form.
> > > Below change try to reuse should_compact_retry() version for
> > > !CONFIG_COMPACTION but it turned out that it also causes regression in
> > > Markus report [1].
> > 
> > I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high
> > order workloads that calling any change in that behavior a regression
> > is little bit exaggerated. Disabling compaction should have a very
> > strong reason. I haven't heard any so far. I am even wondering whether
> > there is a legitimate reason for that these days.
> > 
> > > Theoretical reason for this regression is that it would stop retry
> > > even if there are enough lru pages. It only checks if freepage
> > > excesses min watermark or not for retry decision. To prevent
> > > pre-mature OOM killer, we need to keep allocation loop when there are
> > > enough lru pages. So, logic should be something like that.
> > > 
> > > should_compact_retry()
> > > {
> > > for_each_zone_zonelist_nodemask {
> > > available = zone_reclaimable_pages(zone);
> > > available += zone_page_state_snapshot(zone, 
> > > NR_FREE_PAGES);
> > > if (__zone_watermark_ok(zone, *0*, min_wmark_pages(zone),
> > > ac_classzone_idx(ac), alloc_flags, available))
> > > return true;
> > > 
> > > }
> > > }
> > > 
> > > I suggested it before and current situation looks like it is indeed
> > > needed.
> > 
> > this just opens doors for an unbounded reclaim/threshing becacause
> > you can reclaim as much as you like and there is no guarantee of a
> > forward progress. The reason why !COMPACTION should_compact_retry only
> > checks for the min_wmark without the reclaimable bias is that this will
> > guarantee a retry if we are failing due to high order wmark check rather
> > than a lack of memory. This condition is guaranteed to converge and the
> > probability of the unbounded reclaim is much more reduced.
> 
> In case of a lack of memory with a lot of reclaimable lru pages, why 
> do we stop reclaim/compaction?
> 
> With your partial reverting patch, allocation logic would be like as
> following.
> 
> Assume following situation:
> o a lot of reclaimable lru pages
> o no order-2 freepage
> o not enough order-0 freepage for min watermark
> o order-2 allocation
> 
> 1. order-2 allocation failed due to min watermark
> 2. go to reclaim/compaction
> 3. reclaim some pages (maybe SWAP_CLUSTER_MAX (32) pages) but still
> min watermark isn't met for order-0
> 4. compaction is skipped due to not enough freepage
> 5. should_reclaim_retry() returns false because min watermark for
> order-2 page isn't met
> 6. should_compact_retry() returns false because min watermark for
> order-0 page isn't met
> 6. allocation is failed without any retry and OOM is invoked.

If the direct reclaim is not able to get us over min wmark for order-0
then we would be likely to hit the oom even for order-0 requests.

> Is it what you want?
> 
> And, please elaborate more on how your logic guarantee to converge.
> After order-0 freepage exceed min watermark, there is no way to stop
> reclaim/threshing. Number of freepage just increase monotonically and
> retry cannot be stopped until order-2 allocation succeed. Am I missing
> something?

My statement was imprecise at best. You are right that there is no
guarantee to fullfil order-2 request. What I meant to say is that we
should converge when we are getting out of memory (aka even order-0
would have hard time to succeed). should_reclaim_retry does that by
the back off scaling of the reclaimable pages. should_compact_retry
would have to do the same thing which would effectively turn it into
should_reclaim_retry.

> > > And, I still think that your OOM detection rework has some flaws.
> > >
> > > 1) It doesn't consider freeable objects that can be freed by 
> > > shrink_slab().
> > > There are many subsystems that cache many objects and they will be
> > > freed by shrink_slab() interface. But, you don't account them when
> > > making the OOM decision.
> > 
> > I fully rely on the reclaim and compaction feedback. And that is the
> > place where we should strive for improvements. So if we are growing way
> > too many slab objects we should take care about that in the slab reclaim
> > which is tightly coupled with the LRU reclaim rather than up the layer
> > in the page allocator.
> 
> No. slab shrink logic which is tightly coupled with the LRU reclaim
> totally makes sense.

Once the number of slab object is much larger than LRU pages (what we
have seen in some oom reports) then the way how they are coupled just
stops making a sense because the current app

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

2016-08-24 Thread Ley Foon Tan
On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas  wrote:
> On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote:
>> Altera PCIe IP can be configured as rootport or device and they might have
>> same vendor ID. It will cause the system hang issue if Altera PCIe is in
>> endpoint mode and work with other PCIe rootport that from other vendors.
>> So, add the rootport mode checking in link retrain fixup function.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>> v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT
>> ---
>>  drivers/pci/host/pcie-altera.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
>> index 58eef99..33b6968 100644
>> --- a/drivers/pci/host/pcie-altera.c
>> +++ b/drivers/pci/host/pcie-altera.c
>> @@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev)
>>   u16 linkcap, linkstat;
>>   struct altera_pcie *pcie = dev->bus->sysdata;
>>
>> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
>> + return;
>> +
>>   if (!altera_pcie_link_is_up(pcie))
>>   return;
>
> Instead of making this a PCI fixup, can you make an
> altera_pcie_host_init() function, call it from altera_pcie_probe(),
> and do the link retrain there?  Then you wouldn't need to worry about
> whether this is a Root Port or an Endpoint, plus it would make the
> altera driver structure more like the other drivers.
>
> You would call altera_pcie_host_init() before pci_scan_root_bus(), so
> you wouldn't have a pci_dev yet, so you wouldn't be able to use
> pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit.  But I
> assume there's some device-dependent way to access it using
> cra_writel()?
We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit. We can use
pci_bus_find_capability() and pci_bus_read_config_word() with struct
pci_bus instead.
But this only can be called after pci_scan_root_bus(). Found
iproc_pcie_check_link() have similar implementation.
Tested this method is working. Do you think it is okay? If yes, then I
will send in next revision.

Thanks.

Regards
Ley Foon


Re: of_clk_add_(hw_)providers multipule times for one node?

2016-08-24 Thread Masahiro Yamada
Hi Stephen,


2016-08-12 16:04 GMT+09:00 Masahiro Yamada :
> 2016-08-11 8:08 GMT+09:00 Stephen Boyd :
>> On 08/10, Masahiro Yamada wrote:
>>> Hi Stephen,
>>>
>>>
>>>
>>> 2016-08-09 8:37 GMT+09:00 Stephen Boyd :
>>> > On 08/08, Masahiro Yamada wrote:
>>> >> Hi Stephen,
>>> >>
>>> >>
>>> >> 2016-08-05 6:25 GMT+09:00 Stephen Boyd :
>>> >
>>> >>
>>> >> of_clk_add_provider() calls of_clk_del_provider()
>>> >> in its failure path.
>>> >>
>>> >> Notice of_clk_del_provider() unregister
>>> >> all the providers associated with the device node.
>>> >
>>> > Where is that? I see a break statement in the while loop after
>>> > the first matching np is found.
>>>
>>> Ah, I missed the "break".
>>>
>>> So, this works *almost* well.
>>>
>>> I mean *almost* because the of_clk_mutex is released
>>> between of_clk_add_hw_provider() and of_clk_del_provider().
>>>
>>> What if two providers are added concurrently.
>>> I know it never happens in use-cases we assume, though.
>>
>> Agreed, that would be bad. We can definitely do better in that
>> case and properly delete the provider that we have already
>> registered without calling of_clk_del_provider() though. We have
>> everything in the local scope at the time.
>>
>>>
>>>
>>> >>
>>> >> Some platform drivers call of_clk_del_provider() in a .remove callback,
>>> >> so the same problem could happen.
>>> >>
>>> >> Why does of_clk_del_provider() take (struct device_node *np) ?
>>> >> Shouldn't it take (struct of_clk_provider *cp)?
>>> >>
>>> >
>>> > Not sure. Probably someone thought they could hide the structure
>>> > from consumers and just return success or failure.
>>>
>>> consumers?   or did you mean providers?
>>> I think consumers have no chance to call of_clk_del_provider().
>>
>> Sorry, bad choice of words. I meant users of this
>> of_clk_add*_provider() API.
>>
>>>
>>>
>>> > The best we can do is have the framework only return probe defer
>>> > if there isn't a provider registered. Once a provider is
>>> > registered, it needs to do the right thing and return the
>>> > appropriate error (invalid or probe defer for example) at the
>>> > right time.
>>>
>>> Agreed.
>>
>> Ok. I think I will merge my patch then to restore previous
>> behavior.
>>
>>>
>>> Lastly, we have two solutions so far.  Which do you think is better?
>>>
>>> One solution is, as others suggested,
>>> CLK_OF_DECLARE() can allocate a bigger array than it needs,
>>> so that blank entries can be filled by a platfrom_driver later.
>>>
>>>
>>> The other way is,
>>> CLK_OF_DECLARE() and a platfrom_driver
>>> allocate separate of_clk_provider for each of them.
>>>
>>
>> I believe we have precedence for the former case, so there's some
>> momentum around that approach. It doesn't make me feel great
>> though because we have published the provider before all clks are
>> registered, and then we go back and modify the array in place
>> while consumers could potentially be using it. I suppose we're
>> saved because cpus access the pointer in the array and only see
>> the whole pointer and not half of the old one and half of the new
>> one?
>
>
> I am not sure.
>
> But, maybe just filling the blank entries of the array seems safe.
> In this case, filling should be done at the end of the probe callback.
> Otherwise, devm_clk_hw_register() will free the clk_hw when the driver
> is detached.
>

Looks like the whole of my series was rejected,
but I was not sure why the following one was rejected.
https://patchwork.kernel.org/patch/9236563/


Could you explain why -EPROBE_DEFER should be returned
if both .get_hw and .get are missing.


Is there a way to register an OF clk provider without .get(_hw),
but fill it later or something?



-- 
Best Regards
Masahiro Yamada


Re: [PATCH 5/5] arm64: Add uprobe support

2016-08-24 Thread Pratyush Anand
Hi Oleg,

Thanks a lot for your review, and sorry for delayed response.

On 09/08/2016:08:49:44 PM, Oleg Nesterov wrote:
> On 08/02, Pratyush Anand wrote:
> >
> > This patch adds support for uprobe on ARM64 architecture.
> 
> I know nothing about ARM, so I can't actually review this change.
> But it looks good to me ;)
> 
> Just one note,
> 
> > +int arch_uprobe_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> > +{
> > +   struct uprobe_task *utask = current->utask;
> > +
> > +   /* saved fault code is restored in post_xol */
> > +   utask->autask.saved_fault_code = current->thread.fault_code;
> > +
> > +   /* An invalid fault code between pre/post xol event */
> > +   current->thread.fault_code = UPROBE_INV_FAULT_CODE;
> > +
> > +   /* Instruction point to execute ol */
> > +   instruction_pointer_set(regs, utask->xol_vaddr);
> > +
> > +   user_enable_single_step(current);
> 
> I don't think we want user_{enable,disable{_single_step in the long term,
> please look at 9bd1190a11c9d2 "uprobes/x86: Do not (ab)use TIF_SINGLESTEP
> /user_*_single_step() for single-stepping". it seems that ARM64 sets/clears
> TIF_SINGLESTEP. You can also lool at saved_tf logic, probably ARM64 needs
> the same.

IIUC, then you mean that TIF_SINGLESTEP is a per task flag, while
arch_uprobe_pre/post_xol() should enable/disable single stepping using a per
uprobe_task, and we should have a flag in "struct arch_uprobe_task" to handle
this, right?

> 
> However, I agree we can do this later and initial version can use these
> ptrace helpers.

Yes, I would also like to do that change latter, because these set of patches
have already been tested heavily with systemtap, so it would be better to go
with an incremental changes latter on.

~Pratyush


Re: [PATCH v2 1/4] ARM: dts: exynos: Enable HDMI for Arndale Octa board

2016-08-24 Thread Milo Kim

Hi Andrzej,

On 08/24/2016 02:28 PM, Andrzej Hajda wrote:

Please use ddc property in hdmi node, instead of this legacy binding.
See exynos4210-universal_c210.dts or exynos4412-odroid-common.dtsi for
reference.


Cool! I prefer this simple property. Thanks for the review.

Best regards,
Milo


RE: [PATCH v1 1/5] dma: Add QorIQ qDMA engine driver support

2016-08-24 Thread Yao Yuan
On Thu, Aug 18, 2016 at 05:16 PM +0800, Russell King wrote:
> On Thu, Aug 18, 2016 at 02:38:44PM +0800, Yuan Yao wrote:
> > +   spin_lock(&fsl_comp->qchan->vchan.lock);
> > +   if (status == DMA_COMPLETE)
> > +   vchan_cookie_complete(&fsl_comp->vdesc);
> > +   fsl_comp->qchan->status = status;
> 
> This is buggy - if the DMA has finished processing it, even if it finished in 
> error, it
> must _complete_ the transaction.  Completion is not the same as being
> successful - it means that the DMA is no longer processing the cookie.
> 
> The issue here is that when the _following_ transaction completes 
> successfully,
> _this_ transaction will effectively be marked as complete due to the way the
> cookie system works.
> 
> So... to get this straight - "completion" means "I have finished processing 
> this
> transaction".  It does not mean "I successfully processed this transaction
> without any errors."
> 

Thanks for your review.
So you mean that I should call vchan_cookie_complete no matter whether the 
error issue in QDMA?
I have some random DMA error test case, it seems work will.


Re: [PATCH v2 3/4] gpu: drm: exynos_hdmi: Use consolidated function on binding DDC DT property

2016-08-24 Thread Milo Kim

Hi Andrzej,

On 08/24/2016 02:55 PM, Andrzej Hajda wrote:

This is mistake introduced  by other patch, of_node_put should be called on
np, after calling of_find_i2c_adapter_by_node. You can fix it in your
patch as well.
I think you can move of_find_i2c_adapter_by_node also to this function and
rename it to sth like hdmi_get_ddc_adapter, this way you will enclose
whole logic
of getting resource into one function.


Agree, let me prepare next patch-set. Thanks!

Best regards,
Milo


Re: [PATCH v2] serial: vt8500_serial: Fix a parameter of find_first_zero_bit.

2016-08-24 Thread Arnd Bergmann
On Wednesday, August 24, 2016 7:06:58 AM CEST Christophe JAILLET wrote:
> The 2nd parameter of 'find_first_zero_bit' is the number of bits to search.
> In this case, we are passing 'sizeof(vt8500_ports_in_use)'.
> 'vt8500_ports_in_use' is an 'unsigned long'. So the sizeof is likely to
> return 4 on a 32 bits kernel.
> 
> A few lines below, we check if it is below VT8500_MAX_PORTS, which is 6.
> 
> It is likely that the number of bits in a long was expected here.
> 
> In order to fix it:
>- use DECLARE_BITMAP when declaring the vt8500_ports_in_use
>- use VT8500_MAX_PORTS as a maximum value when checking/setting bits in
>  this bitmap
>- modify code now that 'vt8500_ports_in_use' has become a pointer
>  because of the use of DECLARE_BITMAP
> 
> 
> It has been spotted by the following coccinelle script:
> @@
> expression ret, x;
> 
> @@
> *  ret = \(find_first_bit \| find_first_zero_bit\) (x, sizeof(...));
> 
> Signed-off-by: Christophe JAILLET 
> ---
> v2: - use of VT8500_MAX_PORTS instead of BITS_PER_LONG to better self
>   document the code
> - declare vt8500_ports_in_use with DECLARE_BITMAP in order to self
>   document even better and to be foolproof should VT8500_MAX_PORTS
>   be changed one day

Reviewed-by: Arnd Bergmann 


Re: [PATCH 0/5] ARM64: Uprobe support added

2016-08-24 Thread Pratyush Anand
Hi Will/Catalin,

Do you have any specific comment for this patch set?

~Pratyush

[1] https://lkml.org/lkml/2016/8/22/69

On 02/08/2016:11:00:04 AM, Pratyush Anand wrote:
> ARM64 kprobe support is lying in torvalds/linux.git:master now. Therefore
> sending my uprobe patches which were dependent on decode-insn code of kprobe
> patches.
> 
> Unit tests for following have been done so far and they have been found
> working.
>  1. Step-able instructions, like sub, ldr, add etc.
>  2. Simulation-able like ret, cbnz, cbz etc.
>  3. uretprobe
>  4. Reject-able instructions like sev, wfe etc.
>  5. trapped and abort xol path
>  6. probe at unaligned user address.
>  7. longjump test cases
>  
> Currently it does not support aarch32 instruction probing.
> 
> RFC patches were sent long back, and all review comments for RFCs have been
> incorporated. RFCs were here: https://lwn.net/Articles/648514/
> 
> Pratyush Anand (5):
>   arm64: kprobe: protect/rename few definitions to be reused by uprobe
>   arm64: kgdb_step_brk_fn: ignore other's exception
>   arm64: Handle TRAP_HWBRKPT for user mode as well
>   arm64: Handle TRAP_BRKPT for user mode as well
>   arm64: Add uprobe support
> 
>  arch/arm64/Kconfig  |   3 +
>  arch/arm64/include/asm/debug-monitors.h |   3 +
>  arch/arm64/include/asm/probes.h |  23 ++--
>  arch/arm64/include/asm/ptrace.h |   8 ++
>  arch/arm64/include/asm/thread_info.h|   5 +-
>  arch/arm64/include/asm/uprobes.h|  37 ++
>  arch/arm64/kernel/debug-monitors.c  |  40 +++---
>  arch/arm64/kernel/entry.S   |   6 +-
>  arch/arm64/kernel/kgdb.c|   3 +
>  arch/arm64/kernel/probes/Makefile   |   2 +
>  arch/arm64/kernel/probes/decode-insn.c  |  31 ++---
>  arch/arm64/kernel/probes/decode-insn.h  |   8 +-
>  arch/arm64/kernel/probes/kprobes.c  |  36 ++---
>  arch/arm64/kernel/probes/uprobes.c  | 227 
> 
>  arch/arm64/kernel/signal.c  |   4 +-
>  arch/arm64/mm/flush.c   |   6 +
>  16 files changed, 378 insertions(+), 64 deletions(-)
>  create mode 100644 arch/arm64/include/asm/uprobes.h
>  create mode 100644 arch/arm64/kernel/probes/uprobes.c
> 
> -- 
> 2.5.5


Re: OOM detection regressions since 4.7

2016-08-24 Thread Joonsoo Kim
2016-08-24 16:04 GMT+09:00 Michal Hocko :
> On Wed 24-08-16 14:01:57, Joonsoo Kim wrote:
>> Looks like my mail client eat my reply so I resend.
>>
>> On Tue, Aug 23, 2016 at 09:33:18AM +0200, Michal Hocko wrote:
>> > On Tue 23-08-16 13:52:45, Joonsoo Kim wrote:
>> > [...]
>> > > Hello, Michal.
>> > >
>> > > I agree with partial revert but revert should be a different form.
>> > > Below change try to reuse should_compact_retry() version for
>> > > !CONFIG_COMPACTION but it turned out that it also causes regression in
>> > > Markus report [1].
>> >
>> > I would argue that CONFIG_COMPACTION=n behaves so arbitrary for high
>> > order workloads that calling any change in that behavior a regression
>> > is little bit exaggerated. Disabling compaction should have a very
>> > strong reason. I haven't heard any so far. I am even wondering whether
>> > there is a legitimate reason for that these days.
>> >
>> > > Theoretical reason for this regression is that it would stop retry
>> > > even if there are enough lru pages. It only checks if freepage
>> > > excesses min watermark or not for retry decision. To prevent
>> > > pre-mature OOM killer, we need to keep allocation loop when there are
>> > > enough lru pages. So, logic should be something like that.
>> > >
>> > > should_compact_retry()
>> > > {
>> > > for_each_zone_zonelist_nodemask {
>> > > available = zone_reclaimable_pages(zone);
>> > > available += zone_page_state_snapshot(zone, 
>> > > NR_FREE_PAGES);
>> > > if (__zone_watermark_ok(zone, *0*, min_wmark_pages(zone),
>> > > ac_classzone_idx(ac), alloc_flags, available))
>> > > return true;
>> > >
>> > > }
>> > > }
>> > >
>> > > I suggested it before and current situation looks like it is indeed
>> > > needed.
>> >
>> > this just opens doors for an unbounded reclaim/threshing becacause
>> > you can reclaim as much as you like and there is no guarantee of a
>> > forward progress. The reason why !COMPACTION should_compact_retry only
>> > checks for the min_wmark without the reclaimable bias is that this will
>> > guarantee a retry if we are failing due to high order wmark check rather
>> > than a lack of memory. This condition is guaranteed to converge and the
>> > probability of the unbounded reclaim is much more reduced.
>>
>> In case of a lack of memory with a lot of reclaimable lru pages, why
>> do we stop reclaim/compaction?
>>
>> With your partial reverting patch, allocation logic would be like as
>> following.
>>
>> Assume following situation:
>> o a lot of reclaimable lru pages
>> o no order-2 freepage
>> o not enough order-0 freepage for min watermark
>> o order-2 allocation
>>
>> 1. order-2 allocation failed due to min watermark
>> 2. go to reclaim/compaction
>> 3. reclaim some pages (maybe SWAP_CLUSTER_MAX (32) pages) but still
>> min watermark isn't met for order-0
>> 4. compaction is skipped due to not enough freepage
>> 5. should_reclaim_retry() returns false because min watermark for
>> order-2 page isn't met
>> 6. should_compact_retry() returns false because min watermark for
>> order-0 page isn't met
>> 6. allocation is failed without any retry and OOM is invoked.
>
> If the direct reclaim is not able to get us over min wmark for order-0
> then we would be likely to hit the oom even for order-0 requests.

No, this situation is that direct reclaim can get us over min wmark for order-0
but it needs retry. IIUC, direct reclaim would not reclaim enough memory
at once. It tries to reclaim small amount of lru pages and break out to check
watermark.

>> Is it what you want?
>>
>> And, please elaborate more on how your logic guarantee to converge.
>> After order-0 freepage exceed min watermark, there is no way to stop
>> reclaim/threshing. Number of freepage just increase monotonically and
>> retry cannot be stopped until order-2 allocation succeed. Am I missing
>> something?
>
> My statement was imprecise at best. You are right that there is no
> guarantee to fullfil order-2 request. What I meant to say is that we
> should converge when we are getting out of memory (aka even order-0
> would have hard time to succeed). should_reclaim_retry does that by
> the back off scaling of the reclaimable pages. should_compact_retry
> would have to do the same thing which would effectively turn it into
> should_reclaim_retry.

So, I suggested to change should_reclaim_retry() for high order request,
before.

>> > > And, I still think that your OOM detection rework has some flaws.
>> > >
>> > > 1) It doesn't consider freeable objects that can be freed by 
>> > > shrink_slab().
>> > > There are many subsystems that cache many objects and they will be
>> > > freed by shrink_slab() interface. But, you don't account them when
>> > > making the OOM decision.
>> >
>> > I fully rely on the reclaim and compaction feedback. And that is the
>> > place where we should strive for improvements. So if we are growing way

Re: [PATCH RFC RESEND] Perf: lookup dwarf unwind stack info in debug file pointed by .gnu_debuglink

2016-08-24 Thread Jiri Olsa
On Tue, Aug 23, 2016 at 06:18:10PM +0200, Matija Glavinic Pecotic wrote:

SNIP

> - ret = filename__read_debuglink(filename, debuglink,
> -size - (debuglink - filename));
> + ret = filename__read_debuglink(filename, symfile, PATH_MAX);
> + if (ret)
> + break;
> +
> + /* Check predefined locations where debug file might reside:
> +  *  - if debuglink is absolute path, check only that one
> +  * If debuglink provides name w/o path, look for debug file:
> +  *  - in the same directory as dso
> +  *  - in the .debug subdirectory of dso directory
> +  *  - in the /usr/lib/debug/[dso directory]
> +  *  */
> + ret = 0;
> + if (symfile[0] == '/') {
> + if (!is_regular_file(symfile))
> + ret = -1;
> + else
> + strncpy(filename, symfile, size);
> + break;
>   }
> +
> + snprintf(filename, size, "%s/%s", dso_dir, symfile);
> + if(is_regular_file(filename))
> + break;
> +
> + snprintf(filename, size, "%s/.debug/%s", dso_dir, symfile);
> + if(is_regular_file(filename))
> + break;
> +
> + snprintf(filename, size, "/usr/lib/debug/%s/%s",
> + dso_dir, symfile);
> + if(is_regular_file(filename))
> + break;

it might be more clear to follow the same way we do for vmlinux search,
like array of possible paths and generic code to check.. search for
vmlinux_path in symbol.c

jirka


Re: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties

2016-08-24 Thread Heikki Krogerus
On Tue, Aug 23, 2016 at 12:58:07PM -0700, Stephen Boyd wrote:
> On Fri, Aug 5, 2016 at 2:27 PM, Stephen Boyd  wrote:
> > Quoting Peter Chen (2016-07-08 02:04:58)
> >> On Thu, Jul 07, 2016 at 03:20:54PM -0700, Stephen Boyd wrote:
> >> > @@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct 
> >> > device_driver *driver)
> >> >   struct ulpi *ulpi = to_ulpi_dev(dev);
> >> >   const struct ulpi_device_id *id;
> >> >
> >> > + /* Some ULPI devices don't have a product id so rely on OF match */
> >> > + if (ulpi->id.product == 0)
> >> > + return of_driver_match_device(dev, driver);
> >> > +
> >>
> >> How about using vendor id? It can't be 0, but pid may be 0.
> >> See: http://www.linux-usb.org/usb.ids
> >
> > Heikki suggested a product id of 0 would mean we need to use DT
> > matching. Should it be changed to vendor id instead?
> 
> Any comments here?

It makes sense. I don't have any problem with that.

Thanks,

-- 
heikki


Re: [PATCH] x86/efi-bgrt: remove the check of the version field

2016-08-24 Thread Dave Young
On 08/22/16 at 04:49pm, Icenowy Zheng wrote:
> 
> 
> 22.08.2016, 15:28, "Dave Young" :
> > On 08/18/16 at 09:41pm, Matt Fleming wrote:
> >>  On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> >>  >
> >>  > Could we add some quirk for these broken hardware instead of changing
> >>  > the normal code?
> >>
> >>  I'd prefer not to do that if possible. Due to the way that the BIOS
> >>  ecosystem works, this kind of broken firmware spreads across the
> >>  industry, appearing in newer versions of products from the same vendor
> >>  and even products from different vendors.
> >>
> >>  Continuously updating a quirks table as additional broken platforms
> >>  are discovered simply does not scale.
> >
> > Ok, I assumed that they are limited like one point in the web url
> > http://wiki.osdev.org/Broken_UEFI_implementations
> 
> At least I think all Thinkpads suffer from this.

Icenowy, sorry for late reply, I missed it. I'm not sure other version, but my
T440s does work well.

> 
> >
> > But I arm probably wrong like you said. Please ignore the comment then.
> >

Thanks
Dave


Re: [PATCH v4 2/3] ses: use scsi_is_sas_rphy instead of is_sas_attached

2016-08-24 Thread Johannes Thumshirn
On Mon, Aug 22, 2016 at 04:57:39PM +0800, kbuild test robot wrote:
> Hi Johannes,
> 
> [auto build test ERROR on scsi/for-next]
> [also build test ERROR on v4.8-rc3]
> [cannot apply to next-20160822]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
> 
> url:
> https://github.com/0day-ci/linux/commits/Johannes-Thumshirn/Fix-panic-when-a-SES-device-is-attached-to-a-hpsa-logical-volume/20160815-231901
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> config: x86_64-randconfig-n0-08182202 (attached as .config)
> compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/built-in.o: In function `ses_match_to_enclosure':
> >> ses.c:(.text+0x548dae): undefined reference to `scsi_is_sas_rphy'

Sorry I was not able to reproduce this using the provided config
(neither with James' tree nor Martin's).

Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850


[tip:timers/urgent] timekeeping: Cap array access in timekeeping_debug

2016-08-24 Thread tip-bot for John Stultz
Commit-ID:  a4f8f6667f099036c88f231dcad4cf233652c824
Gitweb: http://git.kernel.org/tip/a4f8f6667f099036c88f231dcad4cf233652c824
Author: John Stultz 
AuthorDate: Tue, 23 Aug 2016 16:08:22 -0700
Committer:  Thomas Gleixner 
CommitDate: Wed, 24 Aug 2016 09:34:32 +0200

timekeeping: Cap array access in timekeeping_debug

It was reported that hibernation could fail on the 2nd attempt, where the
system hangs at hibernate() -> syscore_resume() -> i8237A_resume() ->
claim_dma_lock(), because the lock has already been taken.

However there is actually no other process would like to grab this lock on
that problematic platform.

Further investigation showed that the problem is triggered by setting
/sys/power/pm_trace to 1 before the 1st hibernation.

Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend,
and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller
than 1970) to the release date of that motherboard during POST stage, thus
after resumed, it may seem that the system had a significant long sleep time
which is a completely meaningless value.

Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the
sleep time happened to be set to 1, fls() returns 32 and we add 1 to
sleep_time_bin[32], which causes an out of bounds array access and therefor
memory being overwritten.

As depicted by System.map:
0x81c9d080 b sleep_time_bin
0x81c9d100 B dma_spin_lock
the dma_spin_lock.val is set to 1, which caused this problem.

This patch adds a sanity check in tk_debug_account_sleep_time()
to ensure we don't index past the sleep_time_bin array.

[jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the
 issue slightly differently, but borrowed his excelent explanation of the
 issue here.]

Fixes: 5c83545f24ab "power: Add option to log time spent in suspend"
Reported-by: Janek Kozicki 
Reported-by: Chen Yu 
Signed-off-by: John Stultz 
Cc: linux...@vger.kernel.org
Cc: Peter Zijlstra 
Cc: Xunlei Pang 
Cc: "Rafael J. Wysocki" 
Cc: stable 
Cc: Zhang Rui 
Link: 
http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stu...@linaro.org
Signed-off-by: Thomas Gleixner 

---
 kernel/time/timekeeping_debug.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
index f6bd652..107310a 100644
--- a/kernel/time/timekeeping_debug.c
+++ b/kernel/time/timekeeping_debug.c
@@ -23,7 +23,9 @@
 
 #include "timekeeping_internal.h"
 
-static unsigned int sleep_time_bin[32] = {0};
+#define NUM_BINS 32
+
+static unsigned int sleep_time_bin[NUM_BINS] = {0};
 
 static int tk_debug_show_sleep_time(struct seq_file *s, void *data)
 {
@@ -69,6 +71,9 @@ late_initcall(tk_debug_sleep_time_init);
 
 void tk_debug_account_sleep_time(struct timespec64 *t)
 {
-   sleep_time_bin[fls(t->tv_sec)]++;
+   /* Cap bin index so we don't overflow the array */
+   int bin = min(fls(t->tv_sec), NUM_BINS-1);
+
+   sleep_time_bin[bin]++;
 }
 


[tip:timers/urgent] timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING

2016-08-24 Thread tip-bot for John Stultz
Commit-ID:  27727df240c7cc84f2ba6047c6f18d5addfd25ef
Gitweb: http://git.kernel.org/tip/27727df240c7cc84f2ba6047c6f18d5addfd25ef
Author: John Stultz 
AuthorDate: Tue, 23 Aug 2016 16:08:21 -0700
Committer:  Thomas Gleixner 
CommitDate: Wed, 24 Aug 2016 09:34:31 +0200

timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING

When I added some extra sanity checking in timekeeping_get_ns() under
CONFIG_DEBUG_TIMEKEEPING, I missed that the NMI safe __ktime_get_fast_ns()
method was using timekeeping_get_ns().

Thus the locking added to the debug checks broke the NMI-safety of
__ktime_get_fast_ns().

This patch open-codes the timekeeping_get_ns() logic for
__ktime_get_fast_ns(), so can avoid any deadlocks in NMI.

Fixes: 4ca22c2648f9 "timekeeping: Add warnings when overflows or underflows are 
observed"
Reported-by: Steven Rostedt 
Reported-by: Peter Zijlstra 
Signed-off-by: John Stultz 
Cc: stable 
Link: 
http://lkml.kernel.org/r/1471993702-29148-2-git-send-email-john.stu...@linaro.org
Signed-off-by: Thomas Gleixner 

---
 kernel/time/timekeeping.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 3b65746..e07fb09 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -401,7 +401,10 @@ static __always_inline u64 __ktime_get_fast_ns(struct 
tk_fast *tkf)
do {
seq = raw_read_seqcount_latch(&tkf->seq);
tkr = tkf->base + (seq & 0x01);
-   now = ktime_to_ns(tkr->base) + timekeeping_get_ns(tkr);
+   now = ktime_to_ns(tkr->base);
+
+   now += clocksource_delta(tkr->read(tkr->clock),
+tkr->cycle_last, tkr->mask);
} while (read_seqcount_retry(&tkf->seq, seq));
 
return now;


[PATCH v7 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA

2016-08-24 Thread Zhen Lei
To make each percpu area allocated from its local numa node. Without this
patch, all percpu areas will be allocated from the node which cpu0 belongs
to.

Signed-off-by: Zhen Lei 
---
 arch/arm64/Kconfig   |  8 
 arch/arm64/mm/numa.c | 55 
 2 files changed, 63 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..2815af6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -603,6 +603,14 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA

+config HAVE_SETUP_PER_CPU_AREA
+   def_bool y
+   depends on NUMA
+
+config NEED_PER_CPU_EMBED_FIRST_CHUNK
+   def_bool y
+   depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 7b73808..5e44ad1 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -26,6 +26,7 @@
 #include 

 #include 
+#include 

 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
 EXPORT_SYMBOL(node_data);
@@ -131,6 +132,60 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
nid)
cpu_to_node_map[cpu] = nid;
 }

+#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
+unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
+EXPORT_SYMBOL(__per_cpu_offset);
+
+static int __init early_cpu_to_node(int cpu)
+{
+   return cpu_to_node_map[cpu];
+}
+
+static int __init pcpu_cpu_distance(unsigned int from, unsigned int to)
+{
+   if (early_cpu_to_node(from) == early_cpu_to_node(to))
+   return LOCAL_DISTANCE;
+   else
+   return REMOTE_DISTANCE;
+}
+
+static void * __init pcpu_fc_alloc(unsigned int cpu, size_t size,
+  size_t align)
+{
+   int nid = early_cpu_to_node(cpu);
+
+   return  memblock_virt_alloc_try_nid(size, align,
+   __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+}
+
+static void __init pcpu_fc_free(void *ptr, size_t size)
+{
+   memblock_free_early(__pa(ptr), size);
+}
+
+void __init setup_per_cpu_areas(void)
+{
+   unsigned long delta;
+   unsigned int cpu;
+   int rc;
+
+   /*
+* Always reserve area for module percpu variables.  That's
+* what the legacy allocator did.
+*/
+   rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
+   PERCPU_DYNAMIC_RESERVE, PAGE_SIZE,
+   pcpu_cpu_distance,
+   pcpu_fc_alloc, pcpu_fc_free);
+   if (rc < 0)
+   panic("Failed to initialize percpu areas.");
+
+   delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;
+   for_each_possible_cpu(cpu)
+   __per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
+}
+#endif
+
 /**
  * numa_add_memblk - Set node id to memblk
  * @nid: NUMA node ID of the new memblk
--
2.5.0




[PATCH v7 12/14] arm64/numa: remove the limitation that cpu0 must bind to node0

2016-08-24 Thread Zhen Lei
1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not
   been initialized.
2. No reason to limit cpu0 must belongs to node0.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/numa.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 114180f..07a1978 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -94,7 +94,6 @@ void numa_clear_node(unsigned int cpu)
  */
 static void __init setup_node_to_cpumask_map(void)
 {
-   unsigned int cpu;
int node;

/* setup nr_node_ids if not done yet */
@@ -107,9 +106,6 @@ static void __init setup_node_to_cpumask_map(void)
cpumask_clear(node_to_cpumask_map[node]);
}

-   for_each_possible_cpu(cpu)
-   set_cpu_numa_node(cpu, NUMA_NO_NODE);
-
/* cpumask_of_node() will now work */
pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
 }
@@ -119,13 +115,13 @@ static void __init setup_node_to_cpumask_map(void)
  */
 void numa_store_cpu_info(unsigned int cpu)
 {
-   map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
+   map_cpu_to_node(cpu, cpu_to_node_map[cpu]);
 }

 void __init early_map_cpu_to_node(unsigned int cpu, int nid)
 {
/* fallback to node 0 */
-   if (nid < 0 || nid >= MAX_NUMNODES)
+   if (nid < 0 || nid >= MAX_NUMNODES || numa_off)
nid = 0;

cpu_to_node_map[cpu] = nid;
@@ -375,10 +371,6 @@ static int __init numa_init(int (*init_func)(void))

setup_node_to_cpumask_map();

-   /* init boot processor */
-   cpu_to_node_map[0] = 0;
-   map_cpu_to_node(0, 0);
-
return 0;
 }

--
2.5.0




[PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

2016-08-24 Thread Zhen Lei
numa_init(of_numa_init) may returned error because of numa configuration
error. So "No NUMA configuration found" is inaccurate. In fact, specific
configuration error information should be immediately printed by the
testing branch.

Signed-off-by: Zhen Lei 
---
 arch/arm64/mm/numa.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 5bb15ea..d97c6e2 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -335,8 +335,10 @@ static int __init numa_init(int (*init_func)(void))
if (ret < 0)
return ret;

-   if (nodes_empty(numa_nodes_parsed))
+   if (nodes_empty(numa_nodes_parsed)) {
+   pr_info("No NUMA configuration found\n");
return -EINVAL;
+   }

ret = numa_register_nodes();
if (ret < 0)
@@ -367,8 +369,6 @@ static int __init dummy_numa_init(void)

if (numa_off)
pr_info("NUMA disabled\n"); /* Forced off on command line. */
-   else
-   pr_info("No NUMA configuration found\n");
pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
   0LLU, PFN_PHYS(max_pfn) - 1);

--
2.5.0




[PATCH v7 10/14] arm64/numa: define numa_distance as array to simplify code

2016-08-24 Thread Zhen Lei
1. MAX_NUMNODES is base on CONFIG_NODES_SHIFT, the default value of the
   latter is very small now.
2. Suppose the default value of MAX_NUMNODES is enlarged to 64, so the
   size of numa_distance is 4K, it's still acceptable if run the Image
   on other processors.
3. It will make function __node_distance quicker than before.

Signed-off-by: Zhen Lei 
---
 arch/arm64/include/asm/numa.h |  1 -
 arch/arm64/mm/numa.c  | 74 +++
 2 files changed, 5 insertions(+), 70 deletions(-)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..9b6cc38 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -32,7 +32,6 @@ static inline const struct cpumask *cpumask_of_node(int node)
 void __init arm64_numa_init(void);
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
 void __init numa_set_distance(int from, int to, int distance);
-void __init numa_free_distance(void);
 void __init early_map_cpu_to_node(unsigned int cpu, int nid);
 void numa_store_cpu_info(unsigned int cpu);

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 5e44ad1..6853db7 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -33,8 +33,7 @@ EXPORT_SYMBOL(node_data);
 nodemask_t numa_nodes_parsed __initdata;
 static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };

-static int numa_distance_cnt;
-static u8 *numa_distance;
+static u8 numa_distance[MAX_NUMNODES][MAX_NUMNODES];
 static bool numa_off;

 static __init int numa_parse_early_param(char *opt)
@@ -243,59 +242,6 @@ static void __init setup_node_data(int nid, u64 start_pfn, 
u64 end_pfn)
 }

 /**
- * numa_free_distance
- *
- * The current table is freed.
- */
-void __init numa_free_distance(void)
-{
-   size_t size;
-
-   if (!numa_distance)
-   return;
-
-   size = numa_distance_cnt * numa_distance_cnt *
-   sizeof(numa_distance[0]);
-
-   memblock_free(__pa(numa_distance), size);
-   numa_distance_cnt = 0;
-   numa_distance = NULL;
-}
-
-/**
- *
- * Create a new NUMA distance table.
- *
- */
-static int __init numa_alloc_distance(void)
-{
-   size_t size;
-   u64 phys;
-   int i, j;
-
-   size = nr_node_ids * nr_node_ids * sizeof(numa_distance[0]);
-   phys = memblock_find_in_range(0, PFN_PHYS(max_pfn),
- size, PAGE_SIZE);
-   if (WARN_ON(!phys))
-   return -ENOMEM;
-
-   memblock_reserve(phys, size);
-
-   numa_distance = __va(phys);
-   numa_distance_cnt = nr_node_ids;
-
-   /* fill with the default distances */
-   for (i = 0; i < numa_distance_cnt; i++)
-   for (j = 0; j < numa_distance_cnt; j++)
-   numa_distance[i * numa_distance_cnt + j] = i == j ?
-   LOCAL_DISTANCE : REMOTE_DISTANCE;
-
-   pr_debug("Initialized distance table, cnt=%d\n", numa_distance_cnt);
-
-   return 0;
-}
-
-/**
  * numa_set_distance - Set inter node NUMA distance from node to node.
  * @from: the 'from' node to set distance
  * @to: the 'to'  node to set distance
@@ -310,12 +256,7 @@ static int __init numa_alloc_distance(void)
  */
 void __init numa_set_distance(int from, int to, int distance)
 {
-   if (!numa_distance) {
-   pr_warn_once("Warning: distance table not allocated yet\n");
-   return;
-   }
-
-   if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
+   if (from >= MAX_NUMNODES || to >= MAX_NUMNODES ||
from < 0 || to < 0) {
pr_warn_once("Warning: node ids are out of bound, from=%d to=%d 
distance=%d\n",
from, to, distance);
@@ -329,7 +270,7 @@ void __init numa_set_distance(int from, int to, int 
distance)
return;
}

-   numa_distance[from * numa_distance_cnt + to] = distance;
+   numa_distance[from][to] = distance;
 }

 /**
@@ -337,9 +278,9 @@ void __init numa_set_distance(int from, int to, int 
distance)
  */
 int __node_distance(int from, int to)
 {
-   if (from >= numa_distance_cnt || to >= numa_distance_cnt)
+   if (from >= MAX_NUMNODES || to >= MAX_NUMNODES)
return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
-   return numa_distance[from * numa_distance_cnt + to];
+   return numa_distance[from][to];
 }
 EXPORT_SYMBOL(__node_distance);

@@ -379,11 +320,6 @@ static int __init numa_init(int (*init_func)(void))
nodes_clear(numa_nodes_parsed);
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
-   numa_free_distance();
-
-   ret = numa_alloc_distance();
-   if (ret < 0)
-   return ret;

ret = init_func();
if (ret < 0)
--
2.5.0




[PATCH v7 06/14] of_numa: Use of_get_next_parent to simplify code

2016-08-24 Thread Zhen Lei
From: Kefeng Wang 

Use of_get_next_parent() instead of open-code.

Signed-off-by: Kefeng Wang 
Acked-by: Rob Herring 
---
 drivers/of/of_numa.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 8723f64..ed103e6 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -158,8 +158,6 @@ int of_node_to_nid(struct device_node *device)
np = of_node_get(device);

while (np) {
-   struct device_node *parent;
-
r = of_property_read_u32(np, "numa-node-id", &nid);
/*
 * -EINVAL indicates the property was not found, and
@@ -170,9 +168,7 @@ int of_node_to_nid(struct device_node *device)
if (r != -EINVAL)
break;

-   parent = of_get_parent(np);
-   of_node_put(np);
-   np = parent;
+   np = of_get_next_parent(np);
}
if (np && r)
pr_warn("NUMA: Invalid \"numa-node-id\" property in node %s\n",
--
2.5.0




[PATCH v7 07/14] of_numa: Use pr_fmt()

2016-08-24 Thread Zhen Lei
From: Kefeng Wang 

Use pr_fmt to prefix kernel output.

Signed-off-by: Kefeng Wang 
Acked-by: Rob Herring 
---
 drivers/of/of_numa.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index ed103e6..1234b4a 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -16,6 +16,8 @@
  * along with this program.  If not, see .
  */

+#define pr_fmt(fmt) "OF: NUMA: " fmt
+
 #include 
 #include 
 #include 
@@ -49,10 +51,9 @@ static void __init of_numa_parse_cpu_nodes(void)
if (r)
continue;

-   pr_debug("NUMA: CPU on %u\n", nid);
+   pr_debug("CPU on %u\n", nid);
if (nid >= MAX_NUMNODES)
-   pr_warn("NUMA: Node id %u exceeds maximum value\n",
-   nid);
+   pr_warn("Node id %u exceeds maximum value\n", nid);
else
node_set(nid, numa_nodes_parsed);
}
@@ -76,7 +77,7 @@ static int __init of_numa_parse_memory_nodes(void)
continue;

if (nid >= MAX_NUMNODES) {
-   pr_warn("NUMA: Node id %u exceeds maximum value\n", 
nid);
+   pr_warn("Node id %u exceeds maximum value\n", nid);
return -EINVAL;
}

@@ -85,7 +86,7 @@ static int __init of_numa_parse_memory_nodes(void)

if (!i || r) {
of_node_put(np);
-   pr_err("NUMA: bad property in memory node\n");
+   pr_err("bad property in memory node\n");
return r ? : -EINVAL;
}
}
@@ -99,17 +100,17 @@ static int __init of_numa_parse_distance_map_v1(struct 
device_node *map)
int entry_count;
int i;

-   pr_info("NUMA: parsing numa-distance-map-v1\n");
+   pr_info("parsing numa-distance-map-v1\n");

matrix = of_get_property(map, "distance-matrix", NULL);
if (!matrix) {
-   pr_err("NUMA: No distance-matrix property in distance-map\n");
+   pr_err("No distance-matrix property in distance-map\n");
return -EINVAL;
}

entry_count = of_property_count_u32_elems(map, "distance-matrix");
if (entry_count <= 0) {
-   pr_err("NUMA: Invalid distance-matrix\n");
+   pr_err("Invalid distance-matrix\n");
return -EINVAL;
}

@@ -124,7 +125,7 @@ static int __init of_numa_parse_distance_map_v1(struct 
device_node *map)
matrix++;

numa_set_distance(nodea, nodeb, distance);
-   pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
+   pr_debug("distance[node%d -> node%d] = %d\n",
 nodea, nodeb, distance);

/* Set default distance of node B->A same as A->B */
@@ -171,7 +172,7 @@ int of_node_to_nid(struct device_node *device)
np = of_get_next_parent(np);
}
if (np && r)
-   pr_warn("NUMA: Invalid \"numa-node-id\" property in node %s\n",
+   pr_warn("Invalid \"numa-node-id\" property in node %s\n",
np->name);
of_node_put(np);

--
2.5.0




[PATCH v7 08/14] arm64: numa: Use pr_fmt()

2016-08-24 Thread Zhen Lei
From: Kefeng Wang 

Use pr_fmt to prefix kernel output, and remove duplicated msg
of NUMA turned off.

Signed-off-by: Kefeng Wang 
---
 arch/arm64/mm/numa.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index d97c6e2..7b73808 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,8 @@
  * along with this program.  If not, see .
  */

+#define pr_fmt(fmt) "numa: " fmt
+
 #include 
 #include 
 #include 
@@ -38,10 +40,9 @@ static __init int numa_parse_early_param(char *opt)
 {
if (!opt)
return -EINVAL;
-   if (!strncmp(opt, "off", 3)) {
-   pr_info("%s\n", "NUMA turned off");
+   if (!strncmp(opt, "off", 3))
numa_off = true;
-   }
+
return 0;
 }
 early_param("numa", numa_parse_early_param);
@@ -110,7 +111,7 @@ static void __init setup_node_to_cpumask_map(void)
set_cpu_numa_node(cpu, NUMA_NO_NODE);

/* cpumask_of_node() will now work */
-   pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
+   pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
 }

 /*
@@ -145,13 +146,13 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)

ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
-   pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node 
%d\n",
+   pr_err("memblock [0x%llx - 0x%llx] failed to add on node %d\n",
start, (end - 1), nid);
return ret;
}

node_set(nid, numa_nodes_parsed);
-   pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
+   pr_info("Adding memblock [0x%llx - 0x%llx] on node %d\n",
start, (end - 1), nid);
return ret;
 }
@@ -166,19 +167,18 @@ static void __init setup_node_data(int nid, u64 
start_pfn, u64 end_pfn)
void *nd;
int tnid;

-   pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
-   nid, start_pfn << PAGE_SHIFT,
-   (end_pfn << PAGE_SHIFT) - 1);
+   pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
+   nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);

nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
nd = __va(nd_pa);

/* report and initialize */
-   pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
+   pr_info("  NODE_DATA [mem %#010Lx-%#010Lx]\n",
nd_pa, nd_pa + nd_size - 1);
tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
if (tnid != nid)
-   pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
+   pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);

node_data[nid] = nd;
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
@@ -235,8 +235,7 @@ static int __init numa_alloc_distance(void)
numa_distance[i * numa_distance_cnt + j] = i == j ?
LOCAL_DISTANCE : REMOTE_DISTANCE;

-   pr_debug("NUMA: Initialized distance table, cnt=%d\n",
-   numa_distance_cnt);
+   pr_debug("Initialized distance table, cnt=%d\n", numa_distance_cnt);

return 0;
 }
@@ -257,20 +256,20 @@ static int __init numa_alloc_distance(void)
 void __init numa_set_distance(int from, int to, int distance)
 {
if (!numa_distance) {
-   pr_warn_once("NUMA: Warning: distance table not allocated 
yet\n");
+   pr_warn_once("Warning: distance table not allocated yet\n");
return;
}

if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
from < 0 || to < 0) {
-   pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d 
to=%d distance=%d\n",
+   pr_warn_once("Warning: node ids are out of bound, from=%d to=%d 
distance=%d\n",
from, to, distance);
return;
}

if ((u8)distance != distance ||
(from == to && distance != LOCAL_DISTANCE)) {
-   pr_warn_once("NUMA: Warning: invalid distance parameter, 
from=%d to=%d distance=%d\n",
+   pr_warn_once("Warning: invalid distance parameter, from=%d 
to=%d distance=%d\n",
 from, to, distance);
return;
}
@@ -297,7 +296,7 @@ static int __init numa_register_nodes(void)
/* Check that valid nid is set to memblks */
for_each_memblock(memory, mblk)
if (mblk->nid == NUMA_NO_NODE || mblk->nid >= MAX_NUMNODES) {
-   pr_warn("NUMA: Warning: invalid memblk node %d [mem 
%#010Lx-%#010Lx]\n",
+   pr_warn("Warning: invalid memblk node %d [mem 
%#010Lx-%#010Lx]\n",
mb

[PATCH v7 13/14] of/numa: remove the constraint on the distances of node pairs

2016-08-24 Thread Zhen Lei
At present, the distances must equal in both direction for each node
pairs. For example: the distance of node B->A must the same to A->B.
But we really don't have to do this.

End up fill default distances as below:
1. If both direction specified, keep no change.
2. If only one direction specified, assign it to the other direction.
3. If none of the two direction specified, both are assigned to
   REMOTE_DISTANCE.

Signed-off-by: Zhen Lei 
Acked-by: Rob Herring 
---
 drivers/of/of_numa.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 1234b4a..d0cdf29 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -127,15 +127,25 @@ static int __init of_numa_parse_distance_map_v1(struct 
device_node *map)
numa_set_distance(nodea, nodeb, distance);
pr_debug("distance[node%d -> node%d] = %d\n",
 nodea, nodeb, distance);
-
-   /* Set default distance of node B->A same as A->B */
-   if (nodeb > nodea)
-   numa_set_distance(nodeb, nodea, distance);
}

return 0;
 }

+static void __init fill_default_distances(void)
+{
+   int i, j;
+
+   for (i = 0; i < nr_node_ids; i++)
+   for (j = 0; j < nr_node_ids; j++)
+   if (i == j)
+   numa_set_distance(i, j, LOCAL_DISTANCE);
+   else if (!node_distance(i, j))
+   numa_set_distance(i, j,
+   node_distance(j, i) ? : REMOTE_DISTANCE);
+
+}
+
 static int __init of_numa_parse_distance_map(void)
 {
int ret = 0;
@@ -145,8 +155,10 @@ static int __init of_numa_parse_distance_map(void)
 "numa-distance-map-v1");
if (np)
ret = of_numa_parse_distance_map_v1(np);
-
of_node_put(np);
+
+   fill_default_distances();
+
return ret;
 }

--
2.5.0




[PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs

2016-08-24 Thread Zhen Lei
Update documentation. This limit is unneccessary.

Signed-off-by: Zhen Lei 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/numa.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/numa.txt 
b/Documentation/devicetree/bindings/numa.txt
index 21b3505..c0ea4a7 100644
--- a/Documentation/devicetree/bindings/numa.txt
+++ b/Documentation/devicetree/bindings/numa.txt
@@ -48,7 +48,6 @@ distance (memory latency) between all numa nodes.

   Note:
1. Each entry represents distance from first node to second node.
-   The distances are equal in either direction.
2. The distance from a node to self (local distance) is represented
with value 10 and all internode distance should be represented with
a value greater than 10.
--
2.5.0




[PATCH v7 01/14] of/numa: remove a duplicated pr_debug information

2016-08-24 Thread Zhen Lei
This information will be printed in the subfunction numa_add_memblk.
They are not the same, but very similar.

Signed-off-by: Zhen Lei 
Acked-by: Rob Herring 
---
 drivers/of/of_numa.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index ed5a097..fb71b4e 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -88,10 +88,6 @@ static int __init of_numa_parse_memory_nodes(void)
break;
}

-   pr_debug("NUMA:  base = %llx len = %llx, node = %u\n",
-rsrc.start, rsrc.end - rsrc.start + 1, nid);
-
-
r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);
if (r)
break;
--
2.5.0




[PATCH v7 03/14] arm64/numa: add nid check for memory block

2016-08-24 Thread Zhen Lei
Use the same tactic to cpu and numa-distance nodes.

Signed-off-by: Zhen Lei 
---
 drivers/of/of_numa.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 7b3fbdc..afaeb9c 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -75,6 +75,11 @@ static int __init of_numa_parse_memory_nodes(void)
 */
continue;

+   if (nid >= MAX_NUMNODES) {
+   pr_warn("NUMA: Node id %u exceeds maximum value\n", 
nid);
+   return -EINVAL;
+   }
+
for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++)
r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);

--
2.5.0




[PATCH v7 04/14] of/numa: remove a duplicated warning

2016-08-24 Thread Zhen Lei
This warning has been printed in of_numa_parse_cpu_nodes before.

Signed-off-by: Zhen Lei 
Acked-by: Rob Herring 
---
 drivers/of/of_numa.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index afaeb9c..8723f64 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -179,13 +179,8 @@ int of_node_to_nid(struct device_node *device)
np->name);
of_node_put(np);

-   if (!r) {
-   if (nid >= MAX_NUMNODES)
-   pr_warn("NUMA: Node id %u exceeds maximum value\n",
-   nid);
-   else
-   return nid;
-   }
+   if (!r)
+   return nid;

return NUMA_NO_NODE;
 }
--
2.5.0




[PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-08-24 Thread Zhen Lei
Some numa nodes may have no memory. For example:
1. cpu0 on node0
2. cpu1 on node1
3. device0 access the momory from node0 and node1 take the same time.

So, we can not simply classify device0 to node0 or node1, but we can
define a node2 which distances to node0 and node1 are the same.

Signed-off-by: Zhen Lei 
---
 arch/arm64/Kconfig  |  4 
 arch/arm64/kernel/smp.c |  1 +
 arch/arm64/mm/numa.c| 43 +--
 3 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2815af6..3a2b6ed 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -611,6 +611,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool y
depends on NUMA

+config HAVE_MEMORYLESS_NODES
+   def_bool y
+   depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d93d433..4879085 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -619,6 +619,7 @@ static void __init of_parse_and_init_cpus(void)
}

bootcpu_valid = true;
+   early_map_cpu_to_node(0, of_node_to_nid(dn));

/*
 * cpu_logical_map has already been
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 6853db7..114180f 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -129,6 +129,14 @@ void __init early_map_cpu_to_node(unsigned int cpu, int 
nid)
nid = 0;

cpu_to_node_map[cpu] = nid;
+
+   /*
+* We should set the numa node of cpu0 as soon as possible, because it
+* has already been set up online before. cpu_to_node(0) will soon be
+* called.
+*/
+   if (!cpu)
+   set_cpu_numa_node(cpu, nid);
 }

 #ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
@@ -211,6 +219,35 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
return ret;
 }

+static u64 __init alloc_node_data_from_nearest_node(int nid, const size_t size)
+{
+   int i, best_nid, distance;
+   u64 pa;
+   DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
+
+   bitmap_zero(nodes_map, MAX_NUMNODES);
+   bitmap_set(nodes_map, nid, 1);
+
+find_nearest_node:
+   best_nid = NUMA_NO_NODE;
+   distance = INT_MAX;
+
+   for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
+   if (numa_distance[nid][i] < distance) {
+   best_nid = i;
+   distance = numa_distance[nid][i];
+   }
+
+   pa = memblock_alloc_nid(size, SMP_CACHE_BYTES, best_nid);
+   if (!pa) {
+   BUG_ON(best_nid == NUMA_NO_NODE);
+   bitmap_set(nodes_map, best_nid, 1);
+   goto find_nearest_node;
+   }
+
+   return pa;
+}
+
 /**
  * Initialize NODE_DATA for a node on the local memory
  */
@@ -224,7 +261,9 @@ static void __init setup_node_data(int nid, u64 start_pfn, 
u64 end_pfn)
pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);

-   nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+   nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
+   if (!nd_pa)
+   nd_pa = alloc_node_data_from_nearest_node(nid, nd_size);
nd = __va(nd_pa);

/* report and initialize */
@@ -234,7 +273,7 @@ static void __init setup_node_data(int nid, u64 start_pfn, 
u64 end_pfn)
if (tnid != nid)
pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);

-   node_data[nid] = nd;
+   NODE_DATA(nid) = nd;
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
NODE_DATA(nid)->node_id = nid;
NODE_DATA(nid)->node_start_pfn = start_pfn;
--
2.5.0




[PATCH v7 02/14] of/numa: fix a memory@ node can only contains one memory block

2016-08-24 Thread Zhen Lei
For a normal memory@ devicetree node, its reg property can contains more
memory blocks.

Because we don't known how many memory blocks maybe contained, so we try
from index=0, increase 1 until error returned(the end).

Signed-off-by: Zhen Lei 
Acked-by: Rob Herring 
---
 drivers/of/of_numa.c | 29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index fb71b4e..7b3fbdc 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -63,13 +63,9 @@ static int __init of_numa_parse_memory_nodes(void)
struct device_node *np = NULL;
struct resource rsrc;
u32 nid;
-   int r = 0;
-
-   for (;;) {
-   np = of_find_node_by_type(np, "memory");
-   if (!np)
-   break;
+   int i, r;

+   for_each_node_by_type(np, "memory") {
r = of_property_read_u32(np, "numa-node-id", &nid);
if (r == -EINVAL)
/*
@@ -78,23 +74,18 @@ static int __init of_numa_parse_memory_nodes(void)
 * "numa-node-id" property
 */
continue;
-   else if (r)
-   /* some other error */
-   break;

-   r = of_address_to_resource(np, 0, &rsrc);
-   if (r) {
-   pr_err("NUMA: bad reg property in memory node\n");
-   break;
-   }
+   for (i = 0; !r && !of_address_to_resource(np, i, &rsrc); i++)
+   r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);

-   r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);
-   if (r)
-   break;
+   if (!i || r) {
+   of_node_put(np);
+   pr_err("NUMA: bad property in memory node\n");
+   return r ? : -EINVAL;
+   }
}
-   of_node_put(np);

-   return r;
+   return 0;
 }

 static int __init of_numa_parse_distance_map_v1(struct device_node *map)
--
2.5.0




[PATCH v7 00/14] fix some type infos and bugs for arm64/of numa

2016-08-24 Thread Zhen Lei
v6 -> v7:
Fix a bug for this patch series when "numa=off" was set in bootargs, this
modification only impact patch 12.

Please refer https://lkml.org/lkml/2016/8/23/249 for more details.

@@ -119,13 +115,13 @@ static void __init setup_node_to_cpumask_map(void)
  */
 void numa_store_cpu_info(unsigned int cpu)
 {
-   map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
+   map_cpu_to_node(cpu, cpu_to_node_map[cpu]);
 }

 void __init early_map_cpu_to_node(unsigned int cpu, int nid)
 {
/* fallback to node 0 */
-   if (nid < 0 || nid >= MAX_NUMNODES)
+   if (nid < 0 || nid >= MAX_NUMNODES || numa_off)
nid = 0;

v5 -> v6:
Move memblk nid check from arch/arm64/mm/numa.c into drivers/of/of_numa.c,
because this check is arch independent.

This modification only related to patch 3, but impacted the contents of patch 7 
and 8,
other patches have no change.

v4 -> v5:
This version has no code changes, just add "Acked-by: Rob Herring 
"
into patches 1, 2, 4, 6, 7, 13, 14. Because these patches rely on some acpi numa
patches, and the latter had not been upstreamed in 4.7, but upstreamed in 
4.8-rc1,
so I resend my patches again.

v3 -> v4:
1. Packed three patches of Kefeng Wang, patch6-8.
2. Add 6 new patches(9-15) to enhance the numa on arm64.

v2 -> v3:
1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make the
   patches looks more well. The final code have no change. 

v1 -> v2:
1. Base on https://lkml.org/lkml/2016/5/24/679
2. Rewrote of_numa_parse_memory_nodes according to Rob Herring's advice. So 
that it looks more clear.
3. Rewrote patch 5 because some scenes were not considered before.

Kefeng Wang (3):
  of_numa: Use of_get_next_parent to simplify code
  of_numa: Use pr_fmt()
  arm64: numa: Use pr_fmt()

Zhen Lei (11):
  of/numa: remove a duplicated pr_debug information
  of/numa: fix a memory@ node can only contains one memory block
  arm64/numa: add nid check for memory block
  of/numa: remove a duplicated warning
  arm64/numa: avoid inconsistent information to be printed
  arm64/numa: support HAVE_SETUP_PER_CPU_AREA
  arm64/numa: define numa_distance as array to simplify code
  arm64/numa: support HAVE_MEMORYLESS_NODES
  arm64/numa: remove the limitation that cpu0 must bind to node0
  of/numa: remove the constraint on the distances of node pairs
  Documentation: remove the constraint on the distances of node pairs

 Documentation/devicetree/bindings/numa.txt |   1 -
 arch/arm64/Kconfig |  12 ++
 arch/arm64/include/asm/numa.h  |   1 -
 arch/arm64/kernel/smp.c|   1 +
 arch/arm64/mm/numa.c   | 226 -
 drivers/of/of_numa.c   |  88 ++-
 6 files changed, 179 insertions(+), 150 deletions(-)

--
2.5.0




[tip:x86/urgent] x86/apic: Do not init irq remapping if ioapic is disabled

2016-08-24 Thread tip-bot for Wanpeng Li
Commit-ID:  2e63ad4bd5dd583871e6602f9d398b9322d358d9
Gitweb: http://git.kernel.org/tip/2e63ad4bd5dd583871e6602f9d398b9322d358d9
Author: Wanpeng Li 
AuthorDate: Tue, 23 Aug 2016 20:07:19 +0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 24 Aug 2016 09:45:40 +0200

x86/apic: Do not init irq remapping if ioapic is disabled

native_smp_prepare_cpus
  -> default_setup_apic_routing
-> enable_IR_x2apic
  -> irq_remapping_prepare
-> intel_prepare_irq_remapping
  -> intel_setup_irq_remapping

So IR table is setup even if "noapic" boot parameter is added. As a result we
crash later when the interrupt affinity is set due to a half initialized
remapping infrastructure.

Prevent remap initialization when IOAPIC is disabled.

Signed-off-by: Wanpeng Li 
Cc: Peter Zijlstra 
Cc: Joerg Roedel 
Link: 
http://lkml.kernel.org/r/1471954039-3942-1-git-send-email-wanpeng...@hotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/apic/apic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index cea4fc1..50c95af 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1623,6 +1623,9 @@ void __init enable_IR_x2apic(void)
unsigned long flags;
int ret, ir_stat;
 
+   if (skip_ioapic_setup)
+   return;
+
ir_stat = irq_remapping_prepare();
if (ir_stat < 0 && !x2apic_supported())
return;


Re: [PATCH 2/2] thermal: rcar-thermal: enable hwmon when thermal_zone

2016-08-24 Thread Zhang Rui
On 五, 2016-08-19 at 19:35 +0800, Zhang Rui wrote:
> On 二, 2016-07-19 at 10:01 +, Kuninori Morimoto wrote:
> > 
> > From: Kuninori Morimoto 
> > 
> > rcar-thermal is supporting both thermal_zone_of_sensor_register()
> > and
> > thermal_zone_device_register(). But
> > thermal_zone_of_sensor_register()
> > doesn't enable hwmon as default.
> > This patch enables it to keep compatibility
> > 
> > Signed-off-by: Kuninori Morimoto 
> Queued for 4.9
> 
the subject should be "thermal:rcar-theraml: enable hwmon when
thermal_zone_of_sensor_register is used", right?

thanks,
rui
> thanks,
> rui
> > 
> > ---
> >  drivers/thermal/rcar_thermal.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/thermal/rcar_thermal.c
> > b/drivers/thermal/rcar_thermal.c
> > index 71a3392..4d07644 100644
> > --- a/drivers/thermal/rcar_thermal.c
> > +++ b/drivers/thermal/rcar_thermal.c
> > @@ -31,6 +31,8 @@
> >  #include 
> >  #include 
> >  
> > +#include "thermal_hwmon.h"
> > +
> >  #define IDLE_INTERVAL  5000
> >  
> >  #define COMMON_STR 0x00
> > @@ -75,6 +77,8 @@ struct rcar_thermal_priv {
> >  #define rcar_priv_to_dev(priv) ((priv)->common-
> > >dev)
> >  #define rcar_has_irq_support(priv) ((priv)->common->base)
> >  #define rcar_id_to_shift(priv) ((priv)->id * 8)
> > +#define rcar_of_data(dev)  ((unsigned
> > long)of_device_get_match_data(dev))
> > +#define rcar_use_of_thermal(dev)   (rcar_of_data(dev) ==
> > USE_OF_THERMAL)
> >  
> >  #define USE_OF_THERMAL 1
> >  static const struct of_device_id rcar_thermal_dt_ids[] = {
> > @@ -416,6 +420,8 @@ static int rcar_thermal_remove(struct
> > platform_device *pdev)
> >     rcar_thermal_for_each_priv(priv, common) {
> >     rcar_thermal_irq_disable(priv);
> >     thermal_zone_device_unregister(priv->zone);
> > +   if (rcar_use_of_thermal(dev))
> > +   thermal_remove_hwmon_sysfs(priv->zone);
> >     }
> >  
> >     pm_runtime_put(dev);
> > @@ -430,7 +436,6 @@ static int rcar_thermal_probe(struct
> > platform_device *pdev)
> >     struct rcar_thermal_priv *priv;
> >     struct device *dev = &pdev->dev;
> >     struct resource *res, *irq;
> > -   unsigned long of_data = (unsigned
> > long)of_device_get_match_data(dev);
> >     int mres = 0;
> >     int i;
> >     int ret = -ENODEV;
> > @@ -491,7 +496,7 @@ static int rcar_thermal_probe(struct
> > platform_device *pdev)
> >     if (ret < 0)
> >     goto error_unregister;
> >  
> > -   if (of_data == USE_OF_THERMAL)
> > +   if (rcar_use_of_thermal(dev))
> >     priv->zone =
> > devm_thermal_zone_of_sensor_register(
> >     dev, i, priv,
> >     &rcar_thermal_zone
> > _o
> > f_ops);
> > @@ -507,6 +512,17 @@ static int rcar_thermal_probe(struct
> > platform_device *pdev)
> >     goto error_unregister;
> >     }
> >  
> > +   if (rcar_use_of_thermal(dev)) {
> > +   /*
> > +    * thermal_zone doesn't enable hwmon as
> > default,
> > +    * but, enable it here to keep compatible
> > +    */
> > +   priv->zone->tzp->no_hwmon = false;
> > +   ret = thermal_add_hwmon_sysfs(priv->zone);
> > +   if (ret)
> > +   goto error_unregister;
> > +   }
> > +
> >     rcar_thermal_irq_enable(priv);
> >  
> >     list_move_tail(&priv->list, &common->head);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] treewide: replace config_enabled() with IS_ENABLED() (2nd round)

2016-08-24 Thread Peter Oberparleiter
On 23.08.2016 18:45, Masahiro Yamada wrote:
> Commit 97f2645f358b ("tree-wide: replace config_enabled() with
> IS_ENABLED()") mostly killed config_enabled(), but some new users
> have appeared for v4.8-rc1.  They are all used for a boolean option,
> so can be replaced with IS_ENABLED() safely.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Peter Oberparleiter 

> ---
> 
>  arch/mips/include/asm/page.h | 4 ++--
>  arch/s390/kernel/setup.c | 6 ++
>  arch/x86/mm/kaslr.c  | 2 +-
>  3 files changed, 5 insertions(+), 7 deletions(-)

-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany



Re: linux-next: build warning after merge of the thermal tree

2016-08-24 Thread Zhang Rui
On 三, 2016-08-24 at 13:38 +1000, Stephen Rothwell wrote:
> Hi Zhang,
> 
> After merging the thermal tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
> 
> warning: (HISI_THERMAL) selects STUB_CLK_HI6220 which has unmet
> direct dependencies (COMMON_CLK && COMMON_CLK_HI6220 && MAILBOX)
> 
> Introduced by commit
> 
>   5f63581ce68e ("thermal: hisilicon: Add dependency on the clock
> driver to allow frequency scaling")
> 
> BTW: That commit message does not match the change (which adds a
> "select" not a "depends on".
> 
Right, thanks for reporting the issue. Patch dropped from thermal -next
tree.

thanks,
rui


Re: [PATCH] raid6: fix the input of raid6 algorithm

2016-08-24 Thread liuzhengyuan
Oh, get_random_*() is really expensive. Thanks for your tips. The boot log on 
my aarch64 showed bellow
told it taked about 0.6 second to fill with disk data. 
  
  [0.172831] DMA: preallocated 256 KiB pool for atomic allocations
  [0.788664] raid6: int64x1  gen()   121 MB/s
  [0.856613] raid6: int64x1  xor()74 MB/s
  [0.924665] raid6: int64x2  gen()   166 MB/s
  [0.992846] raid6: int64x2  xor()95 MB/s
  [1.060681] raid6: int64x4  gen()   290 MB/s
  [1.128774] raid6: int64x4  xor()   160 MB/s
  [1.196933] raid6: int64x8  gen()   238 MB/s
  [1.264937] raid6: int64x8  xor()   148 MB/s
  [1.332878] raid6: neonx1   gen()   256 MB/s
  [1.400975] raid6: neonx1   xor()   130 MB/s
  [1.468951] raid6: neonx2   gen()   333 MB/s
  [1.537085] raid6: neonx2   xor()   181 MB/s
  [1.605042] raid6: neonx4   gen()   451 MB/s
  [1.673121] raid6: neonx4   xor()   289 MB/s
  [1.741143] raid6: neonx8   gen()   452 MB/s
  [1.809151] raid6: neonx8   xor()   277 MB/s
  [1.809154] raid6: using algorithm neonx8 gen() 452 MB/s
  [1.809157] raid6:  xor() 277 MB/s, rmw enabled
  [1.809160] raid6: using intx1 recovery algorithm

 I replaced get_random_* with a local PRNG based on well-know 
"linear congruential bit". The patch was like this:

  +/* use the linear congruential bit. */
  +static int32_t get_random_number_by_lcb(void)
  +{
  +static int32_t seed = 1;
  +int32_t ret = 0;
  +ret = ((seed * 1103515245) + 12345) & 0x7fff;
  +seed = ret;
  +return ret;
  +}
 
   /* Try to pick the best algorithm */
   /* This code uses the gfmul table as convenient data set to abuse */
  @@ -229,8 +238,8 @@ int __init raid6_select_algo(void)
  for (i = 0; i < disks-2; i++) {
  dptrs[i] = disk_ptr + PAGE_SIZE*i;
  -   for (j = 0; j < PAGE_SIZE; j++)
  -   get_random_bytes(dptrs[i]+j, 1);
  +   for (j = 0; j < PAGE_SIZE; j = j + 4)
  +   *(int32_t *)(dptrs[i]+j) = get_random_number_by_lcb();
  }
   
  dptrs[disks-2] = disk_ptr + PAGE_SIZE*(disks-2);

The boot log with this patch was showd bellow, it taked about 0.08 second.

  [0.172858] DMA: preallocated 256 KiB pool for atomic allocations
  [0.256673] raid6: int64x1  gen()   121 MB/s
  [0.324484] raid6: int64x1  xor()73 MB/s
  [0.392606] raid6: int64x2  gen()   166 MB/s
  [0.460309] raid6: int64x2  xor()92 MB/s
  [0.528368] raid6: int64x4  gen()   290 MB/s
  [0.596401] raid6: int64x4  xor()   156 MB/s
  [0.664601] raid6: int64x8  gen()   238 MB/s
  [0.732609] raid6: int64x8  xor()   148 MB/s
  [0.800523] raid6: neonx1   gen()   256 MB/s
  [0.868730] raid6: neonx1   xor()   129 MB/s
  [0.936741] raid6: neonx2   gen()   334 MB/s
  [1.004717] raid6: neonx2   xor()   202 MB/s
  [1.072692] raid6: neonx4   gen()   451 MB/s
  [1.140763] raid6: neonx4   xor()   260 MB/s
  [1.208842] raid6: neonx8   gen()   452 MB/s
  [1.276887] raid6: neonx8   xor()   277 MB/s
  [1.276890] raid6: using algorithm neonx8 gen() 452 MB/s
  [1.276894] raid6:  xor() 277 MB/s, rmw enabled
  [1.276897] raid6: using intx1 recovery algorithm
  [1.276941] ACPI: Interpreter disabled.

I'm not familiar with  spurious D$ conflicts and CPU cache behavior. How do you 
think this PRNG or anything else I need to do?

-- Original --
From:  "H. Peter Anvin";
Date:  Tue, Aug 23, 2016 11:53 AM
To:  "liuzhengyuan";
Cc:  "shli"; "linux-raid"; 
"fenghua.yu"; 
"linux-kernel"; 
"liuzhengyuang521";
Subject:  Re: [PATCH] raid6: fix the input of raid6 algorithm
 
Do you have any idea how long this takes to run?  People are already 
complaining about the boot time penalty.  get_random_*() is quite expensive and 
is overkill...
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[PATCH v3 1/2] input: misc: Add generic input driver to read encoded GPIO lines

2016-08-24 Thread Vignesh R
Add a driver to read group of GPIO lines and provide its status as a
numerical value as input event to the system. This will help in
interfacing devices, that can be connected over GPIOs, that provide
input to the system by driving GPIO lines connected to them like a
rotary dial or a switch.

For example, a rotary switch can be connected to four GPIO lines. The
status of the GPIO lines reflect the actual position of the rotary
switch dial. For example, if dial points to 9, then the four GPIO lines
connected to the switch will read HLLH(0b'1001 = 9). This value
can be reported as an ABS_* event to the input subsystem.

Signed-off-by: Vignesh R 
Acked-by: Rob Herring 
---

v3: Fix comments by Andrew and Dmitry
Link to v2: https://lkml.org/lkml/2016/8/23/79

 .../devicetree/bindings/input/gpio-decoder.txt |  23 
 drivers/input/misc/Kconfig |  12 ++
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/gpio_decoder.c  | 134 +
 4 files changed, 170 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/gpio-decoder.txt
 create mode 100644 drivers/input/misc/gpio_decoder.c

diff --git a/Documentation/devicetree/bindings/input/gpio-decoder.txt 
b/Documentation/devicetree/bindings/input/gpio-decoder.txt
new file mode 100644
index ..14a77fb96cf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-decoder.txt
@@ -0,0 +1,23 @@
+* GPIO Decoder DT bindings
+
+Required Properties:
+- compatible: should be "gpio-decoder"
+- gpios: a spec of gpios (at least two) to be decoded to a number with
+  first entry representing the MSB.
+
+Optional Properties:
+- decoder-max-value: Maximum possible value that can be reported by
+  the gpios.
+- linux,axis: the input subsystem axis to map to (ABS_X/ABS_Y).
+  Defaults to 0 (ABS_X).
+
+Example:
+   gpio-decoder0 {
+   compatible = "gpio-decoder";
+   gpios = <&pca9536 3 GPIO_ACTIVE_HIGH>,
+   <&pca9536 2 GPIO_ACTIVE_HIGH>,
+   <&pca9536 1 GPIO_ACTIVE_HIGH>,
+   <&pca9536 0 GPIO_ACTIVE_HIGH>;
+   linux,axis = <0>; /* ABS_X */
+   decoder-max-value = <9>;
+   };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index efb0ca871327..7cdb89397d18 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -292,6 +292,18 @@ config INPUT_GPIO_TILT_POLLED
  To compile this driver as a module, choose M here: the
  module will be called gpio_tilt_polled.
 
+config INPUT_GPIO_DECODER
+   tristate "Polled GPIO Decoder Input driver"
+   depends on GPIOLIB || COMPILE_TEST
+   select INPUT_POLLDEV
+   help
+Say Y here if you want driver to read status of multiple GPIO
+lines and report the encoded value as an absolute integer to
+input subsystem.
+
+To compile this driver as a module, choose M here: the module
+will be called gpio_decoder.
+
 config INPUT_IXP4XX_BEEPER
tristate "IXP4XX Beeper support"
depends on ARCH_IXP4XX
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 6a1e5e20fc1c..0b6d025f0487 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS)   += drv2667.o
 obj-$(CONFIG_INPUT_GP2A)   += gp2ap002a00f.o
 obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o
 obj-$(CONFIG_INPUT_GPIO_TILT_POLLED)   += gpio_tilt_polled.o
+obj-$(CONFIG_INPUT_GPIO_DECODER)   += gpio_decoder.o
 obj-$(CONFIG_INPUT_HISI_POWERKEY)  += hisi_powerkey.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o
diff --git a/drivers/input/misc/gpio_decoder.c 
b/drivers/input/misc/gpio_decoder.c
new file mode 100644
index ..1c2191d4b143
--- /dev/null
+++ b/drivers/input/misc/gpio_decoder.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ *
+ * A generic driver to read multiple gpio lines and translate the
+ * encoded numeric value into an input event.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct gpio_decoder {
+   struct input_polled_dev *poll_dev;
+   struct gpio_descs *input_gpios;
+   struct device *dev;
+   u32 axis;
+   u32 last_stable;
+};
+
+static unsigned int gpio_decoder_ge

[PATCH v3 0/2] AM335x-ICE: Add support for rotary switch

2016-08-24 Thread Vignesh R
This series adds support for rotary-switch on AM335x-ICE that is
connected to TI PCA9536 I2C GPIO expander.
First patch adds new generic driver to read status of group of GPIO
lines and report the value as an input event. The second patch adds DT
entries for the same.

v2: https://lkml.org/lkml/2016/8/23/111
v1: https://lkml.org/lkml/2016/8/12/7


Vignesh R (2):
  input: misc: Add generic input driver to read encoded GPIO lines
  ARM: dts: am335x-icev2: Add nodes for gpio-decoder

 .../devicetree/bindings/input/gpio-decoder.txt |  23 
 arch/arm/boot/dts/am335x-icev2.dts |   9 ++
 drivers/input/misc/Kconfig |  12 ++
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/gpio_decoder.c  | 134 +
 5 files changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/gpio-decoder.txt
 create mode 100644 drivers/input/misc/gpio_decoder.c

-- 
2.9.2



[PATCH v3 2/2] ARM: dts: am335x-icev2: Add nodes for gpio-decoder

2016-08-24 Thread Vignesh R
AM335x ICE board has a rotary-switch connected to PCA9536 I2C GPIO
expander. The position of the rotary-switch is reflected by status of
GPIO lines. Add gpio-decoder node to read these GPIO line status via
gpio-decoder driver and report it as an input event to the system.

Signed-off-by: Vignesh R 
---

v3: s/decoder,max-value/decoder-max-value

 arch/arm/boot/dts/am335x-icev2.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-icev2.dts 
b/arch/arm/boot/dts/am335x-icev2.dts
index bc0190e4f10f..426022ee85c7 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -139,6 +139,15 @@
default-state = "off";
};
};
+   gpio-decoder {
+   compatible = "gpio-decoder";
+   gpios = <&pca9536 3 GPIO_ACTIVE_HIGH>,
+   <&pca9536 2 GPIO_ACTIVE_HIGH>,
+   <&pca9536 1 GPIO_ACTIVE_HIGH>,
+   <&pca9536 0 GPIO_ACTIVE_HIGH>;
+   linux,axis = <0>; /* ABS_X */
+   decoder-max-value = <9>;
+   };
 };
 
 &am33xx_pinmux {
-- 
2.9.2



Re: [PATCH 2/2] i2c: move locking operations to their own struct

2016-08-24 Thread Peter Rosin
On 2016-08-23 23:16, Wolfram Sang wrote:
> On Fri, Jul 29, 2016 at 10:17:57AM +0200, Peter Rosin wrote:
>> This makes it trivial to constify them, so do that.
>>
>> Signed-off-by: Peter Rosin 
> 
> Looks good. Could you rebase to i2c/for-next?

Right, no problem!

Cheers,
Peter

The following changes since commit 00f0ea70d2b82b7d7afeb1bdedc9169eb8ea6675:

  eeprom: at24: check if the chip is functional in probe() (2016-08-22 08:19:58 
+0200)

are available in the git repository at:

  https://github.com/peda-r/i2c-mux.git i2c-lock-op

for you to fetch changes up to 4b42b8c2e3233671e49deee71458edb6737a38bf:

  i2c: move locking operations to their own struct (2016-08-24 06:38:58 +0200)


Peter Rosin (2):
  i2c: add i2c_trylock_bus wrapper, use it
  i2c: move locking operations to their own struct

 drivers/i2c/i2c-core.c | 15 +--
 drivers/i2c/i2c-mux.c  | 29 ++---
 include/linux/i2c.h| 37 +++--
 3 files changed, 58 insertions(+), 23 deletions(-)



Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem strings to sysfs

2016-08-24 Thread Allen Hung
On 08/15/2016 05:55 PM, Allen Hung wrote:
> On 08/03/2016 02:56 AM, Limonciello, Mario wrote:
>>> -Original Message-
>>> From: Jean Delvare [mailto:jdelv...@suse.de]
>>> Sent: Tuesday, August 2, 2016 8:43 AM
>>> To: Limonciello, Mario 
>>> Cc: Hung, Allen ; linux-kernel@vger.kernel.org
>>> Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting oem
>>> strings to sysfs
>>>
>>> Hi Mario, Allen,
>>>
>>> On Tue, 19 Jul 2016 14:47:57 +, mario_limoncie...@dell.com wrote:
 Hi Jean,

 I worked with Allen on this concept, so I've got some comments below.

> -Original Message-
> From: Jean Delvare [mailto:jdelv...@suse.de]
> Sent: Tuesday, July 19, 2016 4:03 AM
> To: Hung, Allen 
> Cc: Jean Delvare ; linux-kernel@vger.kernel.org;
> Limonciello, Mario 
> Subject: Re: [PATCH 2/2] dmi-id: add dmi/id/oem group for exporting
>>> oem
> strings to sysfs
>
> Hello Allen,
>
> On Thu, 14 Jul 2016 16:01:23 +0800, Allen Hung wrote:
>> The oem strings in DMI system identification information of the BIOS
>>> have
>> been parsed and stored as dmi devices in dmi_scan.c but they are not
>> exported to userspace via sysfs.
>
> They are intended for internal consumption by the kernel drivers.
>
>> The patch intends to export oem strings to sysfs device
>>> /sys/class/dmi/id.
>> As the number of oem strings are dynamic, a group "oem" is added to
>>> the
>> device and the strings will be added to the group as string1, string2, 
>> ...,
>> and stringN.
>
> What is the use case? You can already get these strings easily using
> dmidecode:
>
> # dmidecode -qt 11
> OEM Strings
>   String 1: Dell System
>   String 2: 1[05A4]
>   String 3: 3[1.0]
>   String 4: 12[www.dell.com]
>   String 5: 14[1]
>   String 6: 15[3]
>   String 7:
>
> If needed, a dedicated option could be added to dmidecode to extract
> specific OEM strings. Or existing option -s could be extended for that
> purpose.

 The main purpose was to be able to parse these easily from userspace
 without needing dmidecode installed and handling its output
 (with tools such as grep, sed, and awk).
>>>
>>> As I just stated above: dmidecode could be extended to extract the oem
>>> strings directly if there is a need for it.
>>>
 For example in an initramfs, typically dmidecode isn't included, but there
 is value to being able to make decisions on things related to the values of
 those OEM strings.
>>>
>>> dmidecode is not included because nobody needs it. If you need it, you
>>> can include it. 15 years ago, udev was not included in initramfs
>>> either. But we still decided that this stuff should be done in
>>> user-space and we wrote udev and added it to initramfs. It is in the
>>> nature of initramfs to evolve with new needs, and to only include what
>>> is needed on a given machine. mkinitrd/dracut checks the needs
>>> dynamically. Why would it not work in your case?
>>>
>>> I would appreciate more details than "there is value..." I would like
>>> to hear about an actual use case.
>>>
 Instead this allows userspace to iterate the oem/ directory and directly
 look at the values of these strings.
>>>
>>> At the cost of code which will run at every boot, and kernel memory
>>> which will be used forever, on all systems. This is why I am reluctant.
>>> You don't put things in the kernel because this is the easiest way to
>>> fulfill your immediate need. You put things in the kernel because you
>>> absolutely have to, or at the very least because it is where it makes
>>> the most sense. At this point I am not convinced this is the case here.
>>> I see no reason why the same can't be implemented easily in user-space
>>> (dmidecode and dracut.)
>>
>> Thanks, when you put it this way your reluctance makes a lot more sense.
>> I don't disagree that this could live in several different levels of the 
>> software
>> stack.
>>
>> The main reason that we want to have OEM tags exported is to access one
>> particular OEM strings on Dell systems from userspace applications that 
>> should
>> run on Dell systems (not just the initramfs).
>>
>> There is string  that indicates that the system is a Dell System.  Normally 
>> this
>> would be obvious from other SMBIOS strings (such as System Vendor)
>> but Dell also does "OEM systems", which means that they might have 
>> custom branding applied that has otherwise removed the Vendor and
>> Product information.
>>
>> Other strings indicate information that can be used to determine the
>> original product model number and lots of other details.
>>
>> On a system like this it's not possible to know it's a Dell system and what
>> model it was before rebranding without looking at the OEM strings.
>>
>> So by exporting the OEM strings from sysfs, it's possible to accurately 
>> identify Dell systems regardless of whether 

Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats

2016-08-24 Thread Michal Hocko
On Wed 24-08-16 10:15:02, Joonsoo Kim wrote:
> On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote:
> > On Tue 23-08-16 11:13:03, Joonsoo Kim wrote:
> > > On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote:
> > [...]
> > > > I am not opposing the patch (to be honest it is quite neat) but this
> > > > is buggering me for quite some time. Sorry for hijacking this email
> > > > thread but I couldn't resist. Why are we trying to optimize SLAB and
> > > > slowly converge it to SLUB feature-wise. I always thought that SLAB
> > > > should remain stable and time challenged solution which works reasonably
> > > > well for many/most workloads, while SLUB is an optimized implementation
> > > > which experiment with slightly different concepts that might boost the
> > > > performance considerably but might also surprise from time to time. If
> > > > this is not the case then why do we have both of them in the kernel. It
> > > > is a lot of code and some features need tweaking both while only one
> > > > gets testing coverage. So this is mainly a question for maintainers. Why
> > > > do we maintain both and what is the purpose of them.
> > > 
> > > I don't know full history about it since I joined kernel communitiy
> > > recently(?). Christoph would be a better candidate for this topic.
> > > Anyway,
> > > 
> > > SLAB if SLUB beats SLAB completely. But, there are fundamental
> > > differences in implementation detail so they cannot beat each other
> > > for all the workloads. It is similar with filesystem case that various
> > > filesystems exist for it's own workload.
> > 
> > Do we have any documentation/study about which particular workloads
> > benefit from which allocator? It seems that most users will use whatever
> > the default or what their distribution uses. E.g. SLES kernel use SLAB
> > because this is what we used to have for ages and there was no strong
> > reason to change that default. From such a perspective having a stable
> > allocator with minimum changes - just bug fixes - makes a lot of sense.
> 
> It doesn't make sense to me. Even if someone uses SLAB due to
> conventional reason, they would want to use shiny new feature and get
> performance improvement.
> 
> And, it is not only reason to use SLAB. There would be many different
> reasons to use SLAB.

Could you be more specific please? Are there any inherent problems that
would make one allocator unsuitable for specific workloads?

> > I remember Mel doing some benchmarks when "why opensuse kernels do not
> > use the default SLUB allocator" came the last time and he didn't see any
> > large winner there
> > https://lists.opensuse.org/opensuse-kernel/2015-08/msg00098.html
> > This set of workloads is of course not comprehensive to rule one or
> > other but I am wondering whether there are still any pathological
> > workloads where we really want to keep SLAB or add new features to it.
> 
> AFAIK, some network benchmark still shows regression in SLUB.
> 
> http://lkml.kernel.org/r/20150907113026.5bb28...@redhat.com

That suggests that this is not an inherent problem of SLUB though.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH] Make __xfs_xattr_put_listen preperly report errors.

2016-08-24 Thread Artem Savkov
On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> On Tue, Aug 23, 2016 at 05:54:13PM +0200, Artem Savkov wrote:
> > Commit "xfs: only return -errno or success from attr ->put_listent" changes 
> > the
> 
> Please quote commits in --oneline format in changelogs - it makes it
> much easier to find the change you are refering to if there is both
> a commit ID and the text string in the commit message. (i.e. text
> string confirms the commit id is the one you meant to quote).

Noted, thanks.

> 
> commit 2a6fba6 ("xfs: only return -errno or success from attr
> ->put_listent") is the one you are refering to here, right?

Yes, that is the one.

> > returnvalue of __xfs_xattr_put_listen to 0 in case when there is 
> > insufficient
> > space in the buffer assuming that setting context->count to -1 would be 
> > enough,
> > but all of the ->put_listent callers only check seen_enough. This results in
> > a failed assertion:
> > XFS: Assertion failed: context->count >= 0, file: fs/xfs/xfs_xattr.c, line: 
> > 175
> > in insufficient buffer size case.
> 
> You have a test case? Can you turn it into an xfstest? We really
> need regression tests that cover issues like this
> 

llistxattr02 test from LTP reliably hits this, I'll see how this can be
ported to xfstest.

> > Signed-off-by: Artem Savkov 
> > ---
> >  fs/xfs/xfs_xattr.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c
> > index ea62245..6290093 100644
> > --- a/fs/xfs/xfs_xattr.c
> > +++ b/fs/xfs/xfs_xattr.c
> > @@ -147,6 +147,7 @@ __xfs_xattr_put_listent(
> > arraytop = context->count + prefix_len + namelen + 1;
> > if (arraytop > context->firstu) {
> > context->count = -1;/* insufficient space */
> > +   context->seen_enough = 1;
> > return 0;
> > }
> > offset = (char *)context->alist + context->count;
> 
> Looks sane, though I don't know how to test it yet
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com

-- 
Regards,
  Artem


Re: [PATCH v2] kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscd

2016-08-24 Thread Michal Hocko
On Tue 23-08-16 18:32:34, Oleg Nesterov wrote:
> On 08/23, Michal Hocko wrote:
> >
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -913,14 +913,11 @@ void mm_release(struct task_struct *tsk, struct 
> > mm_struct *mm)
> > deactivate_mm(tsk, mm);
> >  
> > /*
> > -* If we're exiting normally, clear a user-space tid field if
> > -* requested.  We leave this alone when dying by signal, to leave
> > -* the value intact in a core dump, and to save the unnecessary
> > -* trouble, say, a killed vfork parent shouldn't touch this mm.
> > -* Userland only wants this done for a sys_exit.
> > +* Signal userspace if we're not exiting with a core dump
> > +* or a killed vfork parent which shouldn't touch this mm.
> 
> Well. ACK, but the comment looks wrong...
> 
> The "killed vfork parent ..." part should be removed, as you pointed
> out this is no longer true.
> 
> OTOH, to me it would be better to not remove the "leave the value
> intact in a core dump" part, otherwise the " we're not exiting with
> a core dump" looks pointless because SIGNAL_GROUP_COREDUMP is self-
> documenting.

Sounds better?
diff --git a/kernel/fork.c b/kernel/fork.c
index b89f0eb99f0a..ddde5849df81 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -914,7 +914,8 @@ void mm_release(struct task_struct *tsk, struct mm_struct 
*mm)
 
/*
 * Signal userspace if we're not exiting with a core dump
-* or a killed vfork parent which shouldn't touch this mm.
+* because we want to leave the value intact for debugging
+* purposes.
 */
if (tsk->clear_child_tid) {
if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) &&
-- 
Michal Hocko
SUSE Labs


[PATCH 2/2] hwmon: (max6650) Add initial rpm target devicetree documentation

2016-08-24 Thread Mike Looijmans
Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.

Signed-off-by: Mike Looijmans 
---
 Documentation/devicetree/bindings/hwmon/max6650.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/max6650.txt 
b/Documentation/devicetree/bindings/hwmon/max6650.txt
index d6c10e3..f6bd87d 100644
--- a/Documentation/devicetree/bindings/hwmon/max6650.txt
+++ b/Documentation/devicetree/bindings/hwmon/max6650.txt
@@ -13,6 +13,10 @@ Optional properties, default is to retain the chip's current 
setting:
 - maxim,fan-prescale  : Pre-scaling value, as per datasheet [1]. Lower values
allow more fine-grained control of slower fans.
Valid: 1, 2, 4, 8, 16.
+- maxim,fan-target-rpm: Initial requested fan rotation speed. If specified, the
+   driver selects closed-loop mode and the requested speed.
+   This ensures the fan is already running before userspace
+   takes over.
 
 Example:
fan-max6650: max6650@1b {
@@ -20,4 +24,5 @@ Example:
compatible = "maxim,max6650";
maxim,fan-microvolt = <1200>;
maxim,fan-prescale = <4>;
+   maxim,fan-target-rpm = <1200>;
};
-- 
1.9.1



[PATCH 1/2] hwmon: (max6650) Allow fan shutdown and initial rpm target

2016-08-24 Thread Mike Looijmans
The fan can be stopped by writing "3" to pwm1_enable in sysfs.

Add devicetree property for early initialization of the fan controller
to prevent overheating, for example when resetting the board while the
fan was completely turned off.

Also improve error reporting, I2C failures were ignored while writing
new values.

Signed-off-by: Mike Looijmans 
---
 Documentation/hwmon/max6650 |   1 +
 drivers/hwmon/max6650.c | 108 +++-
 2 files changed, 68 insertions(+), 41 deletions(-)

diff --git a/Documentation/hwmon/max6650 b/Documentation/hwmon/max6650
index 58d9644..dff1d29 100644
--- a/Documentation/hwmon/max6650
+++ b/Documentation/hwmon/max6650
@@ -34,6 +34,7 @@ fan3_inputro  "
 fan4_input ro  "
 fan1_targetrw  desired fan speed in RPM (closed loop mode only)
 pwm1_enablerw  regulator mode, 0=full on, 1=open loop, 2=closed loop
+   3=off
 pwm1   rw  relative speed (0-255), 255=max. speed.
Used in open loop mode only.
 fan1_div   rw  sets the speed range the inputs can handle. Legal
diff --git a/drivers/hwmon/max6650.c b/drivers/hwmon/max6650.c
index c87517a..a993b44 100644
--- a/drivers/hwmon/max6650.c
+++ b/drivers/hwmon/max6650.c
@@ -185,6 +185,30 @@ static struct max6650_data *max6650_update_device(struct 
device *dev)
return data;
 }
 
+/*
+ * Change the operating mode of the chip (if needed).
+ * mode is one of the MAX6650_CFG_MODE_* values.
+ */
+static int max6650_set_operating_mode(struct max6650_data *data, u8 mode)
+{
+   int result;
+   u8 config = data->config;
+
+   if (mode == (config & MAX6650_CFG_MODE_MASK))
+   return 0;
+
+   config = (config & ~MAX6650_CFG_MODE_MASK) | mode;
+
+   result = i2c_smbus_write_byte_data(data->client, MAX6650_REG_CONFIG,
+  config);
+   if (result < 0)
+   return result;
+
+   data->config = config;
+
+   return 0;
+}
+
 static ssize_t get_fan(struct device *dev, struct device_attribute *devattr,
   char *buf)
 {
@@ -266,18 +290,12 @@ static ssize_t get_target(struct device *dev, struct 
device_attribute *devattr,
return sprintf(buf, "%d\n", rpm);
 }
 
-static ssize_t set_target(struct device *dev, struct device_attribute *devattr,
-const char *buf, size_t count)
+static int max6650_set_target(struct max6650_data *data, unsigned long rpm)
 {
-   struct max6650_data *data = dev_get_drvdata(dev);
-   struct i2c_client *client = data->client;
int kscale, ktach;
-   unsigned long rpm;
-   int err;
 
-   err = kstrtoul(buf, 10, &rpm);
-   if (err)
-   return err;
+   if (rpm == 0)
+   return max6650_set_operating_mode(data, MAX6650_CFG_MODE_OFF);
 
rpm = clamp_val(rpm, FAN_RPM_MIN, FAN_RPM_MAX);
 
@@ -288,8 +306,6 @@ static ssize_t set_target(struct device *dev, struct 
device_attribute *devattr,
 * KTACH = [(fCLK x KSCALE) / (256 x FanSpeed)] - 1
 */
 
-   mutex_lock(&data->update_lock);
-
kscale = DIV_FROM_REG(data->config);
ktach = ((clock * kscale) / (256 * rpm / 60)) - 1;
if (ktach < 0)
@@ -298,10 +314,30 @@ static ssize_t set_target(struct device *dev, struct 
device_attribute *devattr,
ktach = 255;
data->speed = ktach;
 
-   i2c_smbus_write_byte_data(client, MAX6650_REG_SPEED, data->speed);
+   return i2c_smbus_write_byte_data(data->client, MAX6650_REG_SPEED,
+data->speed);
+}
+
+static ssize_t set_target(struct device *dev, struct device_attribute *devattr,
+const char *buf, size_t count)
+{
+   struct max6650_data *data = dev_get_drvdata(dev);
+   unsigned long rpm;
+   int err;
+
+   err = kstrtoul(buf, 10, &rpm);
+   if (err)
+   return err;
+
+   mutex_lock(&data->update_lock);
+
+   err = max6650_set_target(data, rpm);
 
mutex_unlock(&data->update_lock);
 
+   if (err < 0)
+   return err;
+
return count;
 }
 
@@ -355,12 +391,11 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *devattr,
data->dac = 180 - (180 * pwm)/255;
else
data->dac = 76 - (76 * pwm)/255;
-
-   i2c_smbus_write_byte_data(client, MAX6650_REG_DAC, data->dac);
+   err = i2c_smbus_write_byte_data(client, MAX6650_REG_DAC, data->dac);
 
mutex_unlock(&data->update_lock);
 
-   return count;
+   return err < 0 ? err : count;
 }
 
 /*
@@ -369,14 +404,14 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *devattr,
  * 0 = Fan always on
  * 1 = Open loop, Voltage is set according to speed, not regulated.
  * 2 = Closed loop, RPM for all fans regulated by fan1 tachometer
+ * 3 = Fan off
  */
-
 static ssize_t get_enable(struc

[PATCH v2] gpu: ipu-v3: fix a possible NULL dereference

2016-08-24 Thread LABBE Corentin
of_match_device could return NULL, and so cause a NULL pointer
dereference later.

For fixing this problem, we use of_device_get_match_data(), this will
simplify the code a little by using a standard function for
getting the match data.

Testing the return value of of_device_get_match_data is also necessary
for avoiding a second NULL deref later on devtype.

Signed-off-by: LABBE Corentin 
---
Changes in v2:
 - Add a test on devtype for avoiding a second NULL deref.

 drivers/gpu/ipu-v3/ipu-common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 99dcacf..8072470 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1207,15 +1207,15 @@ EXPORT_SYMBOL_GPL(ipu_dump);
 
 static int ipu_probe(struct platform_device *pdev)
 {
-   const struct of_device_id *of_id =
-   of_match_device(imx_ipu_dt_ids, &pdev->dev);
struct ipu_soc *ipu;
struct resource *res;
unsigned long ipu_base;
int i, ret, irq_sync, irq_err;
const struct ipu_devtype *devtype;
 
-   devtype = of_id->data;
+   devtype = of_device_get_match_data(&pdev->dev);
+   if (!devtype)
+   return -EINVAL;
 
irq_sync = platform_get_irq(pdev, 0);
irq_err = platform_get_irq(pdev, 1);
-- 
2.7.3



Re: [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

2016-08-24 Thread Joel
Hi Namhyung,

> On Aug 23, 2016, at 8:20 AM, Namhyung Kim  wrote:
> 
> Hi Joel,
> 
> On Tue, Aug 23, 2016 at 7:25 PM, Joel Fernandes  wrote:
>> From: Namhyung Kim 
> 
>> 
>> Any thoughts on what you think about it? In your approach though, you
>> wouldn't need a backing mem-path file which is the size of the guest
>> RAM (which could be as big as the mem-path file). I wonder if the
>> mem-path file can be created sparse, and/or Qemu has support to
>> configure a certain part of guest RAM as file-backed memory and the
>> rest of it from Anonymous memory (not backed by mem-path) so that
>> the size of the mem-path file can be kept at a minimum.
> 
> The pstore (ramoops) requires the region of the memory is preserved
> across reboot.  Is it possible when -mem-path is used?  I think it’s

I believe the stock qemu won’t persist memory on its own without a reboot.
I found atleast one post where someone was trying to make mem-path
persist across a reboot and claimed to succeed:
https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg03476.html

> 
> Also my approach can handle streams of data bigger than the pstore
> buffer size.  Although we can extract the contents of mem-path file
> periodically, it might be hard for externel process to know the right
> time to extract and there's a possibility of information loss IMHO.
> 

I agree, your approach is better for an emulated environment.

Thanks,
Joel

> Thanks,
> Namhyung



Re: [PATCH] staging: android: ion: ion.c fix parenthesis alignment

2016-08-24 Thread Sudip Mukherjee
On Wed, Aug 24, 2016 at 03:56:32AM +0700, Didik Setiawan wrote:
> Fix checkpatch.pl warning about "Alignment should match open parenthesis".
> ---

you missed the Signed-off-by: line.

regards
sudip


Re: chipidea: udc: kernel panic in isr_setup_status_phase

2016-08-24 Thread Peter Chen
On Tue, Aug 23, 2016 at 02:36:30AM +0200, Clemens Gruber wrote:
> Hi,
> 
> I am using an i.MX6Q embedded board, acting as a (ethernet) gadget with
> RNDIS function, connected over an USB OTG cable to a PC.
> Most of the time it works fine, but in some mysterious circumstances,
> a kernel panic occurs, just after attaching the OTG cable, connecting it
> to the other machine:
> 
> [   54.012989] Unable to handle kernel NULL pointer dereference at virtual 
> address 0020
> [   54.021099] pgd = 80004000
> [   54.023816] [0020] *pgd=
> [   54.027422] Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> [   54.032915] Modules linked in:
> [   54.035998] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 4.8.0-rc3-00017-g336bc4a #315
> [   54.043662] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [   54.050196] task: 80b05f80 task.stack: 80b0
> [   54.054744] PC is at isr_setup_status_phase+0x1c/0x40
> [   54.059805] LR is at 0xbe570890
> [   54.062957] pc : [<804ac464>]lr : []psr: 200e0193
> [   54.062957] sp : 80b01e10  ip : be570570  fp : be570890
> [   54.074442] r10: be5eeebc  r9 : be570010  r8 : be5eeebc
> [   54.079673] r7 : be5708d0  r6 : be5eee80  r5 : be7fcf40  r4 : 0001
> [   54.086206] r3 : be571010  r2 : 804ab368  r1 :   r0 : be570010
> [   54.092742] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [   54.099972] Control: 10c5387d  Table: 4e34404a  DAC: 0051
> [   54.105723] Process swapper/0 (pid: 0, stack limit = 0x80b00210)
> (snip)
> [   54.247100] [<804ac464>] (isr_setup_status_phase) from [<804acbbc>] 
> (isr_tr_complete_handler+0x734/0x98c)
> [   54.256680] [<804acbbc>] (isr_tr_complete_handler) from [<804acfc0>] 
> (udc_irq+0x1ac/0x318)
> [   54.264964] [<804acfc0>] (udc_irq) from [<8018ba28>] 
> (__handle_irq_event_percpu+0x9c/0x128)
> [   54.273330] [<8018ba28>] (__handle_irq_event_percpu) from [<8018bae0>] 
> (handle_irq_event_percpu+0x2c/0x7c)
> [   54.282995] [<8018bae0>] (handle_irq_event_percpu) from [<8018bb68>] 
> (handle_irq_event+0x38/0x5c)
> [   54.291880] [<8018bb68>] (handle_irq_event) from [<8018f2cc>] 
> (handle_fasteoi_irq+0xd0/0x1bc)
> [   54.300418] [<8018f2cc>] (handle_fasteoi_irq) from [<8018afb0>] 
> (generic_handle_irq+0x24/0x34)
> [   54.309042] [<8018afb0>] (generic_handle_irq) from [<8018b2dc>] 
> (__handle_domain_irq+0x7c/0xec)
> [   54.317754] [<8018b2dc>] (__handle_domain_irq) from [<80101524>] 
> (gic_handle_irq+0x38/0x74)
> [   54.326119] [<80101524>] (gic_handle_irq) from [<8010ccb0>] 
> (__irq_svc+0x70/0xb0)
> (snip)
> 
> After looking through the isr_setup_status_phase disassembly, I found
> that ci->status must have been NULL and dereferencing it in
> ci->status->context = ci; triggered the panic.
> 
> The interrupt was a USBINT (UI bit was set) and isr_tr_complete_handler
> was called from udc_irq.
> In the IMX6DQRM I read about the UI bit: "This bit is also set by the
> Host/Device Controller when a short packet is detected." and about
> USBERRINT / UEI bit: "This bit is set along with the USBINT bit, if the
> TD on which the error interrupt occurred also had its interrupt on
> complete (IOC) bit set." (page 5494)
> 
> However, we do not check for UEI in udc_irq.
> Could this be the cause of this error?

UEI is an error interrupt, and software have not handled it, so it will
not affect ci->status.

> Should we only call isr_tr_complete_handler if UI && !UEI ?
> 
> Or would adding a check for ci->status == NULL in isr_setup-status_phase
> and returning an error code also be a good idea?

I agree with that.

> 
> Do you have an idea what's going on there and why ci->status is NULL?
> 

I can't understand it, the only possible is the last disconnect event
(see ci_udc_vbus_session->_gadget_stop_activity) has scheduled very late
due to vbus lowers very slow.

-- 

Best Regards,
Peter Chen


Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

2016-08-24 Thread Dave Young
On 08/23/16 at 06:11pm, Yinghai Lu wrote:
> On Wed, Aug 17, 2016 at 1:20 AM, Dave Young  wrote:
> > On 08/17/16 at 09:50am, Xunlei Pang wrote:
> >> "/sys/kernel/kexec_crash_size" only handles crashk_res, it
> >> is fine in most cases, but sometimes we have crashk_low_res.
> >> For example, when "crashkernel=size[KMG],high" combined with
> >> "crashkernel=size[KMG],low" is used for 64-bit x86.
> >>
> >> Like crashk_res, we introduce the corresponding sysfs file
> >> "/sys/kernel/kexec_crash_low_size" for crashk_low_res.
> >>
> >> So, the exact total reserved memory is the sum of the two.
> >>
> >> crashk_low_res can also be shrunk via this new interface,
> >> and users should be aware of what they are doing.
> ...
> >> @@ -218,6 +238,7 @@ static struct attribute * kernel_attrs[] = {
> >>  #ifdef CONFIG_KEXEC_CORE
> >>   &kexec_loaded_attr.attr,
> >>   &kexec_crash_loaded_attr.attr,
> >> + &kexec_crash_low_size_attr.attr,
> >>   &kexec_crash_size_attr.attr,
> >>   &vmcoreinfo_attr.attr,
> >>  #endif
> 
> would be better if you can use attribute_group .is_visible to control showing 
> of
> crash_low_size only when the crash_base is above 4G.

I have same feeling that it looks odd to show low in sysfs in case no
crashkernel=,high being used. Even if crashkernel=,high is used only in
x86 the resource crashk_low is in common code. What do you think to move
it to x86?

Thanks
Dave

> 
> Thanks
> 
> Yinghai
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats

2016-08-24 Thread Mel Gorman
On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote:
> Do we have any documentation/study about which particular workloads
> benefit from which allocator? It seems that most users will use whatever
> the default or what their distribution uses. E.g. SLES kernel use SLAB
> because this is what we used to have for ages and there was no strong
> reason to change that default.

Yes, with the downside that a reliance on high-orders contended on the
zone lock which would not scale and could degrade over time. If there
were multiple compelling reasons then it would have been an easier
switch.

I did prototype high-order pcp caching up to PAGE_ALLOC_COSTLY_ORDER
but it pushed the size of per_cpu_pages over a cache line which could
be problematic in itself. I never finished off the work as fixing the
allocator for SLUB was not a priority. The prototype no longer applies as
it conflicts with the removal of the fair zone allocation policy.

If/when I get back to the page allocator, the priority would be a bulk
API for faster allocs of batches of order-0 pages instead of allocating
a large page and splitting.

-- 
Mel Gorman
SUSE Labs


Re: [PATCH 2/2] thermal: rcar-thermal: enable hwmon when thermal_zone

2016-08-24 Thread Kuninori Morimoto

Hi Zhang

> > > From: Kuninori Morimoto 
> > > 
> > > rcar-thermal is supporting both thermal_zone_of_sensor_register()
> > > and
> > > thermal_zone_device_register(). But
> > > thermal_zone_of_sensor_register()
> > > doesn't enable hwmon as default.
> > > This patch enables it to keep compatibility
> > > 
> > > Signed-off-by: Kuninori Morimoto 
> > Queued for 4.9
> > 
> the subject should be "thermal:rcar-theraml: enable hwmon when
> thermal_zone_of_sensor_register is used", right?

Yes exactly.
Should I resend v2 patch ?



Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe

2016-08-24 Thread Gabriel Paubert
On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote:

[snip]
> ---
>  Documentation/firmware_class/README|  20 
>  drivers/base/Kconfig   |   2 +-
>  .../request_firmware-avoid-init-probe-init.cocci   | 130 
> +
>  3 files changed, 151 insertions(+), 1 deletion(-)
>  create mode 100644 
> scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> 
> diff --git a/Documentation/firmware_class/README 
> b/Documentation/firmware_class/README
> index cafdca8b3b15..056d1cb9d365 100644
> --- a/Documentation/firmware_class/README
> +++ b/Documentation/firmware_class/README
> @@ -93,6 +93,26 @@
> user contexts to request firmware asynchronously, but can't be called
> in atomic contexts.
>  
> +Requirements:
> +=
> +
> +You should avoid at all costs requesting firmware on both init and probe 
> paths
> +of your device driver. Reason for this is the complexity needed to ensure a
> +firmware will be available for a driver early in boot through different
> +build configurations. Consider built-in drivers needing firmware early, or
> +consider a driver assuming it will only get firmware after pivot_root().
> +
> +Drivers that really need firmware early should use stuff the firmware in

Minor grammatical nit: s/use//

> +initramfs or consider using CONFIG_EXTRA_FIRMWARE. Using initramfs is much
> +more portable to more distributions as not all distributions wish to enable
> +CONFIG_EXTRA_FIRMWARE. Should a driver require the firmware being built-in
> +it should depend on CONFIG_EXTRA_FIRMWARE. There is no current annotation for
> +requiring a firmware on initramfs.
> +
> +If you're a maintainer you can help police this with:
> +
> +$ export 
> COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> +$ make coccicheck MODE=report
>  
>   about in-kernel persistence:
>   ---


Re: [PATCH v5 19/19] iommu/dma: Add support for mapping MSIs

2016-08-24 Thread Thomas Gleixner
On Tue, 23 Aug 2016, Robin Murphy wrote:
> + cookie = domain->iova_cookie;
> + iovad = &cookie->iovad;
> +
> + spin_lock(&cookie->msi_lock);
> + list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> + if (msi_page->phys_hi == msg->address_hi &&
> + msi_page->phys_lo - msg->address_lo < iovad->granule)
> + goto unlock;
> +
> + ret = __iommu_dma_map_msi_page(dev, msg, domain, &msi_page);
> +unlock:
> + spin_unlock(&cookie->msi_lock);
> +
> + if (!ret) {
> + msg->address_hi = upper_32_bits(msi_page->iova);
> + msg->address_lo &= iova_mask(iovad);
> + msg->address_lo += lower_32_bits(msi_page->iova);
> + } else {
> + /*
> +  * We're called from a void callback, so the best we can do is
> +  * 'fail' by filling the message with obviously bogus values.
> +  * Since we got this far due to an IOMMU being present, it's
> +  * not like the existing address would have worked anyway...
> +  */
> + msg->address_hi = ~0U;
> + msg->address_lo = ~0U;
> + msg->data = ~0U;
> + }

The above is really horrible to parse. I had to read it five times to
understand the logic.

static struct iommu_dma_msi_page *
find_or_map_msi_page(struct iommu_dma_cookie *cookie, struct msi_msg *msg)
{
struct iova_domain *iovad = &cookie->iovad;
struct iommu_dma_msi_page *page;

list_for_each_entry(*page, &cookie->msi_page_list, list) {
if (page->phys_hi == msg->address_hi &&
page->phys_lo - msg->address_lo < iovad->granule)
return page;
}

/*
 * FIXME: __iommu_dma_map_msi_page() should return a page or NULL.
 * The integer return value is pretty pointless. If seperate error
 * codes are required that's what ERR_PTR() is for 
 */
ret = __iommu_dma_map_msi_page(dev, msg, domain, &page);
return ret ? ERR_PTR(ret) : page;
}

So now the code in iommu_dma_map_msi_msg() becomes:

spin_lock(&cookie->msi_lock);
msi_page = find_or_map_msi_page(cookie, msg);
spin_unlock(&cookie->msi_lock);

if (!IS_ERR_OR_NULL(msi_page)) {
msg->address_hi = upper_32_bits(msi_page->iova);
msg->address_lo &= iova_mask(iovad);
msg->address_lo += lower_32_bits(msi_page->iova);
} else {
/*
 * We're called from a void callback, so the best we can do is
 * 'fail' by filling the message with obviously bogus values.
 * Since we got this far due to an IOMMU being present, it's
 * not like the existing address would have worked anyway...
 */
msg->address_hi = ~0U;
msg->address_lo = ~0U;
msg->data = ~0U;
}

Hmm? 

Thanks,

tglx


[PATCH 40/41] staging: r8188eu: remove some structure definitions from rtw_event.h

2016-08-24 Thread Ivan Safonov
addba_event, event_node and c2hevent_queue structures are not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtw_event.h | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_event.h 
b/drivers/staging/rtl8188eu/include/rtw_event.h
index 2a45581..df68948 100644
--- a/drivers/staging/rtl8188eu/include/rtw_event.h
+++ b/drivers/staging/rtl8188eu/include/rtw_event.h
@@ -71,10 +71,6 @@ struct stadel_event {
int mac_id;
 };
 
-struct addba_event {
-   unsigned int tid;
-};
-
 #define GEN_EVT_CODE(event)event ## _EVT_
 
 struct fwevent {
@@ -84,21 +80,6 @@ struct fwevent {
 
 #define C2HEVENT_SZ32
 
-struct event_node {
-   unsigned char *node;
-   unsigned char evt_code;
-   unsigned short evt_sz;
-   int *caller_ff_tail;
-   int caller_ff_sz;
-};
-
-struct c2hevent_queue {
-   int head;
-   int tail;
-   struct  event_node  nodes[C2HEVENT_SZ];
-   unsigned char   seq;
-};
-
 #define NETWORK_QUEUE_SZ   4
 
 struct network_queue {
-- 
2.7.3



[PATCH 33/41] staging: r8188eu: remove some structure definitions from wlan_bssdef.h

2016-08-24 Thread Ivan Safonov
ndis_802_11_ai_reqfi, ndis_802_11_ai_resfi, ndis_802_11_assoc_info,
ndis_802_11_remove_key, ndis_802_11_auth_req, ndis_802_11_status_ind,
ndis_802_11_auth_evt, ndis_802_11_test, pmkid_candidate, ndis_802_11_pmkid_list,
ndis_802_11_auth_encrypt and ndis_802_11_cap structures are not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/wlan_bssdef.h | 83 -
 1 file changed, 83 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/wlan_bssdef.h 
b/drivers/staging/rtl8188eu/include/wlan_bssdef.h
index 560966c..e1931dd 100644
--- a/drivers/staging/rtl8188eu/include/wlan_bssdef.h
+++ b/drivers/staging/rtl8188eu/include/wlan_bssdef.h
@@ -123,40 +123,10 @@ enum ndis_802_11_wep_status {
 #define NDIS_802_11_AI_RESFI_STATUSCODE2
 #define NDIS_802_11_AI_RESFI_ASSOCIATIONID 4
 
-struct ndis_802_11_ai_reqfi {
-u16 Capabilities;
-u16 ListenInterval;
-unsigned char CurrentAPAddress[ETH_ALEN];
-};
-
-struct ndis_802_11_ai_resfi {
-u16 Capabilities;
-u16 StatusCode;
-u16 AssociationId;
-};
-
-struct ndis_802_11_assoc_info {
-   u32  Length;
-   u16 AvailableRequestFixedIEs;
-   struct ndis_802_11_ai_reqfiRequestFixedIEs;
-   u32  RequestIELength;
-   u32  OffsetRequestIEs;
-   u16 AvailableResponseFixedIEs;
-   struct ndis_802_11_ai_resfiResponseFixedIEs;
-   u32  ResponseIELength;
-   u32  OffsetResponseIEs;
-};
-
 enum ndis_802_11_reload_def {
Ndis802_11ReloadWEPKeys
 };
 
-struct ndis_802_11_remove_key {
-   u32   Length;/*  Length */
-   u32   KeyIndex;
-   unsigned char BSSID[ETH_ALEN];
-};
-
 struct ndis_802_11_wep {
u32 Length;/*  Length of this structure */
u32 KeyIndex;  /*  0 is the per-client key,
@@ -165,12 +135,6 @@ struct ndis_802_11_wep {
u8 KeyMaterial[16];/*  variable len depending on above field */
 };
 
-struct ndis_802_11_auth_req {
-   u32 Length;/*  Length of structure */
-   unsigned char Bssid[ETH_ALEN];
-   u32 Flags;
-};
-
 enum ndis_802_11_status_type {
Ndis802_11StatusType_Authentication,
Ndis802_11StatusType_MediaStreamMode,
@@ -179,10 +143,6 @@ enum ndis_802_11_status_type {
* an upper bound */
 };
 
-struct ndis_802_11_status_ind {
-   enum ndis_802_11_status_type StatusType;
-};
-
 /*  mask for authentication/integrity fields */
 #define NDIS_802_11_AUTH_REQUEST_AUTH_FIELDS   0x0f
 #define NDIS_802_11_AUTH_REQUEST_REAUTH0x01
@@ -193,21 +153,6 @@ struct ndis_802_11_status_ind {
 /*  MIC check time, 60 seconds. */
 #define MIC_CHECK_TIME 6000
 
-struct ndis_802_11_auth_evt {
-   struct ndis_802_11_status_ind   Status;
-   struct ndis_802_11_auth_req  Request[1];
-};
-
-struct ndis_802_11_test {
-   u32 Length;
-   u32 Type;
-   union {
-   struct ndis_802_11_auth_evt AuthenticationEvent;
-   NDIS_802_11_RSSI RssiTrigger;
-   } tt;
-};
-
-
 #ifndef Ndis802_11APMode
 #define Ndis802_11APMode (Ndis802_11InfrastructureMax+1)
 #endif
@@ -297,32 +242,4 @@ enum UAPSD_MAX_SP {
 #define NUM_PRE_AUTH_KEY 16
 #define NUM_PMKID_CACHE NUM_PRE_AUTH_KEY
 
-/*
-*  WPA2
-*/
-
-struct pmkid_candidate {
-   unsigned char BSSID[ETH_ALEN];
-   u32 Flags;
-};
-
-struct ndis_802_11_pmkid_list {
-   u32 Version;   /*  Version of the structure */
-   u32 NumCandidates; /*  No. of pmkid candidates */
-   struct pmkid_candidate CandidateList[1];
-};
-
-struct ndis_802_11_auth_encrypt {
-   enum ndis_802_11_auth_mode AuthModeSupported;
-   enum ndis_802_11_wep_status EncryptStatusSupported;
-};
-
-struct ndis_802_11_cap {
-   u32  Length;
-   u32  Version;
-   u32  NoOfPMKIDs;
-   u32  NoOfAuthEncryptPairsSupported;
-   struct ndis_802_11_auth_encrypt AuthenticationEncryptionSupported[1];
-};
-
 #endif /* ifndef WLAN_BSSDEF_H_ */
-- 
2.7.3



[PATCH 20/41] staging: r8188eu: change rtw_ieee80211_ht_cap type of structures members to ieee80211_ht_cap

2016-08-24 Thread Ivan Safonov
Also cap_info member of ieee80211_ht_cap wrapped by le16_to_cpu function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c   | 15 ++-
 drivers/staging/rtl8188eu/include/ieee80211.h |  4 ++--
 drivers/staging/rtl8188eu/include/rtw_ht.h|  4 ++--
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 1bccd0a..a148e7d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -481,7 +481,7 @@ void add_RATid(struct adapter *padapter, struct sta_info 
*psta, u8 rssi_level)
limit = 8;/*   1R */
 
for (i = 0; i < limit; i++) {
-   if (psta_ht->ht_cap.supp_mcs_set[i/8] & BIT(i%8))
+   if (psta_ht->ht_cap.mcs.rx_mask[i / 8] & BIT(i % 8))
tx_ra_bitmap |= BIT(i+12);
}
 
@@ -658,11 +658,15 @@ void update_sta_info_apmode(struct adapter *padapter, 
struct sta_info *psta)
phtpriv_sta->ampdu_enable = phtpriv_ap->ampdu_enable;
 
/* check if sta support s Short GI */
-   if ((phtpriv_sta->ht_cap.cap_info & 
phtpriv_ap->ht_cap.cap_info) & (IEEE80211_HT_CAP_SGI_20 | 
IEEE80211_HT_CAP_SGI_40))
+   if (le16_to_cpu(phtpriv_sta->ht_cap.cap_info &
+   phtpriv_ap->ht_cap.cap_info) &
+   (IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40))
phtpriv_sta->sgi = true;
 
/*  bwmode */
-   if ((phtpriv_sta->ht_cap.cap_info & 
phtpriv_ap->ht_cap.cap_info) & IEEE80211_HT_CAP_SUP_WIDTH) {
+   if (le16_to_cpu(phtpriv_sta->ht_cap.cap_info &
+   phtpriv_ap->ht_cap.cap_info) &
+   IEEE80211_HT_CAP_SUP_WIDTH) {
phtpriv_sta->bwmode = pmlmeext->cur_bwmode;
phtpriv_sta->ch_offset = pmlmeext->cur_ch_offset;
}
@@ -1422,7 +1426,8 @@ static int rtw_ht_operation_update(struct adapter 
*padapter)
if (pmlmepriv->num_sta_no_ht ||
(pmlmepriv->ht_op_mode & 
HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT))
new_op_mode = OP_MODE_MIXED;
-   else if ((phtpriv_ap->ht_cap.cap_info & IEEE80211_HT_CAP_SUP_WIDTH) &&
+   else if ((le16_to_cpu(phtpriv_ap->ht_cap.cap_info) &
+ IEEE80211_HT_CAP_SUP_WIDTH) &&
 pmlmepriv->num_sta_ht_20mhz)
new_op_mode = OP_MODE_20MHZ_HT_STA_ASSOCED;
else if (pmlmepriv->olbc_ht)
@@ -1552,7 +1557,7 @@ void bss_cap_update_on_sta_join(struct adapter *padapter, 
struct sta_info *psta)
}
 
if (psta->flags & WLAN_STA_HT) {
-   u16 ht_capab = psta->htpriv.ht_cap.cap_info;
+   u16 ht_capab = le16_to_cpu(psta->htpriv.ht_cap.cap_info);
 
DBG_88E("HT: STA %pM HT Capabilities Info: 0x%04x\n",
(psta->hwaddr), ht_capab);
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index e45ef14..b57f5d7 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -239,7 +239,7 @@ struct ieee_param {
u16 capability;
int flags;
u8 tx_supp_rates[16];
-   struct rtw_ieee80211_ht_cap ht_cap;
+   struct ieee80211_ht_cap ht_cap;
} add_sta;
struct {
u8  reserved[2];/* for set max_num_sta */
@@ -264,7 +264,7 @@ struct sta_data {
u32 sta_set;
u8 tx_supp_rates[16];
u32 tx_supp_rates_len;
-   struct rtw_ieee80211_ht_cap ht_cap;
+   struct ieee80211_ht_cap ht_cap;
u64 rx_pkts;
u64 rx_bytes;
u64 rx_drops;
diff --git a/drivers/staging/rtl8188eu/include/rtw_ht.h 
b/drivers/staging/rtl8188eu/include/rtw_ht.h
index b45483f..7beb0b1 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ht.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ht.h
@@ -15,8 +15,8 @@
 #ifndef _RTW_HT_H_
 #define _RTW_HT_H_
 
+#include 
 #include 
-#include "wifi.h"
 
 struct ht_priv {
u32 ht_option;
@@ -33,7 +33,7 @@ struct ht_priv {
u8  agg_enable_bitmap;
u8  candidate_tid_bitmap;
 
-   struct rtw_ieee80211_ht_cap ht_cap;
+   struct ieee80211_ht_cap ht_cap;
 };
 
 #endif /* _RTL871X_HT_H_ */
-- 
2.7.3



[PATCH 27/41] staging: r8188eu: remove rx_ampdu_maxlen member of ht_priv

2016-08-24 Thread Ivan Safonov
rx_ampdu_maxlen used only once for assigning value.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c  | 1 -
 drivers/staging/rtl8188eu/include/rtw_ht.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index a16d951..9eccadc 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -2037,7 +2037,6 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 *pie, 
uint ie_len)
 
max_ampdu_sz = ht_cap->ampdu_params_info & 
IEEE80211_HT_CAP_AMPDU_FACTOR;
max_ampdu_sz = 1 << (max_ampdu_sz+3); /*  max_ampdu_sz 
(kbytes); */
-   phtpriv->rx_ampdu_maxlen = max_ampdu_sz;
}
len = 0;
p = rtw_get_ie(pie+sizeof(struct ndis_802_11_fixed_ie), 
_HT_ADD_INFO_IE_, &len, ie_len-sizeof(struct ndis_802_11_fixed_ie));
diff --git a/drivers/staging/rtl8188eu/include/rtw_ht.h 
b/drivers/staging/rtl8188eu/include/rtw_ht.h
index 2b03b11..0ee11ef 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ht.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ht.h
@@ -21,8 +21,6 @@
 struct ht_priv {
u32 ht_option;
u32 ampdu_enable;/* for enable Tx A-MPDU */
-   u32 rx_ampdu_maxlen; /* for rx reordering ctrl win_sz,
- * updated when join_callback. */
u8  bwmode;/*  */
u8  ch_offset;/* PRIME_CHNL_OFFSET */
u8  sgi;/* short GI */
-- 
2.7.3



[PATCH] mm: memcontrol: avoid unused function warning

2016-08-24 Thread Arnd Bergmann
A bugfix in v4.8-rc2 introduced a harmless warning when CONFIG_MEMCG_SWAP
is disabled but CONFIG_MEMCG is enabled:

mm/memcontrol.c:4085:27: error: 'mem_cgroup_id_get_online' defined but not used 
[-Werror=unused-function]
 static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)

This adds an extra #ifdef that matches the one around the caller to
avoid the warning.

Signed-off-by: Arnd Bergmann 
Fixes: 1f47b61fb407 ("mm: memcontrol: fix swap counter leak on swapout from 
offline cgroup")
---
 mm/memcontrol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2ff0289ad061..e8d787163b65 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4082,6 +4082,7 @@ static void mem_cgroup_id_get_many(struct mem_cgroup 
*memcg, unsigned int n)
atomic_add(n, &memcg->id.ref);
 }
 
+#ifdef CONFIG_MEMCG_SWAP
 static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
 {
while (!atomic_inc_not_zero(&memcg->id.ref)) {
@@ -4099,6 +4100,7 @@ static struct mem_cgroup *mem_cgroup_id_get_online(struct 
mem_cgroup *memcg)
}
return memcg;
 }
+#endif
 
 static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
 {
-- 
2.9.0



[PATCH 05/41] staging: r8188eu: remove issue_action_spct_ch_switch function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c| 60 
 drivers/staging/rtl8188eu/include/rtw_mlme_ext.h |  2 -
 2 files changed, 62 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 7f32b39..40e0b60 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -1559,66 +1559,6 @@ exit:
return ret;
 }
 
-void issue_action_spct_ch_switch(struct adapter *padapter, u8 *ra, u8 new_ch, 
u8 ch_offset)
-{
-   struct xmit_frame   *pmgntframe;
-   struct pkt_attrib   *pattrib;
-   unsigned char   *pframe;
-   struct rtw_ieee80211_hdr*pwlanhdr;
-   __le16 *fctrl;
-   struct xmit_priv*pxmitpriv = 
&(padapter->xmitpriv);
-   struct mlme_ext_priv*pmlmeext = &(padapter->mlmeextpriv);
-
-
-   DBG_88E(FUNC_NDEV_FMT" ra =%pM, ch:%u, offset:%u\n",
-   FUNC_NDEV_ARG(padapter->pnetdev), ra, new_ch, ch_offset);
-
-   pmgntframe = alloc_mgtxmitframe(pxmitpriv);
-   if (pmgntframe == NULL)
-   return;
-
-   /* update attribute */
-   pattrib = &pmgntframe->attrib;
-   update_mgntframe_attrib(padapter, pattrib);
-
-   memset(pmgntframe->buf_addr, 0, WLANHDR_OFFSET + TXDESC_OFFSET);
-
-   pframe = (u8 *)(pmgntframe->buf_addr) + TXDESC_OFFSET;
-   pwlanhdr = (struct rtw_ieee80211_hdr *)pframe;
-
-   fctrl = &(pwlanhdr->frame_ctl);
-   *(fctrl) = 0;
-
-   memcpy(pwlanhdr->addr1, ra, ETH_ALEN); /* RA */
-   memcpy(pwlanhdr->addr2, myid(&(padapter->eeprompriv)), ETH_ALEN); /* TA 
*/
-   memcpy(pwlanhdr->addr3, ra, ETH_ALEN); /* DA = RA */
-
-   SetSeqNum(pwlanhdr, pmlmeext->mgnt_seq);
-   pmlmeext->mgnt_seq++;
-   SetFrameSubType(pframe, WIFI_ACTION);
-
-   pframe += sizeof(struct rtw_ieee80211_hdr_3addr);
-   pattrib->pktlen = sizeof(struct rtw_ieee80211_hdr_3addr);
-
-   /* category, action */
-   {
-   u8 category, action;
-   category = RTW_WLAN_CATEGORY_SPECTRUM_MGMT;
-   action = RTW_WLAN_ACTION_SPCT_CHL_SWITCH;
-
-   pframe = rtw_set_fixed_ie(pframe, 1, &(category), 
&(pattrib->pktlen));
-   pframe = rtw_set_fixed_ie(pframe, 1, &(action), 
&(pattrib->pktlen));
-   }
-
-   pframe = rtw_set_ie_ch_switch(pframe, &(pattrib->pktlen), 0, new_ch, 0);
-   pframe = rtw_set_ie_secondary_ch_offset(pframe, &(pattrib->pktlen),
-   hal_ch_offset_to_secondary_ch_offset(ch_offset));
-
-   pattrib->last_txcmdsz = pattrib->pktlen;
-
-   dump_mgntframe(padapter, pmgntframe);
-}
-
 static void issue_action_BA(struct adapter *padapter, unsigned char *raddr,
unsigned char action, unsigned short status)
 {
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h 
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index 27382ff..9c2447e 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -562,8 +562,6 @@ int issue_qos_nulldata(struct adapter *padapter, unsigned 
char *da,
   u16 tid, int try_cnt, int wait_ms);
 int issue_deauth(struct adapter *padapter, unsigned char *da,
 unsigned short reason);
-void issue_action_spct_ch_switch(struct adapter *padapter, u8 *ra, u8 new_ch,
-u8 ch_offset);
 unsigned int send_delba(struct adapter *padapter, u8 initiator, u8 *addr);
 unsigned int send_beacon(struct adapter *padapter);
 
-- 
2.7.3



[PATCH 38/41] staging: r8188eu: remove some structure definitions from wlan_bssdef.h

2016-08-24 Thread Ivan Safonov
cmd_msg_parm, H2C_SS_RFOFF_PARAM, joinbssrpt_parm,
P2P_PS_Offload_t and P2P_PS_CTWPeriod_t structures are not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtl8188e_cmd.h | 30 
 1 file changed, 30 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_cmd.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_cmd.h
index 4d7d804..820c045 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_cmd.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_cmd.h
@@ -49,12 +49,6 @@ enum RTL8188E_H2C_CMD_ID {
 H2C_RESET_TSF  = 0xc0,
 };
 
-struct cmd_msg_parm {
-   u8 eid; /* element id */
-   u8 sz; /*  sz */
-   u8 buf[6];
-};
-
 enum {
PWRS
 };
@@ -67,15 +61,6 @@ struct setpwrmode_parm {
u8 PwrState;/* AllON(0x0c),RFON(0x04),RFOFF(0x00) */
 };
 
-struct H2C_SS_RFOFF_PARAM {
-   u8 ROFOn; /*  1: on, 0:off */
-   u16 gpio_period; /*  unit: 1024 us */
-} __packed;
-
-struct joinbssrpt_parm {
-   u8 OpMode;  /*  RT_MEDIA_STATUS */
-};
-
 struct rsvdpage_loc {
u8 LocProbeRsp;
u8 LocPsPoll;
@@ -84,21 +69,6 @@ struct rsvdpage_loc {
u8 LocBTQosNull;
 };
 
-struct P2P_PS_Offload_t {
-   u8 Offload_En:1;
-   u8 role:1; /*  1: Owner, 0: Client */
-   u8 CTWindow_En:1;
-   u8 NoA0_En:1;
-   u8 NoA1_En:1;
-   u8 AllStaSleep:1; /*  Only valid in Owner */
-   u8 discovery:1;
-   u8 rsvd:1;
-};
-
-struct P2P_PS_CTWPeriod_t {
-   u8 CTWPeriod;   /* TU */
-};
-
 /*  host message to firmware cmd */
 void rtl8188e_set_FwPwrMode_cmd(struct adapter *padapter, u8 Mode);
 void rtl8188e_set_FwJoinBssReport_cmd(struct adapter *padapter, u8 mstatus);
-- 
2.7.3



[PATCH 02/41] staging: r8188eu: remove rtw_get_ie_ex function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 44 --
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 46 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index b8ba90a..a37d847 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -236,50 +236,6 @@ u8 *rtw_get_ie(u8 *pbuf, int index, int *len, int limit)
return NULL;
 }
 
-/**
- * rtw_get_ie_ex - Search specific IE from a series of IEs
- * @in_ie: Address of IEs to search
- * @in_len: Length limit from in_ie
- * @eid: Element ID to match
- * @oui: OUI to match
- * @oui_len: OUI length
- * @ie: If not NULL and the specific IE is found, the IE will be copied to the 
buf starting from the specific IE
- * @ielen: If not NULL and the specific IE is found, will set to the length of 
the entire IE
- *
- * Returns: The address of the specific IE found, or NULL
- */
-u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len, u8 eid, u8 *oui, u8 oui_len, u8 *ie, 
uint *ielen)
-{
-   uint cnt;
-   u8 *target_ie = NULL;
-
-
-   if (ielen)
-   *ielen = 0;
-
-   if (!in_ie || in_len <= 0)
-   return target_ie;
-
-   cnt = 0;
-
-   while (cnt < in_len) {
-   if (eid == in_ie[cnt] && (!oui || !memcmp(&in_ie[cnt + 2], oui, 
oui_len))) {
-   target_ie = &in_ie[cnt];
-
-   if (ie)
-   memcpy(ie, &in_ie[cnt], in_ie[cnt + 1] + 2);
-
-   if (ielen)
-   *ielen = in_ie[cnt + 1] + 2;
-
-   break;
-   } else {
-   cnt += in_ie[cnt + 1] + 2; /* goto next */
-   }
-   }
-   return target_ie;
-}
-
 void rtw_set_supported_rate(u8 *SupportedRates, uint mode)
 {
 
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index a62077b..8afef17 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1106,8 +1106,6 @@ u8 *rtw_set_ie_mesh_ch_switch_parm(u8 *buf, u32 *buf_len, 
u8 ttl,
   u8 flags, u16 reason, u16 precedence);
 
 u8 *rtw_get_ie(u8 *pbuf, int index, int *len, int limit);
-u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len, u8 eid, u8 *oui,
- u8 oui_len, u8 *ie, uint *ielen);
 
 void rtw_set_supported_rate(u8 *SupportedRates, uint mode);
 
-- 
2.7.3



[PATCH 06/41] staging: r8188eu: remove hal_ch_offset_to_secondary_ch_offset function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 12 
 drivers/staging/rtl8188eu/include/ieee80211.h  |  1 -
 2 files changed, 13 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 641c874..557832f8 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -166,18 +166,6 @@ inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 
ch_switch_mode,
return rtw_set_ie(buf, WLAN_EID_CHANNEL_SWITCH,  3, ie_data, buf_len);
 }
 
-inline u8 hal_ch_offset_to_secondary_ch_offset(u8 ch_offset)
-{
-   if (ch_offset == HAL_PRIME_CHNL_OFFSET_DONT_CARE)
-   return SCN;
-   else if (ch_offset == HAL_PRIME_CHNL_OFFSET_LOWER)
-   return SCB;
-   else if (ch_offset == HAL_PRIME_CHNL_OFFSET_UPPER)
-   return SCA;
-
-   return SCN;
-}
-
 inline u8 *rtw_set_ie_secondary_ch_offset(u8 *buf, u32 *buf_len, u8 
secondary_ch_offset)
 {
return rtw_set_ie(buf, WLAN_EID_SECONDARY_CHANNEL_OFFSET,  1, 
&secondary_ch_offset, buf_len);
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index 976bb63..ba634df 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1096,7 +1096,6 @@ enum secondary_ch_offset {
SCA = 1, /* secondary channel above */
SCB = 3,  /* secondary channel below */
 };
-u8 hal_ch_offset_to_secondary_ch_offset(u8 ch_offset);
 u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
 u8 new_ch, u8 ch_switch_cnt);
 u8 *rtw_set_ie_secondary_ch_offset(u8 *buf, u32 *buf_len,
-- 
2.7.3



[PATCH 35/41] staging: r8188eu: remove sha256_state structure

2016-08-24 Thread Ivan Safonov
This structure does not used in driver code.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtw_security.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_security.h 
b/drivers/staging/rtl8188eu/include/rtw_security.h
index ca1247b..2663e60 100644
--- a/drivers/staging/rtl8188eu/include/rtw_security.h
+++ b/drivers/staging/rtl8188eu/include/rtw_security.h
@@ -164,12 +164,6 @@ struct security_priv {
u8 bWepDefaultKeyIdxSet;
 };
 
-struct sha256_state {
-   u64 length;
-   u32 state[8], curlen;
-   u8 buf[64];
-};
-
 #define GET_ENCRY_ALGO(psecuritypriv, psta, encry_algo, bmcst) \
 do {   \
switch (psecuritypriv->dot11AuthAlgrthm) {  \
-- 
2.7.3



Re: [PATCH 2/2] thermal: rcar-thermal: enable hwmon when thermal_zone

2016-08-24 Thread Zhang Rui
On 三, 2016-08-24 at 08:17 +, Kuninori Morimoto wrote:
> Hi Zhang
> 
> > 
> > > 
> > > > 
> > > > From: Kuninori Morimoto 
> > > > 
> > > > rcar-thermal is supporting both
> > > > thermal_zone_of_sensor_register()
> > > > and
> > > > thermal_zone_device_register(). But
> > > > thermal_zone_of_sensor_register()
> > > > doesn't enable hwmon as default.
> > > > This patch enables it to keep compatibility
> > > > 
> > > > Signed-off-by: Kuninori Morimoto  > > > com>
> > > Queued for 4.9
> > > 
> > the subject should be "thermal:rcar-theraml: enable hwmon when
> > thermal_zone_of_sensor_register is used", right?
> Yes exactly.
> Should I resend v2 patch ?
> 
nop. I've already updated the patch subject.

thanks,
rui


[PATCH 07/41] staging: r8188eu: remove rtw_set_ie_secondary_ch_offset function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 5 -
 drivers/staging/rtl8188eu/include/ieee80211.h  | 2 --
 2 files changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 557832f8..13080d1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -166,11 +166,6 @@ inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 
ch_switch_mode,
return rtw_set_ie(buf, WLAN_EID_CHANNEL_SWITCH,  3, ie_data, buf_len);
 }
 
-inline u8 *rtw_set_ie_secondary_ch_offset(u8 *buf, u32 *buf_len, u8 
secondary_ch_offset)
-{
-   return rtw_set_ie(buf, WLAN_EID_SECONDARY_CHANNEL_OFFSET,  1, 
&secondary_ch_offset, buf_len);
-}
-
 inline u8 *rtw_set_ie_mesh_ch_switch_parm(u8 *buf, u32 *buf_len, u8 ttl,
u8 flags, u16 reason, u16 precedence)
 {
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index ba634df..d957caa 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1098,8 +1098,6 @@ enum secondary_ch_offset {
 };
 u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
 u8 new_ch, u8 ch_switch_cnt);
-u8 *rtw_set_ie_secondary_ch_offset(u8 *buf, u32 *buf_len,
-  u8 secondary_ch_offset);
 u8 *rtw_set_ie_mesh_ch_switch_parm(u8 *buf, u32 *buf_len, u8 ttl,
   u8 flags, u16 reason, u16 precedence);
 
-- 
2.7.3



[PATCH 30/41] staging: r8188eu: remove some structure definitions from include/ieee80211.h

2016-08-24 Thread Ivan Safonov
ieee_ibss_seq, rtw_ieee80211_hdr_qos, eapol, ieee80211_rx_stats,
ieee80211_frag_entry, ieee80211_stats, ieee80211_softmac_stats,
ieee80211_security, ieee80211_header_data, ieee80211_info_element_hdr,
ieee80211_info_element, ieee80211_authentication, ieee80211_probe_response,
ieee80211_probe_request, ieee80211_assoc_request_frame,
ieee80211_assoc_response_frame structures are not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/ieee80211.h | 196 --
 1 file changed, 196 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index b57f5d7..37a6f9d 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -291,14 +291,6 @@ struct sta_data {
 /* this is stolen from ipw2200 driver */
 #define IEEE_IBSS_MAC_HASH_SIZE 31
 
-struct ieee_ibss_seq {
-   u8 mac[ETH_ALEN];
-   u16 seq_num;
-   u16 frag_num;
-   unsigned long packet_time;
-   struct list_head list;
-};
-
 struct rtw_ieee80211_hdr {
__le16 frame_ctl;
__le16 duration_id;
@@ -318,17 +310,6 @@ struct rtw_ieee80211_hdr_3addr {
u16 seq_ctl;
 } __packed;
 
-struct rtw_ieee80211_hdr_qos {
-   __le16 frame_ctl;
-   __le16 duration_id;
-   u8 addr1[ETH_ALEN];
-   u8 addr2[ETH_ALEN];
-   u8 addr3[ETH_ALEN];
-   u16 seq_ctl;
-   u8 addr4[ETH_ALEN];
-   u16 qc;
-}  __packed;
-
 struct rtw_ieee80211_hdr_3addr_qos {
__le16 frame_ctl;
__le16 duration_id;
@@ -339,14 +320,6 @@ struct rtw_ieee80211_hdr_3addr_qos {
u16 qc;
 }  __packed;
 
-struct eapol {
-   u8 snap[6];
-   u16 ethertype;
-   u8 version;
-   u8 type;
-   u16 length;
-} __packed;
-
 enum eap_type {
EAP_PACKET = 0,
EAPOL_START,
@@ -552,83 +525,12 @@ struct ieee80211_snap_hdr {
 #define IEEE80211_NUM_CCK_RATES4
 #define IEEE80211_OFDM_SHIFT_MASK_A4
 
-/* NOTE: This data is for statistical purposes; not all hardware provides this
- *   information for frames received.  Not setting these will not cause
- *   any adverse affects. */
-struct ieee80211_rx_stats {
-   /* u32 mac_time[2]; */
-   s8 rssi;
-   u8 signal;
-   u8 noise;
-   u8 received_channel;
-   u16 rate; /* in 100 kbps */
-   /* u8 control; */
-   u8 mask;
-   u8 freq;
-   u16 len;
-};
-
 /* IEEE 802.11 requires that STA supports concurrent reception of at least
  * three fragmented frames. This define can be increased to support more
  * concurrent frames, but it should be noted that each entry can consume about
  * 2 kB of RAM and increasing cache size will slow down frame reassembly. */
 #define IEEE80211_FRAG_CACHE_LEN 4
 
-struct ieee80211_frag_entry {
-   u32 first_frag_time;
-   uint seq;
-   uint last_frag;
-   uint qos;   /* jackson */
-   uint tid;   /* jackson */
-   struct sk_buff *skb;
-   u8 src_addr[ETH_ALEN];
-   u8 dst_addr[ETH_ALEN];
-};
-
-struct ieee80211_stats {
-   uint tx_unicast_frames;
-   uint tx_multicast_frames;
-   uint tx_fragments;
-   uint tx_unicast_octets;
-   uint tx_multicast_octets;
-   uint tx_deferred_transmissions;
-   uint tx_single_retry_frames;
-   uint tx_multiple_retry_frames;
-   uint tx_retry_limit_exceeded;
-   uint tx_discards;
-   uint rx_unicast_frames;
-   uint rx_multicast_frames;
-   uint rx_fragments;
-   uint rx_unicast_octets;
-   uint rx_multicast_octets;
-   uint rx_fcs_errors;
-   uint rx_discards_no_buffer;
-   uint tx_discards_wrong_sa;
-   uint rx_discards_undecryptable;
-   uint rx_message_in_msg_fragments;
-   uint rx_message_in_bad_msg_fragments;
-};
-
-struct ieee80211_softmac_stats {
-   uint rx_ass_ok;
-   uint rx_ass_err;
-   uint rx_probe_rq;
-   uint tx_probe_rs;
-   uint tx_beacons;
-   uint rx_auth_rq;
-   uint rx_auth_rs_ok;
-   uint rx_auth_rs_err;
-   uint tx_auth_rq;
-   uint no_auth_rs;
-   uint no_ass_rs;
-   uint tx_ass_rq;
-   uint rx_ass_rq;
-   uint tx_probe_rq;
-   uint reassoc;
-   uint swtxstop;
-   uint swtxawake;
-};
-
 #define SEC_KEY_1  (1<<0)
 #define SEC_KEY_2  (1<<1)
 #define SEC_KEY_3  (1<<2)
@@ -648,42 +550,6 @@ struct ieee80211_softmac_stats {
 #define WEP_KEYS 4
 #define WEP_KEY_LEN 13
 
-struct ieee80211_security {
-   u16 active_key:2,
-   enabled:1,
-   auth_mode:2,
-   auth_algo:4,
-   unicast_uses_group:1;
-   u8 key_sizes[WEP_KEYS];
-   u8 keys[WEP_KEYS][WEP_KEY_LEN];
-   u8 level;
-   u16 flags;
-} __packed;
-
-/*
-
- 802.11 data frame from AP
-
-  ,---.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-

[PATCH 24/41] staging: r8188eu: replace HT_caps_element with ieee80211_ht_cap structure

2016-08-24 Thread Ivan Safonov
HT_caps_element is reimplementation of ieee80211_ht_cap.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c  | 10 -
 drivers/staging/rtl8188eu/core/rtw_ioctl_set.c   |  6 +++---
 drivers/staging/rtl8188eu/core/rtw_mlme.c| 12 +--
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c| 22 +--
 drivers/staging/rtl8188eu/core/rtw_wlan_util.c   | 27 
 drivers/staging/rtl8188eu/include/rtw_mlme_ext.h |  6 +++---
 6 files changed, 42 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index be4d624..3562f11 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -706,12 +706,12 @@ static void update_hw_ht_param(struct adapter *padapter)
 
/* handle A-MPDU parameter field */
/*
-   AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k
-   AMPDU_para [4:2]:Min MPDU Start Spacing
+   ampdu_params_info [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 
3:64k
+   ampdu_params_info [4:2]:Min MPDU Start Spacing
*/
-   max_AMPDU_len = pmlmeinfo->HT_caps.AMPDU_para & 0x03;
+   max_AMPDU_len = pmlmeinfo->HT_caps.ampdu_params_info & 0x03;
 
-   min_MPDU_spacing = (pmlmeinfo->HT_caps.AMPDU_para & 0x1c) >> 2;
+   min_MPDU_spacing = (pmlmeinfo->HT_caps.ampdu_params_info & 0x1c) >> 2;
 
rtw_hal_set_hwreg(padapter, HW_VAR_AMPDU_MIN_SPACE, (u8 
*)(&min_MPDU_spacing));
 
@@ -720,7 +720,7 @@ static void update_hw_ht_param(struct adapter *padapter)
/*  */
/*  Config SM Power Save setting */
/*  */
-   pmlmeinfo->SM_PS = (le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & 
0x0C) >> 2;
+   pmlmeinfo->SM_PS = (le16_to_cpu(pmlmeinfo->HT_caps.cap_info) & 0x0C) >> 
2;
if (pmlmeinfo->SM_PS == WLAN_HT_CAP_SM_PS_STATIC)
DBG_88E("%s(): WLAN_HT_CAP_SM_PS_STATIC\n", __func__);
 }
diff --git a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c 
b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
index a830752..6ed23f4 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
@@ -588,8 +588,8 @@ u16 rtw_get_cur_max_rate(struct adapter *adapter)
/* cur_bwmod is updated by beacon, pmlmeinfo is updated 
by association response */
bw_40MHz = (pmlmeext->cur_bwmode && 
(HT_INFO_HT_PARAM_REC_TRANS_CHNL_WIDTH & pmlmeinfo->HT_info.infos[0])) ? 1 : 0;
 
-   short_GI_20 = 
(le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & IEEE80211_HT_CAP_SGI_20) ? 1 : 
0;
-   short_GI_40 = 
(le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & IEEE80211_HT_CAP_SGI_40) ? 1 : 
0;
+   short_GI_20 = (le16_to_cpu(pmlmeinfo->HT_caps.cap_info) 
& IEEE80211_HT_CAP_SGI_20) ? 1 : 0;
+   short_GI_40 = (le16_to_cpu(pmlmeinfo->HT_caps.cap_info) 
& IEEE80211_HT_CAP_SGI_40) ? 1 : 0;
 
rtw_hal_get_hwreg(adapter, HW_VAR_RF_TYPE, (u8 
*)(&rf_type));
max_rate = rtw_mcs_rate(
@@ -597,7 +597,7 @@ u16 rtw_get_cur_max_rate(struct adapter *adapter)
bw_40MHz & (pregistrypriv->cbw40_enable),
short_GI_20,
short_GI_40,
-   pmlmeinfo->HT_caps.MCS_rate
+   pmlmeinfo->HT_caps.mcs.rx_mask
);
}
} else {
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 03baaa1..a16d951 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1971,8 +1971,8 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
rtw_hal_get_def_var(padapter, HAL_DEF_MAX_RECVBUF_SZ, 
&max_recvbuf_sz);
 
/*
-   AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k
-   AMPDU_para [4:2]:Min MPDU Start Spacing
+   ampdu_params_info [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 
3:64k
+   ampdu_params_info [4:2]:Min MPDU Start Spacing
*/
 
rtw_hal_get_def_var(padapter, HW_VAR_MAX_RX_AMPDU_FACTOR, 
&max_rx_ampdu_factor);
@@ -2044,7 +2044,7 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 *pie, 
uint ie_len)
 
/* update cur_bwmode & cur_ch_offset */
if ((pregistrypriv->cbw40_enable) &&
-   (le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & BIT(1)) &&
+   (le16_to_cpu(pmlmeinfo->HT_caps.cap_info) & BIT(1)) &&
(pmlmeinfo->HT_info.infos[0] & BIT(2))) {
int i;
u8  rf_type;
@@ -2054,9 +2054,9 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 *pie, 
uint i

[PATCH 15/41] staging: r8188eu: replace rtw_ieee80211_ht_cap with ieee80211_ht_cap type in rtw_check_beacon_data function

2016-08-24 Thread Ivan Safonov
rtw_ieee80211_ht_cap is reimplementation of the ieee80211_ht_cap.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index bbb1aa7..1bccd0a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -1032,7 +1032,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 
*pbuf,  int len)
   (pbss_network->IELength - _BEACON_IE_OFFSET_));
if (p && ie_len > 0) {
u8 rf_type;
-   struct rtw_ieee80211_ht_cap *pht_cap = (struct 
rtw_ieee80211_ht_cap *)(p+2);
+   struct ieee80211_ht_cap *pht_cap = (struct ieee80211_ht_cap 
*)(p + 2);
 
pHT_caps_ie = p;
ht_cap = true;
@@ -1050,8 +1050,8 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 
*pbuf,  int len)
pht_cap->ampdu_params_info |= (IEEE80211_HT_CAP_AMPDU_FACTOR & 
0x03);
 
if (rf_type == RF_1T1R) {
-   pht_cap->supp_mcs_set[0] = 0xff;
-   pht_cap->supp_mcs_set[1] = 0x0;
+   pht_cap->mcs.rx_mask[0] = 0xff;
+   pht_cap->mcs.rx_mask[1] = 0x0;
}
memcpy(&pmlmepriv->htpriv.ht_cap, p+2, ie_len);
}
-- 
2.7.3



[PATCH 19/41] staging: r8188eu: change rtw_ieee80211_ht_cap type of local variables to ieee80211_ht_cap

2016-08-24 Thread Ivan Safonov
rtw_ieee80211_ht_cap is reimplementation of the ieee80211_ht_cap.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c |  9 
 drivers/staging/rtl8188eu/core/rtw_mlme.c  | 31 +-
 drivers/staging/rtl8188eu/core/rtw_wlan_util.c |  7 +++---
 3 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 0c616bc..914c492 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -1042,7 +1042,6 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
__le16 le_tmp;
u16 wpa_len = 0, rsn_len = 0;
struct HT_info_element *pht_info = NULL;
-   struct rtw_ieee80211_ht_cap *pht_cap = NULL;
unsigned intlen;
unsigned char   *p;
 
@@ -1078,10 +1077,12 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
/* parsing HT_CAP_IE */
p = rtw_get_ie(pnetwork->network.IEs + _FIXED_IE_LENGTH_, 
_HT_CAPABILITY_IE_, &len, pnetwork->network.IELength - _FIXED_IE_LENGTH_);
if (p && len > 0) {
-   pht_cap = (struct rtw_ieee80211_ht_cap *)(p + 2);
-   pnetwork->BcnInfo.ht_cap_info = pht_cap->cap_info;
+   struct ieee80211_ht_cap *ht_cap =
+   (struct ieee80211_ht_cap *)(p + 2);
+
+   pnetwork->BcnInfo.ht_cap_info = le16_to_cpu(ht_cap->cap_info);
} else {
-   pnetwork->BcnInfo.ht_cap_info = 0;
+   pnetwork->BcnInfo.ht_cap_info = 0;
}
/* parsing HT_INFO_IE */
p = rtw_get_ie(pnetwork->network.IEs + _FIXED_IE_LENGTH_, 
_HT_ADD_INFO_IE_, &len, pnetwork->network.IELength - _FIXED_IE_LENGTH_);
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index a4e3bde..4979c61 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1935,7 +1935,6 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
u32 ielen, out_len;
enum ht_cap_ampdu_factor max_rx_ampdu_factor;
unsigned char *p;
-   struct rtw_ieee80211_ht_cap ht_capie;
unsigned char WMM_IE[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01, 0x00};
struct mlme_priv*pmlmepriv = &padapter->mlmepriv;
struct qos_priv *pqospriv = &pmlmepriv->qospriv;
@@ -1948,6 +1947,8 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
p = rtw_get_ie(in_ie+12, _HT_CAPABILITY_IE_, &ielen, in_len-12);
 
if (p && ielen > 0) {
+   struct ieee80211_ht_cap ht_cap;
+
if (pqospriv->qos_option == 0) {
out_len = *pout_len;
rtw_set_ie(out_ie+out_len, _VENDOR_SPECIFIC_IE_,
@@ -1958,13 +1959,13 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
 
out_len = *pout_len;
 
-   memset(&ht_capie, 0, sizeof(struct ieee80211_ht_cap));
+   memset(&ht_cap, 0, sizeof(struct ieee80211_ht_cap));
 
-   ht_capie.cap_info = IEEE80211_HT_CAP_SUP_WIDTH |
-   IEEE80211_HT_CAP_SGI_20 |
-   IEEE80211_HT_CAP_SGI_40 |
-   IEEE80211_HT_CAP_TX_STBC |
-   IEEE80211_HT_CAP_DSSSCCK40;
+   ht_cap.cap_info = cpu_to_le16(IEEE80211_HT_CAP_SUP_WIDTH |
+ IEEE80211_HT_CAP_SGI_20 |
+ IEEE80211_HT_CAP_SGI_40 |
+ IEEE80211_HT_CAP_TX_STBC |
+ IEEE80211_HT_CAP_DSSSCCK40);
 
rtw_hal_get_def_var(padapter, HAL_DEF_RX_PACKET_OFFSET, 
&rx_packet_offset);
rtw_hal_get_def_var(padapter, HAL_DEF_MAX_RECVBUF_SZ, 
&max_recvbuf_sz);
@@ -1975,17 +1976,16 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
*/
 
rtw_hal_get_def_var(padapter, HW_VAR_MAX_RX_AMPDU_FACTOR, 
&max_rx_ampdu_factor);
-   ht_capie.ampdu_params_info = (max_rx_ampdu_factor&0x03);
+   ht_cap.ampdu_params_info = max_rx_ampdu_factor & 0x03;
 
if (padapter->securitypriv.dot11PrivacyAlgrthm == _AES_)
-   ht_capie.ampdu_params_info |= 
(IEEE80211_HT_CAP_AMPDU_DENSITY&(0x07<<2));
+   ht_cap.ampdu_params_info |= 
IEEE80211_HT_CAP_AMPDU_DENSITY & (0x07 << 2);
else
-   ht_capie.ampdu_params_info |= 
(IEEE80211_HT_CAP_AMPDU_DENSITY&0x00);
-
+   ht_cap.ampdu_params_info |= 
IEEE80211_HT_CAP_AMPDU_DENSITY & 0x00;
 
rtw_set_ie(ou

[PATCH] fb: udl: fix build without CONFIG_FB_DEFERRED_IO

2016-08-24 Thread Arnd Bergmann
A cleanup in v4.8 dropped several dependencies, but caused the udl driver
to fail building when CONFIG_FB_DEFERRED_IO is not set:

drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_open':
drivers/gpu/drm/udl/udl_fb.c:206:23: error: 'struct fb_info' has no member 
named 'fbdefio'
  if (fb_defio && (info->fbdefio == NULL)) {
   ^~

This adds an #ifdef check around the code that fails. We know this
is safe because it always checks info->fbdefio for being non-NULL,
and that member is not defined here.

Signed-off-by: Arnd Bergmann 
Fixes: c0f0c177b5a9 ("drm/udl: make fbdev support really optional")
---
 drivers/gpu/drm/udl/udl_fb.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d5df555aeba0..fec47733e57e 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -24,11 +24,14 @@
 
 #define DL_DEFIO_WRITE_DELAY(HZ/20) /* fb_deferred_io.delay in jiffies */
 
-static int fb_defio = 0;  /* Optionally enable experimental fb_defio mmap 
support */
 static int fb_bpp = 16;
 
 module_param(fb_bpp, int, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
+
+#ifdef CONFIG_FB_DEFERRED_IO
+static int fb_defio = 0;  /* Optionally enable experimental fb_defio mmap 
support */
 module_param(fb_defio, int, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
+#endif
 
 struct udl_fbdev {
struct drm_fb_helper helper;
@@ -203,6 +206,7 @@ static int udl_fb_open(struct fb_info *info, int user)
 
ufbdev->fb_count++;
 
+#ifdef CONFIG_FB_DEFERRED_IO
if (fb_defio && (info->fbdefio == NULL)) {
/* enable defio at last moment if not disabled by client */
 
@@ -218,6 +222,7 @@ static int udl_fb_open(struct fb_info *info, int user)
info->fbdefio = fbdefio;
fb_deferred_io_init(info);
}
+#endif
 
pr_notice("open /dev/fb%d user=%d fb_info=%p count=%d\n",
  info->node, user, info, ufbdev->fb_count);
@@ -235,12 +240,14 @@ static int udl_fb_release(struct fb_info *info, int user)
 
ufbdev->fb_count--;
 
+#ifdef CONFIG_FB_DEFERRED_IO
if ((ufbdev->fb_count == 0) && (info->fbdefio)) {
fb_deferred_io_cleanup(info);
kfree(info->fbdefio);
info->fbdefio = NULL;
info->fbops->fb_mmap = udl_fb_mmap;
}
+#endif
 
pr_warn("released /dev/fb%d user=%d count=%d\n",
info->node, user, ufbdev->fb_count);
-- 
2.9.0



[PATCH 12/41] staging: r8188eu: remove rtw_action_frame_parse function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 29 --
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 31 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index f3e9f7e..fac1241 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -1155,35 +1155,6 @@ u16 rtw_mcs_rate(u8 rf_type, u8 bw_40MHz, u8 
short_GI_20, u8 short_GI_40, unsign
return max_rate;
 }
 
-int rtw_action_frame_parse(const u8 *frame, u32 frame_len, u8 *category, u8 
*action)
-{
-   const u8 *frame_body = frame + sizeof(struct rtw_ieee80211_hdr_3addr);
-   u16 fc;
-   u8 c, a = 0;
-
-   fc = le16_to_cpu(((struct rtw_ieee80211_hdr_3addr *)frame)->frame_ctl);
-
-   if ((fc & (RTW_IEEE80211_FCTL_FTYPE | RTW_IEEE80211_FCTL_STYPE)) !=
-   (RTW_IEEE80211_FTYPE_MGMT | RTW_IEEE80211_STYPE_ACTION))
-   return false;
-
-   c = frame_body[0];
-
-   switch (c) {
-   case RTW_WLAN_CATEGORY_P2P: /* vendor-specific */
-   break;
-   default:
-   a = frame_body[1];
-   }
-
-   if (category)
-   *category = c;
-   if (action)
-   *action = a;
-
-   return true;
-}
-
 static const char *_action_public_str[] = {
"ACT_PUB_BSSCOEXIST",
"ACT_PUB_DSE_ENABLE",
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index 375a7a4..8a3176f 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1152,8 +1152,6 @@ void rtw_macaddr_cfg(u8 *mac_addr);
 u16 rtw_mcs_rate(u8 rf_type, u8 bw_40MHz, u8 short_GI_20, u8 short_GI_40,
 unsigned char *MCS_rate);
 
-int rtw_action_frame_parse(const u8 *frame, u32 frame_len, u8 *category,
-  u8 *action);
 const char *action_public_str(u8 action);
 
 #endif /* IEEE80211_H */
-- 
2.7.3



[PATCH 09/41] staging: r8188eu: remove rtw_set_ie_ch_switch function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 11 ---
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 13 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 25226b2..a54dafa 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -155,17 +155,6 @@ u8 *rtw_set_ie
return pbuf + len + 2;
 }
 
-inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
-   u8 new_ch, u8 ch_switch_cnt)
-{
-   u8 ie_data[3];
-
-   ie_data[0] = ch_switch_mode;
-   ie_data[1] = new_ch;
-   ie_data[2] = ch_switch_cnt;
-   return rtw_set_ie(buf, WLAN_EID_CHANNEL_SWITCH,  3, ie_data, buf_len);
-}
-
 /*
 index: the information element id index, limit is the limit for search
 -*/
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index cd0f9b3..4a8504d 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1096,8 +1096,6 @@ enum secondary_ch_offset {
SCA = 1, /* secondary channel above */
SCB = 3,  /* secondary channel below */
 };
-u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
-u8 new_ch, u8 ch_switch_cnt);
 
 u8 *rtw_get_ie(u8 *pbuf, int index, int *len, int limit);
 
-- 
2.7.3



[PATCH 37/41] staging: r8188eu: remove odm_sta_info structure

2016-08-24 Thread Ivan Safonov
odm_sta_info structure does not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/odm.h | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/odm.h 
b/drivers/staging/rtl8188eu/include/odm.h
index dbebf17..21fb4225 100644
--- a/drivers/staging/rtl8188eu/include/odm.h
+++ b/drivers/staging/rtl8188eu/include/odm.h
@@ -315,22 +315,6 @@ enum odm_ability {
ODM_PSD2AFH = 0x0800
 };
 
-/*  2011/20/20 MH For MP driver RT_WLAN_STA =  struct sta_info */
-/*  Please declare below ODM relative info in your STA info structure. */
-
-struct odm_sta_info {
-   /*  Driver Write */
-   boolbUsed;  /*  record the sta status link or not? */
-   u8  IOTPeer;/*  Enum value. HT_IOT_PEER_E */
-
-   /*  ODM Write */
-   /* 1 PHY_STATUS_INFO */
-   u8  RSSI_Path[4];   /*  */
-   u8  RSSI_Ave;
-   u8  RXEVM[4];
-   u8  RXSNR[4];
-};
-
 /*  2011/10/20 MH Define Common info enum for all team. */
 
 enum odm_common_info_def {
-- 
2.7.3



[PATCH 29/41] staging:r8188eu: remove unnecessary include from include/rtw_ht.h

2016-08-24 Thread Ivan Safonov
osdep_service.h does not required in include/rtw_ht.h.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtw_ht.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_ht.h 
b/drivers/staging/rtl8188eu/include/rtw_ht.h
index 0ee11ef..d842ead 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ht.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ht.h
@@ -16,7 +16,6 @@
 #define _RTW_HT_H_
 
 #include 
-#include 
 
 struct ht_priv {
u32 ht_option;
-- 
2.7.3



[PATCH 13/41] staging: r8188eu: remove action_public_str function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.
Also _action_public_str array removed.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 26 --
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 28 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index fac1241..0c616bc 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -1154,29 +1154,3 @@ u16 rtw_mcs_rate(u8 rf_type, u8 bw_40MHz, u8 
short_GI_20, u8 short_GI_40, unsign
}
return max_rate;
 }
-
-static const char *_action_public_str[] = {
-   "ACT_PUB_BSSCOEXIST",
-   "ACT_PUB_DSE_ENABLE",
-   "ACT_PUB_DSE_DEENABLE",
-   "ACT_PUB_DSE_REG_LOCATION",
-   "ACT_PUB_EXT_CHL_SWITCH",
-   "ACT_PUB_DSE_MSR_REQ",
-   "ACT_PUB_DSE_MSR_RPRT",
-   "ACT_PUB_MP",
-   "ACT_PUB_DSE_PWR_CONSTRAINT",
-   "ACT_PUB_VENDOR",
-   "ACT_PUB_GAS_INITIAL_REQ",
-   "ACT_PUB_GAS_INITIAL_RSP",
-   "ACT_PUB_GAS_COMEBACK_REQ",
-   "ACT_PUB_GAS_COMEBACK_RSP",
-   "ACT_PUB_TDLS_DISCOVERY_RSP",
-   "ACT_PUB_LOCATION_TRACK",
-   "ACT_PUB_RSVD",
-};
-
-const char *action_public_str(u8 action)
-{
-   action = min_t(u8, action, ACT_PUBLIC_MAX);
-   return _action_public_str[action];
-}
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index 8a3176f..ddb9db4 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1152,6 +1152,4 @@ void rtw_macaddr_cfg(u8 *mac_addr);
 u16 rtw_mcs_rate(u8 rf_type, u8 bw_40MHz, u8 short_GI_20, u8 short_GI_40,
 unsigned char *MCS_rate);
 
-const char *action_public_str(u8 action);
-
 #endif /* IEEE80211_H */
-- 
2.7.3



[PATCH] serial: 8250_dw: Check the data->pclk when get apb_pclk

2016-08-24 Thread Kefeng Wang
It should check the data->pclk, not data->clk when get apb_pclk.

Fixes: c8ed99d4f6a8("serial: 8250_dw: Add support for deferred probing")
Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index e199696..b022f5a 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -462,7 +462,7 @@ static int dw8250_probe(struct platform_device *pdev)
}
 
data->pclk = devm_clk_get(&pdev->dev, "apb_pclk");
-   if (IS_ERR(data->clk) && PTR_ERR(data->clk) == -EPROBE_DEFER) {
+   if (IS_ERR(data->pclk) && PTR_ERR(data->pclk) == -EPROBE_DEFER) {
err = -EPROBE_DEFER;
goto err_clk;
}
-- 
2.6.0.GIT



Re: [REGRESSION] Select hang with zero sized UDP packets

2016-08-24 Thread Dan Akunis
When select wakes up on a UDP socket, user is expecting to get data. Getting 
0 from recvfrom() or whatever read function she uses, is a wrong attitude.

I agree with David.

The unit test that expects select to wake up is wrong and should be changed.

-Original Message- 
From: David Miller

Sent: Tuesday, August 23, 2016 9:25 PM
To: labb...@redhat.com
Cc: kuz...@ms2.inr.ac.ru ; jmor...@namei.org ; yoshf...@linux-ipv6.org ; 
ka...@trash.net ; samanthaku...@google.com ; will...@google.com ; 
net...@vger.kernel.org ; linux-kernel@vger.kernel.org

Subject: Re: [REGRESSION] Select hang with zero sized UDP packets

From: Laura Abbott 
Date: Tue, 23 Aug 2016 10:53:26 -0700


Fedora received a report[1] of a unit test failing on Ruby when using
the
4.7 kernel. This was a test to send a zero sized UDP packet. With the
4.7 kernel, the test now timing out on a select instead of completing.
The reduced ruby test is

  def test_udp_recvfrom_nonblock
u1 = UDPSocket.new
u2 = UDPSocket.new
u1.bind("127.0.0.1", 0)
u2.send("", 0, u1.getsockname)
IO.select [u1]  # test gets stuck here
  ensure
u1.close if u1
u2.close if u2
  end


Well, if there is no data, should select really wake up?

I think it's valid not to. 



Re: [PATCH v3 3/3] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 soc

2016-08-24 Thread Kefeng Wang


On 2016/8/22 22:05, Heikki Krogerus wrote:
> Hi,
> 
> On Mon, Aug 22, 2016 at 02:24:14PM +0300, Andy Shevchenko wrote:
>> On Fri, 2016-07-15 at 19:01 +0800, Kefeng Wang wrote:
>>> Use built-in device properties to set device parameters for the
>>> existing device probed by acpi.
>>
>> acpi -> ACPI
>>
>>>
>>> Add ACPI identifier for UART on Hisilicon Hip05 soc, be careful
>>
>> soc -> SoC
>>
>>> that it is not 16550 compatibal, so we need set "reg-io-width"
>>
>> compatibal -> compatible

Will fix.

>>
>>> and "reg-shift" by _DSD method in DSDT.
>>>
>>> Signed-off-by: Kefeng Wang 
>>> ---
>>>  drivers/tty/serial/8250/8250_dw.c | 23 +--
>>>  1 file changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/8250/8250_dw.c
>>> b/drivers/tty/serial/8250/8250_dw.c
>>> index d6934310..5ab9cfe 100644
>>> --- a/drivers/tty/serial/8250/8250_dw.c
>>> +++ b/drivers/tty/serial/8250/8250_dw.c
>>> @@ -297,12 +297,6 @@ static void dw8250_quirks(struct uart_port *p,
>>> struct dw8250_data *data)
>>> p->serial_in = dw8250_serial_in32be;
>>> p->serial_out = dw8250_serial_out32be;
>>> }
>>> -   } else if (has_acpi_companion(p->dev)) {
>>> -   p->iotype = UPIO_MEM32;
>>> -   p->regshift = 2;
>>> -   p->serial_in = dw8250_serial_in32;
>>> -   /* So far none of there implement the Busy
>>> Functionality */
>>> -   data->uart_16550_compatible = true;
>>> }
>>>  
>>> /* Platforms with iDMA */
>>> @@ -352,6 +346,19 @@ static void dw8250_setup_port(struct uart_port
>>> *p)
>>> up->capabilities |= UART_CAP_AFE;
>>>  }
>>>  
>>> +static struct property_entry dw8250_properties[] = {
>>> +   PROPERTY_ENTRY_U32("reg-io-width", 4),
>>> +   PROPERTY_ENTRY_U32("reg-shift", 2),
>>> +   PROPERTY_ENTRY_BOOL("snps,uart-16550-compatible"),
>>> +   { },
>>> +};
>>> +
>>> +/* non 16550 compatible id list*/
>>
>> non 16550 -> Non-16550
>> Space before */
>>
>>> +static const struct acpi_device_id non_16550_ids[] = {
>>> +   { "HISI0031", 0 },
>>> +   { },
>>> +};
>>> +
>>>  static int dw8250_probe(struct platform_device *pdev)
>>>  {
>>> struct uart_8250_port uart = {};
>>> @@ -395,6 +402,9 @@ static int dw8250_probe(struct platform_device
>>> *pdev)
>>> if (!data)
>>> return -ENOMEM;
>>>  
>>> +   if (has_acpi_companion(dev) &&
>>> !acpi_match_device(non_16550_ids, dev))
>>
>>
>>> +   platform_device_add_properties(pdev,
>>> dw8250_properties);
>>
>> What if we probe device which has already properties assigned?
>>
>> Heikki, are you good with such trick?
> 
> No this is not the way to do this. As we talked, we need to add the
> properties in the mfd drivers when they exist and not in the driver
> itself. Only if there is no mfd driver that creates the actual
> platform device for dw8250 and when also the ACPI tables don't provide
> the properties, we identify the board in dw8250_quirks and handle it
> separately. Right now there is only one such board.
> 
> I'll prepare the patches for that right now. This series can then be
> made on top of those.
> 

OK, will base on your patchset.

Thanks Andy and Heikki for your comments.

Kefeng


> 
> Thanks,
> 



[PATCH 21/41] staging: r8188eu: remove rtw_ieee80211_ht_cap structure

2016-08-24 Thread Ivan Safonov
rtw_ieee80211_ht_cap does not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/wifi.h | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index e7c5121..e049eed 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -508,22 +508,6 @@ struct rtw_ieee80211_bar {
 #define IEEE80211_BAR_CTRL_ACK_POLICY_NORMAL 0x
 #define IEEE80211_BAR_CTRL_CBMTID_COMPRESSED_BA  0x0004
 
- /**
- * struct rtw_ieee80211_ht_cap - HT capabilities
- *
- * This structure refers to "HT capabilities element" as
- * described in 802.11n draft section 7.3.2.52
- */
-
-struct rtw_ieee80211_ht_cap {
-   unsigned short  cap_info;
-   unsigned char   ampdu_params_info;
-   unsigned char   supp_mcs_set[16];
-   unsigned short  extended_ht_cap_info;
-   unsigned inttx_BF_cap_info;
-   unsigned char   antenna_selection_info;
-} __packed;
-
 /**
  * struct rtw_ieee80211_ht_cap - HT additional information
  *
-- 
2.7.3



[PATCH 17/41] staging: r8188eu: replace sizeof(struct rtw_ieee80211_ht_cap) with sizeof(struct ieee80211_ht_cap)

2016-08-24 Thread Ivan Safonov
Values of this expressions are equal, but ieee80211_ht_cap is library type.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c  | 5 +++--
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c  | 8 +---
 drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6 --
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 1456499..a4e3bde 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1958,7 +1958,7 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
 
out_len = *pout_len;
 
-   memset(&ht_capie, 0, sizeof(struct rtw_ieee80211_ht_cap));
+   memset(&ht_capie, 0, sizeof(struct ieee80211_ht_cap));
 
ht_capie.cap_info = IEEE80211_HT_CAP_SUP_WIDTH |
IEEE80211_HT_CAP_SGI_20 |
@@ -1984,7 +1984,8 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
 
 
rtw_set_ie(out_ie+out_len, _HT_CAPABILITY_IE_,
-  sizeof(struct rtw_ieee80211_ht_cap), (unsigned char 
*)&ht_capie, pout_len);
+  sizeof(struct ieee80211_ht_cap),
+  (unsigned char *)&ht_capie, pout_len);
 
phtpriv->ht_option = true;
 
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 40e0b60..91e7b36 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -3236,13 +3236,15 @@ static unsigned int OnAssocReq(struct adapter *padapter,
}
 
/* save HT capabilities in the sta object */
-   memset(&pstat->htpriv.ht_cap, 0, sizeof(struct rtw_ieee80211_ht_cap));
-   if (elems.ht_capabilities && elems.ht_capabilities_len >= sizeof(struct 
rtw_ieee80211_ht_cap)) {
+   memset(&pstat->htpriv.ht_cap, 0, sizeof(struct ieee80211_ht_cap));
+   if (elems.ht_capabilities &&
+   elems.ht_capabilities_len >= sizeof(struct ieee80211_ht_cap)) {
pstat->flags |= WLAN_STA_HT;
 
pstat->flags |= WLAN_STA_WME;
 
-   memcpy(&pstat->htpriv.ht_cap, elems.ht_capabilities, 
sizeof(struct rtw_ieee80211_ht_cap));
+   memcpy(&pstat->htpriv.ht_cap,
+  elems.ht_capabilities, sizeof(struct ieee80211_ht_cap));
} else {
pstat->flags &= ~WLAN_STA_HT;
}
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index a2b3552..44d3ed6 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2531,7 +2531,8 @@ static int rtw_add_sta(struct net_device *dev, struct 
ieee_param *param)
if (WLAN_STA_HT&flags) {
psta->htpriv.ht_option = true;
psta->qos_option = 1;
-   memcpy((void *)&psta->htpriv.ht_cap, (void 
*)¶m->u.add_sta.ht_cap, sizeof(struct rtw_ieee80211_ht_cap));
+   memcpy(&psta->htpriv.ht_cap, ¶m->u.add_sta.ht_cap,
+  sizeof(struct ieee80211_ht_cap));
} else {
psta->htpriv.ht_option = false;
}
@@ -2627,7 +2628,8 @@ static int rtw_ioctl_get_sta_data(struct net_device *dev, 
struct ieee_param *par
  (psta->ht_20mhz_set << 5));
psta_data->tx_supp_rates_len =  psta->bssratelen;
memcpy(psta_data->tx_supp_rates, psta->bssrateset, 
psta->bssratelen);
-   memcpy(&psta_data->ht_cap, &psta->htpriv.ht_cap, sizeof(struct 
rtw_ieee80211_ht_cap));
+   memcpy(&psta_data->ht_cap,
+  &psta->htpriv.ht_cap, sizeof(struct ieee80211_ht_cap));
psta_data->rx_pkts = psta->sta_stats.rx_data_pkts;
psta_data->rx_bytes = psta->sta_stats.rx_bytes;
psta_data->rx_drops = psta->sta_stats.rx_drops;
-- 
2.7.3



Re: [PATCH RFC RESEND] Perf: lookup dwarf unwind stack info in debug file pointed by .gnu_debuglink

2016-08-24 Thread Matija Glavinic Pecotic
On 24/08/16 09:30, Jiri Olsa wrote:
> On Tue, Aug 23, 2016 at 06:18:10PM +0200, Matija Glavinic Pecotic wrote:
>> -ret = filename__read_debuglink(filename, debuglink,
>> -   size - (debuglink - filename));
>> +ret = filename__read_debuglink(filename, symfile, PATH_MAX);
>> +if (ret)
>> +break;
>> +
>> +/* Check predefined locations where debug file might reside:
>> + *  - if debuglink is absolute path, check only that one
>> + * If debuglink provides name w/o path, look for debug file:
>> + *  - in the same directory as dso
>> + *  - in the .debug subdirectory of dso directory
>> + *  - in the /usr/lib/debug/[dso directory]
>> + *  */
>> +ret = 0;
>> +if (symfile[0] == '/') {
>> +if (!is_regular_file(symfile))
>> +ret = -1;
>> +else
>> +strncpy(filename, symfile, size);
>> +break;
>>  }
>> +
>> +snprintf(filename, size, "%s/%s", dso_dir, symfile);
>> +if(is_regular_file(filename))
>> +break;
>> +
>> +snprintf(filename, size, "%s/.debug/%s", dso_dir, symfile);
>> +if(is_regular_file(filename))
>> +break;
>> +
>> +snprintf(filename, size, "/usr/lib/debug/%s/%s",
>> +dso_dir, symfile);
>> +if(is_regular_file(filename))
>> +break;
> 
> it might be more clear to follow the same way we do for vmlinux search,
> like array of possible paths and generic code to check.. search for
> vmlinux_path in symbol.c

It indeed looks better:

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 774f6ec..3ea205cc 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -35,6 +35,13 @@ char dso__symtab_origin(const struct dso *dso)
return origin[dso->symtab_type];
 }
 
+static const char * const debuglink_paths[] = {
+   "%.0s%s",
+   "%s/%s",
+   "%s/.debug/%s",
+   "/usr/lib/debug%s/%s"
+};
+
 int dso__read_binary_type_filename(const struct dso *dso,
   enum dso_binary_type type,
   char *root_dir, char *filename, size_t size)
@@ -44,24 +51,44 @@ int dso__read_binary_type_filename(const struct dso *dso,
size_t len;
 
switch (type) {
-   case DSO_BINARY_TYPE__DEBUGLINK: {
-   char *debuglink;
+   case DSO_BINARY_TYPE__DEBUGLINK:
+   {
+   const char *last_slash;
+   char dso_dir[PATH_MAX];
+   char symfile[PATH_MAX];
+   unsigned int i;
 
len = __symbol__join_symfs(filename, size, dso->long_name);
-   debuglink = filename + len;
-   while (debuglink != filename && *debuglink != '/')
-   debuglink--;
-   if (*debuglink == '/')
-   debuglink++;
+   last_slash = filename + len;
+   while (last_slash != filename && *last_slash != '/')
+   last_slash--;
 
-   ret = -1;
-   if (!is_regular_file(filename))
+   strncpy(dso_dir, filename, last_slash - filename);
+   dso_dir[last_slash-filename] = '\0';
+
+   if (!is_regular_file(filename)) {
+   ret = -1;
+   break;
+   }
+
+   ret = filename__read_debuglink(filename, symfile, PATH_MAX);
+   if (ret)
break;
 
-   ret = filename__read_debuglink(filename, debuglink,
-  size - (debuglink - filename));
+   /* Check predefined locations where debug file might reside */
+   ret = -1;
+   for (i = 0; i < ARRAY_SIZE(debuglink_paths); i++) {
+   snprintf(filename, size,
+   debuglink_paths[i], dso_dir, symfile);
+   if(is_regular_file(filename)) {
+   ret = 0;
+   break;
+   }
}
+
break;
+   }

Thanks,

Matija


[PATCH 23/41] staging: r8188eu: simplify HT_caps_element structure

2016-08-24 Thread Ivan Safonov
Now HT_caps_element structure is similar to ieee80211_ht_caps.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c|  6 +++---
 drivers/staging/rtl8188eu/core/rtw_ioctl_set.c |  6 +++---
 drivers/staging/rtl8188eu/core/rtw_mlme.c  |  8 
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c  | 18 +-
 drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 24 
 drivers/staging/rtl8188eu/include/wifi.h   | 16 ++--
 6 files changed, 37 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index a148e7d..be4d624 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -709,9 +709,9 @@ static void update_hw_ht_param(struct adapter *padapter)
AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k
AMPDU_para [4:2]:Min MPDU Start Spacing
*/
-   max_AMPDU_len = pmlmeinfo->HT_caps.u.HT_cap_element.AMPDU_para & 0x03;
+   max_AMPDU_len = pmlmeinfo->HT_caps.AMPDU_para & 0x03;
 
-   min_MPDU_spacing = (pmlmeinfo->HT_caps.u.HT_cap_element.AMPDU_para & 
0x1c) >> 2;
+   min_MPDU_spacing = (pmlmeinfo->HT_caps.AMPDU_para & 0x1c) >> 2;
 
rtw_hal_set_hwreg(padapter, HW_VAR_AMPDU_MIN_SPACE, (u8 
*)(&min_MPDU_spacing));
 
@@ -720,7 +720,7 @@ static void update_hw_ht_param(struct adapter *padapter)
/*  */
/*  Config SM Power Save setting */
/*  */
-   pmlmeinfo->SM_PS = 
(le16_to_cpu(pmlmeinfo->HT_caps.u.HT_cap_element.HT_caps_info) & 0x0C) >> 2;
+   pmlmeinfo->SM_PS = (le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & 
0x0C) >> 2;
if (pmlmeinfo->SM_PS == WLAN_HT_CAP_SM_PS_STATIC)
DBG_88E("%s(): WLAN_HT_CAP_SM_PS_STATIC\n", __func__);
 }
diff --git a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c 
b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
index 62b2f71..a830752 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
@@ -588,8 +588,8 @@ u16 rtw_get_cur_max_rate(struct adapter *adapter)
/* cur_bwmod is updated by beacon, pmlmeinfo is updated 
by association response */
bw_40MHz = (pmlmeext->cur_bwmode && 
(HT_INFO_HT_PARAM_REC_TRANS_CHNL_WIDTH & pmlmeinfo->HT_info.infos[0])) ? 1 : 0;
 
-   short_GI_20 = 
(le16_to_cpu(pmlmeinfo->HT_caps.u.HT_cap_element.HT_caps_info) & 
IEEE80211_HT_CAP_SGI_20) ? 1 : 0;
-   short_GI_40 = 
(le16_to_cpu(pmlmeinfo->HT_caps.u.HT_cap_element.HT_caps_info) & 
IEEE80211_HT_CAP_SGI_40) ? 1 : 0;
+   short_GI_20 = 
(le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & IEEE80211_HT_CAP_SGI_20) ? 1 : 
0;
+   short_GI_40 = 
(le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & IEEE80211_HT_CAP_SGI_40) ? 1 : 
0;
 
rtw_hal_get_hwreg(adapter, HW_VAR_RF_TYPE, (u8 
*)(&rf_type));
max_rate = rtw_mcs_rate(
@@ -597,7 +597,7 @@ u16 rtw_get_cur_max_rate(struct adapter *adapter)
bw_40MHz & (pregistrypriv->cbw40_enable),
short_GI_20,
short_GI_40,
-   pmlmeinfo->HT_caps.u.HT_cap_element.MCS_rate
+   pmlmeinfo->HT_caps.MCS_rate
);
}
} else {
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 4979c61..03baaa1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -2044,7 +2044,7 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 *pie, 
uint ie_len)
 
/* update cur_bwmode & cur_ch_offset */
if ((pregistrypriv->cbw40_enable) &&
-   (le16_to_cpu(pmlmeinfo->HT_caps.u.HT_cap_element.HT_caps_info) & 
BIT(1)) &&
+   (le16_to_cpu(pmlmeinfo->HT_caps.HT_caps_info) & BIT(1)) &&
(pmlmeinfo->HT_info.infos[0] & BIT(2))) {
int i;
u8  rf_type;
@@ -2054,9 +2054,9 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 *pie, 
uint ie_len)
/* update the MCS rates */
for (i = 0; i < 16; i++) {
if ((rf_type == RF_1T1R) || (rf_type == RF_1T2R))
-   pmlmeinfo->HT_caps.u.HT_cap_element.MCS_rate[i] 
&= MCS_rate_1R[i];
+   pmlmeinfo->HT_caps.MCS_rate[i] &= 
MCS_rate_1R[i];
else
-   pmlmeinfo->HT_caps.u.HT_cap_element.MCS_rate[i] 
&= MCS_rate_2R[i];
+   pmlmeinfo->HT_caps.MCS_rate[i] &= 
MCS_rate_2R[i];
}
/* switch to the 40M Hz mode according to the AP */
pmlmeext->cur_bwmode = HT_CHANNEL_WIDT

[PATCH 26/41] staging: r8188eu: remove unused members of ht_priv structure

2016-08-24 Thread Ivan Safonov
tx_amsdu_enable and tx_amdsu_maxlen are not used in driver code.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtw_ht.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_ht.h 
b/drivers/staging/rtl8188eu/include/rtw_ht.h
index 7beb0b1..2b03b11 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ht.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ht.h
@@ -21,8 +21,6 @@
 struct ht_priv {
u32 ht_option;
u32 ampdu_enable;/* for enable Tx A-MPDU */
-   u32 tx_amsdu_enable;/* for enable Tx A-MSDU */
-   u32 tx_amdsu_maxlen; /*  1: 8k, 0:4k ; default:8k, for tx */
u32 rx_ampdu_maxlen; /* for rx reordering ctrl win_sz,
  * updated when join_callback. */
u8  bwmode;/*  */
-- 
2.7.3



[PATCH 18/41] staging: r8188eu: remove dead code from rtw_get_cur_max_rate function

2016-08-24 Thread Ivan Safonov
Values assugned to pht_capie and mcs_rate variables,
but variables does not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ioctl_set.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c 
b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
index f85a6ab..62b2f71 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
@@ -14,7 +14,6 @@
  
**/
 #define _RTW_IOCTL_SET_C_
 
-
 #include 
 #include 
 #include 
@@ -570,10 +569,8 @@ u16 rtw_get_cur_max_rate(struct adapter *adapter)
struct registry_priv *pregistrypriv = &adapter->registrypriv;
struct mlme_priv*pmlmepriv = &adapter->mlmepriv;
struct wlan_bssid_ex  *pcur_bss = &pmlmepriv->cur_network.network;
-   struct rtw_ieee80211_ht_cap *pht_capie;
u8  rf_type = 0;
u8  bw_40MHz = 0, short_GI_20 = 0, short_GI_40 = 0;
-   u16 mcs_rate = 0;
u32 ht_ielen = 0;
 
if (adapter->registrypriv.mp_mode == 1) {
@@ -588,10 +585,6 @@ u16 rtw_get_cur_max_rate(struct adapter *adapter)
if (pmlmeext->cur_wireless_mode & (WIRELESS_11_24N|WIRELESS_11_5N)) {
p = rtw_get_ie(&pcur_bss->IEs[12], _HT_CAPABILITY_IE_, 
&ht_ielen, pcur_bss->IELength-12);
if (p && ht_ielen > 0) {
-   pht_capie = (struct rtw_ieee80211_ht_cap *)(p+2);
-
-   memcpy(&mcs_rate, pht_capie->supp_mcs_set, 2);
-
/* cur_bwmod is updated by beacon, pmlmeinfo is updated 
by association response */
bw_40MHz = (pmlmeext->cur_bwmode && 
(HT_INFO_HT_PARAM_REC_TRANS_CHNL_WIDTH & pmlmeinfo->HT_info.infos[0])) ? 1 : 0;
 
-- 
2.7.3



[PATCH 01/41] staging: r8188eu: remove rtw_ies_remove_ie function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 47 --
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 49 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 0b0d78f..b8ba90a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -280,53 +280,6 @@ u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len, u8 eid, u8 *oui, 
u8 oui_len, u8 *ie, u
return target_ie;
 }
 
-/**
- * rtw_ies_remove_ie - Find matching IEs and remove
- * @ies: Address of IEs to search
- * @ies_len: Pointer of length of ies, will update to new length
- * @offset: The offset to start scarch
- * @eid: Element ID to match
- * @oui: OUI to match
- * @oui_len: OUI length
- *
- * Returns: _SUCCESS: ies is updated, _FAIL: not updated
- */
-int rtw_ies_remove_ie(u8 *ies, uint *ies_len, uint offset, u8 eid, u8 *oui, u8 
oui_len)
-{
-   int ret = _FAIL;
-   u8 *target_ie;
-   u32 target_ielen;
-   u8 *start;
-   uint search_len;
-
-   if (!ies || !ies_len || *ies_len <= offset)
-   goto exit;
-
-   start = ies + offset;
-   search_len = *ies_len - offset;
-
-   while (1) {
-   target_ie = rtw_get_ie_ex(start, search_len, eid, oui, oui_len, 
NULL, &target_ielen);
-   if (target_ie && target_ielen) {
-   u8 buf[MAX_IE_SZ] = {0};
-   u8 *remain_ies = target_ie + target_ielen;
-   uint remain_len = search_len - (remain_ies - start);
-
-   memcpy(buf, remain_ies, remain_len);
-   memcpy(target_ie, buf, remain_len);
-   *ies_len = *ies_len - target_ielen;
-   ret = _SUCCESS;
-
-   start = target_ie;
-   search_len = remain_len;
-   } else {
-   break;
-   }
-   }
-exit:
-   return ret;
-}
-
 void rtw_set_supported_rate(u8 *SupportedRates, uint mode)
 {
 
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index d8284c8..a62077b 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1108,8 +1108,6 @@ u8 *rtw_set_ie_mesh_ch_switch_parm(u8 *buf, u32 *buf_len, 
u8 ttl,
 u8 *rtw_get_ie(u8 *pbuf, int index, int *len, int limit);
 u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len, u8 eid, u8 *oui,
  u8 oui_len, u8 *ie, uint *ielen);
-int rtw_ies_remove_ie(u8 *ies, uint *ies_len, uint offset,
- u8 eid, u8 *oui, u8 oui_len);
 
 void rtw_set_supported_rate(u8 *SupportedRates, uint mode);
 
-- 
2.7.3



[PATCH 08/41] staging: r8188eu: remove rtw_set_ie_mesh_ch_switch_parm function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 13 -
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 15 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 13080d1..25226b2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -166,19 +166,6 @@ inline u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 
ch_switch_mode,
return rtw_set_ie(buf, WLAN_EID_CHANNEL_SWITCH,  3, ie_data, buf_len);
 }
 
-inline u8 *rtw_set_ie_mesh_ch_switch_parm(u8 *buf, u32 *buf_len, u8 ttl,
-   u8 flags, u16 reason, u16 precedence)
-{
-   u8 ie_data[6];
-
-   ie_data[0] = ttl;
-   ie_data[1] = flags;
-   *(u16 *)(ie_data + 2) = cpu_to_le16(reason);
-   *(u16 *)(ie_data + 4) = cpu_to_le16(precedence);
-
-   return rtw_set_ie(buf, 0x118,  6, ie_data, buf_len);
-}
-
 /*
 index: the information element id index, limit is the limit for search
 -*/
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index d957caa..cd0f9b3 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1098,8 +1098,6 @@ enum secondary_ch_offset {
 };
 u8 *rtw_set_ie_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
 u8 new_ch, u8 ch_switch_cnt);
-u8 *rtw_set_ie_mesh_ch_switch_parm(u8 *buf, u32 *buf_len, u8 ttl,
-  u8 flags, u16 reason, u16 precedence);
 
 u8 *rtw_get_ie(u8 *pbuf, int index, int *len, int limit);
 
-- 
2.7.3



Re: [PATCH][RFC] printk: make pr_cont buffer per-cpu

2016-08-24 Thread Petr Mladek
On Wed 2016-08-24 10:14:20, Sergey Senozhatsky wrote:
> Hello,
> 
> On (08/23/16 13:47), Petr Mladek wrote:
> [..]
> > >   if (!(lflags & LOG_NEWLINE)) {
> > > + if (!this_cpu_read(cont_printing)) {
> > > + if (system_state == SYSTEM_RUNNING) {
> > > + this_cpu_write(cont_printing, true);
> > > + preempt_disable();
> > > + }
> > > + }
> > 
> > I am afraid that this is not acceptable. It means that printk() will have
> > an unexpected side effect. The missing "\n" at the end of a printed
> > string would disable preemption. See below for more.
> 
> missing '\n' must WARN about "sched while atomic" eventually, so it
> shouldn't go unnoticed or stay hidden.

Well, it will still force people to rebuilt a test kernel because they
forget to use '\n" and the test kernel is unusable.

IMHO, the connection between '\n' and preemption is not
intuitive and hard to spot. We should do our best to avoid it.


> > I think that cont lines should be a corner case. There should be only
> > a limited use of them. We should not make too complicated things to
> > support them. Also printk() must not get harder to use because of them.
> > I still see a messed output rather as a cosmetic problem in compare with
> > possible possible deadlocks or hung tasks.
> 
> oh, I would love it if pr_cont() was never used in SMP. but this is not
> the case, unfortunately. and, ironically, where pr_cont really matters
> is debugging -- for instance, look at arch/x86/kernel/dumpstack_{32,64}.c
> show_regs() or show_stack_log_lvl()

Sure but how big is the problem in the daily life? I have never heard
colleagues complaining about messed cont lines. It is rare and it
is always possible to restore it. Checking BUG/WARN messages is
a rather hard detective work anyway.

The most painful situation would be if backtraces from different
CPUs are mixed. But there will be problem even with mixed lines.
Fortunately, this usually happens when printing backtraces from
all CPUs in NMI and the output is serialized.


> well, I do understand what you mean and agree with it, but I'm
> afraid pr_cont() kinda matters after all and people *probably*
> expect it to be SMP safe (I'm not entirely sure whether all of
> those pr_cont() calls were put there with the idea that the
> output can be messed up and quite hard to read).

This was even worse before the cont lines buffer.

Sigh, I do not feel experienced enough to decide about this.
I wonder if this is rather theoretical problem or if there
are many real complains about it.

I feel that we might be trapped by a perfectionism. Perfect output
would be great. But it must not make printk() hard to use
in the daily life.

Best Regards,
Petr


[PATCH 41/41] staging: r8188eu: remove some structures definitions from rtw_ioctl.h

2016-08-24 Thread Ivan Safonov
oid_funs_node and oid_obj_priv structures are not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtw_ioctl.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_ioctl.h 
b/drivers/staging/rtl8188eu/include/rtw_ioctl.h
index 3a652df..a6b1c85 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ioctl.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ioctl.h
@@ -69,15 +69,6 @@ enum oid_type {
SET_OID
 };
 
-struct oid_funs_node {
-   unsigned int oid_start; /* the starting number for OID */
-   unsigned int oid_end; /* the ending number for OID */
-   struct oid_obj_priv *node_array;
-   unsigned int array_sz; /* the size of node_array */
-   int query_counter; /* count the number of query hits for this segment */
-   int set_counter; /* count the number of set hits for this segment */
-};
-
 struct oid_par_priv {
void*adapter_context;
NDIS_OIDoid;
@@ -89,12 +80,6 @@ struct oid_par_priv {
u32 dbg;
 };
 
-struct oid_obj_priv {
-   unsigned char   dbg; /*  0: without OID debug message
- *  1: with OID debug message */
-   int (*oidfuns)(struct oid_par_priv *poid_par_priv);
-};
-
 #if defined(_RTW_MP_IOCTL_C_)
 static int oid_null_function(struct oid_par_priv *poid_par_priv) {
return NDIS_STATUS_SUCCESS;
-- 
2.7.3



[PATCH 31/41] staging: r8188eu: remove some structure definitions from Hal8188EPhyCfg.h

2016-08-24 Thread Ivan Safonov
ant_sel_ofdm and ant_sel_cck structures are not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/Hal8188EPhyCfg.h | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/Hal8188EPhyCfg.h 
b/drivers/staging/rtl8188eu/include/Hal8188EPhyCfg.h
index 8990748..0976a76 100644
--- a/drivers/staging/rtl8188eu/include/Hal8188EPhyCfg.h
+++ b/drivers/staging/rtl8188eu/include/Hal8188EPhyCfg.h
@@ -158,24 +158,6 @@ struct bb_reg_def {
 * Path A and B */
 };
 
-struct ant_sel_ofdm {
-   u32 r_tx_antenna:4;
-   u32 r_ant_l:4;
-   u32 r_ant_non_ht:4;
-   u32 r_ant_ht1:4;
-   u32 r_ant_ht2:4;
-   u32 r_ant_ht_s1:4;
-   u32 r_ant_non_ht_s1:4;
-   u32 OFDM_TXSC:2;
-   u32 reserved:2;
-};
-
-struct ant_sel_cck {
-   u8 r_cckrx_enable_2:2;
-   u8 r_cckrx_enable:2;
-   u8 r_ccktx_enable:4;
-};
-
 /*--Define structure*/
 
 
-- 
2.7.3



[PATCH 11/41] staging: r8188eu: remove dump_wps_ie function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 21 -
 drivers/staging/rtl8188eu/include/ieee80211.h  |  2 --
 2 files changed, 23 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 1df25ff..f3e9f7e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -952,27 +952,6 @@ void rtw_macaddr_cfg(u8 *mac_addr)
DBG_88E("rtw_macaddr_cfg MAC Address  = %pM\n", (mac_addr));
 }
 
-void dump_wps_ie(u8 *ie, u32 ie_len)
-{
-   u8 *pos = ie;
-   u16 id;
-   u16 len;
-   u8 *wps_ie;
-   uint wps_ielen;
-
-   wps_ie = rtw_get_wps_ie(ie, ie_len, NULL, &wps_ielen);
-   if (wps_ie != ie || wps_ielen == 0)
-   return;
-
-   pos += 6;
-   while (pos - ie < ie_len) {
-   id = get_unaligned_be16(pos);
-   len = get_unaligned_be16(pos + 2);
-   DBG_88E("%s ID:0x%04x, LEN:%u\n", __func__, id, len);
-   pos += (4 + len);
-   }
-}
-
 /* Baron adds to avoid FreeBSD warning */
 int ieee80211_is_empty_essid(const char *essid, int essid_len)
 {
diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index 79ae555..375a7a4 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1131,8 +1131,6 @@ u8 *rtw_get_wps_attr_content(u8 *wps_ie, uint wps_ielen, 
u16 target_attr_id,
for (ie = (void *)buf; (((u8 *)ie) - ((u8 *)buf) + 1) < buf_len;
\
ie = (void *)(((u8 *)ie) + *(((u8 *)ie)+1) + 2))
 
-void dump_wps_ie(u8 *ie, u32 ie_len);
-
 uint   rtw_get_rateset_len(u8  *rateset);
 
 struct registry_priv;
-- 
2.7.3



[PATCH 14/41] staging: r8188eu: remove for_each_ie macro

2016-08-24 Thread Ivan Safonov
for_each_ie does not used in the driver code.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/ieee80211.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/ieee80211.h 
b/drivers/staging/rtl8188eu/include/ieee80211.h
index ddb9db4..e45ef14 100644
--- a/drivers/staging/rtl8188eu/include/ieee80211.h
+++ b/drivers/staging/rtl8188eu/include/ieee80211.h
@@ -1121,16 +1121,6 @@ u8 *rtw_get_wps_attr(u8 *wps_ie, uint wps_ielen, u16 
target_attr_id,
 u8 *rtw_get_wps_attr_content(u8 *wps_ie, uint wps_ielen, u16 target_attr_id,
 u8 *buf_content, uint *len_content);
 
-/**
- * for_each_ie - iterate over continuous IEs
- * @ie:
- * @buf:
- * @buf_len:
- */
-#define for_each_ie(ie, buf, buf_len) \
-   for (ie = (void *)buf; (((u8 *)ie) - ((u8 *)buf) + 1) < buf_len;
\
-   ie = (void *)(((u8 *)ie) + *(((u8 *)ie)+1) + 2))
-
 uint   rtw_get_rateset_len(u8  *rateset);
 
 struct registry_priv;
-- 
2.7.3



[PATCH 34/41] staging: r8188eu: remove agg_pkt_info structure

2016-08-24 Thread Ivan Safonov
This structure does not used.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/rtw_xmit.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_xmit.h 
b/drivers/staging/rtl8188eu/include/rtw_xmit.h
index 7895008..cb49aca 100644
--- a/drivers/staging/rtl8188eu/include/rtw_xmit.h
+++ b/drivers/staging/rtl8188eu/include/rtw_xmit.h
@@ -256,11 +256,6 @@ struct hw_txqueue {
int ac_tag;
 };
 
-struct agg_pkt_info {
-   u16 offset;
-   u16 pkt_len;
-};
-
 struct xmit_priv {
spinlock_t lock;
struct __queue be_pending;
-- 
2.7.3



Re: [PATCH 2/2] thermal: rcar-thermal: enable hwmon when thermal_zone

2016-08-24 Thread Kuninori Morimoto

Hi Zhang

> > > > > From: Kuninori Morimoto 
> > > > > 
> > > > > rcar-thermal is supporting both
> > > > > thermal_zone_of_sensor_register()
> > > > > and
> > > > > thermal_zone_device_register(). But
> > > > > thermal_zone_of_sensor_register()
> > > > > doesn't enable hwmon as default.
> > > > > This patch enables it to keep compatibility
> > > > > 
> > > > > Signed-off-by: Kuninori Morimoto  > > > > com>
> > > > Queued for 4.9
> > > > 
> > > the subject should be "thermal:rcar-theraml: enable hwmon when
> > > thermal_zone_of_sensor_register is used", right?
> > Yes exactly.
> > Should I resend v2 patch ?
> > 
> nop. I've already updated the patch subject.

Thank you for your help


[PATCH 03/41] staging: r8188eu: remove rtw_ap_inform_ch_switch function

2016-08-24 Thread Ivan Safonov
Driver does not use this function.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c| 34 --
 drivers/staging/rtl8188eu/include/rtw_ap.h |  1 -
 2 files changed, 35 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index a575535..bbb1aa7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -1710,40 +1710,6 @@ u8 ap_free_sta(struct adapter *padapter, struct sta_info 
*psta,
return beacon_updated;
 }
 
-int rtw_ap_inform_ch_switch(struct adapter *padapter, u8 new_ch, u8 ch_offset)
-{
-   struct list_head *phead, *plist;
-   struct sta_info *psta = NULL;
-   struct sta_priv *pstapriv = &padapter->stapriv;
-   struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
-   struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
-   u8 bc_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-
-   if ((pmlmeinfo->state&0x03) != WIFI_FW_AP_STATE)
-   return 0;
-
-   DBG_88E(FUNC_NDEV_FMT" with ch:%u, offset:%u\n",
-   FUNC_NDEV_ARG(padapter->pnetdev), new_ch, ch_offset);
-
-   spin_lock_bh(&pstapriv->asoc_list_lock);
-   phead = &pstapriv->asoc_list;
-   plist = phead->next;
-
-   /* for each sta in asoc_queue */
-   while (phead != plist) {
-   psta = container_of(plist, struct sta_info, asoc_list);
-   plist = plist->next;
-
-   issue_action_spct_ch_switch(padapter, psta->hwaddr, new_ch, 
ch_offset);
-   psta->expire_to = min_t(unsigned int, pstapriv->expire_to * 2, 
5);
-   }
-   spin_unlock_bh(&pstapriv->asoc_list_lock);
-
-   issue_action_spct_ch_switch(padapter, bc_addr, new_ch, ch_offset);
-
-   return 0;
-}
-
 int rtw_sta_flush(struct adapter *padapter)
 {
struct list_head *phead, *plist;
diff --git a/drivers/staging/rtl8188eu/include/rtw_ap.h 
b/drivers/staging/rtl8188eu/include/rtw_ap.h
index b820684..e8dd6d4 100644
--- a/drivers/staging/rtl8188eu/include/rtw_ap.h
+++ b/drivers/staging/rtl8188eu/include/rtw_ap.h
@@ -50,7 +50,6 @@ void ap_sta_info_defer_update(struct adapter *padapter, 
struct sta_info *psta);
 u8 ap_free_sta(struct adapter *padapter, struct sta_info *psta,
   bool active, u16 reason);
 int rtw_sta_flush(struct adapter *padapter);
-int rtw_ap_inform_ch_switch(struct adapter *padapter, u8 new_ch, u8 ch_offset);
 void start_ap_mode(struct adapter *padapter);
 void stop_ap_mode(struct adapter *padapter);
 #endif /* end of CONFIG_88EU_AP_MODE */
-- 
2.7.3



  1   2   3   4   5   6   7   8   9   >