Re: [PATCH 09/39] mtd: nand: denali: fix erased page check code

[Boris Brezillon]

On Fri, 2 Dec 2016 13:33:58 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 
> 2016-11-28 0:21 GMT+09:00 Boris Brezillon 
> :
> > On Sun, 27 Nov 2016 03:05:55 +0900
> > Masahiro Yamada  wrote:
> >  
> >> Currently, is_erased() is called against "buf" twice, so the second
> >> call is meaningless.  The second one should be checked against
> >> chip->oob_poi.
> >>  
> >
> > IMO, patch 9 to 12 should be squashed in a single patch. All you're
> > doing in these patch is fixing the check_erased_page logic.
> >
> > You can describe the different broken thing in the commit message, but
> > splitting things as you do does not help much.  
> 
> 
> OK. I will do so.
> 
> I realized some mistakes in this part
> (both in my patches and in the current mainline code),
> so I will rework it in a more sensible chunk.
> 
> 
> > Also, please have at nand_check_erased_ecc_chunk() [1] instead of using
> > a private method (is_erased()) to check if the page is erased.
> > With this method you get bitflips in erased pages correction for free.  
> 
> I will use this helper, thanks!
> 
> 
> 
> 
> With this, I think I answered all of your questions to v1.

You did. I'm waiting for the v2 now ;)

> 
> (Please tell me if there is something I missed to answer.)
> 
> Thanks a lot for your review.
> 
> 
> 

Re: [PATCH 15/39] mtd: nand: denali: improve readability of handle_ecc()

[Boris Brezillon]

On Fri, 2 Dec 2016 13:26:27 +0900
Masahiro Yamada  wrote:

> Hi Boris,
> 
> 
> 2016-11-28 0:42 GMT+09:00 Boris Brezillon 
> :
> >> + if (err_byte < ECC_SECTOR_SIZE) {
> >> + struct mtd_info *mtd =
> >> + nand_to_mtd(&denali->nand);
> >> + int offset;
> >> +
> >> + offset = (err_sector * ECC_SECTOR_SIZE + 
> >> err_byte) *
> >> + denali->devnum + err_device;
> >> + /* correct the ECC error */
> >> + buf[offset] ^= err_correction_value;
> >> + mtd->ecc_stats.corrected++;
> >> + bitflips++;  
> >
> > Hm, bitflips is what is set in max_bitflips, and apparently the
> > implementation (which is not yours) is not doing what the core expects.
> >
> > You should first count bitflips per sector with something like that:
> >
> > bitflips[err_sector]++;
> >
> >
> > And then once you've iterated over all errors do:
> >
> > for (i = 0; i < nsectors; i++)
> > max_bitflips = max(bitflips[err_sector], max_bitflips);  
> 
> 
> I see.
> 
> For soft ECC fixup, we can calculate bitflips
> for each ECC sector, so I can fix the max_bitflips
> as the core framework expects.
> 
> For hard ECC fixup, the register only reports
> the number of corrected bit-flips
> in the whole page (sum from all ECC sectors).
> We cannot calculate max_bitflips, I think.
> 

That's unfortunate. This means you'll return -EUCLEAN more quickly
(which will trigger UBI eraseblock move), since the NAND framework is
basing its 'too many bitflips' detection logic on the max_bitflips per
ECC chunk and the bitflips threshold (by default 3/4 of the ECC
strength).

That doesn't mean it won't work, you'll just wear your NAND more
quickly :-(.

ITOH, doing max_bitflips = nbitflips / nsteps is not good either,
because the bitflips might be all concentrated in the same ECC chunk,
and in this case you really want to return -EUCLEAN.

> 
> 
> BTW, I noticed another problem of the current code.
> 
>   buf[offset] ^= err_correction_value;
>   mtd->ecc_stats.corrected++;
>   bitflips++;
> 
> This code is counting the number of corrected bytes,
> not the number of corrected bits.
> 
> 
> I think multiple bit-flips within one byte can happen.

Yes.

> 
> 
> Perhaps, we should add
> 
>   hweight8(buf[offset] ^ err_correction_value)
> 
> to ecc_stats.corrected and bitflips.
> 

Looks good.

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

[Chanwoo Choi]

Hi Felipe,

On 2016년 11월 30일 19:36, Felipe Balbi wrote:
> 
> Hi,
> 
> Chanwoo Choi  writes:
>> This patch uses the resource-managed extcon API for 
>> extcon_register_notifier()
>> and replaces the deprecated extcon API as following:
>> - extcon_get_cable_state_() -> extcon_get_state()
>>
>> Signed-off-by: Chanwoo Choi 
> 
> Acked-by: Felipe Balbi 
> 

Thanks for your review.

Each patch has no any dependency among patches.
So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?

-- 
Best Regards,
Chanwoo Choi

Re: [PATCH v4 1/3] lib: add bitrev8x4()

[Anatolij Gustschin]

Hi Joshua,

On Thu, 1 Dec 2016 16:04:09 -0800
Joshua Clayton stillcompil...@gmail.com wrote:
...
>>> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
>>> +{
>>> +   __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));  
>>  return x;  
>Oops thats a little embarrassing;
>I'll add a return.
>>> +}  
>> otherwise you get
>>
>> In function '__arch_bitrev8x4':
>> warning: no return statement in function returning non-void [-Wreturn-type]
>>
>
>I wonder why I do not see this warning when compiling. The inlining, maybe?

do you have CONFIG_HAVE_ARCH_BITREVERSE=y in your .config?
Probably not optimized code is used, otherwise you will send wrong
data to FPGA (due to wrong return values from __arch_bitrev8x4).

Anatolij

Re: [PATCH v4 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Thu, Dec 1, 2016 at 11:12 PM, Jon Masters  wrote:
> On 12/01/2016 09:27 PM, Duc Dang wrote:
>> PCIe controllers in X-Gene SoCs is not ECAM compliant: software
>> needs to configure additional controller's register to address
>> device at bus:dev:function.
>>
>> The quirk will discover controller MMIO register space and configure
>> controller registers to select and address the target secondary device.
>>
>> The quirk will only be applied for X-Gene PCIe MCFG table with
>> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>>
>> Signed-off-by: Duc Dang 
>
> So far I've tested this on an HPE ProLiant m400 (Moonshot) cartridge
> and will test it on some other reference platforms soon. Bootlog for
> the m400 attached in case Bjorn wants to see the output. Here's
> what I see in /proc/iomem btw on that platform:
>
> # cat /proc/iomem
> 1052-10523fff : APMC0D18:00
>   1052-10523fff : APMC0D18:00
> 10524000-10527fff : APMC0D17:00
> 1054-1054a0ff : APMC0D01:00
>   10546000-10546fff : APMC0D50:00
>   1054a000-1054a00f : APMC0D12:03
> 1054a000-1054a00f : APMC0D12:02
>   1054a000-1054a00f : APMC0D12:01
> 1054a000-1054a00f : APMC0D12:00
> 1700-17000fff : APMC0D01:00
> 17001000-17001fff : APMC0D01:00
>   17001000-170013ff : APMC0D15:00
> 17001000-170013ff : APMC0D15:00
> 1701c000-1701cfff : APMC0D14:00
> 1a80-1a800fff : APMC0D0D:00
>   1a80-1a800fff : APMC0D0D:00
> 1c000200-1c0002ff : APMC0D06:00
> 1c021000-1c0210ff : APMC0D08:00
>   1c021000-1c02101f : serial
> 1c024000-1c024fff : APMC0D07:00
> 1f23-1f230fff : APMC0D0D:00
>   1f23-1f230fff : APMC0D0D:00
> 1f23d000-1f23dfff : APMC0D0D:00
>   1f23d000-1f23dfff : APMC0D0D:00
> 1f23e000-1f23efff : APMC0D0D:00
>   1f23e000-1f23efff : APMC0D0D:00
> 1f2a-1f31 : APMC0D06:00
> 1f50-1f50 : PCI Bus :00
>   1f50-1f50 : PNP0A08:00
> 7880-78800fff : APMC0D13:00
>   7880-78800fff : APMC0D12:03
> 7880-78800fff : APMC0D12:02
>   7880-78800fff : APMC0D12:01
> 7880-78800fff : APMC0D12:00
>   7880-78800fff : APMC0D11:00
>   7880-78800fff : APMC0D10:03
>   7880-78800fff : APMC0D10:02
>   7880-78800fff : APMC0D10:01
>   7880-78800fff : APMC0D10:00
> 7900-798f : APMC0D0E:00
> 7c00-7c1f : APMC0D12:00
> 7c20-7c3f : APMC0D12:01
> 7c40-7c5f : APMC0D12:02
> 7c60-7c7f : APMC0D12:03
> 7e00-7e000fff : APMC0D13:00
> 7e20-7e200fff : APMC0D10:03
>   7e20-7e200fff : APMC0D10:02
> 7e20-7e200fff : APMC0D10:01
>   7e20-7e200fff : APMC0D10:00
> 7e60-7e600fff : APMC0D11:00
> 7e70-7e700fff : APMC0D10:03
>   7e70-7e700fff : APMC0D10:02
> 7e70-7e700fff : APMC0D10:01
>   7e70-7e700fff : APMC0D10:00
> 7e72-7e720fff : APMC0D10:03
>   7e72-7e720fff : APMC0D10:02
> 7e72-7e720fff : APMC0D10:01
>   7e72-7e720fff : APMC0D10:00
> 7e80-7e800fff : APMC0D10:00
> 7e84-7e840fff : APMC0D10:01
> 7e88-7e880fff : APMC0D10:02
> 7e8c-7e8c0fff : APMC0D10:03
> 7e93-7e930fff : APMC0D13:00
> 40-4001ff : System RAM
>   48-4000c3 : Kernel code
>   4000db-400165 : Kernel data
> 40023a-4ff733 : System RAM
> 4ff734-4ff77c : reserved
> 4ff77d-4ff79c : System RAM
> 4ff79d-4ff7e7 : reserved
> 4ff7e8-4ff7e8 : System RAM
> 4ff7e9-4ff7ef : reserved
> 4ff7f1-4ff800 : reserved
> 4ff801-4f : System RAM
> a02000-a03fff : PCI Bus :00
>   a02000-a0201f : PCI Bus :01
> a02000-a0200f : :01:00.0
>   a02000-a0200f : mlx4_core
> a02010-a0201f : :01:00.0
> a06000-a07fff : PCI Bus :00
> a0d000-a0dfff : PCI ECAM
> a11000-a14fff : PCI Bus :00
>   a11000-a121ff : PCI Bus :01
> a11000-a111ff : :01:00.0
>   a11000-a111ff : mlx4_core
> a11200-a121ff : :01:00.0
>
> Adding a Tested-by for the record:
>
> Tested-by: Jon Masters 

Thanks a lot for testing this, Jon.
>
> Jon.
>
> --
> Computer Architect | Sent from my Fedora powered laptop
>
Regards,
Duc Dang.

Re: [PATCH 02/15] hyperv: Add a function to detect hv_device

[Greg KH]

On Fri, Dec 02, 2016 at 07:14:03AM +, KY Srinivasan wrote:
> > In other words, why do you need this and PCI or USB doesn't?  Why is
> > hyperv "special"?
> 
> On Hyper-V, each VF interface (SR-IOV interface)
> is paired with an instance of the 
> synthetic interface that is managed by netvsc.
> When the VF interface comes up, we
> need to associate the VF instance with 
> the corresponding netvsc instance. To do this
> without modifying the VF drivers, netvsc registers 
> for netdev events.

Why not modify the VF drivers?  You have the full source to them...

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Thu, Dec 1, 2016 at 10:31 PM, Jon Masters  wrote:
> Bjorn,
>
> Although I think the below still applies (that we need to leave that
> Memory32Fixed for existing deployments, and this is going to result
> in /proc/iomem polution), I've done some more reading of your ecam
> tree and the implementation of acpi_get_rc_resources you mentioned,
> and in particular how the PNP0C02 devices actually get wired up.
>
> I would like to be able to boot upstream on existing shipping and
> deployed machines that are in the field (not to mention our labs), but
> there's no reason we can't *also* get APM to add a new vendor specific
> PNP0C02 to the ACPI namespace in future firmware updates (for at least
> their own Mustang reference boards) matching segment to CSR, as in the
> case of the HiSi patches. That might then allow for some later
> preference to use that for the CSR rather than getting it from the RC
> device. Still, it would be ideal to boot on machines that are shipping
> from HPE and others at this moment, so I am still hopeful you'll
> at least allow the approach from Duc's v4 for now (4.10).

APM X-Gene 1 and X-Gene 2 ACPI tables will absolutely have PNP0C02
nodes (in upcoming firmware release). I hope to have a solution that
works for both old buggy firmware and the future improved firmware. So
I am thinking the CSR discovery will be like this:

(1) Use  acpi_get_rc_resources() to discover CSR resource by checking
PNP0C02 nodes
(2) (1) should succeed with the new firmware
(3) If (1) fails, we can fall back to approach on v4 patch: calling
xgene_get_csr_resource() to discover the CSR described by
Memory32Fixed macro.

How do you feel about this? The drawback is the new firmware that does
not have the CSR space described with Memory32Fixed macro will fail on
the distro version that uses the old quirk (that relies on this
Memory32Fixed macro).

>
> Another nasty option for later consideration could then be having
> the kernel fake up any missing PNP0C02 on existing machines, but
> it would need special knowledge of the platform to generate that
> so as to handle the problem Mark flagged earlier (segment vs
> controller mismatch on some platforms). That could be done with a
> DMI quirk that matched on a specific (e.g. HPE) machine. It would
> only be needed on "broken" existing machines, and could be added
> post-4.10 to clean this up if you really want to do that.

Bjorn suggested similar approach (have a PNP quirk to fabricate a
PNP0C02 device and decleare all the required resources there) on
another thread. But as you said, this approach does not scale, it can
only applicable for a specific machine (by checking DMI information to
apply the PNP quirk).

>
> That's all very nasty...
>
> Jon.
>
> On 12/01/2016 11:08 PM, Jon Masters wrote:
>> Hi Bjorn, Duc, Mark,
>>
>> I switched my brain to the on mode and went and read some specs, and a few
>> tables, so here's my 2 cents on this...
>>
>> On 12/01/2016 06:22 PM, Duc Dang wrote:
>>> On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas  wrote:
 On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
>>
>>> The SoC provide some number of RC bridges, each with a different base
>>> for some mmio registers. Even if segment is legitimate in MCFG, there
>>> is still a problem if a platform doesn't use the segment ordering
>>> implied by the code. But the PNP0A03 _CRS does have this base address
>>> as the first memory resource, so we could get it from there and not
>>> have hard-coded addresses and implied ording in the quirk code.
>>
>> I'm confused.  Doesn't the current code treat every item in PNP0A03
>> _CRS as a window?  Do you mean the first resource is handled
>> differently somehow?  The Consumer/Producer bit could allow us to do
>> this by marking the RC MMIO space as "Consumer", but I didn't think
>> that strategy was quite working yet.
>>
>> Let's see if I summarized this correctly...
>>
>> 1. The MMIO registers for the host bridge itself need to be described
>>somewhere, especially if we need to find those in a quirk and poke
>>them. Since those registers are very much part of the bridge device,
>>it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
>>
>> 2. The address space covering these registers MUST be described as a
>>ResourceConsumer in order to avoid accidentally exposing them as
>>available for use by downstream devices on the PCI bus.
>>
>> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
>>This is a macro that doesn't have the notion of a producer or consumer.
>>HOWEVER various interpretations seem to be that this could/should
>>default to being interpreted as a consumed region.
>>
>> 4. At one point, a regression was added to the kernel:
>>
>>63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
>>host bridge itself")
>>
>>Which lead to a series on conversations about what should happen
>>for bridge resourc

Re: [PATCH 4/4] x86/asm: Change sync_core() to use MOV to CR2 to serialize

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Wed, Nov 30, 2016 at 12:34:55PM -0800, Andy Lutomirski wrote:
> > Aside from being excessively slow, CPUID is problematic: Linux runs
> > on a handful of CPUs that don't have CPUID.  MOV to CR2 is always
> > available, so use it instead.
> > 
> > Signed-off-by: Andy Lutomirski 
> > ---
> >  arch/x86/include/asm/processor.h | 31 ---
> >  1 file changed, 8 insertions(+), 23 deletions(-)
> 
> Looks nice.
> 
> I'm wondering if we should leave this one in tip for an additional cycle
> to have it tested on more hw. I know, it is architectural and so on but
> who knows what every implementation actually does...

I think -tip and "upstream of the day" mostly gets tested on relatively recent 
x86 
hardware - proven by the fact that these regressions are many months old.

The reason v4.9 got extra testing is the announced Long Term Support (LTS) 
aspect: 
more, older, weirder hardware is being tested because it's going to be a very 
popular base kernel.

So the best option would be to get these fixes into -tip, make sure it's sane 
all 
around and works on hardware that gets tested on bleeding edge kernels, then 
push 
it upstream sooner rather than later and also have Cc:stable tags on the 
obvious 
fixes, and handle any eventual fallout as it happens.

That's the best we can do I think.

Thanks,

Ingo

[PATCH] fuse: freezing abort when use wait_event_killable{,_exclusive}().

[cuilifei]

Freezing process can abort when a client is waiting uninterruptibly
for a response. Add new macro wait_fatal_freezable to try to fix it.

Signed-off-by: cuilifei 
---
 fs/fuse/dev.c | 45 +
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 70ea57c..3447ecc 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -23,6 +23,22 @@
 MODULE_ALIAS_MISCDEV(FUSE_MINOR);
 MODULE_ALIAS("devname:fuse");
 
+#define wait_fatal_freezable(wq, condition, exclusive) \
+({ \
+   int __ret = 0;  \
+   do {\
+   if (exclusive)  \
+   __ret = wait_event_interruptible_exclusive(wq,  \
+   condition); \
+   else\
+   __ret = wait_event_interruptible(wq,\
+   condition); \
+   if (!__ret || fatal_signal_pending(current))\
+   break;  \
+   } while (try_to_freeze());  \
+   __ret;  \
+})
+
 static struct kmem_cache *fuse_req_cachep;
 
 static struct fuse_dev *fuse_get_dev(struct file *file)
@@ -99,6 +115,19 @@ void fuse_request_free(struct fuse_req *req)
kmem_cache_free(fuse_req_cachep, req);
 }
 
+static void block_sigs(sigset_t *oldset)
+{
+   sigset_t mask;
+
+   siginitsetinv(&mask, sigmask(SIGKILL));
+   sigprocmask(SIG_BLOCK, &mask, oldset);
+}
+
+static void restore_sigs(sigset_t *oldset)
+{
+   sigprocmask(SIG_SETMASK, oldset, NULL);
+}
+
 void __fuse_get_request(struct fuse_req *req)
 {
atomic_inc(&req->count);
@@ -134,13 +163,18 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn 
*fc, unsigned npages,
   bool for_background)
 {
struct fuse_req *req;
+   sigset_t oldset;
+   int intr;
int err;
atomic_inc(&fc->num_waiting);
 
if (fuse_block_alloc(fc, for_background)) {
err = -EINTR;
-   if (wait_event_killable_exclusive(fc->blocked_waitq,
-   !fuse_block_alloc(fc, for_background)))
+   block_sigs(&oldset);
+   intr = wait_fatal_freezable(fc->blocked_waitq,
+   !fuse_block_alloc(fc, for_background), true);
+   restore_sigs(&oldset);
+   if (intr)
goto out;
}
/* Matches smp_wmb() in fuse_set_initialized() */
@@ -427,9 +461,12 @@ static void request_wait_answer(struct fuse_conn *fc, 
struct fuse_req *req)
}
 
if (!test_bit(FR_FORCE, &req->flags)) {
+   sigset_t oldset;
/* Only fatal signals may interrupt this */
-   err = wait_event_killable(req->waitq,
-   test_bit(FR_FINISHED, &req->flags));
+   block_sigs(&oldset);
+   err = wait_fatal_freezable(req->waitq,
+   test_bit(FR_FINISHED, &req->flags), false);
+   restore_sigs(&oldset);
if (!err)
return;
 
-- 
1.9.1

ATTENZIONE;

[Sistemi amministratore]

ATTENZIONE;

La cassetta postale ha superato il limite di archiviazione, che è 5 GB come 
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si 
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare 
la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti 
informazioni qui di seguito:

nome:
Nome utente:
Password:
Conferma Password:
E-mail:
telefono:

Se non si riesce a rinnovare la vostra casella di posta, la vostra casella di 
posta sarà disabilitato!

Ci dispiace per l'inconvenienza.
Codice di verifica: en:0085362LK.16.2016 Mail Technical Support ©2016

grazie
Sistemi amministratore

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

[Vlastimil Babka]

On 12/01/2016 04:25 PM, Michal Hocko wrote:

From: Michal Hocko 

__alloc_pages_may_oom makes sure to skip the OOM killer depending on
the allocation request. This includes lowmem requests, costly high
order requests and others. For a long time __GFP_NOFAIL acted as an
override for all those rules. This is not documented and it can be quite
surprising as well. E.g. GFP_NOFS requests are not invoking the OOM
killer but GFP_NOFS|__GFP_NOFAIL does so if we try to convert some of
the existing open coded loops around allocator to nofail request (and we
have done that in the past) then such a change would have a non trivial
side effect which is not obvious. Note that the primary motivation for
skipping the OOM killer is to prevent from pre-mature invocation.

The exception has been added by 82553a937f12 ("oom: invoke oom killer
for __GFP_NOFAIL"). The changelog points out that the oom killer has to
be invoked otherwise the request would be looping for ever. But this
argument is rather weak because the OOM killer doesn't really guarantee
any forward progress for those exceptional cases - e.g. it will hardly
help to form costly order - I believe we certainly do not want to kill
all processes and eventually panic the system just because there is a
nasty driver asking for order-9 page with GFP_NOFAIL not realizing all
the consequences - it is much better this request would loop for ever
than the massive system disruption, lowmem is also highly unlikely to be
freed during OOM killer and GFP_NOFS request could trigger while there
is still a lot of memory pinned by filesystems.

This patch simply removes the __GFP_NOFAIL special case in order to have
a more clear semantic without surprising side effects. Instead we do
allow nofail requests to access memory reserves to move forward in both
cases when the OOM killer is invoked and when it should be supressed.
__alloc_pages_nowmark helper has been introduced for that purpose.

Signed-off-by: Michal Hocko 


Acked-by: Vlastimil Babka 

[PATCH 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
Exynos5433 has the following AMBA AXI buses to translate data
between DRAM and sub-blocks.

Following list specify the detailed correlation between sub-block and clock:
- CLK_ACLK_G2D_{400|266}  : Bus clock for G2D
- CLK_ACLK_MSCL_400   : Bus clock for MSCL (Mobile Scaler)
- CLK_ACLK_GSCL_333   : Bus clock for GSCL (General Scaler)
- CLK_SCLK_JPEG_MSCL  : Bus clock for JPEG
- CLK_ACLK_MFC_400: Bus clock for MFC (Multi Format Codec)
- CLK_ACLK_HEVC_400   : Bus clock for HEVC (High Effective Video Codec)
- CLK_ACLK_BUS0_400   : NoC(Network On Chip)'s bus clock for 
PERIC/PERIS/FSYS/MSCL
- CLK_ACLK_BUS1_400   : NoC's bus clock for MFC/HEVC/G3D
- CLK_ACLK_BUS2_400   : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 208 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |   1 +
 2 files changed, 209 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
new file mode 100644
index ..b1e1d9c622e1
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -0,0 +1,208 @@
+/*
+ * Samsung's Exynos5433 SoC Memory interface and AMBA bus device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Chanwoo Choi 
+ *
+ * Samsung's Exynos5433 SoC Memory interface and AMBA buses are listed
+ * as device tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+   /* INT (Internal) block using VDD_INT */
+   bus_g2d_400: bus_g2d_400 {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_G2D_400>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_g2d_400_opp_table>;
+   status ="disable";
+   };
+
+   bus_mscl: bus_mscl {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_MSCL_400>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_g2d_400_opp_table>;
+   status ="disable";
+   };
+
+   bus_jpeg: bus_jpeg {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_SCLK_JPEG_MSCL>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_g2d_400_opp_table>;
+   status ="disable";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_MFC_400>;
+
+   clock-names = "bus";
+   operating-points-v2 = <&bus_g2d_400_opp_table>;
+   status ="disable";
+   };
+
+   bus_g2d_266: bus_g2d_266 {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_G2D_266>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_g2d_266_opp_table>;
+   status ="disable";
+   };
+
+   bus_gscl: bus_gscl {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_GSCL_333>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_gscl_opp_table>;
+   status ="disable";
+   };
+
+   bus_hevc: bus_hevc {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_HEVC_400>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_hevc_opp_table>;
+   status ="disable";
+   };
+
+   bus_bus0: bus_bus0 {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_BUS0_400>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_hevc_opp_table>;
+   status ="disable";
+   };
+
+   bus_bus1: bus_bus1 {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_top CLK_ACLK_BUS1_400>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_hevc_opp_table>;
+   status ="disable";
+   };
+
+   bus_bus2: bus_bus2 {
+   compatible = "samsung,exynos-bus";
+   clocks = <&cmu_mif CLK_ACLK_BUS2_400>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_bus2_opp_table>;
+   status ="disable";
+   };
+
+   bus_g2d_400_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <1075000>;
+   }

[PATCH 2/5] PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433

[Chanwoo Choi]

This patch adds the detailed corrleation between sub-blocks and VDD_INT power
line for Exynos5433. VDD_INT provided the power source to INT (Internal) block.

Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d3ec8e676b6b..d085ef90d27c 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -123,6 +123,20 @@ Detailed correlation between sub-blocks and power line 
according to Exynos SoC:
|--- FSYS
|--- FSYS2
 
+- In case of Exynos5433, there is VDD_INT power line as following:
+   VDD_INT |--- G2D (parent device)
+   |--- MSCL
+   |--- GSCL
+   |--- JPEG
+   |--- MFC
+   |--- HEVC
+   |--- BUS0
+   |--- BUS1
+   |--- BUS2
+   |--- PERIS (Fixed clock rate)
+   |--- PERIC (Fixed clock rate)
+   |--- FSYS  (Fixed clock rate)
+
 Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
-- 
1.9.1

[PATCH 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical

[Chanwoo Choi]

The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are
disabled, the system halt happen. Following clock must be always enabled.
- CLK_ACLK_BUS0_400 : NoC's bus clock for PERIC/PERIS/FSYS/MSCL
- CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
- CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Also, this patch adds the CLK_SET_RATE_PARENT flag to the CLK_SCLK_JPEG_MSCL
because this clock should be used for bus frequency scaling. This clock need to
be changed on the fly with CLK_SET_RATE_PARENT flag.

Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc:linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/clk/samsung/clk-exynos5433.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index f096bd7df40c..0db5204c307c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -549,10 +549,10 @@
29, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_BUS0_400, "aclk_bus0_400", "div_aclk_bus0_400",
ENABLE_ACLK_TOP, 26,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_BUS1_400, "aclk_bus1_400", "div_aclk_bus1_400",
ENABLE_ACLK_TOP, 25,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_IMEM_200, "aclk_imem_200", "div_aclk_imem_266",
ENABLE_ACLK_TOP, 24,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
@@ -616,7 +616,7 @@
 
/* ENABLE_SCLK_TOP_MSCL */
GATE(CLK_SCLK_JPEG_MSCL, "sclk_jpeg_mscl", "div_sclk_jpeg",
-   ENABLE_SCLK_TOP_MSCL, 0, 0, 0),
+   ENABLE_SCLK_TOP_MSCL, 0, CLK_SET_RATE_PARENT, 0),
 
/* ENABLE_SCLK_TOP_CAM1 */
GATE(CLK_SCLK_ISP_SENSOR2, "sclk_isp_sensor2", "div_sclk_isp_sensor2_b",
@@ -1382,7 +1382,7 @@ static void __init exynos5433_cmu_cpif_init(struct 
device_node *np)
/* ENABLE_ACLK_MIF3 */
GATE(CLK_ACLK_BUS2_400, "aclk_bus2_400", "div_aclk_bus2_400",
ENABLE_ACLK_MIF3, 4,
-   CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+   CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_DISP_333, "aclk_disp_333", "div_aclk_disp_333",
ENABLE_ACLK_MIF3, 1,
CLK_IS_CRITICAL | CLK_SET_RATE_PARENT, 0),
-- 
1.9.1

[PATCH 0/5] arm64: dts: Enable bus frequency scaling on Exynos5433-based TM2 board

[Chanwoo Choi]

This patches add the AMBA bus Device-tree node unsing VDD_INT
to enable the bus frequency scaling on Exynos5433-based TM2 board.

There are two kind of bus device with devfreq framework.
- Parent bus device  : Change the frequency/voltage according to bus's 
utilization.
- Passive bus device : Change only frequency according to the new level
   of parent bus device.

The VDD_INT regulator provides the power source to INT (Internal) block as
following. The sub-blocks in the INT block share the one power source.
   VDD_INT |--- G2D (parent device)
   |--- MSCL
   |--- GSCL
   |--- JPEG
   |--- MFC
   |--- HEVC
   |--- BUS0
   |--- BUS1
   |--- BUS2
   |--- PERIS (Fixed clock rate)
   |--- PERIC (Fixed clock rate)
   |--- FSYS  (Fixed clock rate)

Each sub-block has the bus clock as following:
 - CLK_ACLK_G2D_{400|266} : Bus clock for G2D
 - CLK_ACLK_MSCL_400  : Bus clock for MSCL (Mobile Scaler)
 - CLK_ACLK_GSCL_333  : Bus clock for GSCL (General Scaler)
 - CLK_SCLK_JPEG_MSCL : Bus clock for JPEG
 - CLK_ACLK_MFC_400   : Bus clock for MFC (Multi Format Codec)
 - CLK_ACLK_HEVC_400  : Bus clock for HEVC (High Effective Video Codec)
 - CLK_ACLK_BUS0_400  : NoC(Network On Chip)'s bus clock for 
PERIC/PERIS/FSYS/MSCL
 - CLK_ACLK_BUS1_400  : NoC's bus clock for MFC/HEVC/G3D
 - CLK_ACLK_BUS2_400  : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP

Chanwoo Choi (5):
  clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
  PM / devfreq: exynos-bus: Add the detailed correlation for Exynos5433
  arm64: dts: exynos5433: Add PPMU dt node
  arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
  arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2

 .../devicetree/bindings/devfreq/exynos-bus.txt |  14 ++
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 208 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  72 +++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  25 +++
 drivers/clk/samsung/clk-exynos5433.c   |   8 +-
 5 files changed, 323 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi

-- 
1.9.1

[PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node

[Chanwoo Choi]

This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
to measure the utilization of each IP in Exynos SoC.

- PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
  block with VDD_MIF power source.
- PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
  block with VDD_INT power source.

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 64226d5ae471..8c4ee84d5232 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -599,6 +599,30 @@
clock-names = "fin_pll", "mct";
};
 
+   ppmu_d0_cpu: ppmu@1048 {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x1048 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d0_general: ppmu@1049 {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x1049 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d1_cpu: ppmu@104b {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x104b 0x2000>;
+   status = "disabled";
+   };
+
+   ppmu_d1_general: ppmu@104c {
+   compatible = "samsung,exynos-ppmu-v2";
+   reg = <0x104c 0x2000>;
+   status = "disabled";
+   };
+
pinctrl_alive: pinctrl@1058 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x1058 0x1a20>, <0x1109 0x100>;
-- 
1.9.1

[PATCH 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2

[Chanwoo Choi]

This patch adds the bus Device-tree nodes for INT (Internal) block
to enable the bus frequency scaling.

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index c08589970134..7b37aae336b1 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -170,6 +170,58 @@
};
 };
 
+&bus_g2d_400 {
+   devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
+   vdd-supply = <&buck4_reg>;
+   exynos,saturation-ratio = <10>;
+   status = "okay";
+};
+
+&bus_mscl {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_jpeg {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_mfc {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_g2d_266 {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_gscl {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_hevc {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_bus0 {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_bus1 {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
+&bus_bus2 {
+   devfreq = <&bus_g2d_400>;
+   status = "okay";
+};
+
 &cmu_aud {
assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
@@ -794,6 +846,26 @@
bus-width = <4>;
 };
 
+&ppmu_d0_general {
+   status = "okay";
+
+   events {
+   ppmu_event0_d0_general: ppmu-event0-d0-general {
+   event-name = "ppmu-event0-d0-general";
+   };
+   };
+};
+
+&ppmu_d1_general {
+   status = "okay";
+
+   events {
+   ppmu_event0_d1_general: ppmu-event0-d1-general {
+  event-name = "ppmu-event0-d1-general";
+  };
+   };
+};
+
 &pinctrl_alive {
pinctrl-names = "default";
pinctrl-0 = <&initial_alive>;
-- 
1.9.1

RE: [PATCH 02/15] hyperv: Add a function to detect hv_device

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, December 1, 2016 10:48 PM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; leann.ogasaw...@canonical.com; Haiyang Zhang
> 
> Subject: Re: [PATCH 02/15] hyperv: Add a function to detect hv_device
> 
> On Fri, Dec 02, 2016 at 06:02:29AM +, KY Srinivasan wrote:
> >
> >
> > > -Original Message-
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Thursday, December 1, 2016 12:36 PM
> > > To: KY Srinivasan 
> > > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> > > jasow...@redhat.com; leann.ogasaw...@canonical.com; Haiyang Zhang
> > > 
> > > Subject: Re: [PATCH 02/15] hyperv: Add a function to detect hv_device
> 
> Ugh, please fix your email client...
> 
> > >
> > > On Thu, Dec 01, 2016 at 09:28:39AM -0800, k...@exchange.microsoft.com
> > > wrote:
> > > > From: Haiyang Zhang 
> > > >
> > > > Signed-off-by: Haiyang Zhang 
> > > > Signed-off-by: K. Y. Srinivasan 
> > > > ---
> > > >  drivers/hv/vmbus_drv.c |6 ++
> > > >  include/linux/hyperv.h |2 ++
> > > >  2 files changed, 8 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > > > index 0276d2e..1730ac0 100644
> > > > --- a/drivers/hv/vmbus_drv.c
> > > > +++ b/drivers/hv/vmbus_drv.c
> > > > @@ -692,6 +692,12 @@ struct onmessage_work_context {
> > > > struct hv_message msg;
> > > >  };
> > > >
> > > > +bool device_is_hyperv(struct device *dev)
> > > > +{
> > > > +   return dev->release == vmbus_device_release;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(device_is_hyperv);
> > >
> > > Wait, eek, no!  That's NOT how you determine a device type, if you
> > > really even ever need to do that.
> > >
> > > Why are you needing this?  You should always "just know" what type of
> > > device a struct device * is, that's what we rely on in the driver model.
> > > Otherwise things get messy very very quickly.
> > >
> > > Sorry, I can't take this without a ton of justification, and even then,
> > > you need to do this correctly (and no, I'm not going to tell you how to
> > > do that as I don't like it being done...)
> > >
> > Greg,
> >
> > To support SR-IOV, netvsc registers for all netdev events. For netdev
> events related to the
> > VF interface, we need to do some special processing. And so, we need to
> determine
> > if the device that is generating the netdev event is Hyper-V device or not
> > (passed through the PCI pass through driver). Is this justification 
> > sufficient.
> > As you have observed, currently there is no user of this API and that is
> because netvsc
> > will be the user. To avoid cross-tree dependency, we wanted to get this
> functionality in first
> > before submitting the netvsc patch.
> 
> See, you do have some text for a changelog!
> 
> {grumble...}
> 
> No, I don't think this is a good justification, where are you going to
> put this "check" into the networking stack?  Your driver should only be
> binding to devices of this "type" anyway, so by that logic, it already
> "knows" that the device is of this type.
> 
> In other words, why do you need this and PCI or USB doesn't?  Why is
> hyperv "special"?

On Hyper-V, each VF interface (SR-IOV interface)
is paired with an instance of the 
synthetic interface that is managed by netvsc.
When the VF interface comes up, we
need to associate the VF instance with 
the corresponding netvsc instance. To do this
without modifying the VF drivers, netvsc registers 
for netdev events. In the netdev
event handler (in netvsc) currently I am 
doing the association based on the MAC
address - this code is currently committed 
upstream (see drivers/net/hyperv/netvsc_drv.c 
netvsc_register_vf()). Going forward, we want to 
base this association based on a sequence
number that the host publishes both for the 
VF as well as the corresponding
synthetic (netvsc) instance.

You are right, netvsc already knows that the 
devices it is managing belong to vmbus.
Since we are registering for netdev events, 
we will get notified for devices that may not
be vmbus devices and that is where this new 
API will be used. If the device is a vmbus device
we can extract the sequence number to implement the match.

Regards,

K. Y

Re: [PATCH v4 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Jon Masters]

On 12/01/2016 09:27 PM, Duc Dang wrote:
> PCIe controllers in X-Gene SoCs is not ECAM compliant: software
> needs to configure additional controller's register to address
> device at bus:dev:function.
> 
> The quirk will discover controller MMIO register space and configure
> controller registers to select and address the target secondary device.
> 
> The quirk will only be applied for X-Gene PCIe MCFG table with
> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
> 
> Signed-off-by: Duc Dang 

So far I've tested this on an HPE ProLiant m400 (Moonshot) cartridge
and will test it on some other reference platforms soon. Bootlog for
the m400 attached in case Bjorn wants to see the output. Here's
what I see in /proc/iomem btw on that platform:

# cat /proc/iomem 
1052-10523fff : APMC0D18:00
  1052-10523fff : APMC0D18:00
10524000-10527fff : APMC0D17:00
1054-1054a0ff : APMC0D01:00
  10546000-10546fff : APMC0D50:00
  1054a000-1054a00f : APMC0D12:03
1054a000-1054a00f : APMC0D12:02
  1054a000-1054a00f : APMC0D12:01
1054a000-1054a00f : APMC0D12:00
1700-17000fff : APMC0D01:00
17001000-17001fff : APMC0D01:00
  17001000-170013ff : APMC0D15:00
17001000-170013ff : APMC0D15:00
1701c000-1701cfff : APMC0D14:00
1a80-1a800fff : APMC0D0D:00
  1a80-1a800fff : APMC0D0D:00
1c000200-1c0002ff : APMC0D06:00
1c021000-1c0210ff : APMC0D08:00
  1c021000-1c02101f : serial
1c024000-1c024fff : APMC0D07:00
1f23-1f230fff : APMC0D0D:00
  1f23-1f230fff : APMC0D0D:00
1f23d000-1f23dfff : APMC0D0D:00
  1f23d000-1f23dfff : APMC0D0D:00
1f23e000-1f23efff : APMC0D0D:00
  1f23e000-1f23efff : APMC0D0D:00
1f2a-1f31 : APMC0D06:00
1f50-1f50 : PCI Bus :00
  1f50-1f50 : PNP0A08:00
7880-78800fff : APMC0D13:00
  7880-78800fff : APMC0D12:03
7880-78800fff : APMC0D12:02
  7880-78800fff : APMC0D12:01
7880-78800fff : APMC0D12:00
  7880-78800fff : APMC0D11:00
  7880-78800fff : APMC0D10:03
  7880-78800fff : APMC0D10:02
  7880-78800fff : APMC0D10:01
  7880-78800fff : APMC0D10:00
7900-798f : APMC0D0E:00
7c00-7c1f : APMC0D12:00
7c20-7c3f : APMC0D12:01
7c40-7c5f : APMC0D12:02
7c60-7c7f : APMC0D12:03
7e00-7e000fff : APMC0D13:00
7e20-7e200fff : APMC0D10:03
  7e20-7e200fff : APMC0D10:02
7e20-7e200fff : APMC0D10:01
  7e20-7e200fff : APMC0D10:00
7e60-7e600fff : APMC0D11:00
7e70-7e700fff : APMC0D10:03
  7e70-7e700fff : APMC0D10:02
7e70-7e700fff : APMC0D10:01
  7e70-7e700fff : APMC0D10:00
7e72-7e720fff : APMC0D10:03
  7e72-7e720fff : APMC0D10:02
7e72-7e720fff : APMC0D10:01
  7e72-7e720fff : APMC0D10:00
7e80-7e800fff : APMC0D10:00
7e84-7e840fff : APMC0D10:01
7e88-7e880fff : APMC0D10:02
7e8c-7e8c0fff : APMC0D10:03
7e93-7e930fff : APMC0D13:00
40-4001ff : System RAM
  48-4000c3 : Kernel code
  4000db-400165 : Kernel data
40023a-4ff733 : System RAM
4ff734-4ff77c : reserved
4ff77d-4ff79c : System RAM
4ff79d-4ff7e7 : reserved
4ff7e8-4ff7e8 : System RAM
4ff7e9-4ff7ef : reserved
4ff7f1-4ff800 : reserved
4ff801-4f : System RAM
a02000-a03fff : PCI Bus :00
  a02000-a0201f : PCI Bus :01
a02000-a0200f : :01:00.0
  a02000-a0200f : mlx4_core
a02010-a0201f : :01:00.0
a06000-a07fff : PCI Bus :00
a0d000-a0dfff : PCI ECAM
a11000-a14fff : PCI Bus :00
  a11000-a121ff : PCI Bus :01
a11000-a111ff : :01:00.0
  a11000-a111ff : mlx4_core
a11200-a121ff : :01:00.0

Adding a Tested-by for the record:

Tested-by: Jon Masters 

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.0-rc7.ecam_jcm1+ 
(r...@hp-moonshot-02-c08.khw.lab.eng.bos.redhat.com) (gcc version 4.8.5 
20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Fri Dec 2 01:13:24 EST 2016
[0.00] Boot CPU: AArch64 Processor [500f0001]
[0.00] earlycon: uart8250 at MMIO32 0x1c021000 (options '')
[0.00] bootconsole [uart8250] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: EFI v2.60 by HPE
[0.00] efi:  ACPI 2.0=0x4ff800  SMBIOS 3.0=0x4ff7a9  
MEMATTR=0x4ff2411818 
[0.00] cma: Reserved 512 MiB at 0x0040e000
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x004FF800 24 (v02 HP)
[0.00] ACPI: XSDT 0x004FF7FF 84 (v01 HP ProLiant 
0001  0113)
[0.00] ACPI: FACP 0x004FF7FB 000114 (v06 HPEProLiant 
0001 HP   0001)
[0.00] ACPI: DSDT 0x004FF7F8 0023CA (v05 HPEDSDT 

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

[Matthew Garrett]

On Fri, Dec 02, 2016 at 07:55:30AM +0100, Greg KH wrote:
> On Fri, Dec 02, 2016 at 03:07:00AM +, Matthew Garrett wrote:
> > If root is able to modify the behaviour of verified code after it was 
> > verified, then the value of that verification is reduced. Ensuring that 
> > the code remains trustworthy is vital in a number of security use cases.
> 
> Ok, but why are you now deciding to somehow try to "classify" the types
> of module parameters?  Why would you want to allow irqs to change, but
> not iobase?  Or something else?  Who is going to do this "I want you and
> you but not you" decision?  Why not just forbid all module parameters at
> all if they are so dangerous?

If the parameters plausibly make it possible for root to modify the 
kernel in interesting ways, then restricting them makes sense. My gut 
sense is that parameters that allow the alteration of the base address 
of memory mapped devices are clearly a problem in this respect, but port 
io and IRQs *probably* aren't. On the other hand, blocking mmio base 
addresses and not blocking the others is kind of inconsistent.

> > If root can tell a driver to probe for hardware at a specific address, 
> > and that driver will then blindly do so, root is trivially able to 
> > modify arbitrary kernel memory and disable arbitrary security features. 
> > IRQ or io port attacks are much more difficult to take advantage of, but 
> > I could imagine that some of them are still plausible.
> 
> Then just mark them all as "bad", why pick and choose?

Most parameters are going to be fine, but sure, flagging all 
IRQ/mmio/pio address parameters seems reasonable.

> > Here's an example. The sysfs option to enable module signing is write 
> > once. If root sets that, root can't unset it. Except there's a whole 
> > bunch of ways that root *can* unset it, including kexec 
> > (https://mjg59.dreamwidth.org/28746.html) and a bunch of other things 
> > that are disabled by this patchset. That feature is entirely useless as 
> > is. This patchset helps make it useful.
> 
> "this" patchset does nothing to disable anything, so I can't speak to
> any of the other goals you might have for that code, that's not what we
> are reviewing here.

This is prep work that makes it possible to block module parameters that 
would otherwise make it possible to avoid those restrictions.

> > Right now, the secure boot patchset is shipped by basically every single 
> > mainstream Linux distribution (and a whole bunch that are niche). Right 
> > now they're having to do extra work to rebase it and ensure that fixes 
> > get distributed to everyone. There's clearly demand, and Linus has been 
> > clear that features that are shipped by everyone should just go into 
> > mainline, so if there are *technical* objections then let's figure them 
> > out and otherwise just get this stuff merged.
> 
> "this stuff" is brand new things, that no one is shipping.  And nothing
> "just goes" into mainline, no matter what foolish stuff distros end up
> shipping (an example, do you want the giant Xen kernel patchset that
> SuSE has been dragging around for 10+ years?)

This is a logical extension to the base patchset, and one maintainer has 
NAKed the base patchset due to it lacking this feature. If you don't 
care about this then just tell Alan that you want the base patchset 
merged anyway and we'll go from there. Let's not get into a situation 
where people are being given incompatible requirements before 
something's merged.

-- 
Matthew Garrett | mj...@srcf.ucam.org

Re: [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section

[Robert Richter]

James,

On 01.12.16 17:26:55, James Morse wrote:
> On 01/12/16 16:45, Will Deacon wrote:
> > Thanks for sending out the new patch. Whilst I'm still a bit worried about
> > changing pfn_valid like this, I guess we'll just have to fix up any callers
> > which suffer from this change.
> 
> Hibernate's core code falls foul of this. This patch causes a panic when 
> copying
> memory to build the 'image'[0].
> saveable_page() in kernel/power/snapshot.c broadly assumes that pfn_valid()
> pages can be accessed.
> 
> Fortunately the core code exposes pfn_is_nosave() which we can extend to catch
> 'nomap' pages, but only if they are also marked as PageReserved().
> 
> Are there any side-effects of marking all the nomap regions with
> mark_page_reserved()? (it doesn't appear to be the case today).

Reserving the page adds it to the memory management which is what we
would like to avoid for NOMAP pages. I don't believe we should do
this. Since NOMAP is to some degree now core functionality I would
rather implement pfn_is_nomap() that defaults to pfn_is_valid() but
calls memblock_is_nomap() for arm64 or does something equivalent.

The question arises what to do with that mem at all. There could be
mappings by the kernel, e.g. of acpi tables. We can't assume the mem
regions still come out the same from the BIOS during resume. Do we
need to save the mem? I can't answer that as I don't know much about
hibernation yet.

Thanks,

-Robert

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

Hey Arnaldo,

On Tue, Nov 22, 2016 at 04:01:06PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 10, 2016 at 04:40:46PM -0800, Krister Johansen escreveu:
> > Thanks.  As part of processing this did you run into any problems?
> > Would you like me to rebase against the latest perf/core and re-send the
> > patch?
> 
> Sorry for the overly long delay, trying it now after fixing up a
> conflict with a recent patchkit (branch stuff) I tested it by running
> 'perf top -g' and I'm getting some assertion bugs:

I appreciate you taking another stab at pulling this in.  My turn to
apologize for the delay.

> # perf top -g
>1.34% filemap_map_pages
>  - 0.59% alloc_pages_vma
>   1.20% __alloc_pages_nodemask
> -5.87% 0.45%  [kernel][k] handle_mm_fault
>- 1.94% handle_mm_fault
> 1.34% filemap_map_pages
>   - 0.59% alloc_pages_vma
>1.22% __alloc_pages_nodemask
> +5.75% 0.03%  perf[.] 
> hist_entry_iter__add
> +4.46% 0.00%  [unknown]   [.] 
> -4.06% 2.74%  libc-2.23.so[.] _int_malloc
>- 1.95% 0
> 1.94% _int_malloc
> -3.20% 0.23%  perf[.] 
> iter_add_next_cumulative_entry
>- 1.49% iter_add_next_cumulative_entry
>   - 1.43% __hists__add_entry
>  2.58% 0.01%  [kernel][k] 
> return_from_SYSCALL_64
>  2.57% 2.55%  libperl.so.5.22.2   [.] Perl_fbm_instr
> -2.54% 2.51%  liblzma.so.5.2.2[.] lzma_decode
>- 2.51% lzma_decode
>  2.33% 0.00%  ld-2.23.so  [.] _dl_sysdep_start
> +2.24% 0.04%  ld-2.23.so  [.] dl_main
>  2.13% 0.03%  [kernel][k] ext4_readdir
>  2.09% 0.01%  [kernel][k] sys_newstat
>  2.08% 0.04%  [kernel][k] vfs_fstatat
>  2.07% 0.02%  [kernel][k] SYSC_newstat
>  2.02% 0.01%  [kernel][k] iterate_dir
> -1.96% 0.17%  [kernel][k] 
> __alloc_pages_nodemask
>- 1.37% __alloc_pages_nodemask
> perf: util/map.c:246: map__exit: Assertion 
> `!(!((&map->rb_node)->__rb_parent_color == (unsigned long)(&map->rb_node)))' 
> failed.

Assuming that I'd failed to test 'perf top -g' I went ahead and re-ran
this with the last version of the patch I sent out parented against the
4.8 STABLE branch.  That didn't trigger any assertion failures for me.

Is this branch that gave you merge conflicts now in perf/core or
otherwise publicly avilable?  If so, I'd be happy to try to resolve any
conflicts and re-test against it.  The copy of the patch you sent out
didn't look obviously incorrect.

Thanks,

-K

Re: [PATCH v4] of: Fix issue where code would fall through to error case.

[Frank Rowand]

On 12/01/16 22:10, Moritz Fischer wrote:
> From: Moritz Fischer 
> 
> No longer fall through into the error case that prints out
> an error if no error (err = 0) occurred.
> 
> Fixes d9181b20a83(of: Add back an error message, restructured)
> Signed-off-by: Moritz Fischer 
> Reviewed-by: Frank Rowand 
> ---
> Hi Frank, Rob
> 
> sorry for the noise before.

I'm sure I created much more noise than you did.  Thanks for
persisting.

I am confirming that this still applies for v4:

   Reviewed-by: Frank Rowand 

-Frank

> 
> Thanks,
> Moritz
> ---
>  drivers/of/resolver.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
> index 783bd09..8bf12e9 100644
> --- a/drivers/of/resolver.c
> +++ b/drivers/of/resolver.c
> @@ -298,12 +298,12 @@ int of_resolve_phandles(struct device_node *overlay)
>   if (!overlay) {
>   pr_err("null overlay\n");
>   err = -EINVAL;
> - goto err_out;
> + goto out;
>   }
>   if (!of_node_check_flag(overlay, OF_DETACHED)) {
>   pr_err("overlay not detached\n");
>   err = -EINVAL;
> - goto err_out;
> + goto out;
>   }
>  
>   phandle_delta = live_tree_max_phandle() + 1;
> @@ -315,7 +315,7 @@ int of_resolve_phandles(struct device_node *overlay)
>  
>   err = adjust_local_phandle_references(local_fixups, overlay, 
> phandle_delta);
>   if (err)
> - goto err_out;
> + goto out;
>  
>   overlay_fixups = NULL;
>  
> @@ -333,7 +333,7 @@ int of_resolve_phandles(struct device_node *overlay)
>   if (!tree_symbols) {
>   pr_err("no symbols in root of device tree.\n");
>   err = -EINVAL;
> - goto err_out;
> + goto out;
>   }
>  
>   for_each_property_of_node(overlay_fixups, prop) {
> @@ -345,12 +345,12 @@ int of_resolve_phandles(struct device_node *overlay)
>   err = of_property_read_string(tree_symbols,
>   prop->name, &refpath);
>   if (err)
> - goto err_out;
> + goto out;
>  
>   refnode = of_find_node_by_path(refpath);
>   if (!refnode) {
>   err = -ENOENT;
> - goto err_out;
> + goto out;
>   }
>  
>   phandle = refnode->phandle;
> @@ -361,9 +361,9 @@ int of_resolve_phandles(struct device_node *overlay)
>   break;
>   }
>  
> -err_out:
> - pr_err("overlay phandle fixup failed: %d\n", err);
>  out:
> + if (err)
> + pr_err("overlay phandle fixup failed: %d\n", err);
>   of_node_put(tree_symbols);
>  
>   return err;
> 

Re: [PATCH 05/12] usb: chipdata: Replace the extcon API

[Peter Chen]

On Wed, Nov 30, 2016 at 02:57:33PM +0900, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/usb/chipidea/core.c | 30 ++
>  1 file changed, 6 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 69426e644d17..a5b44963eaea 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_vbus;
>  
>   if (!IS_ERR(ext_vbus)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
> + ret = extcon_get_state(cable->edev, EXTCON_USB);
>   if (ret)
>   cable->state = true;
>   else
> @@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_id;
>  
>   if (!IS_ERR(ext_id)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
> + ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
>   if (ret)
>   cable->state = false;
>   else
> @@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   id = &ci->platdata->id_extcon;
>   id->ci = ci;
>   if (!IS_ERR(id->edev)) {
> - ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
> -&id->nb);
> + ret = devm_extcon_register_notifier(ci->dev, id->edev,
> + EXTCON_USB_HOST, &id->nb);
>   if (ret < 0) {
>   dev_err(ci->dev, "register ID failed\n");
>   return ret;
> @@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   vbus = &ci->platdata->vbus_extcon;
>   vbus->ci = ci;
>   if (!IS_ERR(vbus->edev)) {
> - ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
> -&vbus->nb);
> + ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
> + EXTCON_USB, &vbus->nb);
>   if (ret < 0) {
> - extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
> -&id->nb);
>   dev_err(ci->dev, "register VBUS failed\n");
>   return ret;
>   }
> @@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   return 0;
>  }
>  
> -static void ci_extcon_unregister(struct ci_hdrc *ci)
> -{
> - struct ci_hdrc_cable *cable;
> -
> - cable = &ci->platdata->id_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
> -&cable->nb);
> -
> - cable = &ci->platdata->vbus_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB, &cable->nb);
> -}
> -
>  static DEFINE_IDA(ci_ida);
>  
>  struct platform_device *ci_hdrc_add_device(struct device *dev,
> @@ -1053,7 +1037,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   if (!ret)
>   return 0;
>  
> - ci_extcon_unregister(ci);
>  stop:
>   ci_role_destroy(ci);
>  deinit_phy:
> @@ -1073,7 +1056,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
>   }
>  
>   dbg_remove_files(ci);
> - ci_extcon_unregister(ci);
>   ci_role_destroy(ci);
>   ci_hdrc_enter_lpm(ci, true);
>   ci_usb_phy_exit(ci);
> -- 

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH] kernel/sysctl: return -EINVAL if write invalid val to ulong type sysctl

[Yisheng Xie]

On 2016/12/1 5:33, Andrew Morton wrote:
> On Wed, 30 Nov 2016 18:30:52 +0800 Yisheng Xie  wrote:
> 
>> I tried to echo an invalid value to an unsigned long type sysctl on
>> 4.9.0-rc6:
>>linux:~# cat /proc/sys/vm/user_reserve_kbytes
>>131072
>>linux:~# echo -1 > /proc/sys/vm/user_reserve_kbytes
>>linux:~# cat /proc/sys/vm/user_reserve_kbytes
>>131072
>>
>> The echo operation got error and the value do not write to
>> user_reserve_kbytes, however, user do not know it until checking
>> the value again.
>>
>> This patch return -EINVAL when write an invalid value to unsigned
>> long type sysctl to make user know  what happened without
>> checking its value once more, just as what proc_douintvec do.
> 
> hmpf.
> 
> # echo 18446744073709551615  > /proc/sys/vm/user_reserve_kbytes   
>   
> # cat /proc/sys/vm/user_reserve_kbytes
> 18446744073709551615
> 
> I think that when taking in an unsigned long the kernel should simply
> treat -1 as 0x (or 0x).  It's natural and
> normal and everyone knows what it means?
> 
Hi Andrew,
Thank you for your reply.
Do you means it should be like this:
  # echo -1 > /proc/sys/vm/user_reserve_kbytes
  # cat /proc/sys/vm/user_reserve_kbytes
  18446744073709551615

I looks ok to me, however, I not sure whether other code in the kernel
will also use its complement if user write a negative number for an
unsigned long.  Does anyone have other opinion ?

Thanks
Yisheng Xie.

> 
> 
> 
> .
> 

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

[Greg KH]

On Fri, Dec 02, 2016 at 03:07:00AM +, Matthew Garrett wrote:
> On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:
> 
> > First off, this "secure boot support" massive patchset has not gone
> > anywhere yet, so why do this now?
> 
> Because David ended up with the short straw when distro maintainers 
> talked about this at LPC.
> 
> > Secure boot is a trust that the previous boot process is now booting
> > your image that it feels is secure (with various levels of "secure").
> > It is not about "lock things down so no one can ever touch the hardware
> > through different options, except through random logic[1] that we
> > somehow trust "more" than configuration options.
> 
> If root is able to modify the behaviour of verified code after it was 
> verified, then the value of that verification is reduced. Ensuring that 
> the code remains trustworthy is vital in a number of security use cases.

Ok, but why are you now deciding to somehow try to "classify" the types
of module parameters?  Why would you want to allow irqs to change, but
not iobase?  Or something else?  Who is going to do this "I want you and
you but not you" decision?  Why not just forbid all module parameters at
all if they are so dangerous?

> > So, what are you really trying to "block" here?  The ability for someone
> > to set an i/o port value?  why?  Why does it matter what root sets for
> > an irq?  For a dma buffer?  For anything else?  What is preventing this
> > going to "secure" somehow?
> 
> If root can tell a driver to probe for hardware at a specific address, 
> and that driver will then blindly do so, root is trivially able to 
> modify arbitrary kernel memory and disable arbitrary security features. 
> IRQ or io port attacks are much more difficult to take advantage of, but 
> I could imagine that some of them are still plausible.

Then just mark them all as "bad", why pick and choose?

> > Overall, I really don't like this, and honestly, don't like the whole
> > "secure boot" patchset either, as it is really a lot of work for
> > absolutely no gain that I can see.  Who is "asking" for this type of
> > thing, and what are their specific requirements?
> 
> Here's an example. The sysfs option to enable module signing is write 
> once. If root sets that, root can't unset it. Except there's a whole 
> bunch of ways that root *can* unset it, including kexec 
> (https://mjg59.dreamwidth.org/28746.html) and a bunch of other things 
> that are disabled by this patchset. That feature is entirely useless as 
> is. This patchset helps make it useful.

"this" patchset does nothing to disable anything, so I can't speak to
any of the other goals you might have for that code, that's not what we
are reviewing here.

> Right now, the secure boot patchset is shipped by basically every single 
> mainstream Linux distribution (and a whole bunch that are niche). Right 
> now they're having to do extra work to rebase it and ensure that fixes 
> get distributed to everyone. There's clearly demand, and Linus has been 
> clear that features that are shipped by everyone should just go into 
> mainline, so if there are *technical* objections then let's figure them 
> out and otherwise just get this stuff merged.

"this stuff" is brand new things, that no one is shipping.  And nothing
"just goes" into mainline, no matter what foolish stuff distros end up
shipping (an example, do you want the giant Xen kernel patchset that
SuSE has been dragging around for 10+ years?)

Come on, you know better than this, each patch/series/feature has to be
justifable on it's own, and this patchset, as-is, doesn't pass that test
to me, if for no other reason than it is just "marking" things that is
never then being used.

thanks,

greg k-h

Re: [PATCH v10 2/8] power: add power sequence library

[Peter Chen]

On Thu, Dec 01, 2016 at 10:57:24PM +0100, Rafael J. Wysocki wrote:
> On Tue, Nov 22, 2016 at 4:53 AM, Peter Chen  wrote:
> > On Tue, Nov 22, 2016 at 03:23:12AM +0100, Rafael J. Wysocki wrote:
> >> > @@ -0,0 +1,237 @@
> >> > +/*
> >> > + * core.c  power sequence core file
> >> > + *
> >> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> >> > + * Author: Peter Chen 
> >> > + *
> >> > + * This program is free software: you can redistribute it and/or modify
> >> > + * it under the terms of the GNU General Public License version 2  of
> >> > + * the License as published by the Free Software Foundation.
> >> > + *
> >> > + * This program is distributed in the hope that it will be useful,
> >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> > + * GNU General Public License for more details.
> >> > + *
> >> > + * You should have received a copy of the GNU General Public License
> >> > + * along with this program.  If not, see .
> >>
> >> The last paragraph is not necessary AFAICS.
> >
> > I just copy it from:
> >
> > https://www.gnu.org/licenses/gpl-howto.en.html
> >
> > If you are concerns about it, I can delete it.
> 
> It is redundant, so yes, please.

ok.

> 
> >> > +
> >> > +static struct pwrseq *pwrseq_find_available_instance(struct device_node 
> >> > *np)
> >> > +{
> >> > +   struct pwrseq *pwrseq;
> >> > +
> >> > +   list_for_each_entry(pwrseq, &pwrseq_list, node) {
> >> > +   if (pwrseq->used)
> >> > +   continue;
> >> > +
> >> > +   /* compare compatible string for pwrseq node */
> >> > +   if (of_match_node(pwrseq->pwrseq_of_match_table, np)) {
> >> > +   pwrseq->used = true;
> >> > +   return pwrseq;
> >> > +   }
> >> > +
> >> > +   /* return generic pwrseq instance */
> >> > +   if (!strcmp(pwrseq->pwrseq_of_match_table->compatible,
> >> > +   "generic")) {
> >> > +   pr_debug("using generic pwrseq instance for 
> >> > %s\n",
> >> > +   np->full_name);
> >> > +   pwrseq->used = true;
> >> > +   return pwrseq;
> >> > +   }
> >> > +   }
> >> > +   pr_warn("Can't find any pwrseq instances for %s\n", 
> >> > np->full_name);
> >>
> >> pr_debug() ?
> >
> > If there is no pwrseq instance for that node, the power sequence on routine 
> > will
> > return fail, so I think an warning message is useful for user.
> 
> Useful in what way?  How is the user supposed to know what happened
> from this message?

Ok, I will change it to debug message.

> >> > + */
> >> > +struct pwrseq *of_pwrseq_on(struct device_node *np)
> >> > +{
> >> > +   struct pwrseq *pwrseq;
> >> > +   int ret;
> >> > +
> >> > +   pwrseq = pwrseq_find_available_instance(np);
> >>
> >> What does guarantee the integrity of ths list at this point?
> >
> > Once the use selects the specific pwrseq library, the library will
> > create an empty one instance during the initialization, and it
> > will be called at postcore_initcall, the device driver has not
> > probed yet.
> 
> Which doesn't matter really, because the list is global and some other
> driver using it might have been probed already.
> 
> You have a mutex here and it is used for add/remove.  Why isn't it
> used for list browsing?

I will add mutex for it, thanks.

> >
> >> > + */
> >> > +int of_pwrseq_on_list(struct device_node *np, struct list_head *head)
> >> > +{
> >> > +   struct pwrseq *pwrseq;
> >> > +   struct pwrseq_list_per_dev *pwrseq_list_node;
> >> > +
> >> > +   pwrseq = of_pwrseq_on(np);
> >> > +   if (IS_ERR(pwrseq))
> >> > +   return PTR_ERR(pwrseq);
> >> > +
> >> > +   pwrseq_list_node = kzalloc(sizeof(*pwrseq_list_node), 
> >> > GFP_KERNEL);
> >>
> >> Why don't you allocate memory before turning the power sequence on?
> >>
> >
> > This list is only for power sequence on instance, if I allocate memory 
> > before
> > power sequence on, I need to free it if power sequence on is failed.
> 
> So why is that a problem?
> 

Not any problems, I will follow your comments.

> >> > +   if (!pwrseq_list_node) {
> >> > +   of_pwrseq_off(pwrseq);
> >> > +   return -ENOMEM;
> >> > +   }
> >> > +   pwrseq_list_node->pwrseq = pwrseq;
> >> > +   list_add(&pwrseq_list_node->list, head);
> >> > +
> >> > +   return 0;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(of_pwrseq_on_list);
> >>
> >> So the caller is supposed to provide a list head of the list to put
> >> the power sequence object into on success, right?
> >
> > Yes
> >
> >>
> >> Can you explain to me what the idea here is, please?
> >>
> >
> > Taking USB devices as an example, there is one power sequence on list
> > per bus, and there are several U

Re: [PATCH 02/15] hyperv: Add a function to detect hv_device

[Greg KH]

On Fri, Dec 02, 2016 at 06:02:29AM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, December 1, 2016 12:36 PM
> > To: KY Srinivasan 
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> > jasow...@redhat.com; leann.ogasaw...@canonical.com; Haiyang Zhang
> > 
> > Subject: Re: [PATCH 02/15] hyperv: Add a function to detect hv_device

Ugh, please fix your email client...

> > 
> > On Thu, Dec 01, 2016 at 09:28:39AM -0800, k...@exchange.microsoft.com
> > wrote:
> > > From: Haiyang Zhang 
> > >
> > > Signed-off-by: Haiyang Zhang 
> > > Signed-off-by: K. Y. Srinivasan 
> > > ---
> > >  drivers/hv/vmbus_drv.c |6 ++
> > >  include/linux/hyperv.h |2 ++
> > >  2 files changed, 8 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > > index 0276d2e..1730ac0 100644
> > > --- a/drivers/hv/vmbus_drv.c
> > > +++ b/drivers/hv/vmbus_drv.c
> > > @@ -692,6 +692,12 @@ struct onmessage_work_context {
> > >   struct hv_message msg;
> > >  };
> > >
> > > +bool device_is_hyperv(struct device *dev)
> > > +{
> > > + return dev->release == vmbus_device_release;
> > > +}
> > > +EXPORT_SYMBOL_GPL(device_is_hyperv);
> > 
> > Wait, eek, no!  That's NOT how you determine a device type, if you
> > really even ever need to do that.
> > 
> > Why are you needing this?  You should always "just know" what type of
> > device a struct device * is, that's what we rely on in the driver model.
> > Otherwise things get messy very very quickly.
> > 
> > Sorry, I can't take this without a ton of justification, and even then,
> > you need to do this correctly (and no, I'm not going to tell you how to
> > do that as I don't like it being done...)
> > 
> Greg,
> 
> To support SR-IOV, netvsc registers for all netdev events. For netdev events 
> related to the
> VF interface, we need to do some special processing. And so, we need to 
> determine
> if the device that is generating the netdev event is Hyper-V device or not
> (passed through the PCI pass through driver). Is this justification 
> sufficient.
> As you have observed, currently there is no user of this API and that is 
> because netvsc
> will be the user. To avoid cross-tree dependency, we wanted to get this 
> functionality in first
> before submitting the netvsc patch.

See, you do have some text for a changelog!

{grumble...}

No, I don't think this is a good justification, where are you going to
put this "check" into the networking stack?  Your driver should only be
binding to devices of this "type" anyway, so by that logic, it already
"knows" that the device is of this type.

In other words, why do you need this and PCI or USB doesn't?  Why is
hyperv "special"?

greg k-h

Re: [PATCH] mmc: sdhci-of-at91: remove bogus MMC_SDHCI_IO_ACCESSORS select

[Ludovic Desroches]

On Thu, Dec 01, 2016 at 01:05:46PM +0900, Masahiro Yamada wrote:
> I see no override of read/write callbacks in sdhci-of-at91.c.
> 
> Signed-off-by: Masahiro Yamada 
Acked-by: Ludovic Desroches 

Thanks

> ---
> 
> BTW, this config may not be so useful in recent multi-platforms.
> Perhaps, is it better to remove this config entirely instead of
> the AT91 fix only.
> 
> 
>  drivers/mmc/host/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 39f6f96..8ac1640 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -135,7 +135,6 @@ config MMC_SDHCI_OF_AT91
>   tristate "SDHCI OF support for the Atmel SDMMC controller"
>   depends on MMC_SDHCI_PLTFM
>   depends on OF
> - select MMC_SDHCI_IO_ACCESSORS
>   help
> This selects the Atmel SDMMC driver
>  
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-acpi] [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version

[Jon Masters]

On 12/02/2016 01:42 AM, Duc Dang wrote:
> On Thu, Dec 1, 2016 at 9:50 PM, Jon Masters  wrote:
>> On 11/30/2016 07:28 PM, Bjorn Helgaas wrote:
>>
>>> I'm hoping to end up with something like this:
>>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469
>>
>> The following build warnings happen using your branch on RHELSA7.3:
>>
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>>   THUNDER_PEM_QUIRK(2,  0), /* off-chip devices */
>>   ^
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[44].cfgres.start’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[44].cfgres.end’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[45].cfgres.start’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[45].cfgres.end’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[46].cfgres.start’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[46].cfgres.end’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[47].cfgres.start’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[47].cfgres.end’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[48].cfgres.start’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[48].cfgres.end’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[49].cfgres.start’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
>> [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
>> ‘mcfg_quirks[49].cfgres.end’) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type 
>> [enabled by default]
>>   THUNDER_PEM_QUIRK(2,  1), /* off-chip devices */
>>   ^
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a 
>> constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for 
>> ‘mcfg_quirks[50].cfgres.start’) [enabled by default]
>> drivers/acpi/

Re: [Linaro-acpi] [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version

[Duc Dang]

On Thu, Dec 1, 2016 at 9:50 PM, Jon Masters  wrote:
> On 11/30/2016 07:28 PM, Bjorn Helgaas wrote:
>
>> I'm hoping to end up with something like this:
>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469
>
> The following build warnings happen using your branch on RHELSA7.3:
>
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
>   THUNDER_PEM_QUIRK(2,  0), /* off-chip devices */
>   ^
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[44].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[44].cfgres.end’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[45].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[45].cfgres.end’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[46].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[46].cfgres.end’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[47].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[47].cfgres.end’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[48].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[48].cfgres.end’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[49].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
> ‘mcfg_quirks[49].cfgres.end’) [enabled by default]
> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type 
> [enabled by default]
>   THUNDER_PEM_QUIRK(2,  1), /* off-chip devices */
>   ^
> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant 
> expression [enabled by default]
> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for 
> ‘mcfg_quirks[50].cfgres.start’) [enabled by default]
> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type 
> [enabled by default]
> drivers/acpi/pci_mcfg.c:102:2: warning: initi

Re: drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

[Vlastimil Babka]

On 12/01/2016 10:02 PM, Michal Nazarewicz wrote:

On Thu, Dec 01 2016, Michal Hocko wrote:

I am not familiar with this code so I cannot really argue but a quick
look at rmem_cma_setup doesn't suggest any speicific placing or
anything...


early_cma parses ‘cma’ command line argument which can specify where
exactly the default CMA area is to be located.  Furthermore, CMA areas
can be assigned per-device (via the Device Tree IIRC).


OK, but the context of this bug report is a generic cma pool and generic 
dma alloc, which tries cma first and then fallback to 
alloc_pages_node(). If a device really requires specific placing as you 
suggest, then it probably uses a different allocation interface, 
otherwise there would be some flag to disallow the alloc_pages_node() 
fallback?

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Jon Masters]

Bjorn,

Although I think the below still applies (that we need to leave that
Memory32Fixed for existing deployments, and this is going to result
in /proc/iomem polution), I've done some more reading of your ecam
tree and the implementation of acpi_get_rc_resources you mentioned,
and in particular how the PNP0C02 devices actually get wired up.

I would like to be able to boot upstream on existing shipping and
deployed machines that are in the field (not to mention our labs), but
there's no reason we can't *also* get APM to add a new vendor specific
PNP0C02 to the ACPI namespace in future firmware updates (for at least
their own Mustang reference boards) matching segment to CSR, as in the
case of the HiSi patches. That might then allow for some later
preference to use that for the CSR rather than getting it from the RC
device. Still, it would be ideal to boot on machines that are shipping
from HPE and others at this moment, so I am still hopeful you'll
at least allow the approach from Duc's v4 for now (4.10).

Another nasty option for later consideration could then be having
the kernel fake up any missing PNP0C02 on existing machines, but
it would need special knowledge of the platform to generate that
so as to handle the problem Mark flagged earlier (segment vs
controller mismatch on some platforms). That could be done with a
DMI quirk that matched on a specific (e.g. HPE) machine. It would
only be needed on "broken" existing machines, and could be added
post-4.10 to clean this up if you really want to do that.

That's all very nasty...

Jon.

On 12/01/2016 11:08 PM, Jon Masters wrote:
> Hi Bjorn, Duc, Mark,
> 
> I switched my brain to the on mode and went and read some specs, and a few
> tables, so here's my 2 cents on this...
> 
> On 12/01/2016 06:22 PM, Duc Dang wrote:
>> On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas  wrote:
>>> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
> 
>> The SoC provide some number of RC bridges, each with a different base
>> for some mmio registers. Even if segment is legitimate in MCFG, there
>> is still a problem if a platform doesn't use the segment ordering
>> implied by the code. But the PNP0A03 _CRS does have this base address
>> as the first memory resource, so we could get it from there and not
>> have hard-coded addresses and implied ording in the quirk code.
>
> I'm confused.  Doesn't the current code treat every item in PNP0A03
> _CRS as a window?  Do you mean the first resource is handled
> differently somehow?  The Consumer/Producer bit could allow us to do
> this by marking the RC MMIO space as "Consumer", but I didn't think
> that strategy was quite working yet.
> 
> Let's see if I summarized this correctly...
> 
> 1. The MMIO registers for the host bridge itself need to be described
>somewhere, especially if we need to find those in a quirk and poke
>them. Since those registers are very much part of the bridge device,
>it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
> 
> 2. The address space covering these registers MUST be described as a
>ResourceConsumer in order to avoid accidentally exposing them as
>available for use by downstream devices on the PCI bus.
> 
> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
>This is a macro that doesn't have the notion of a producer or consumer.
>HOWEVER various interpretations seem to be that this could/should
>default to being interpreted as a consumed region.
> 
> 4. At one point, a regression was added to the kernel:
> 
>63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
>host bridge itself")
> 
>Which lead to a series on conversations about what should happen
>for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
> 
> 5. This resulted in the following commit reverting point 4:
> 
>2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
>available on PCI bus")
> 
>Which also stated that:
> 
>"This solution will also ease the way to consolidate ACPI PCI host
> bridge common code from x86, ia64 and ARM64"
> 
> End of summary.
> 
> So it seems that generally there is an aversion to having bridge resources
> be described in this manner and you would like to require that they be
> described e.g. using QWordMemory with a ResourceConsumer type?
> 
> BUT if we were to do that, it would break existing shipping systems since
> there are quirks out there that use this form to find the base CSR:
> 
>if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> fixed32 = &acpi_res->data.fixed_memory32;
> port->csr_base = ioremap(fixed32->address,
>  fixed32->address_length);
> return AE_CTRL_TERMINATE;
> }
> 
> That's what's shipping in at least RHEL(SA) today, and probably in other
> distros. So if we get vendors to take that out,

RE: [PATCH 06/15] hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels()

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, December 1, 2016 12:37 PM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 06/15] hv: acquire vmbus_connection.channel_mutex in
> vmbus_free_channels()
> 
> On Thu, Dec 01, 2016 at 09:28:43AM -0800, k...@exchange.microsoft.com
> wrote:
> > From: Vitaly Kuznetsov 
> >
> > "kernel BUG at drivers/hv/channel_mgmt.c:350!" is observed when
> hv_vmbus
> > module is unloaded. BUG_ON() was introduced in commit 85d9aa705184
> > ("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()") as
> > vmbus_free_channels() codepath was apparently forgotten.
> >
> > Fixes: 85d9aa705184 ("Drivers: hv: vmbus: add an API
> vmbus_hvsock_device_unregister()")
> > Signed-off-by: Vitaly Kuznetsov 
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/hv/channel_mgmt.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> Shouldn't this go to stable kernels?

Yes; I will resubmit.

Regards,

K. Y

Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted

[Vlastimil Babka]

On 12/02/2016 04:47 AM, Hillf Danton wrote:

On Friday, December 02, 2016 8:23 AM Mel Gorman wrote:

Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
defer debugging checks of pages allocated from the PCP") will allow the
per-cpu list counter to be out of sync with the per-cpu list contents
if a struct page is corrupted. This patch keeps the accounting in sync.

Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from 
the PCP")
Signed-off-by: Mel Gorman 
cc: sta...@vger.kernel.org [4.7+]


Acked-by: Vlastimil Babka 


---
 mm/page_alloc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6de9440e3ae2..777ed59570df 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2192,7 +2192,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
unsigned long count, struct list_head *list,
int migratetype, bool cold)
 {
-   int i;
+   int i, alloced = 0;

spin_lock(&zone->lock);
for (i = 0; i < count; ++i) {
@@ -2217,13 +2217,14 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
else
list_add_tail(&page->lru, list);
list = &page->lru;
+   alloced++;
if (is_migrate_cma(get_pcppage_migratetype(page)))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
  -(1 << order));
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));


Now i is a pure index, yes?


No, even if a page fails the check_pcp_refill() check and is not 
"allocated", it is also no longer a free page, so it's correct to 
subtract it from NR_FREE_PAGES.



spin_unlock(&zone->lock);
-   return i;
+   return alloced;
 }

 #ifdef CONFIG_NUMA
--
2.10.2

[PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

[Juergen Gross]

Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.

Suggested-by: Jan Beulich 
Signed-off-by: Juergen Gross 
---
Aargh! Need more coffee! Resend with corrected mail address for Martin Petersen
---
 drivers/scsi/xen-scsifront.c | 190 +++
 1 file changed, 84 insertions(+), 106 deletions(-)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index c01316c..9aa1fe1 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -79,10 +79,13 @@
 struct vscsifrnt_shadow {
/* command between backend and frontend */
unsigned char act;
+   uint8_t nr_segments;
uint16_t rqid;
+   uint16_t ref_rqid;
 
unsigned int nr_grants; /* number of grants in gref[] */
struct scsiif_request_segment *sg;  /* scatter/gather elements */
+   struct scsiif_request_segment seg[VSCSIIF_SG_TABLESIZE];
 
/* Do reset or abort function. */
wait_queue_head_t wq_reset; /* reset work queue   */
@@ -172,68 +175,90 @@ static void scsifront_put_rqid(struct vscsifrnt_info 
*info, uint32_t id)
scsifront_wake_up(info);
 }
 
-static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info)
+static int scsifront_do_request(struct vscsifrnt_info *info,
+   struct vscsifrnt_shadow *shadow)
 {
struct vscsiif_front_ring *ring = &(info->ring);
struct vscsiif_request *ring_req;
+   struct scsi_cmnd *sc = shadow->sc;
uint32_t id;
+   int i, notify;
+
+   if (RING_FULL(&info->ring))
+   return -EBUSY;
 
id = scsifront_get_rqid(info);  /* use id in response */
if (id >= VSCSIIF_MAX_REQS)
-   return NULL;
+   return -EBUSY;
+
+   info->shadow[id] = shadow;
+   shadow->rqid = id;
 
ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
-
ring->req_prod_pvt++;
 
-   ring_req->rqid = (uint16_t)id;
+   ring_req->rqid= id;
+   ring_req->act = shadow->act;
+   ring_req->ref_rqid= shadow->ref_rqid;
+   ring_req->nr_segments = shadow->nr_segments;
 
-   return ring_req;
-}
+   ring_req->id  = sc->device->id;
+   ring_req->lun = sc->device->lun;
+   ring_req->channel = sc->device->channel;
+   ring_req->cmd_len = sc->cmd_len;
 
-static void scsifront_do_request(struct vscsifrnt_info *info)
-{
-   struct vscsiif_front_ring *ring = &(info->ring);
-   int notify;
+   BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
+
+   memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+
+   ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+   ring_req->timeout_per_command = sc->request->timeout / HZ;
+
+   for (i = 0; i < (shadow->nr_segments & ~VSCSIIF_SG_GRANT); i++)
+   ring_req->seg[i] = shadow->seg[i];
 
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
if (notify)
notify_remote_via_irq(info->irq);
+
+   return 0;
 }
 
-static void scsifront_gnttab_done(struct vscsifrnt_info *info, uint32_t id)
+static void scsifront_gnttab_done(struct vscsifrnt_info *info,
+ struct vscsifrnt_shadow *shadow)
 {
-   struct vscsifrnt_shadow *s = info->shadow[id];
int i;
 
-   if (s->sc->sc_data_direction == DMA_NONE)
+   if (shadow->sc->sc_data_direction == DMA_NONE)
return;
 
-   for (i = 0; i < s->nr_grants; i++) {
-   if (unlikely(gnttab_query_foreign_access(s->gref[i]) != 0)) {
+   for (i = 0; i < shadow->nr_grants; i++) {
+   if (unlikely(gnttab_query_foreign_access(shadow->gref[i]))) {
shost_printk(KERN_ALERT, info->host, KBUILD_MODNAME
 "grant still in use by backend\n");
BUG();
}
-   gnttab_end_foreign_access(s->gref[i], 0, 0UL);
+   gnttab_end_foreign_access(shadow->gref[i], 0, 0UL);
}
 
-   kfree(s->sg);
+   kfree(shadow->sg);
 }
 
 static void scsifront_cdb_cmd_done(struct vscsifrnt_info *info,
   struct vscsiif_response *ring_rsp)
 {
+   struct vscsifrnt_shadow *shadow;
struct scsi_cmnd *sc;
uint32_t id;
uint8_t sense_len;
 
id = ring_rsp->rqid;
-   sc = info->shadow[id]->sc;
+   shadow = info->shadow[id];
+   sc = shadow->sc;
 
BUG_ON(sc == NULL);
 
-   scsifront_gnttab_done(info, id);
+   scsifront_gnttab_done(info, shadow);
scsifront_put_rqid(info, id);
 
sc->result = ring_rsp->rslt;
@@ -366,7 +391,6 @@ static void scsifront_finish_all(struct vscsifrnt_info 

[PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

[Juergen Gross]

Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.

Suggested-by: Jan Beulich 
Signed-off-by: Juergen Gross 
---
Resend with corrected mail address for Martin Peter
---
 drivers/scsi/xen-scsifront.c | 190 +++
 1 file changed, 84 insertions(+), 106 deletions(-)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index c01316c..9aa1fe1 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -79,10 +79,13 @@
 struct vscsifrnt_shadow {
/* command between backend and frontend */
unsigned char act;
+   uint8_t nr_segments;
uint16_t rqid;
+   uint16_t ref_rqid;
 
unsigned int nr_grants; /* number of grants in gref[] */
struct scsiif_request_segment *sg;  /* scatter/gather elements */
+   struct scsiif_request_segment seg[VSCSIIF_SG_TABLESIZE];
 
/* Do reset or abort function. */
wait_queue_head_t wq_reset; /* reset work queue   */
@@ -172,68 +175,90 @@ static void scsifront_put_rqid(struct vscsifrnt_info 
*info, uint32_t id)
scsifront_wake_up(info);
 }
 
-static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info)
+static int scsifront_do_request(struct vscsifrnt_info *info,
+   struct vscsifrnt_shadow *shadow)
 {
struct vscsiif_front_ring *ring = &(info->ring);
struct vscsiif_request *ring_req;
+   struct scsi_cmnd *sc = shadow->sc;
uint32_t id;
+   int i, notify;
+
+   if (RING_FULL(&info->ring))
+   return -EBUSY;
 
id = scsifront_get_rqid(info);  /* use id in response */
if (id >= VSCSIIF_MAX_REQS)
-   return NULL;
+   return -EBUSY;
+
+   info->shadow[id] = shadow;
+   shadow->rqid = id;
 
ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
-
ring->req_prod_pvt++;
 
-   ring_req->rqid = (uint16_t)id;
+   ring_req->rqid= id;
+   ring_req->act = shadow->act;
+   ring_req->ref_rqid= shadow->ref_rqid;
+   ring_req->nr_segments = shadow->nr_segments;
 
-   return ring_req;
-}
+   ring_req->id  = sc->device->id;
+   ring_req->lun = sc->device->lun;
+   ring_req->channel = sc->device->channel;
+   ring_req->cmd_len = sc->cmd_len;
 
-static void scsifront_do_request(struct vscsifrnt_info *info)
-{
-   struct vscsiif_front_ring *ring = &(info->ring);
-   int notify;
+   BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
+
+   memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+
+   ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+   ring_req->timeout_per_command = sc->request->timeout / HZ;
+
+   for (i = 0; i < (shadow->nr_segments & ~VSCSIIF_SG_GRANT); i++)
+   ring_req->seg[i] = shadow->seg[i];
 
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
if (notify)
notify_remote_via_irq(info->irq);
+
+   return 0;
 }
 
-static void scsifront_gnttab_done(struct vscsifrnt_info *info, uint32_t id)
+static void scsifront_gnttab_done(struct vscsifrnt_info *info,
+ struct vscsifrnt_shadow *shadow)
 {
-   struct vscsifrnt_shadow *s = info->shadow[id];
int i;
 
-   if (s->sc->sc_data_direction == DMA_NONE)
+   if (shadow->sc->sc_data_direction == DMA_NONE)
return;
 
-   for (i = 0; i < s->nr_grants; i++) {
-   if (unlikely(gnttab_query_foreign_access(s->gref[i]) != 0)) {
+   for (i = 0; i < shadow->nr_grants; i++) {
+   if (unlikely(gnttab_query_foreign_access(shadow->gref[i]))) {
shost_printk(KERN_ALERT, info->host, KBUILD_MODNAME
 "grant still in use by backend\n");
BUG();
}
-   gnttab_end_foreign_access(s->gref[i], 0, 0UL);
+   gnttab_end_foreign_access(shadow->gref[i], 0, 0UL);
}
 
-   kfree(s->sg);
+   kfree(shadow->sg);
 }
 
 static void scsifront_cdb_cmd_done(struct vscsifrnt_info *info,
   struct vscsiif_response *ring_rsp)
 {
+   struct vscsifrnt_shadow *shadow;
struct scsi_cmnd *sc;
uint32_t id;
uint8_t sense_len;
 
id = ring_rsp->rqid;
-   sc = info->shadow[id]->sc;
+   shadow = info->shadow[id];
+   sc = shadow->sc;
 
BUG_ON(sc == NULL);
 
-   scsifront_gnttab_done(info, id);
+   scsifront_gnttab_done(info, shadow);
scsifront_put_rqid(info, id);
 
sc->result = ring_rsp->rslt;
@@ -366,7 +391,6 @@ static void scsifront_finish_all(struct vscsifrnt_info 
*info)
 
 static int map_dat

[PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

[Juergen Gross]

Instead of requesting a new slot on the ring to the backend early, do
so only after all has been setup for the request to be sent. This
makes error handling easier as we don't need to undo the request id
allocation and ring slot allocation.

Suggested-by: Jan Beulich 
Signed-off-by: Juergen Gross 
---
 drivers/scsi/xen-scsifront.c | 190 +++
 1 file changed, 84 insertions(+), 106 deletions(-)

diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index c01316c..9aa1fe1 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -79,10 +79,13 @@
 struct vscsifrnt_shadow {
/* command between backend and frontend */
unsigned char act;
+   uint8_t nr_segments;
uint16_t rqid;
+   uint16_t ref_rqid;
 
unsigned int nr_grants; /* number of grants in gref[] */
struct scsiif_request_segment *sg;  /* scatter/gather elements */
+   struct scsiif_request_segment seg[VSCSIIF_SG_TABLESIZE];
 
/* Do reset or abort function. */
wait_queue_head_t wq_reset; /* reset work queue   */
@@ -172,68 +175,90 @@ static void scsifront_put_rqid(struct vscsifrnt_info 
*info, uint32_t id)
scsifront_wake_up(info);
 }
 
-static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info)
+static int scsifront_do_request(struct vscsifrnt_info *info,
+   struct vscsifrnt_shadow *shadow)
 {
struct vscsiif_front_ring *ring = &(info->ring);
struct vscsiif_request *ring_req;
+   struct scsi_cmnd *sc = shadow->sc;
uint32_t id;
+   int i, notify;
+
+   if (RING_FULL(&info->ring))
+   return -EBUSY;
 
id = scsifront_get_rqid(info);  /* use id in response */
if (id >= VSCSIIF_MAX_REQS)
-   return NULL;
+   return -EBUSY;
+
+   info->shadow[id] = shadow;
+   shadow->rqid = id;
 
ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
-
ring->req_prod_pvt++;
 
-   ring_req->rqid = (uint16_t)id;
+   ring_req->rqid= id;
+   ring_req->act = shadow->act;
+   ring_req->ref_rqid= shadow->ref_rqid;
+   ring_req->nr_segments = shadow->nr_segments;
 
-   return ring_req;
-}
+   ring_req->id  = sc->device->id;
+   ring_req->lun = sc->device->lun;
+   ring_req->channel = sc->device->channel;
+   ring_req->cmd_len = sc->cmd_len;
 
-static void scsifront_do_request(struct vscsifrnt_info *info)
-{
-   struct vscsiif_front_ring *ring = &(info->ring);
-   int notify;
+   BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
+
+   memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+
+   ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+   ring_req->timeout_per_command = sc->request->timeout / HZ;
+
+   for (i = 0; i < (shadow->nr_segments & ~VSCSIIF_SG_GRANT); i++)
+   ring_req->seg[i] = shadow->seg[i];
 
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
if (notify)
notify_remote_via_irq(info->irq);
+
+   return 0;
 }
 
-static void scsifront_gnttab_done(struct vscsifrnt_info *info, uint32_t id)
+static void scsifront_gnttab_done(struct vscsifrnt_info *info,
+ struct vscsifrnt_shadow *shadow)
 {
-   struct vscsifrnt_shadow *s = info->shadow[id];
int i;
 
-   if (s->sc->sc_data_direction == DMA_NONE)
+   if (shadow->sc->sc_data_direction == DMA_NONE)
return;
 
-   for (i = 0; i < s->nr_grants; i++) {
-   if (unlikely(gnttab_query_foreign_access(s->gref[i]) != 0)) {
+   for (i = 0; i < shadow->nr_grants; i++) {
+   if (unlikely(gnttab_query_foreign_access(shadow->gref[i]))) {
shost_printk(KERN_ALERT, info->host, KBUILD_MODNAME
 "grant still in use by backend\n");
BUG();
}
-   gnttab_end_foreign_access(s->gref[i], 0, 0UL);
+   gnttab_end_foreign_access(shadow->gref[i], 0, 0UL);
}
 
-   kfree(s->sg);
+   kfree(shadow->sg);
 }
 
 static void scsifront_cdb_cmd_done(struct vscsifrnt_info *info,
   struct vscsiif_response *ring_rsp)
 {
+   struct vscsifrnt_shadow *shadow;
struct scsi_cmnd *sc;
uint32_t id;
uint8_t sense_len;
 
id = ring_rsp->rqid;
-   sc = info->shadow[id]->sc;
+   shadow = info->shadow[id];
+   sc = shadow->sc;
 
BUG_ON(sc == NULL);
 
-   scsifront_gnttab_done(info, id);
+   scsifront_gnttab_done(info, shadow);
scsifront_put_rqid(info, id);
 
sc->result = ring_rsp->rslt;
@@ -366,7 +391,6 @@ static void scsifront_finish_all(struct vscsifrnt_info 
*info)
 
 static int map_data_for_request(struct vscsifrnt_info *info,
 

[PATCH v4] of: Fix issue where code would fall through to error case.

[Moritz Fischer]

From: Moritz Fischer 

No longer fall through into the error case that prints out
an error if no error (err = 0) occurred.

Fixes d9181b20a83(of: Add back an error message, restructured)
Signed-off-by: Moritz Fischer 
Reviewed-by: Frank Rowand 
---
Hi Frank, Rob

sorry for the noise before.

Thanks,
Moritz
---
 drivers/of/resolver.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 783bd09..8bf12e9 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -298,12 +298,12 @@ int of_resolve_phandles(struct device_node *overlay)
if (!overlay) {
pr_err("null overlay\n");
err = -EINVAL;
-   goto err_out;
+   goto out;
}
if (!of_node_check_flag(overlay, OF_DETACHED)) {
pr_err("overlay not detached\n");
err = -EINVAL;
-   goto err_out;
+   goto out;
}
 
phandle_delta = live_tree_max_phandle() + 1;
@@ -315,7 +315,7 @@ int of_resolve_phandles(struct device_node *overlay)
 
err = adjust_local_phandle_references(local_fixups, overlay, 
phandle_delta);
if (err)
-   goto err_out;
+   goto out;
 
overlay_fixups = NULL;
 
@@ -333,7 +333,7 @@ int of_resolve_phandles(struct device_node *overlay)
if (!tree_symbols) {
pr_err("no symbols in root of device tree.\n");
err = -EINVAL;
-   goto err_out;
+   goto out;
}
 
for_each_property_of_node(overlay_fixups, prop) {
@@ -345,12 +345,12 @@ int of_resolve_phandles(struct device_node *overlay)
err = of_property_read_string(tree_symbols,
prop->name, &refpath);
if (err)
-   goto err_out;
+   goto out;
 
refnode = of_find_node_by_path(refpath);
if (!refnode) {
err = -ENOENT;
-   goto err_out;
+   goto out;
}
 
phandle = refnode->phandle;
@@ -361,9 +361,9 @@ int of_resolve_phandles(struct device_node *overlay)
break;
}
 
-err_out:
-   pr_err("overlay phandle fixup failed: %d\n", err);
 out:
+   if (err)
+   pr_err("overlay phandle fixup failed: %d\n", err);
of_node_put(tree_symbols);
 
return err;
-- 
2.7.4

Re: [PATCH v2] arm64: dts: zx: support cpu-freq for zx296718

[Viresh Kumar]

On 02-12-16, 13:58, Baoyou Xie wrote:
> + Viresh, the author of the bindings.
> 
> On 2 December 2016 at 13:52, Baoyou Xie  wrote:
> 
> > This patch adds the CPU clock phandle in CPU's node
> > and uses operating-points-v2 to register operating points.
> >
> > So it can be used by cpufreq-dt driver.
> >
> > Signed-off-by: Baoyou Xie 
> > ---
> >  arch/arm64/boot/dts/zte/zx296718.dtsi | 39 ++
> > +
> >  1 file changed, 39 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

RE: [PATCH 02/15] hyperv: Add a function to detect hv_device

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, December 1, 2016 12:36 PM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; leann.ogasaw...@canonical.com; Haiyang Zhang
> 
> Subject: Re: [PATCH 02/15] hyperv: Add a function to detect hv_device
> 
> On Thu, Dec 01, 2016 at 09:28:39AM -0800, k...@exchange.microsoft.com
> wrote:
> > From: Haiyang Zhang 
> >
> > Signed-off-by: Haiyang Zhang 
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/hv/vmbus_drv.c |6 ++
> >  include/linux/hyperv.h |2 ++
> >  2 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > index 0276d2e..1730ac0 100644
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -692,6 +692,12 @@ struct onmessage_work_context {
> > struct hv_message msg;
> >  };
> >
> > +bool device_is_hyperv(struct device *dev)
> > +{
> > +   return dev->release == vmbus_device_release;
> > +}
> > +EXPORT_SYMBOL_GPL(device_is_hyperv);
> 
> Wait, eek, no!  That's NOT how you determine a device type, if you
> really even ever need to do that.
> 
> Why are you needing this?  You should always "just know" what type of
> device a struct device * is, that's what we rely on in the driver model.
> Otherwise things get messy very very quickly.
> 
> Sorry, I can't take this without a ton of justification, and even then,
> you need to do this correctly (and no, I'm not going to tell you how to
> do that as I don't like it being done...)
> 
Greg,

To support SR-IOV, netvsc registers for all netdev events. For netdev events 
related to the
VF interface, we need to do some special processing. And so, we need to 
determine
if the device that is generating the netdev event is Hyper-V device or not
(passed through the PCI pass through driver). Is this justification sufficient.
As you have observed, currently there is no user of this API and that is 
because netvsc
will be the user. To avoid cross-tree dependency, we wanted to get this 
functionality in first
before submitting the netvsc patch.

Regards,

K. Y  

> greg k-h

Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5

[Joonsoo Kim]

Hello, Mel.

I didn't follow up previous discussion so what I raise here would be
duplicated. Please let me know the link if it is answered before.

On Fri, Dec 02, 2016 at 12:22:44AM +, Mel Gorman wrote:
> Changelog since v4
> o Avoid pcp->count getting out of sync if struct page gets corrupted
> 
> Changelog since v3
> o Allow high-order atomic allocations to use reserves
> 
> Changelog since v2
> o Correct initialisation to avoid -Woverflow warning
> 
> SLUB has been the default small kernel object allocator for quite some time
> but it is not universally used due to performance concerns and a reliance
> on high-order pages. The high-order concerns has two major components --
> high-order pages are not always available and high-order page allocations
> potentially contend on the zone->lock. This patch addresses some concerns
> about the zone lock contention by extending the per-cpu page allocator to
> cache high-order pages. The patch makes the following modifications
> 
> o New per-cpu lists are added to cache the high-order pages. This increases
>   the cache footprint of the per-cpu allocator and overall usage but for
>   some workloads, this will be offset by reduced contention on zone->lock.
>   The first MIGRATE_PCPTYPE entries in the list are per-migratetype. The
>   remaining are high-order caches up to and including
>   PAGE_ALLOC_COSTLY_ORDER
> 
> o pcp accounting during free is now confined to free_pcppages_bulk as it's
>   impossible for the caller to know exactly how many pages were freed.
>   Due to the high-order caches, the number of pages drained for a request
>   is no longer precise.
> 
> o The high watermark for per-cpu pages is increased to reduce the probability
>   that a single refill causes a drain on the next free.
> 
> The benefit depends on both the workload and the machine as ultimately the
> determining factor is whether cache line bounces on zone->lock or contention
> is a problem. The patch was tested on a variety of workloads and machines,
> some of which are reported here.
> 
> This is the result from netperf running UDP_STREAM on localhost. It was
> selected on the basis that it is slab-intensive and has been the subject
> of previous SLAB vs SLUB comparisons with the caveat that this is not
> testing between two physical hosts.
> 
> 2-socket modern machine
> 4.9.0-rc5 4.9.0-rc5
>   vanilla hopcpu-v5
> Hmeansend-64 178.38 (  0.00%)  260.54 ( 46.06%)
> Hmeansend-128351.49 (  0.00%)  518.56 ( 47.53%)
> Hmeansend-256671.23 (  0.00%) 1005.72 ( 49.83%)
> Hmeansend-1024  2663.60 (  0.00%) 3880.54 ( 45.69%)
> Hmeansend-2048  5126.53 (  0.00%) 7545.38 ( 47.18%)
> Hmeansend-3312  7949.99 (  0.00%)11324.34 ( 42.44%)
> Hmeansend-4096  9433.56 (  0.00%)12818.85 ( 35.89%)
> Hmeansend-8192 15940.64 (  0.00%)21404.98 ( 34.28%)
> Hmeansend-1638426699.54 (  0.00%)32810.08 ( 22.89%)
> Hmeanrecv-64 178.38 (  0.00%)  260.52 ( 46.05%)
> Hmeanrecv-128351.49 (  0.00%)  518.53 ( 47.53%)
> Hmeanrecv-256671.20 (  0.00%) 1005.42 ( 49.79%)
> Hmeanrecv-1024  2663.45 (  0.00%) 3879.75 ( 45.67%)
> Hmeanrecv-2048  5126.26 (  0.00%) 7544.23 ( 47.17%)
> Hmeanrecv-3312  7949.50 (  0.00%)11322.52 ( 42.43%)
> Hmeanrecv-4096  9433.04 (  0.00%)12816.68 ( 35.87%)
> Hmeanrecv-8192 15939.64 (  0.00%)21402.75 ( 34.27%)
> Hmeanrecv-1638426698.44 (  0.00%)32806.81 ( 22.88%)
> 
> 1-socket 6 year old machine
> 4.9.0-rc5 4.9.0-rc5
>   vanilla hopcpu-v4
> Hmeansend-64  87.47 (  0.00%)  127.01 ( 45.21%)
> Hmeansend-128174.36 (  0.00%)  254.86 ( 46.17%)
> Hmeansend-256347.52 (  0.00%)  505.91 ( 45.58%)
> Hmeansend-1024  1363.03 (  0.00%) 1962.49 ( 43.98%)
> Hmeansend-2048  2632.68 (  0.00%) 3731.74 ( 41.75%)
> Hmeansend-3312  4123.19 (  0.00%) 5859.08 ( 42.10%)
> Hmeansend-4096  5056.48 (  0.00%) 7058.00 ( 39.58%)
> Hmeansend-8192  8784.22 (  0.00%)12134.53 ( 38.14%)
> Hmeansend-1638415081.60 (  0.00%)19638.90 ( 30.22%)
> Hmeanrecv-64  86.19 (  0.00%)  126.34 ( 46.58%)
> Hmeanrecv-128173.93 (  0.00%)  253.51 ( 45.75%)
> Hmeanrecv-256346.19 (  0.00%)  503.34 ( 45.40%)
> Hmeanrecv-1024  1358.28 (  0.00%) 1951.63 ( 43.68%)
> Hmeanrecv-2048  2623.45 (  0.00%) 3701.67 ( 41.10%)
> Hmeanrecv-3312  4108.63 (  0.00%) 5817.75 ( 41.60%)
> Hmeanrecv-4096  5037.25 (  0.00%) 7004.79 ( 39.06%)
> Hmeanrecv-8192  8762.32 (  0.00%)12059.83 ( 37.63%)
> Hmeanrecv-1638415042.36 (  0.00%)19514

[PATCH] Input: elantech - Add a special mode for a specific FW The touchapd which sample ver is 0x74 and hw_version is 0x03 have a fw bug which will cause crush sometimes, I add some work-around for i

[KT Liao]

---
 drivers/input/mouse/elantech.c | 152 +++--
 1 file changed, 131 insertions(+), 21 deletions(-)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index db7d1d6..acfe7f2 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -539,6 +539,30 @@ static void elantech_report_absolute_v3(struct psmouse 
*psmouse,
input_sync(dev);
 }
 
+static psmouse_ret_t elantech_report_relative_v3(struct psmouse *psmouse)
+{
+   struct input_dev *dev = psmouse->dev;
+   unsigned char *packet = psmouse->packet;
+   int rel_x = 0, rel_y = 0;
+
+   if (psmouse->pktcnt < psmouse->pktsize)
+   return PSMOUSE_GOOD_DATA;
+
+   input_report_rel(dev, REL_WHEEL, -(signed char)packet[3]);
+
+   rel_x = (int) packet[1] - (int) ((packet[0] << 4) & 0x100);
+   rel_y = (int) ((packet[0] << 3) & 0x100) - (int) packet[2];
+
+   input_report_key(dev, BTN_LEFT,packet[0]   & 1);
+   input_report_key(dev, BTN_RIGHT,  (packet[0] >> 1) & 1);
+   input_report_rel(dev, REL_X, rel_x);
+   input_report_rel(dev, REL_Y, rel_y);
+
+   input_sync(dev);
+
+   return PSMOUSE_FULL_PACKET;
+}
+
 static void elantech_input_sync_v4(struct psmouse *psmouse)
 {
struct input_dev *dev = psmouse->dev;
@@ -696,14 +720,14 @@ static int elantech_packet_check_v1(struct psmouse 
*psmouse)
 
 static int elantech_debounce_check_v2(struct psmouse *psmouse)
 {
-/*
- * When we encounter packet that matches this exactly, it means the
- * hardware is in debounce status. Just ignore the whole packet.
- */
-const u8 debounce_packet[] = { 0x84, 0xff, 0xff, 0x02, 0xff, 0xff };
-unsigned char *packet = psmouse->packet;
-
-return !memcmp(packet, debounce_packet, sizeof(debounce_packet));
+   /*
+* When we encounter packet that matches this exactly, it means the
+* hardware is in debounce status. Just ignore the whole packet.
+*/
+   const u8 debounce_packet[] = { 0x84, 0xff, 0xff, 0x02, 0xff, 0xff };
+   unsigned char *packet = psmouse->packet;
+
+   return !memcmp(packet, debounce_packet, sizeof(debounce_packet));
 }
 
 static int elantech_packet_check_v2(struct psmouse *psmouse)
@@ -995,6 +1019,29 @@ static int elantech_set_absolute_mode(struct psmouse 
*psmouse)
return rc;
 }
 
+/* it's the work around mode for some touchpad which has FW bug, but dont' 
support IAP funciton */
+static int elantech_set_special_mode(struct psmouse *psmouse)
+{
+   unsigned char param[3];
+   int rc = 0;
+
+   param[0] = 0xc8;
+   param[1] = 0x64;
+   param[2] = 0x50;
+
+   if (elantech_ps2_command(psmouse, ¶m[0], PSMOUSE_CMD_SETRATE) ||
+  elantech_ps2_command(psmouse, ¶m[1], PSMOUSE_CMD_SETRATE) ||
+  elantech_ps2_command(psmouse, ¶m[2], PSMOUSE_CMD_SETRATE) ||
+  elantech_ps2_command(psmouse, param, PSMOUSE_CMD_GETID)) {
+   rc = -1;
+   }
+
+   psmouse->set_rate(psmouse, 0x64);
+   psmouse->set_resolution(psmouse, 200);
+
+   return rc;
+}
+
 static int elantech_set_range(struct psmouse *psmouse,
  unsigned int *x_min, unsigned int *y_min,
  unsigned int *x_max, unsigned int *y_max,
@@ -1279,6 +1326,32 @@ static int elantech_set_input_params(struct psmouse 
*psmouse)
return 0;
 }
 
+static int elantech_set_input_params_special(struct psmouse *psmouse)
+{
+   struct input_dev *dev = psmouse->dev;
+   struct elantech_data *etd = psmouse->private;
+   unsigned int x_min = 0, y_min = 0, x_max = 0, y_max = 0, width = 0;
+
+   if (elantech_set_range(psmouse, &x_min, &y_min, &x_max, &y_max, &width))
+   return -1;
+
+   __set_bit(INPUT_PROP_POINTER, dev->propbit);
+   __set_bit(EV_KEY, dev->evbit);
+
+   __set_bit(BTN_LEFT, dev->keybit);
+   __set_bit(BTN_RIGHT, dev->keybit);
+
+   __set_bit(EV_REL, dev->evbit);
+   __set_bit(REL_X, dev->relbit);
+   __set_bit(REL_Y, dev->relbit);
+   __set_bit(REL_WHEEL, dev->relbit);
+
+   etd->y_max = y_max;
+   etd->width = width;
+
+   return 0;
+}
+
 struct elantech_attr_data {
size_t  field_offset;
unsigned char   reg;
@@ -1483,15 +1556,28 @@ static void elantech_disconnect(struct psmouse *psmouse)
  */
 static int elantech_reconnect(struct psmouse *psmouse)
 {
+
+   struct elantech_data *etd = psmouse->private;
+
psmouse_reset(psmouse);
 
if (elantech_detect(psmouse, 0))
return -1;
 
-   if (elantech_set_absolute_mode(psmouse)) {
-   psmouse_err(psmouse,
-   "failed to put touchpad back into absolute 
mode.\n");
-   return -1;
+   if (etd->samples[1] == 0x74 && etd->hw_version == 0x03) {
+   /* handle specail FW issue */
+   psmouse_in

[PATCH v2] arm64: dts: zx: support cpu-freq for zx296718

[Baoyou Xie]

This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.

So it can be used by cpufreq-dt driver.

Signed-off-by: Baoyou Xie 
---
 arch/arm64/boot/dts/zte/zx296718.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi 
b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 7a1aed7..b44d1d1 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+   clocks = <&topcrm A53_GATE>;
+   operating-points-v2 = <&cluster0_opp>;
};
 
cpu1: cpu@1 {
@@ -88,6 +91,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+   clocks = <&topcrm A53_GATE>;
+   operating-points-v2 = <&cluster0_opp>;
};
 
cpu2: cpu@2 {
@@ -95,6 +100,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+   clocks = <&topcrm A53_GATE>;
+   operating-points-v2 = <&cluster0_opp>;
};
 
cpu3: cpu@3 {
@@ -102,6 +109,38 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+   clocks = <&topcrm A53_GATE>;
+   operating-points-v2 = <&cluster0_opp>;
+   };
+   };
+
+   cluster0_opp: opp-table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5 {
+   opp-hz = /bits/ 64 <5>;
+   clock-latency-ns = <50>;
+   };
+
+   opp@64800 {
+   opp-hz = /bits/ 64 <64800>;
+   clock-latency-ns = <50>;
+   };
+
+   opp@8 {
+   opp-hz = /bits/ 64 <8>;
+   clock-latency-ns = <50>;
+   };
+
+   opp@10 {
+   opp-hz = /bits/ 64 <10>;
+   clock-latency-ns = <50>;
+   };
+
+   opp@118800 {
+   opp-hz = /bits/ 64 <118800>;
+   clock-latency-ns = <50>;
};
};
 
-- 
2.7.4

Re: [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version

[Jon Masters]

On 11/30/2016 07:28 PM, Bjorn Helgaas wrote:

> I'm hoping to end up with something like this:
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469

The following build warnings happen using your branch on RHELSA7.3:

drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
  THUNDER_PEM_QUIRK(2,  0), /* off-chip devices */
  ^
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[44].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[44].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[45].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[45].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[46].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[46].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[47].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[47].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[48].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[48].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[49].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for 
‘mcfg_quirks[49].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type 
[enabled by default]
  THUNDER_PEM_QUIRK(2,  1), /* off-chip devices */
  ^
drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for 
‘mcfg_quirks[50].cfgres.start’) [enabled by default]
drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type 
[enabled by default]
drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant 
expression [enabled by default]
drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for 
‘mcfg_quirks[50].cfgres.end’) [enabled by default]
drivers/acpi/pci_mcfg.c:102:2: warning: left shi

RE: [PATCH 02/15] hyperv: Add a function to detect hv_device

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, December 1, 2016 12:34 PM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; leann.ogasaw...@canonical.com; Haiyang Zhang
> 
> Subject: Re: [PATCH 02/15] hyperv: Add a function to detect hv_device
> 
> On Thu, Dec 01, 2016 at 09:28:39AM -0800, k...@exchange.microsoft.com
> wrote:
> > From: Haiyang Zhang 
> >
> > Signed-off-by: Haiyang Zhang 
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/hv/vmbus_drv.c |6 ++
> >  include/linux/hyperv.h |2 ++
> >  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> I can't, and you shouldn't, take patches with no changelog comments at
> all.
> 
> sorry.

Sorry about this; this will be fixed.

K. Y
> 
> greg k-h

Re: [PATCH v2] ACPI / APEI: Fix NMI notification handling

[Hanjun Guo]

On 2016/12/2 7:12, Rafael J. Wysocki wrote:
> On Thursday, December 01, 2016 11:47:17 PM Borislav Petkov wrote:
>> On Thu, Dec 01, 2016 at 11:29:45PM +0100, Rafael J. Wysocki wrote:
>>> Well, there's another ARM-related patch touching APEI.
>>>
>>> I guess whoever takes this one should also take the other one and
>>> honestly they can go in via any tree as far as I'm concerned, I'm just 
>>> trying to
>>> avoid merge clashes here. :-)
>> Maybe have ARM-folk ACK the other one and take both through your ACPI
>> tree? They both do have ACPI in common :-)
> That one have been ACKed already.
>
> OK, I'll take them both.

Thank you very much :)

Hanjun

Re: [PATCH] powerpc: cputime: fix a compile warning

[yjin]

On 2016年12月02日 13:15, Pan Xinhui wrote:



在 2016/12/2 12:35, yjin 写道:


On 2016年12月02日 12:22, Balbir Singh wrote:
On Fri, Dec 2, 2016 at 3:15 PM, Michael Ellerman 
 wrote:

yanjiang@windriver.com writes:

diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h

index 4f60db0..4423e97 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -228,7 +228,8 @@ static inline cputime_t 
clock_t_to_cputime(const unsigned long clk)

   return (__force cputime_t) ct;
  }

-#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
+#define cputime64_to_clock_t(ct) \
+ (__force u64)(cputime_to_clock_t((cputime_t)(ct)))

Given the name of the function is "cputime64 to clock_t", surely we
should be returning a clock_t ?

Please fix it in cpuacct.c  Also check out git commit
527b0a76f41d062381adbb55c8eb61e32cb0bfc9
sched/cpuacct: Avoid %lld seq_printf warning


Hi Balbir,

Where can I find this commit?


hello,
it is in next tree. :)


Got it. Thanks!

Regards!
Yanjiang



commit 527b0a76f41d062381adbb55c8eb61e32cb0bfc9
Author: Martin Schwidefsky 
Date:   Fri Nov 11 15:27:49 2016 +0100

sched/cpuacct: Avoid %lld seq_printf warning
For s390 kernel builds I keep getting this warning:
 kernel/sched/cpuacct.c: In function 'cpuacct_stats_show':
 kernel/sched/cpuacct.c:298:25: warning: format '%lld' expects 
argument of type 'long long int', but argument 4 has type 'clock_t 
{aka long int}' [-Wformat=]

   seq_printf(sf, "%s %lld\n",
Silence the warning by adding an explicit cast.
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/2016142749.6545-1-schwidef...@de.ibm.com

Signed-off-by: Ingo Molnar 

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index bc0b309c..9add206 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -297,7 +297,7 @@ static int cpuacct_stats_show(struct seq_file *sf, 
void *v)

for (stat = 0; stat < CPUACCT_STAT_NSTATS; stat++) {
seq_printf(sf, "%s %lld\n",
   cpuacct_stat_desc[stat],
-  cputime64_to_clock_t(val[stat]));
+  (long long)cputime64_to_clock_t(val[stat]));
}

return 0;


Thanks!
Yanjiang


Balbir

Re: [PATCH] powerpc: cputime: fix a compile warning

[Pan Xinhui]

在 2016/12/2 12:35, yjin 写道:


On 2016年12月02日 12:22, Balbir Singh wrote:

On Fri, Dec 2, 2016 at 3:15 PM, Michael Ellerman  wrote:

yanjiang@windriver.com writes:


diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h
index 4f60db0..4423e97 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -228,7 +228,8 @@ static inline cputime_t clock_t_to_cputime(const unsigned 
long clk)
   return (__force cputime_t) ct;
  }

-#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
+#define cputime64_to_clock_t(ct) \
+ (__force u64)(cputime_to_clock_t((cputime_t)(ct)))

Given the name of the function is "cputime64 to clock_t", surely we
should be returning a clock_t ?

Please fix it in cpuacct.c  Also check out git commit
527b0a76f41d062381adbb55c8eb61e32cb0bfc9
sched/cpuacct: Avoid %lld seq_printf warning


Hi Balbir,

Where can I find this commit?


hello,
it is in next tree. :)

commit 527b0a76f41d062381adbb55c8eb61e32cb0bfc9
Author: Martin Schwidefsky 
Date:   Fri Nov 11 15:27:49 2016 +0100

sched/cpuacct: Avoid %lld seq_printf warning

For s390 kernel builds I keep getting this warning:

 kernel/sched/cpuacct.c: In function 'cpuacct_stats_show':

 kernel/sched/cpuacct.c:298:25: warning: format '%lld' expects argument of 
type 'long long int', but argument 4 has type 'clock_t {aka long int}' 
[-Wformat=]
   seq_printf(sf, "%s %lld\n",

Silence the warning by adding an explicit cast.

Signed-off-by: Martin Schwidefsky 

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/2016142749.6545-1-schwidef...@de.ibm.com
Signed-off-by: Ingo Molnar 

diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index bc0b309c..9add206 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -297,7 +297,7 @@ static int cpuacct_stats_show(struct seq_file *sf, void *v)
for (stat = 0; stat < CPUACCT_STAT_NSTATS; stat++) {
seq_printf(sf, "%s %lld\n",
   cpuacct_stat_desc[stat],
-  cputime64_to_clock_t(val[stat]));
+  (long long)cputime64_to_clock_t(val[stat]));
}
 
return 0;



Thanks!
Yanjiang


Balbir

Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors

[Jon Masters]

On 11/10/2016 12:42 PM, Bjorn Helgaas wrote:

> For the PNP/ACPI quirks, there are two interesting cases:
> 
>   1) Firmware provides a PNP0C02 device, but its _CRS doesn't include
>  the ECAM space, and
> 
>   2) Firmware doesn't provide a PNP0C02 device at all.
> 
> For case 1, we could consider adding the ECAM space to the existing
> device.  This is essentially what quirk_amd_mmconfig_area() does.
> 
> For case 2, we would have to fabricate the PNP0C02 device itself, then
> add the ECAM space to it.  I don't think there's any existing code
> that does this, so this is what the example I proposed in this thread
> does.  

(this isn't QCOM/QDT specific) We'll go scrub for examples where there
are systems missing the motherboard resource and get firmware fixed. As
an example, I know that HPE ProLiant m400 (Moonshot) will need to be
updated. It would probably be easier to just get the firmware fixed
to add this than to introduce the first DMI quirk for this one.

Ard and others very reasonably want to avoid DMI quirks on arm64. I
take responsibility for being the guilty party that wrote SMBIOS/DMI
into the SBBR originally as a means of keeping this failsafe for the
future and because "that's what x86 does, so people will expect it".
But we'll save that for a nasty situation further down the road. We
are still working on getting vendors (other than QCOM and HPE, who
have had this right since the beginning) to release firmware other
than version "1.0" every time. That's always a good start ;)

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Kalle Valo]

Stephen Rothwell  writes:

> Hi all,
>
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/ath/ath10k/mac.c
>
> between commit:
>
>   f3fe4e93dd63 ("mac80211: add a HW flag for supporting HW TX fragmentation")
>
> from the net-next tree and commit:
>
>   ff32eeb86aa1 ("ath10k: advertize hardware packet loss mechanism")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix looks good, thanks. I sent a pull request to Dave yesteday which
should fix this.

-- 
Kalle Valo

Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/

[Kalle Valo]

David Howells  writes:

> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image.  Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
>
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify.  The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
>
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
>
> This patch annotates drivers in drivers/net/wireless/.
>
> Suggested-by: One Thousand Gnomes 
> Signed-off-by: David Howells 
> cc: Kalle Valo 
> cc: linux-wirel...@vger.kernel.org
> cc: net...@vger.kernel.org
> ---
>
>  drivers/net/wireless/cisco/airo.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Via which tree are you planning to submit this, should I take it to
wireless-drivers or will someone else handle it? I didn't get the cover
letter so I have no idea.

-- 
Kalle Valo

Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors

[Jon Masters]

On 11/03/2016 10:00 AM, Bjorn Helgaas wrote:

> It turns out that we can't use the _CRS of host bridges because of the
> Producer/Consumer bit screwup [1].  So the fallback is to include the
> ECAM space in the _CRS of a PNP0C02 device.  This is what the PCI
> Firmware spec r3.0, Table 4-2, footnote 2 is talking about.
> 
> Bjorn
> 
> [1] The original ACPI spec intent was that Consumer resources would be
> space like ECAM that is consumed directly by the bridge, and Producer
> resources would be the windows forwarded down to PCI.  But BIOSes
> didn't use the Producer/Consumer bit consistently, so we have to
> assume that all resources in host bridge _CRS are windows, which
> leaves us no way to describe the Consumer resources.

Aside - and now I realize you'd called this out as recently as last
month. Alas the HPE m400 I reference on the other thread about the
APM quirks doesn't have the motherboard resource entry so we're
stuck with exactly the situation you describe above there.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[PATCH] bdisp: Clean up file handle in open() error path.

[Shailendra Verma]

The File handle is not yet added in the vdev list.So no need to call 
v4l2_fh_del(&ctx->fh)if it fails to create control.

Signed-off-by: Shailendra Verma 
---
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index 45f82b5..fbf302f 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -632,8 +632,8 @@ static int bdisp_open(struct file *file)
 
 error_ctrls:
bdisp_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(&ctx->fh);
+error_fh:
v4l2_fh_exit(&ctx->fh);
bdisp_hw_free_nodes(ctx);
 mem_ctx:
-- 
1.7.9.5

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

[Baolin Wang]

On 2 December 2016 at 12:40, Lu Baolu  wrote:
> Hi,
>
> On 12/02/2016 12:18 PM, Baolin Wang wrote:
>> On 2 December 2016 at 10:29, Lu Baolu  wrote:
>>> handle_cmd_completion() frees a command structure which might
>>> be still referenced by xhci->current_cmd. This might cause
>>> problem when xhci->current_cmd is accessed after that.
>>>
>>> A real-life case could be like this. The host takes a very long
>>> time to respond to a command, and the command timer is fired at
>>> the same time when the command completion event arrives. The
>>> command completion handler frees xhci->current_cmd before the
>>> timer function can grab xhci->lock. Afterward, timer function
>>> grabs the lock and go ahead with checking and setting members
>>> of xhci->current_cmd.
>>>
>>> Cc:  # v3.16+
>>> Signed-off-by: Lu Baolu 
>> Nice catch. I was also curious where set xhci->current_cmd to be NULL
>> when current command is freed.
>
> Below code does:

Yes, I just means you did that, but the original code did not. Sorry
for confusing.

>
> xhci->current_cmd = list_entry(cmd->cmd_list.next,
>struct xhci_command, cmd_list);
> mod_timer(&xhci->cmd_timer, jiffies + 
> XHCI_CMD_DEFAULT_TIMEOUT);
> +   } else if (xhci->current_cmd == cmd) {
> +   xhci->current_cmd = NULL;
> +   } else {
> +   xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
> }
>
>
> Best regards,
> Lu Baolu
>
>> Tested-by: Baolin Wang 
>>
>>> ---
>>>  drivers/usb/host/xhci-ring.c | 16 +++-
>>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>>> index bdf6b13..13e05f6 100644
>>> --- a/drivers/usb/host/xhci-ring.c
>>> +++ b/drivers/usb/host/xhci-ring.c
>>> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>>> bool second_timeout = false;
>>> xhci = (struct xhci_hcd *) data;
>>>
>>> -   /* mark this command to be cancelled */
>>> spin_lock_irqsave(&xhci->lock, flags);
>>> -   if (xhci->current_cmd) {
>>> -   if (xhci->current_cmd->status == COMP_CMD_ABORT)
>>> -   second_timeout = true;
>>> -   xhci->current_cmd->status = COMP_CMD_ABORT;
>>> +   if (!xhci->current_cmd) {
>>> +   spin_unlock_irqrestore(&xhci->lock, flags);
>>> +   return;
>>> }
>>>
>>> +   if (xhci->current_cmd->status == COMP_CMD_ABORT)
>>> +   second_timeout = true;
>>> +   xhci->current_cmd->status = COMP_CMD_ABORT;
>>> +
>>> /* Make sure command ring is running before aborting it */
>>> hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>>> if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
>>> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd 
>>> *xhci,
>>> xhci->current_cmd = list_entry(cmd->cmd_list.next,
>>>struct xhci_command, 
>>> cmd_list);
>>> mod_timer(&xhci->cmd_timer, jiffies + 
>>> XHCI_CMD_DEFAULT_TIMEOUT);
>>> +   } else if (xhci->current_cmd == cmd) {
>>> +   xhci->current_cmd = NULL;
>>> +   } else {
>>> +   xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>>> }
>>>
>>>  event_handled:
>>> --
>>> 2.1.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>



-- 
Baolin.wang
Best Regards

[PATCH] exynos-gsc: Clean up file handle in open() error path.

[Shailendra Verma]

The File handle is not yet added in the vfd list.So no need to call
v4l2_fh_del(&ctx->fh) if it fails to create control.

Signed-off-by: Shailendra Verma 
---
 drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c 
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 9f03b79..5ea97c1 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -664,8 +664,8 @@ static int gsc_m2m_open(struct file *file)
 
 error_ctrls:
gsc_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(&ctx->fh);
+error_fh:
v4l2_fh_exit(&ctx->fh);
kfree(ctx);
 unlock:
-- 
1.7.9.5

[PATCH] exynos4-is: Clean up file handle in open() error path.

[Shailendra Verma]

The File handle is not yet added in the vfd list.So no need to call 
v4l2_fh_del(&ctx->fh) if it fails to create control.

Signed-off-by: Shailendra Verma 
---
 drivers/media/platform/exynos4-is/fimc-m2m.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c 
b/drivers/media/platform/exynos4-is/fimc-m2m.c
index 6028e4f..d8724fe 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -663,8 +663,8 @@ static int fimc_m2m_open(struct file *file)
v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
 error_c:
fimc_ctrls_delete(ctx);
-error_fh:
v4l2_fh_del(&ctx->fh);
+error_fh:
v4l2_fh_exit(&ctx->fh);
kfree(ctx);
 unlock:
-- 
1.7.9.5

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

[Lu Baolu]

Hi,

On 12/02/2016 12:18 PM, Baolin Wang wrote:
> On 2 December 2016 at 10:29, Lu Baolu  wrote:
>> handle_cmd_completion() frees a command structure which might
>> be still referenced by xhci->current_cmd. This might cause
>> problem when xhci->current_cmd is accessed after that.
>>
>> A real-life case could be like this. The host takes a very long
>> time to respond to a command, and the command timer is fired at
>> the same time when the command completion event arrives. The
>> command completion handler frees xhci->current_cmd before the
>> timer function can grab xhci->lock. Afterward, timer function
>> grabs the lock and go ahead with checking and setting members
>> of xhci->current_cmd.
>>
>> Cc:  # v3.16+
>> Signed-off-by: Lu Baolu 
> Nice catch. I was also curious where set xhci->current_cmd to be NULL
> when current command is freed.

Below code does:

xhci->current_cmd = list_entry(cmd->cmd_list.next,
   struct xhci_command, cmd_list);
mod_timer(&xhci->cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
+   } else if (xhci->current_cmd == cmd) {
+   xhci->current_cmd = NULL;
+   } else {
+   xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
}


Best regards,
Lu Baolu

> Tested-by: Baolin Wang 
>
>> ---
>>  drivers/usb/host/xhci-ring.c | 16 +++-
>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index bdf6b13..13e05f6 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
>> bool second_timeout = false;
>> xhci = (struct xhci_hcd *) data;
>>
>> -   /* mark this command to be cancelled */
>> spin_lock_irqsave(&xhci->lock, flags);
>> -   if (xhci->current_cmd) {
>> -   if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> -   second_timeout = true;
>> -   xhci->current_cmd->status = COMP_CMD_ABORT;
>> +   if (!xhci->current_cmd) {
>> +   spin_unlock_irqrestore(&xhci->lock, flags);
>> +   return;
>> }
>>
>> +   if (xhci->current_cmd->status == COMP_CMD_ABORT)
>> +   second_timeout = true;
>> +   xhci->current_cmd->status = COMP_CMD_ABORT;
>> +
>> /* Make sure command ring is running before aborting it */
>> hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
>> if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
>> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd 
>> *xhci,
>> xhci->current_cmd = list_entry(cmd->cmd_list.next,
>>struct xhci_command, 
>> cmd_list);
>> mod_timer(&xhci->cmd_timer, jiffies + 
>> XHCI_CMD_DEFAULT_TIMEOUT);
>> +   } else if (xhci->current_cmd == cmd) {
>> +   xhci->current_cmd = NULL;
>> +   } else {
>> +   xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
>> }
>>
>>  event_handled:
>> --
>> 2.1.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

[PATCH V5] leds: pca955x: Add ACPI support for pca955x

[Tin Huynh]

This patch enables ACPI support for leds-pca955x driver.

Signed-off-by: Tin Huynh 
---
 drivers/leds/leds-pca955x.c |   24 ++--
 1 files changed, 22 insertions(+), 2 deletions(-)

Change from V4:
 -Using client->name instead of id->name to avoid NULL pointer in ACPI.
 
Change from V3:
 -Drop ".id =" and ".driver_data =" from pca955x_acpi_ids initializers.

Change from V2:
 -Correct coding conventions.

Change from V1:
 -Remove CONFIG_ACPI.

diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
index 840401a..78a7ce8 100644
--- a/drivers/leds/leds-pca955x.c
+++ b/drivers/leds/leds-pca955x.c
@@ -40,6 +40,7 @@
  *  bits the chip supports.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -100,6 +101,15 @@ struct pca955x_chipdef {
 };
 MODULE_DEVICE_TABLE(i2c, pca955x_id);
 
+static const struct acpi_device_id pca955x_acpi_ids[] = {
+   { "PCA9550",  pca9550 },
+   { "PCA9551",  pca9551 },
+   { "PCA9552",  pca9552 },
+   { "PCA9553",  pca9553 },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+
 struct pca955x {
struct mutex lock;
struct pca955x_led *leds;
@@ -250,7 +260,16 @@ static int pca955x_probe(struct i2c_client *client,
struct led_platform_data *pdata;
int i, err;
 
-   chip = &pca955x_chipdefs[id->driver_data];
+   if (id) {
+   chip = &pca955x_chipdefs[id->driver_data];
+   } else {
+   const struct acpi_device_id *acpi_id;
+
+   acpi_id = acpi_match_device(pca955x_acpi_ids, &client->dev);
+   if (!acpi_id)
+   return -ENODEV;
+   chip = &pca955x_chipdefs[acpi_id->driver_data];
+   }
adapter = to_i2c_adapter(client->dev.parent);
pdata = dev_get_platdata(&client->dev);
 
@@ -264,7 +283,7 @@ static int pca955x_probe(struct i2c_client *client,
 
dev_info(&client->dev, "leds-pca955x: Using %s %d-bit LED driver at "
"slave address 0x%02x\n",
-   id->name, chip->bits, client->addr);
+   client->name, chip->bits, client->addr);
 
if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
return -EIO;
@@ -358,6 +377,7 @@ static int pca955x_remove(struct i2c_client *client)
 static struct i2c_driver pca955x_driver = {
.driver = {
.name   = "leds-pca955x",
+   .acpi_match_table = ACPI_PTR(pca955x_acpi_ids),
},
.probe  = pca955x_probe,
.remove = pca955x_remove,
-- 
1.7.1

[PATCH v2 1/2] mailbox: Add driver for Broadcom FlexRM ring manager

[Anup Patel]

Some of the Broadcom iProc SoCs have FlexRM ring manager
which provides a ring-based programming interface to various
offload engines (e.g. RAID, Crypto, etc).

This patch adds a common mailbox driver for Broadcom FlexRM
ring manager which can be shared by various offload engine
drivers (implemented as mailbox clients).

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Reviewed-by: Pramod KUMAR 
Signed-off-by: Anup Patel 
---
 drivers/mailbox/Kconfig  |  11 +
 drivers/mailbox/Makefile |   2 +
 drivers/mailbox/mailbox-flexrm/Makefile  |   6 +
 drivers/mailbox/mailbox-flexrm/flexrm-desc.c | 764 
 drivers/mailbox/mailbox-flexrm/flexrm-desc.h |  47 ++
 drivers/mailbox/mailbox-flexrm/flexrm-main.c | 829 +++
 include/linux/mailbox/brcm-message.h |  14 +-
 7 files changed, 1669 insertions(+), 4 deletions(-)
 create mode 100644 drivers/mailbox/mailbox-flexrm/Makefile
 create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.c
 create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.h
 create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-main.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 11eebfe..bfeced1 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -143,4 +143,15 @@ config BCM_PDC_MBOX
  Mailbox implementation for the Broadcom PDC ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom PDC.
+
+config BCM_FLEXRM_MBOX
+   tristate "Broadcom FlexRM Mailbox"
+   depends on ARM64 || COMPILE_TEST
+   depends on HAS_DMA
+   select GENERIC_MSI_IRQ_DOMAIN
+   default ARCH_BCM_IPROC
+   help
+ Mailbox implementation of the Broadcom FlexRM ring manager,
+ which provides access to various offload engines on Broadcom
+ SoCs. Say Y here if you want to use the Broadcom FlexRM.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index ace6fed..9594266 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -29,3 +29,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
 obj-$(CONFIG_HI6220_MBOX)  += hi6220-mailbox.o
 
 obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
+
+obj-$(CONFIG_BCM_FLEXRM_MBOX)  += mailbox-flexrm/
diff --git a/drivers/mailbox/mailbox-flexrm/Makefile 
b/drivers/mailbox/mailbox-flexrm/Makefile
new file mode 100644
index 000..f5bf069
--- /dev/null
+++ b/drivers/mailbox/mailbox-flexrm/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for Broadcom FlexRM Mailbox Driver.
+#
+
+flexrm-mbox-objs := flexrm-main.o flexrm-desc.o
+obj-$(CONFIG_BCM_FLEXRM_MBOX) += flexrm-mbox.o
diff --git a/drivers/mailbox/mailbox-flexrm/flexrm-desc.c 
b/drivers/mailbox/mailbox-flexrm/flexrm-desc.c
new file mode 100644
index 000..b0449eb
--- /dev/null
+++ b/drivers/mailbox/mailbox-flexrm/flexrm-desc.c
@@ -0,0 +1,764 @@
+/* Broadcom FlexRM Mailbox Driver
+ *
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * FlexRM descriptor library
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "flexrm-desc.h"
+
+/* Completion descriptor format */
+#define CMPL_OPAQUE_SHIFT  0
+#define CMPL_OPAQUE_MASK   0x
+#define CMPL_ENGINE_STATUS_SHIFT   16
+#define CMPL_ENGINE_STATUS_MASK0x
+#define CMPL_DME_STATUS_SHIFT  32
+#define CMPL_DME_STATUS_MASK   0x
+#define CMPL_RM_STATUS_SHIFT   48
+#define CMPL_RM_STATUS_MASK0x
+
+/* Completion DME status code */
+#define DME_STATUS_MEM_COR_ERR BIT(0)
+#define DME_STATUS_MEM_UCOR_ERRBIT(1)
+#define DME_STATUS_FIFO_UNDERFLOW  BIT(2)
+#define DME_STATUS_FIFO_OVERFLOW   BIT(3)
+#define DME_STATUS_RRESP_ERR   BIT(4)
+#define DME_STATUS_BRESP_ERR   BIT(5)
+#define DME_STATUS_ERROR_MASK  (DME_STATUS_MEM_COR_ERR | \
+DME_STATUS_MEM_UCOR_ERR | \
+DME_STATUS_FIFO_UNDERFLOW | \
+DME_STATUS_FIFO_OVERFLOW | \
+DME_STATUS_RRESP_ERR | \
+DME_STATUS_BRESP_ERR)
+
+/* Completion RM status code */
+#define RM_STATUS_CODE_SHIFT   0
+#define RM_STATUS_CODE_MASK0x3ff
+#define RM_STATUS_CODE_GOOD0x0
+#define RM_STATUS_CODE_AE_TIMEOUT  0x3ff
+
+/* General descriptor format */
+#define DESC_TYPE_SHIFT  

[PATCH v2 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager

[Anup Patel]

This patch adds device tree bindings document for the FlexRM
ring manager found on Broadcom iProc SoCs.

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Anup Patel 
---
 .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt| 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt 
b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
new file mode 100644
index 000..e81f116
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
@@ -0,0 +1,60 @@
+Broadcom FlexRM Ring Manager
+
+The Broadcom FlexRM ring manager provides a set of rings which can be
+used to submit work to offload engines. An SoC may have multiple FlexRM
+hardware blocks. There is one device tree entry per FlexRM block. The
+FlexRM driver will create a mailbox-controller instance for given FlexRM
+hardware block where each mailbox channel is a separate FlexRM ring.
+
+Required properties:
+
+- compatible:  Should be "brcm,iproc-flexrm-mbox"
+- reg: Specifies base physical address and size of the FlexRM
+   ring registers
+- msi-parent:  Phandles (and potential Device IDs) to MSI controllers
+   The FlexRM engine will send MSIs (instead of wired
+   interrupts) to CPU. There is one MSI for each FlexRM ring.
+   Refer devicetree/bindings/interrupt-controller/msi.txt
+- #mbox-cells: Specifies the number of cells needed to encode a mailbox
+   channel. This should be 3.
+
+   The 1st cell is the mailbox channel number.
+
+   The 2nd cell contains MSI completion threshold. This is the
+   number of completion messages for which FlexRM will inject
+   one MSI interrupt to CPU.
+
+   The 3nd cell contains MSI timer value representing time for
+   which FlexRM will wait to accumulate N completion messages
+   where N is the value specified by 2nd cell above. If FlexRM
+   does not get required number of completion messages in time
+   specified by this cell then it will inject one MSI interrupt
+   to CPU provided atleast one completion message is available.
+
+Optional properties:
+
+- dma-coherent:Present if DMA operations made by the FlexRM engine 
(such
+   as DMA descriptor access, access to buffers pointed by DMA
+   descriptors and read/write pointer updates to DDR) are
+   cache coherent with the CPU.
+
+Example:
+
+crypto_mbox: mbox@6700 {
+   compatible = "brcm,flexrm-mbox";
+   reg = <0x6700 0x20>;
+   msi-parent = <&gic_its 0x7f00>;
+   #mbox-cells = <3>;
+};
+
+crypto_client {
+   ...
+   mboxes = <&crypto_mbox 0 0x1 0x>,
+<&crypto_mbox 1 0x1 0x>,
+<&crypto_mbox 16 0x1 0x>,
+<&crypto_mbox 17 0x1 0x>,
+<&crypto_mbox 30 0x1 0x>,
+<&crypto_mbox 31 0x1 0x>;
+   };
+   ...
+};
-- 
2.7.4

[PATCH v2 0/2] Broadcom FlexRM ring manager support

[Anup Patel]

The Broadcom FlexRM ring manager provides producer-consumer style
ring interface for offload engines on Broadcom iProc SoCs. We can
have one or more instances of Broadcom FlexRM ring manager in a SoC.

This patchset adds a mailbox driver for Broadcom FlexRM ring manager
which can be used by offload engine drivers as mailbox clients.

The Broadcom FlexRM mailbox driver is feature complete for RAID and
Crypto offload engines. We will have incremental patches in-future
for ring-level statistics using debugfs and minor optimizations.

This patchset is based on Linux-4.9-rc7 and it is also available
at flexrm-v2 branch of https://github.com/Broadcom/arm64-linux.git

Changes since v1:
 - Use compatile string as brcm,iproc-flexrm-mbox
 - Rephrase commit message and text in DT bindings patch

Anup Patel (2):
  mailbox: Add driver for Broadcom FlexRM ring manager
  dt-bindings: Add DT bindings info for FlexRM ring manager

 .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt|  60 ++
 drivers/mailbox/Kconfig|  11 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/mailbox-flexrm/Makefile|   6 +
 drivers/mailbox/mailbox-flexrm/flexrm-desc.c   | 764 +++
 drivers/mailbox/mailbox-flexrm/flexrm-desc.h   |  47 ++
 drivers/mailbox/mailbox-flexrm/flexrm-main.c   | 829 +
 include/linux/mailbox/brcm-message.h   |  14 +-
 8 files changed, 1729 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
 create mode 100644 drivers/mailbox/mailbox-flexrm/Makefile
 create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.c
 create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.h
 create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-main.c

-- 
2.7.4

CONFIG_* in UAPI headers

[Eugene Syromyatnikov]

Hello.

It was noticed during addition of support for the new arch_prctl code constants
to strace that these new constants (ARCH_MAP_VDSO_X32, ARCH_MAP_VDSO_32 and
ARCH_MAP_VDSO_64) are guarded with the CONFIG_CHECKPOINT_RESTORE ifdef.
However, from what I can see (by looking at headers in and around
/usr/include/linux in Debian and Red Hat distributions), kernel configuration
definitions are not exported as a part of the UAPI headers, so these definitions
would be unusable unless user application explicitly defines
CONFIG_CHECKPOINT_RESTORE macro, regardless of kernel support.

Further inspection of UAPI headers revealed that there are several other
examples of such CONFIG_*-guarded definitions, namely:
 * include/uapi/asm-generic/fcntl.h — ifndef CONFIG_64BIT (however glibc
   headers have own magic regarding fcntl constants)
 * include/uapi/asm-generic/mman-common.h —
   ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
 * include/uapi/asm-generic/unistd.h — ifdef CONFIG_MMU
 * include/uapi/linux/atmdev.h — ifdef CONFIG_COMPAT
 * include/uapi/linux/elfcore.h — ifdef CONFIG_BINFMT_ELF_FDPIC
 * include/uapi/linux/eventpoll.h — ifdef CONFIG_PM_SLEEP
 * include/uapi/linux/fb.h — ifdef CONFIG_FB_BACKLIGHT
 * include/uapi/linux/flat.h — ifdef CONFIG_BINFMT_SHARED_FLAT
 * include/uapi/linux/hw_breakpoint.h — ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
 * include/uapi/linux/pktcdvd.h — if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
 * arch/arc/include/uapi/asm/swab.h — ifdef CONFIG_ARC_HAS_SWAPE
 * arch/arm/include/uapi/asm/ptrace.h — ifdef CONFIG_CPU_ENDIAN_BE8
 * arch/hexagon/include/uapi/asm/ptrace.h — if CONFIG_HEXAGON_ARCH_VERSION >= 4
 * arch/hexagon/include/uapi/asm/user.h — if CONFIG_HEXAGON_ARCH_VERSION < 4
 * arch/m68k/include/uapi/asm/ptrace.h — ifdef CONFIG_COLDFIRE
 * arch/nios2/include/uapi/asm/swab.h — ifdef CONFIG_NIOS2_CI_SWAB_SUPPORT
 * arch/x86/include/uapi/asm/auxvec.h — if defined(CONFIG_IA32_EMULATION) ||
   !defined(CONFIG_X86_64)
 * arch/x86/include/uapi/asm/mman.h —
   ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS (another piece of the new code
   added in 4.9)
 * arch/xtensa/include/uapi/asm/mman.h — ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED

Maybe most of these are false positives, but by looking at them it isn't clear
how user space should use definitions and code under under these checks, so
maybe it should be moved out from UAPI or at least fitted with comments
regarding necessity of these guards useful only in kernel space?

-- 
Eugene Syromyatnikov
mailto:evg...@gmail.com
xmpp:esyr@jabber.{ru|org}

Re: [PATCH] powerpc: cputime: fix a compile warning

[yjin]

On 2016年12月02日 12:22, Balbir Singh wrote:

On Fri, Dec 2, 2016 at 3:15 PM, Michael Ellerman  wrote:

yanjiang@windriver.com writes:


diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h
index 4f60db0..4423e97 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -228,7 +228,8 @@ static inline cputime_t clock_t_to_cputime(const unsigned 
long clk)
   return (__force cputime_t) ct;
  }

-#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
+#define cputime64_to_clock_t(ct) \
+ (__force u64)(cputime_to_clock_t((cputime_t)(ct)))

Given the name of the function is "cputime64 to clock_t", surely we
should be returning a clock_t ?

Please fix it in cpuacct.c  Also check out git commit
527b0a76f41d062381adbb55c8eb61e32cb0bfc9
sched/cpuacct: Avoid %lld seq_printf warning


Hi Balbir,

Where can I find this commit?

Thanks!
Yanjiang


Balbir

Re: [PATCH 09/39] mtd: nand: denali: fix erased page check code

[Masahiro Yamada]

Hi Boris,


2016-11-28 0:21 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:05:55 +0900
> Masahiro Yamada  wrote:
>
>> Currently, is_erased() is called against "buf" twice, so the second
>> call is meaningless.  The second one should be checked against
>> chip->oob_poi.
>>
>
> IMO, patch 9 to 12 should be squashed in a single patch. All you're
> doing in these patch is fixing the check_erased_page logic.
>
> You can describe the different broken thing in the commit message, but
> splitting things as you do does not help much.


OK. I will do so.

I realized some mistakes in this part
(both in my patches and in the current mainline code),
so I will rework it in a more sensible chunk.


> Also, please have at nand_check_erased_ecc_chunk() [1] instead of using
> a private method (is_erased()) to check if the page is erased.
> With this method you get bitflips in erased pages correction for free.

I will use this helper, thanks!




With this, I think I answered all of your questions to v1.

(Please tell me if there is something I missed to answer.)

Thanks a lot for your review.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 13/39] mtd: nand: denali: increment ecc_stats->corrected

[Masahiro Yamada]

Hi Boris,

2016-11-28 0:31 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:05:59 +0900
> Masahiro Yamada  wrote:
>
>> Update the number of corrected bit flips when read_page() succeeds.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  drivers/mtd/nand/denali.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> index a6445d9..4cc8945 100644
>> --- a/drivers/mtd/nand/denali.c
>> +++ b/drivers/mtd/nand/denali.c
>> @@ -1162,6 +1162,9 @@ static int denali_read_page(struct mtd_info *mtd, 
>> struct nand_chip *chip,
>>   mtd->ecc_stats.failed++;
>>   return 0;
>>   }
>> +
>> + mtd->ecc_stats.corrected += max_bitflips;
>
> First of all, ecc_stats.corrected should contain the total number of
> bitflips detected on the MTD device, here you're just adding the
> maximum number of bitflips per ECC chunk for the current page, which is
> slightly different.
>
> Then, ecc_stats.corrected seems to be properly updated in handle_ecc()
> [1], so I see no reason to do it here.
>

You are right.

This patch is completely wrong, so I will drop it in v2.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 15/39] mtd: nand: denali: improve readability of handle_ecc()

[Masahiro Yamada]

Hi Boris,


2016-11-28 0:42 GMT+09:00 Boris Brezillon :
>> + if (err_byte < ECC_SECTOR_SIZE) {
>> + struct mtd_info *mtd =
>> + nand_to_mtd(&denali->nand);
>> + int offset;
>> +
>> + offset = (err_sector * ECC_SECTOR_SIZE + 
>> err_byte) *
>> + denali->devnum + err_device;
>> + /* correct the ECC error */
>> + buf[offset] ^= err_correction_value;
>> + mtd->ecc_stats.corrected++;
>> + bitflips++;
>
> Hm, bitflips is what is set in max_bitflips, and apparently the
> implementation (which is not yours) is not doing what the core expects.
>
> You should first count bitflips per sector with something like that:
>
> bitflips[err_sector]++;
>
>
> And then once you've iterated over all errors do:
>
> for (i = 0; i < nsectors; i++)
> max_bitflips = max(bitflips[err_sector], max_bitflips);


I see.

For soft ECC fixup, we can calculate bitflips
for each ECC sector, so I can fix the max_bitflips
as the core framework expects.

For hard ECC fixup, the register only reports
the number of corrected bit-flips
in the whole page (sum from all ECC sectors).
We cannot calculate max_bitflips, I think.



BTW, I noticed another problem of the current code.

  buf[offset] ^= err_correction_value;
  mtd->ecc_stats.corrected++;
  bitflips++;

This code is counting the number of corrected bytes,
not the number of corrected bits.


I think multiple bit-flips within one byte can happen.


Perhaps, we should add

  hweight8(buf[offset] ^ err_correction_value)

to ecc_stats.corrected and bitflips.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] powerpc: cputime: fix a compile warning

[Balbir Singh]

On Fri, Dec 2, 2016 at 3:15 PM, Michael Ellerman  wrote:
> yanjiang@windriver.com writes:
>
>> diff --git a/arch/powerpc/include/asm/cputime.h 
>> b/arch/powerpc/include/asm/cputime.h
>> index 4f60db0..4423e97 100644
>> --- a/arch/powerpc/include/asm/cputime.h
>> +++ b/arch/powerpc/include/asm/cputime.h
>> @@ -228,7 +228,8 @@ static inline cputime_t clock_t_to_cputime(const 
>> unsigned long clk)
>>   return (__force cputime_t) ct;
>>  }
>>
>> -#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
>> +#define cputime64_to_clock_t(ct) \
>> + (__force u64)(cputime_to_clock_t((cputime_t)(ct)))
>
> Given the name of the function is "cputime64 to clock_t", surely we
> should be returning a clock_t ?

Please fix it in cpuacct.c  Also check out git commit
527b0a76f41d062381adbb55c8eb61e32cb0bfc9
sched/cpuacct: Avoid %lld seq_printf warning

Balbir

[PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR

[Michael Ellerman]

This adds two tests, to check that a read or write to LIST_POISON1 and
ZERO_SIZE_PTR are blocked.

The default values for both (256 and 16) typically fall in the range
of valid user space addresses. However in general mmap_min_addr is 64K,
which prevents user space from mapping anything at those addresses.

However it's feasible that an attacker will be able to find a way to
cause an access at an offset from either value, and if that offset is
greater than 64K then they can access user space again.

To simulate that case, in the test we create a user mapping at
approximately mmap_min_addr, and offset the pointer by that amount. This
gives the test the greatest chance of failing (ie. an access
succeeding). We don't actually use mmap_min_addr, because that would
require exporting it to modules, instead we use the default value at
compile time as a reasonable approximation.

Signed-off-by: Michael Ellerman 
---
 drivers/misc/lkdtm.h  |  2 ++
 drivers/misc/lkdtm_bugs.c | 48 +++
 drivers/misc/lkdtm_core.c |  2 ++
 3 files changed, 52 insertions(+)

v2: Fix 32-bit compile errors by using int not long.
Avoid need to export mmap_min_addr by using CONFIG_DEFAULT_MMAP_MIN_ADDR.

diff --git a/drivers/misc/lkdtm.h b/drivers/misc/lkdtm.h
index fdf954c2107f..cc207f7824f9 100644
--- a/drivers/misc/lkdtm.h
+++ b/drivers/misc/lkdtm.h
@@ -21,6 +21,8 @@ void lkdtm_SPINLOCKUP(void);
 void lkdtm_HUNG_TASK(void);
 void lkdtm_ATOMIC_UNDERFLOW(void);
 void lkdtm_ATOMIC_OVERFLOW(void);
+void lkdtm_ACCESS_LIST_POISON(void);
+void lkdtm_ACCESS_ZERO_SIZE_PTR(void);
 
 /* lkdtm_heap.c */
 void lkdtm_OVERWRITE_ALLOCATION(void);
diff --git a/drivers/misc/lkdtm_bugs.c b/drivers/misc/lkdtm_bugs.c
index 30e62dd7e7ca..9ae079ac9a93 100644
--- a/drivers/misc/lkdtm_bugs.c
+++ b/drivers/misc/lkdtm_bugs.c
@@ -5,7 +5,10 @@
  * test source files.
  */
 #include "lkdtm.h"
+#include 
 #include 
+#include 
+#include 
 
 /*
  * Make sure our attempts to over run the kernel stack doesn't trigger
@@ -147,3 +150,48 @@ void lkdtm_ATOMIC_OVERFLOW(void)
pr_info("attempting bad atomic overflow\n");
atomic_inc(&over);
 }
+
+static void test_poison_ptr(void *base, const char *desc)
+{
+   unsigned int *ptr, bias, val;
+   unsigned long uaddr;
+
+   /* We'd rather not export mmap_min_addr, so use the default instead */
+   bias = PAGE_ALIGN(CONFIG_DEFAULT_MMAP_MIN_ADDR);
+
+   uaddr = vm_mmap(NULL, bias, PAGE_SIZE, PROT_READ | PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, 0);
+   if (uaddr >= TASK_SIZE) {
+   pr_warn("Failed to allocate user memory, can't perform 
test.\n");
+   return;
+   }
+
+   /*
+* Creating a mapping and adding mmap_min_addr to the value is cheating
+* in a way. But it simulates the case where an attacker is able to
+* cause an access at a small offset from the base value, leading to a
+* user space access. If an arch doesn't define 
CONFIG_ILLEGAL_POINTER_VALUE
+* then it's likely this will work in the absence of other protections.
+*/
+   ptr = bias + base;
+
+   pr_info("attempting read of %s %p\n", desc, ptr);
+   val = *ptr;
+   pr_info("FAIL: Was able to read %s! Got 0x%x\n", desc, val);
+
+   pr_info("attempting write of %s %p\n", desc, ptr);
+   *ptr = 0xdeadbeefU;
+   pr_info("FAIL: Was able to write %s! Now = 0x%x\n", desc, *ptr);
+
+   vm_munmap(uaddr, PAGE_SIZE);
+}
+
+void lkdtm_ACCESS_LIST_POISON(void)
+{
+   test_poison_ptr(LIST_POISON1, "LIST_POISON");
+}
+
+void lkdtm_ACCESS_ZERO_SIZE_PTR(void)
+{
+   test_poison_ptr(ZERO_SIZE_PTR, "ZERO_SIZE_PTR");
+}
diff --git a/drivers/misc/lkdtm_core.c b/drivers/misc/lkdtm_core.c
index f9154b8d67f6..025a0ee8d8ee 100644
--- a/drivers/misc/lkdtm_core.c
+++ b/drivers/misc/lkdtm_core.c
@@ -220,6 +220,8 @@ struct crashtype crashtypes[] = {
CRASHTYPE(WRITE_KERN),
CRASHTYPE(ATOMIC_UNDERFLOW),
CRASHTYPE(ATOMIC_OVERFLOW),
+   CRASHTYPE(ACCESS_LIST_POISON),
+   CRASHTYPE(ACCESS_ZERO_SIZE_PTR),
CRASHTYPE(USERCOPY_HEAP_SIZE_TO),
CRASHTYPE(USERCOPY_HEAP_SIZE_FROM),
CRASHTYPE(USERCOPY_HEAP_FLAG_TO),
-- 
2.7.4

linux-next: Tree for Dec 2

[Stephen Rothwell]

Hi all,

Changes since 20161201:

The v4l-dvb tree gained conflicts against the jc_docs tree.

The wireless-drivers-next tree gained a conflict against the net-next
tree.

Non-merge commits (relative to Linus' tree): 9313
 8873 files changed, 552758 insertions(+), 202970 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (2caceb3294a7 Merge branch 'overlayfs-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to 
arm64 producing host-arch debs)
Merging arc-current/for-curr (7badf6fefca8 ARC: axs10x: really enable ARC PGU)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to 
definitions")
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (dd7b2f035ec4 powerpc/mm: Fix lazy icache flush on 
pre-POWER5)
Merging sparc/master (88abd8249ee8 Merge branch 'for-4.9-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata)
Merging net/master (fadf3a280544 net: asix: Fix AX88772_suspend() USB vendor 
commands failure issues)
Merging ipsec/master (a55e23864d38 esp6: Fix integrity verification when ESN 
are used)
Merging netfilter/master (7bbf91ce27dd Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec)
Merging ipvs/master (9b6c14d51bd2 net: tcp response should set oif only if it 
is L3 master)
Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 
32-byte SSIDs)
Merging mac80211/master (9590112241ba tipc: fix link statistics counter errors)
Merging sound-current/for-linus (b5337cfe067e ALSA: hda/ca0132 - Add quirk for 
Alienware 15 R2 2016)
Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary 
to 128 iff Root Port supports it (_HPX))
Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (e5517c2a5a49 Linux 4.9-rc7)
Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong 
parenthesis in ffs_func_req_match())
Merging usb-serial-fixes/usb-linus (2ab13292d7a3 USB: serial: cp210x: add ID 
for the Zone DPMX)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5)
Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5)
Merging input-current/for-linus (2425f1808123 Input: change KEY_DATA from 0x275 
to 0x277)
Merging crypto-current/master (57891633eeef crypto: rsa - Add Makefile 
dependencies to fix parallel builds)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging vfio-fixes/for-linus (05692d7005a3 vfio/pci: F

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

[Baolin Wang]

On 2 December 2016 at 10:29, Lu Baolu  wrote:
> handle_cmd_completion() frees a command structure which might
> be still referenced by xhci->current_cmd. This might cause
> problem when xhci->current_cmd is accessed after that.
>
> A real-life case could be like this. The host takes a very long
> time to respond to a command, and the command timer is fired at
> the same time when the command completion event arrives. The
> command completion handler frees xhci->current_cmd before the
> timer function can grab xhci->lock. Afterward, timer function
> grabs the lock and go ahead with checking and setting members
> of xhci->current_cmd.
>
> Cc:  # v3.16+
> Signed-off-by: Lu Baolu 

Nice catch. I was also curious where set xhci->current_cmd to be NULL
when current command is freed.
Tested-by: Baolin Wang 

> ---
>  drivers/usb/host/xhci-ring.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index bdf6b13..13e05f6 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1267,14 +1267,16 @@ void xhci_handle_command_timeout(unsigned long data)
> bool second_timeout = false;
> xhci = (struct xhci_hcd *) data;
>
> -   /* mark this command to be cancelled */
> spin_lock_irqsave(&xhci->lock, flags);
> -   if (xhci->current_cmd) {
> -   if (xhci->current_cmd->status == COMP_CMD_ABORT)
> -   second_timeout = true;
> -   xhci->current_cmd->status = COMP_CMD_ABORT;
> +   if (!xhci->current_cmd) {
> +   spin_unlock_irqrestore(&xhci->lock, flags);
> +   return;
> }
>
> +   if (xhci->current_cmd->status == COMP_CMD_ABORT)
> +   second_timeout = true;
> +   xhci->current_cmd->status = COMP_CMD_ABORT;
> +
> /* Make sure command ring is running before aborting it */
> hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
> if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
> @@ -1422,6 +1424,10 @@ static void handle_cmd_completion(struct xhci_hcd 
> *xhci,
> xhci->current_cmd = list_entry(cmd->cmd_list.next,
>struct xhci_command, cmd_list);
> mod_timer(&xhci->cmd_timer, jiffies + 
> XHCI_CMD_DEFAULT_TIMEOUT);
> +   } else if (xhci->current_cmd == cmd) {
> +   xhci->current_cmd = NULL;
> +   } else {
> +   xhci_warn(xhci, "WARN current_cmd doesn't match command\n");
> }
>
>  event_handled:
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Baolin.wang
Best Regards

Re: [PATCH] powerpc: cputime: fix a compile warning

[Michael Ellerman]

yanjiang@windriver.com writes:

> diff --git a/arch/powerpc/include/asm/cputime.h 
> b/arch/powerpc/include/asm/cputime.h
> index 4f60db0..4423e97 100644
> --- a/arch/powerpc/include/asm/cputime.h
> +++ b/arch/powerpc/include/asm/cputime.h
> @@ -228,7 +228,8 @@ static inline cputime_t clock_t_to_cputime(const unsigned 
> long clk)
>   return (__force cputime_t) ct;
>  }
>  
> -#define cputime64_to_clock_t(ct) cputime_to_clock_t((cputime_t)(ct))
> +#define cputime64_to_clock_t(ct) \
> + (__force u64)(cputime_to_clock_t((cputime_t)(ct)))

Given the name of the function is "cputime64 to clock_t", surely we
should be returning a clock_t ?

cheers

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Jon Masters]

Hi Bjorn, Duc, Mark,

I switched my brain to the on mode and went and read some specs, and a few
tables, so here's my 2 cents on this...

On 12/01/2016 06:22 PM, Duc Dang wrote:
> On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas  wrote:
>> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:

> The SoC provide some number of RC bridges, each with a different base
> for some mmio registers. Even if segment is legitimate in MCFG, there
> is still a problem if a platform doesn't use the segment ordering
> implied by the code. But the PNP0A03 _CRS does have this base address
> as the first memory resource, so we could get it from there and not
> have hard-coded addresses and implied ording in the quirk code.

 I'm confused.  Doesn't the current code treat every item in PNP0A03
 _CRS as a window?  Do you mean the first resource is handled
 differently somehow?  The Consumer/Producer bit could allow us to do
 this by marking the RC MMIO space as "Consumer", but I didn't think
 that strategy was quite working yet.

Let's see if I summarized this correctly...

1. The MMIO registers for the host bridge itself need to be described
   somewhere, especially if we need to find those in a quirk and poke
   them. Since those registers are very much part of the bridge device,
   it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.

2. The address space covering these registers MUST be described as a
   ResourceConsumer in order to avoid accidentally exposing them as
   available for use by downstream devices on the PCI bus.

3. The ACPI specification allows for resources of the type "Memory32Fixed".
   This is a macro that doesn't have the notion of a producer or consumer.
   HOWEVER various interpretations seem to be that this could/should
   default to being interpreted as a consumed region.

4. At one point, a regression was added to the kernel:

   63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
   host bridge itself")

   Which lead to a series on conversations about what should happen
   for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )

5. This resulted in the following commit reverting point 4:

   2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
   available on PCI bus")

   Which also stated that:

   "This solution will also ease the way to consolidate ACPI PCI host
bridge common code from x86, ia64 and ARM64"

End of summary.

So it seems that generally there is an aversion to having bridge resources
be described in this manner and you would like to require that they be
described e.g. using QWordMemory with a ResourceConsumer type?

BUT if we were to do that, it would break existing shipping systems since
there are quirks out there that use this form to find the base CSR:

   if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
fixed32 = &acpi_res->data.fixed_memory32;
port->csr_base = ioremap(fixed32->address,
 fixed32->address_length);
return AE_CTRL_TERMINATE;
}

That's what's shipping in at least RHEL(SA) today, and probably in other
distros. So if we get vendors to take that out, existing stuff will break,
which will have the downside that customers will have to choose between
whether to run a given distro or be able to use upstream kernels. In
that sense, to me, there are shipping platforms out there, which may well
be doing the "wrong" thing, but they are deployed and they are doing it.

Which makes me wonder a couple of things (I think should NOT be done):

1. What would happen if we had both. A FixedMemory32 and the same region
   described again using the longer form as a consumed region. I doubt
   that's legal, and the current code would still add the region if it
   saw the FixedMemory32 first when walking the tree. I don't like it,
   but I'm mentioning it in case that leads to some helpful thinking.

2. What would happen if we had a difference policy on arm64 for such
   resources. x86 has an "exception" for accessing the config space
   using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
   we can make the rules for a new platform (i.e. actually prescribe
   exactly what the behavior is, rather than have it not be defined).
   This is of course terrible in that existing BIOS vendors and so on
   won't necessarily know this when working on ARM ACPI later on.

I don't like either of these obviously. I'm hoping there's some way we
can say that this is tolerated in this one quirk (allow the use of
FixedMemory32 in this case) on the grounds that the driver claims
this bridge region and can be annotated to explain such.

Once you let us know what you prefer, we will go and update the ARM
SBBR to spell out that future platforms should not make this mistake
again. We can prescribe whatever you'd like in terms of how bridge
resources consumed by the bridge are exposed. I have sp

Re: [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

[Archit Taneja]

Hi,

On 12/02/2016 08:02 AM, zain wang wrote:

We will ignored PSR setting if panel not support it. So, in this case, we should
return from analogix_dp_enable/disable_psr() without any error code.
Let's retrun 0 instead of -EINVAL when panel not support PSR in
analogix_dp_enable/disable_psr().

Signed-off-by: zain wang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6e0447f..0cb3695 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -112,7 +112,7 @@ int analogix_dp_enable_psr(struct device *dev)
struct edp_vsc_psr psr_vsc;

if (!dp->psr_support)
-   return -EINVAL;
+   return 0;


Looking at the rockchip analogix dp code, in analogix_dp_psr_set, the worker 
that calls
analogix_dp_enable/disable_psr isn't even if psr isn't enabled. So, the bridge 
funcs
shouldn't be called in the first place. I think the error handling is fine to 
have
here.



/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
@@ -135,7 +135,7 @@ int analogix_dp_disable_psr(struct device *dev)
struct edp_vsc_psr psr_vsc;

if (!dp->psr_support)
-   return -EINVAL;
+   return 0;

/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
@@ -878,6 +878,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
dp->psr_support = analogix_dp_detect_sink_psr(dp);
if (dp->psr_support)
analogix_dp_enable_sink_psr(dp);
+   else
+   dev_warn(dp->dev, "Sink not support PSR\n");


This doesn't seem beneficial either. There seems to be a debug
print already in analogix_dp_detect_sink_psr which reports PSR
related info.

Archit


 }

 /*



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted

[Hillf Danton]

On Friday, December 02, 2016 8:23 AM Mel Gorman wrote:
> Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
> defer debugging checks of pages allocated from the PCP") will allow the
> per-cpu list counter to be out of sync with the per-cpu list contents
> if a struct page is corrupted. This patch keeps the accounting in sync.
> 
> Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages 
> allocated from the PCP")
> Signed-off-by: Mel Gorman 
> cc: sta...@vger.kernel.org [4.7+]
> ---
>  mm/page_alloc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6de9440e3ae2..777ed59570df 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2192,7 +2192,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
> order,
>   unsigned long count, struct list_head *list,
>   int migratetype, bool cold)
>  {
> - int i;
> + int i, alloced = 0;
> 
>   spin_lock(&zone->lock);
>   for (i = 0; i < count; ++i) {
> @@ -2217,13 +2217,14 @@ static int rmqueue_bulk(struct zone *zone, unsigned 
> int order,
>   else
>   list_add_tail(&page->lru, list);
>   list = &page->lru;
> + alloced++;
>   if (is_migrate_cma(get_pcppage_migratetype(page)))
>   __mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
> -(1 << order));
>   }
>   __mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));

Now i is a pure index, yes?

>   spin_unlock(&zone->lock);
> - return i;
> + return alloced;
>  }
> 
>  #ifdef CONFIG_NUMA
> --
> 2.10.2

Re: [PATCH] platform/chrome : Add myself as Maintainer

[Darren Hart]

On Sun, Nov 27, 2016 at 12:38:21PM -0800, Olof Johansson wrote:
> On Wed, Nov 16, 2016 at 10:19 AM, Benson Leung  wrote:
> > I'll be taking over maintainership of platform/chrome from Olof,
> > so let's add me to the list of maintainers.
> >
> > Signed-off-by: Benson Leung 
> 
> Acked-by: Olof Johansson 
>

Thanks Olof,

Hi Benson!

> I talked to Darren at Plumbers about drivers/platform/chrome, and
> whether he was open to merge that contents through his
> drivers/platform tree, and he was open to that.

+Andy Shevchenko, we co-maintain platform-drivers-x86

> Darren, meet Benson -- Benson will be picking up maintainership of the
> chrome platform code since I no longer have good access to hardware to
> test new changes. We didn't talk about the method of merging, if you
> prefer to get patches sent directly to you or if you're OK with
> merging a git branch from Benson. The latter might be easier for
> Benson, the former might be easier for you.

It depends a bit on what Benson is looking for from us. Are you looking for
close code review and inspection? I would assume not, that drivers/chrome is
something you expect to entirely own and you would like to roll it up to Linus
through us because it is small enough that it doesn't make sense to roll it up
independently? If that's accurate, then:

We don't currently have anything that we manage via pull requests, however
platform/chrome is sufficiently independent from the rest of our tree that I'm
open to using pull requests.

Benson, what would you prefer?

Olof, any suggestions on working with pull requests and rolling them up to
Linus?

  - Do you ask your sub-maintainers to have their code in -next before a pull
request to you? Assuming not.

In general, please use signed tags:

platform-drivers-chrome-v4.9-1
platform-drivers-chrome-v4.9-2
platform-drivers-chrome-v4.9-3

Plan to have the bulk of your changes sent to us in a pull request a week or two
before the merge window opens so they can bake a bit in our for-next branch.

>From there, there is a rapid taper off period from rc1 to rc4 or so in terms of
the types of changes, by rc4 and on we would expect only serious bug fixes.

> 
> In the past, the amount of code coming in through the platform/chrome
> tree has been relatively small, it's mostly been a matter of acking
> drivers going in through MFD or other trees. The main reason to split
> them out to a separate platform directory has been because it cuts
> across architectures and none of the previous ones were a good fit
> (i.e. drivers/platform/x86 was too narrow). I expect that to stay true
> as long as there are ARM Chromebooks, which is hopefully forever. :)
> 

Yes, that makes sense.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

[Matthew Garrett]

On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:

> First off, this "secure boot support" massive patchset has not gone
> anywhere yet, so why do this now?

Because David ended up with the short straw when distro maintainers 
talked about this at LPC.

> Secure boot is a trust that the previous boot process is now booting
> your image that it feels is secure (with various levels of "secure").
> It is not about "lock things down so no one can ever touch the hardware
> through different options, except through random logic[1] that we
> somehow trust "more" than configuration options.

If root is able to modify the behaviour of verified code after it was 
verified, then the value of that verification is reduced. Ensuring that 
the code remains trustworthy is vital in a number of security use cases.

> So, what are you really trying to "block" here?  The ability for someone
> to set an i/o port value?  why?  Why does it matter what root sets for
> an irq?  For a dma buffer?  For anything else?  What is preventing this
> going to "secure" somehow?

If root can tell a driver to probe for hardware at a specific address, 
and that driver will then blindly do so, root is trivially able to 
modify arbitrary kernel memory and disable arbitrary security features. 
IRQ or io port attacks are much more difficult to take advantage of, but 
I could imagine that some of them are still plausible.

> Overall, I really don't like this, and honestly, don't like the whole
> "secure boot" patchset either, as it is really a lot of work for
> absolutely no gain that I can see.  Who is "asking" for this type of
> thing, and what are their specific requirements?

Here's an example. The sysfs option to enable module signing is write 
once. If root sets that, root can't unset it. Except there's a whole 
bunch of ways that root *can* unset it, including kexec 
(https://mjg59.dreamwidth.org/28746.html) and a bunch of other things 
that are disabled by this patchset. That feature is entirely useless as 
is. This patchset helps make it useful.

Right now, the secure boot patchset is shipped by basically every single 
mainstream Linux distribution (and a whole bunch that are niche). Right 
now they're having to do extra work to rebase it and ensure that fixes 
get distributed to everyone. There's clearly demand, and Linus has been 
clear that features that are shipped by everyone should just go into 
mainline, so if there are *technical* objections then let's figure them 
out and otherwise just get this stuff merged.

--
Matthew Garrett | mj...@srcf.ucam.org

[PATCH 1/2] Add crypto driver support for some MediaTek chips

[Ryder Lee]

This adds support for the MediaTek hardware accelerator on
mt7623/mt2701/mt8521p SoC.

This driver currently implement:
- SHA1 and SHA2 family(HMAC) hash alogrithms.
- AES block cipher in CBC/ECB mode with 128/196/256 bits keys.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/mediatek/Makefile   |2 +
 drivers/crypto/mediatek/mtk-aes.c  |  734 +
 drivers/crypto/mediatek/mtk-platform.c |  575 +
 drivers/crypto/mediatek/mtk-platform.h |  230 ++
 drivers/crypto/mediatek/mtk-regs.h |  194 +
 drivers/crypto/mediatek/mtk-sha.c  | 1384 
 8 files changed, 3137 insertions(+)
 create mode 100644 drivers/crypto/mediatek/Makefile
 create mode 100644 drivers/crypto/mediatek/mtk-aes.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.h
 create mode 100644 drivers/crypto/mediatek/mtk-regs.h
 create mode 100644 drivers/crypto/mediatek/mtk-sha.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..5d9c803 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
  This driver interfaces with the hardware crypto accelerator.
  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
 
+config CRYPTO_DEV_MEDIATEK
+   tristate "MediaTek's Cryptographic Engine driver"
+   depends on ARM && ARCH_MEDIATEK
+   select NEON
+   select KERNEL_MODE_NEON
+   select ARM_CRYPTO
+   select CRYPTO_AES
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_SHA1_ARM_NEON
+   select CRYPTO_SHA256_ARM
+   select CRYPTO_SHA512_ARM
+   select CRYPTO_HMAC
+   help
+ This driver allows you to utilize the hardware crypto accelerator
+ which can be found on the MT7623 MT2701, MT8521p, etc 
+ Select this if you want to use it for AES/SHA1/SHA2 algorithms.
+
 source "drivers/crypto/chelsio/Kconfig"
 
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index ad7250f..272b51a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
 obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
+obj-$(CONFIG_CRYPTO_DEV_MEDIATEK) += mediatek/
 obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
 obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
 n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/mediatek/Makefile b/drivers/crypto/mediatek/Makefile
new file mode 100644
index 000..187be79
--- /dev/null
+++ b/drivers/crypto/mediatek/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MEDIATEK) += mtk-crypto.o
+mtk-crypto-objs:= mtk-platform.o mtk-aes.o mtk-sha.o
diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
new file mode 100644
index 000..feb0e57
--- /dev/null
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -0,0 +1,734 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for MediaTek AES hardware accelerator.
+ *
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Some ideas are from atmel-aes.c drivers.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "mtk-platform.h"
+#include "mtk-regs.h"
+
+#define AES_QUEUE_LENGTH   512
+#define AES_BUFFER_ORDER   2
+#define AES_BUFFER_SIZE((PAGE_SIZE << AES_BUFFER_ORDER) \
+   & ~(AES_BLOCK_SIZE - 1))
+
+/* AES command token */
+#define AES_CT_SIZE_ECB2
+#define AES_CT_SIZE_CBC3
+#define AES_CT_CTRL_HDR0x0022
+#define AES_COMMAND0   0x0500
+#define AES_COMMAND1   0x2d06
+#define AES_COMMAND2   0xe4a63806
+
+/* AES transform information */
+#define AES_TFM_ECB(0x0 << 0)
+#define AES_TFM_CBC(0x1 << 0)
+#define AES_TFM_DECRYPT(0x5 << 0)
+#define AES_TFM_ENCRYPT(0x4 << 0)
+#define AES_TFM_SIZE(x)((x) << 8)
+#define AES_TFM_128BITS(0xb << 16)
+#define AES_TFM_192BITS(0xd << 16)
+#define AES_TFM_256BITS(0xf << 16)
+#define AES_TFM_FULL_IV(0xf << 5)
+
+/* AES flags */
+#define AES_FLAGS_MODE_MSK GENMASK(2, 0)
+#define AES_FLAGS_ECB  BIT(0)
+#define AES_FLAGS_CBC  BIT(1)
+#define AES_FLAGS_ENCRYPT  BIT(2)
+#define AES_FLAGS_BUSY BIT(3)
+
+/* AES command token */
+struct mtk_aes_ct {
+   u32 ct_ctrl0;
+   u32 ct_ctrl1;
+   u32 ct_ctrl2;
+};
+
+/* AES

[PATCH 2/2] crypto: mediatek - add DT bindings documentation

[Ryder Lee]

Add DT bindings documentation for the crypto driver

Signed-off-by: Ryder Lee 
---
 .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt

diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt 
b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
new file mode 100644
index 000..8b1db08
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
@@ -0,0 +1,32 @@
+MediaTek cryptographic accelerators
+
+Required properties:
+- compatible: Should be "mediatek,mt7623-crypto"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the five crypto engines interrupts in numeric
+   order. These are global system and four descriptor rings.
+- clocks: the clock used by the core
+- clock-names: the names of the clock listed in the clocks property. These are
+   "ethif", "cryp"
+- power-domains: Must contain a reference to the PM domain.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+
+
+Example:
+   crypto: crypto@1b24 {
+   compatible = "mediatek,mt7623-crypto";
+   reg = <0 0x1b24 0 0x2>;
+   interrupts = ,
+,
+,
+,
+;
+   clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+<ðsys CLK_ETHSYS_CRYPTO>;
+   clock-names = "ethif","cryp";
+   power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+   };
-- 
1.9.1

[PATCH 0/2] Add MediaTek crypto acclelrator driver

[Ryder Lee]

This adds support for the MediaTek hardware accelerator on 
mt7623 SoC.

This driver currently implement: 
- SHA1 and SHA2 family(HMAC) hash alogrithms.
- AES block cipher in CBC/ECB mode with 128/196/256 bits keys.

Ryder Lee (2):
  Add crypto driver support for some MediaTek chips
  crypto: mediatek - add DT bindings documentation

 .../devicetree/bindings/crypto/mediatek-crypto.txt |   32 +
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/mediatek/Makefile   |2 +
 drivers/crypto/mediatek/mtk-aes.c  |  734 +++
 drivers/crypto/mediatek/mtk-platform.c |  575 
 drivers/crypto/mediatek/mtk-platform.h |  230 
 drivers/crypto/mediatek/mtk-regs.h |  194 +++
 drivers/crypto/mediatek/mtk-sha.c  | 1384 
 9 files changed, 3169 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
 create mode 100644 drivers/crypto/mediatek/Makefile
 create mode 100644 drivers/crypto/mediatek/mtk-aes.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.c
 create mode 100644 drivers/crypto/mediatek/mtk-platform.h
 create mode 100644 drivers/crypto/mediatek/mtk-regs.h
 create mode 100644 drivers/crypto/mediatek/mtk-sha.c

-- 
1.9.1

Re: [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support

[Xishi Qiu]

On 2016/12/2 10:38, Scott Branden wrote:

> Hi Xishi,
> 
> Thanks for the reply - please see comments below.
> 
> On 16-12-01 05:49 PM, Xishi Qiu wrote:
>> On 2016/12/2 8:19, Scott Branden wrote:
>>
>>> This patchset is sent for comment to add memory hotplug support for ARM64
>>> based platforms.  It follows hotplug code added for other architectures
>>> in the linux kernel.
>>>
>>> I tried testing the memory hotplug feature following documentation from
>>> Documentation/memory-hotplug.txt.  I don't think it is working as expected
>>> - see below:
>>>
>>> To add memory to the system I did the following:
>>> echo 0x4 > /sys/devices/system/memory/probe
>>>
>>> The memory is displayed as system ram:
>>> cat /proc/iomem:
>>> 7400-77ff : System RAM
>>>   7408-748d : Kernel code
>>>   7495-749d2fff : Kernel data
>>> 4-43fff : System RAM
>>>
>>> But does not seem to be added to the kernel memory.
>>> /proc/meminfo did not change.
>>>
>>> What else needs to be done so the memory is added to the kernel memory
>>> pool for normal allocation?
>>>
>>
>> Hi Scott,
>>
>> Do you mean it still don't support hod-add after apply this patchset?
> 
> After applying the patch it appears to partially support hot-add. Please let 
> me know if you think it is working as expected?
> 
> The memory probe functions in that the memory is registered with the system 
> and shows up in /proc/iomem.  But, the memory is not available in 
> /proc/meminfo.  Do you think something else needs to be adjusted for ARM64 to 
> hotadd the memory
> 
> I just found another clue:
> under /sys/devices/system/memory I only see one memory entry (before or after 
> I try to hotadd additional memory).
> 
> /sys/devices/system/memory # ls
> auto_online_blocks  memory0uevent
> block_size_bytesprobe
> 
> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 
> to 28 and recompile I get the following:
> /sys/devices/system/memory # ls
> auto_online_blocks  memory7uevent
> block_size_bytesprobe
> 
> 
> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 
> to 27 and recompile I get the following:
> /sys/devices/system/memory # ls
> auto_online_blocks  memory14uevent
> block_size_bytesprobe
> 
> If looks to me like something is not working properly in the ARM64 
> implementation.  I should expect to see multiple memoryX entries under 
> /sys/devices/system/memory?
> 

Hi Scott,

1. Do you enable the following configs?
CONFIG_SPARSEMEM
MEMORY_HOTPLUG
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE

2. I find you missed create mapping in arch_add_memory(), and x86 has it.

3. We will add memblock first, so pfn_valid() maybe always return true(in the
following function), and this will lead __add_section() failed. Please check
it.

int pfn_valid(unsigned long pfn)
{
return (pfn & PFN_MASK) == pfn && memblock_is_memory(pfn << PAGE_SHIFT);
}

add_memory
  add_memory_resource
memblock_add_node
  arch_add_memory
__add_pages
  __add_section
pfn_valid

Thanks,
Xishi Qiu

> 
> 
>>
>> Thanks,
>> Xishi Qiu
>>
>>> Scott Branden (2):
>>>   arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
>>> MEMORY_PROBE
>>>   arm64: defconfig: enable MEMORY_HOTPLUG config options
>>>
>>>  arch/arm64/Kconfig   | 10 ++
>>>  arch/arm64/configs/defconfig |  3 +++
>>>  arch/arm64/mm/init.c | 42 
>>> ++
>>>  3 files changed, 55 insertions(+)
>>>
>>
>>
>>
> 
> .
> 

Re: arm64: dts: zx: support cpu-freq for zx296718

[Viresh Kumar]

On 02-12-16, 10:36, Shawn Guo wrote:
> + Viresh, the author of the bindings.
> 
> On Thu, Dec 01, 2016 at 08:08:55PM +0800, Baoyou Xie wrote:
> > This patch adds the CPU clock phandle in CPU's node
> > and uses operating-points-v2 to register operating points.
> > 
> > So it can be used by cpufreq-dt driver.
> > 
> > Signed-off-by: Baoyou Xie 
> 
> Just out of curiosity, why is there no '[PATCH]' prefix in the subject?
> 
> > ---
> >  arch/arm64/boot/dts/zte/zx296718.dtsi | 37 
> > +++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi 
> > b/arch/arm64/boot/dts/zte/zx296718.dtsi
> > index 7a1aed7..16f7d5e 100644
> > --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> > +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> > @@ -44,6 +44,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  / {
> > compatible = "zte,zx296718";
> > @@ -81,6 +82,8 @@
> > compatible = "arm,cortex-a53","arm,armv8";
> > reg = <0x0 0x0>;
> > enable-method = "psci";
> > +   clocks = <&topcrm A53_GATE>;
> > +   operating-points-v2 = <&cluster0_opp>;
> > };
> >  
> > cpu1: cpu@1 {
> > @@ -88,6 +91,7 @@
> > compatible = "arm,cortex-a53","arm,armv8";
> > reg = <0x0 0x1>;
> > enable-method = "psci";
> > +   operating-points-v2 = <&cluster0_opp>;
> > };
> >  
> > cpu2: cpu@2 {
> > @@ -95,6 +99,7 @@
> > compatible = "arm,cortex-a53","arm,armv8";
> > reg = <0x0 0x2>;
> > enable-method = "psci";
> > +   operating-points-v2 = <&cluster0_opp>;
> > };
> >  
> > cpu3: cpu@3 {
> > @@ -102,6 +107,38 @@
> > compatible = "arm,cortex-a53","arm,armv8";
> > reg = <0x0 0x3>;
> > enable-method = "psci";
> > +   operating-points-v2 = <&cluster0_opp>;
> > +   };
> > +   };
> > +
> > +   cluster0_opp: opp_table0 {

Also, you better add "clocks" property in all above nodes.

-- 
viresh

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

[Masahiro Yamada]

Hi Rob,
(+CC Dinh)

2016-12-02 1:05 GMT+09:00 Rob Herring :
> On Sun, Nov 27, 2016 at 03:06:25AM +0900, Masahiro Yamada wrote:
>> Add two compatible strings for UniPhier SoCs.  The revision register
>> on both shows revision 5.0, but they are different hardware.
>>
>> Features:
>>  - DMA engine with 64 bit physical address support
>>  - 1024 byte ECC step size
>>  - 8 / 16 / 24 bit ECC strength
>>  - The n_banks format depends on SoC
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  .../devicetree/bindings/mtd/denali-nand.txt| 10 +--
>>  drivers/mtd/nand/denali_dt.c   | 33 
>> --
>>  2 files changed, 38 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt 
>> b/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> index 51fe195..cea46e2 100644
>> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
>> @@ -1,13 +1,19 @@
>>  * Denali NAND controller
>>
>>  Required properties:
>> -  - compatible : should be "denali,denali-nand-dt"
>> +  - compatible : should be one of the following:
>> +  "denali,denali-nand-dt"
>
> There are multiple things wrong with this string. denali,denali is
> redundant is one.

One more redundancy; "-dt" is weird because
DT compatible should be a name of hardware.


> It's also fairly useless as this IP has several
> versions and numerous configuration options IIRC. This should be
> deprecated IMO.

Right.  There are several customizable parameters for this IP,
so a generic compatible string like this is probably useless.

This DT binding was added by commit 30f9f2f for Altera SOCFPGA,
A funny thing is that they upstreamed DT binding, but they did not upstream
needed changes for the Denali driver core.
So, the mainline driver has never worked on SOCFPGA
(or any of DT-based SoCs).



>> +  "denali,denali-nand-uniphier-v5a"
>> +  "denali,denali-nand-uniphier-v5b"
>
> Use your vendor prefix, not denali. The 2nd denali can probably be
> dropped because it is not likely you have another kind of nand
> controller in the SoC.

Hmm, your statement implies that a vendor prefix
belongs to an SoC vendor, not an IP vendor.
(I was not quite sure about this.)


It is unlikely to happen to have two different NAND controllers on one SoC.
But, we used a different NAND controller for our SoC family before
introducing the Denali IP.
It also implies that Socionext may use a different NAND IP in the future.
I'd like to include "denali" somewhere because it is clearly associated with
the driver name.
Also, this will give an idea what kind of _basic_ hardware is used,
even though we know various parameters are customizable.



(Plan A)
  "denali,socfpga-nand"   (for Altera SOCFPGA variant)
  "denali,uniphier-nand-v1"   (for old Socionext UniPhier family variant)
  "denali,uniphier-nand-v2"   (for new Socionext UniPhier family variant)

(Plan B)
  "altera,denali-nand"(for Altera SOCFPGA variant)
  "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant)
  "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant)


I think Plan B is nearer to your suggestion,
and I think it is OK for Socionext (hopefully for Altera too).





-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas  wrote:
> Hi Duc,
>
> On Wed, Nov 30, 2016 at 03:42:53PM -0800, Duc Dang wrote:
>> PCIe controllers in X-Gene SoCs is not ECAM compliant: software
>> needs to configure additional controller's register to address
>> device at bus:dev:function.
>>
>> The quirk will only be applied for X-Gene PCIe MCFG table with
>> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>>
>> The quirk declares the X-Gene PCIe controller register space as 64KB
>> fixed memory resource with name "PCIe CSR". This name will be showed
>> next to the resource range in the output of "cat /proc/iomem".
>>
>> Signed-off-by: Duc Dang 
>> ---
>> v3:
>>   - Rebase on top of pci/ecam-v6 tree.
>>   - Use DEFINE_RES_MEM_NAMED to declare controller register space
>>   with name "PCIe CSR"
>> v2:
>>   RFC v2: https://patchwork.ozlabs.org/patch/686846/
>> v1:
>>   RFC v1: https://patchwork.kernel.org/patch/9337115/
>>
>>  drivers/acpi/pci_mcfg.c  |  31 
>>  drivers/pci/host/pci-xgene.c | 165 
>> ++-
>>  include/linux/pci-ecam.h |   7 ++
>>  3 files changed, 200 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index ac21db3..eb6125b 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -57,6 +57,37 @@ struct mcfg_fixup {
>>   { "QCOM  ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
>>   { "QCOM  ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
>>   { "QCOM  ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
>> +
>> +#ifdef CONFIG_PCI_XGENE
>
> As you've no doubt noticed, I'm proposing to add these quirks without
> CONFIG_PCI_XGENE, so we don't have to select each device when building
> a generic ACPI kernel.
>
> I'm also proposing some Kconfig and Makefile changes so we don't build
> the platform driver part in a generic ACPI kernel (unless we *also*
> explicitly select the platform driver).
>
> Here's an example:
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=f80edf4d6c05

I made similar changes in v4 patch. The ECAM quirk will be built when
ACPI and PCI_QUIRKS are enabled.

When building for DT only, the ECAM quirk won't be compiled.
>
>> +#define XGENE_V1_ECAM_MCFG(rev, seg) \
>> + {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
>> + &xgene_v1_pcie_ecam_ops }
>> +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
>> + {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
>> + &xgene_v2_1_pcie_ecam_ops }
>> +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
>> + {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
>> + &xgene_v2_2_pcie_ecam_ops }
>> +
>> + /* X-Gene SoC with v1 PCIe controller */
>> + XGENE_V1_ECAM_MCFG(1, 0),
>> + XGENE_V1_ECAM_MCFG(1, 1),
>
>> @@ -64,6 +66,7 @@
>>  /* PCIe IP version */
>>  #define XGENE_PCIE_IP_VER_UNKN   0
>>  #define XGENE_PCIE_IP_VER_1  1
>> +#define XGENE_PCIE_IP_VER_2  2
>
> This isn't used anywhere, which makes me wonder whether it's worth
> keeping it.

V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
XGENE_PCIE_IP_VER_2). This will be used to indicate that the
controller is V2, and to enable configuration request retry status
feature (by not disable it like V1 controller).

>
>>  static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
>>  {
>> - struct xgene_pcie_port *port = bus->sysdata;
>> + struct pci_config_window *cfg;
>> + struct xgene_pcie_port *port;
>> +
>> + if (acpi_disabled)
>> + port = bus->sysdata;
>> + else {
>> + cfg = bus->sysdata;
>> + port = cfg->priv;
>> + }
>
> I would really, really like to figure out a way to get rid of these
> "if (acpi_disabled)" checks sprinkled through here.  Is there any way
> we can set up bus->sysdata to be the same, regardless of whether we're
> using this as a platform driver or an ACPI quirk?

Right now, I created a inline function to extract xgene_pcie_port from
pci_bus. In order to get rid of acpi_disabled, I will need to make
sysdata in DT case also point to pci_config_window structure, which
means I will need to convert and test the DT driver to use ecam ops.
It is a separate patch itself. So I think I should do it at later time
(after this ECAM quirk patch). I hope you are ok with this.

>
>> +#ifdef CONFIG_ACPI
>
> You've probably noticed that I've been using
>
>   #if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)
>
> in this situation, mostly to make it clear that this is part of a
> workaround.  I don't want people to blindly copy this stuff without
> realizing that it's a workaround for a hardware issue.

Yes, I used defined(CONFIG_PCI_QUIRKS) in v4 patch as well.
>
>> +static struct resource xgene_v1_csr_res[] = {
>> + [0] = DEFINE_RES_MEM_NAMED(0x1f2bUL, SZ_64K, "PCIe CSR"),
>> + [1] = DEFINE_RES_MEM_NAMED(0x1f2cUL, SZ_64K, "

Re: [PATCH v3 2/2] HID: i2c-hid: support regulator power on/off

[Brian Norris]

On Thu, Dec 01, 2016 at 05:16:15PM -0800, Dmitry Torokhov wrote:
> On Thu, Dec 01, 2016 at 04:42:15PM -0800, Brian Norris wrote:
> > On Thu, Dec 01, 2016 at 04:37:37PM -0800, Dmitry Torokhov wrote:
> > > On Thu, Dec 01, 2016 at 04:31:10PM -0800, Brian Norris wrote:
> > > > On some boards, we need to enable a regulator before using the HID, and
> > > > it's also nice to save power in suspend by disabling it. Support an
> > > > optional "vdd-supply" and a companion initialization delay.
> > > > 
> > > > Signed-off-by: Brian Norris 
> > > > Signed-off-by: Caesar Wang 
> > > > Cc: Jiri Kosina 
> > > > Cc: linux-in...@vger.kernel.org
> > > > ---
> > > > v2:
> > > >  * support compatible property for wacom, with specific "vdd-supply" 
> > > > name
> > > >  * support the 100ms delay needed for this digitizer
> > > >  * target regulator support only at specific device
> > > > 
> > > > v3:
> > > >  * drop Wacom specifics and allow this to be used generically
> > > >  * add "init-delay-ms" property support
> > > > 
> > > >  drivers/hid/i2c-hid/i2c-hid.c | 48 
> > > > ++-
> > > >  include/linux/i2c/i2c-hid.h   |  6 ++
> > > >  2 files changed, 53 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/hid/i2c-hid/i2c-hid.c 
> > > > b/drivers/hid/i2c-hid/i2c-hid.c
> > > > index b3ec4f2de875..4cb523133d13 100644
> > > > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > > > +++ b/drivers/hid/i2c-hid/i2c-hid.c

...

> > > > @@ -937,6 +939,22 @@ static int i2c_hid_of_probe(struct i2c_client 
> > > > *client,
> > > > }
> > > > pdata->hid_descriptor_address = val;
> > > >  
> > > > +   ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val);
> > > > +   if (!ret)
> > > > +   pdata->init_delay_ms = ret;
> > > > +
> > > > +   pdata->supply = devm_regulator_get_optional(dev, "vdd");
> > > 
> > > Make it devm_regulator_get(), it's cleaner (you'll get a dummy regulator
> > > that you can enable/disbale and not check if it is null or not).
> > > 
> > >   pdata->supply = devm_regulator_get_optional(dev, "vdd");
> > >   if (IS_ERR(pdata->supply)) {
> > >   ret = PTR_ERR(pdata->supply);
> > >   if (ret != -EPROBE_DEFER)
> > >   dev_err(...);
> > >   return ret;
> > >   }
> > 
> > I had it as devm_regulator_get() in v1, but at that time, I was faking
> > the firmware init delay using a regulator property. Now that I want to
> > delay in this driver after enabling the regulator, I'd like to know the
> > difference between a dummy and a real regulator. There's no need to wait
> > after messing with the dummy regulator.
> 
> If there is no regulator in ACPI/DT there would not be "init-delay-ms"
> property either.

I suppose that's a fair assumption... the difference being that you
assumed it, and I enforced it :)

Anyway, I can respin without the _optional(). I'll wait at least a day
or so, as the DT binding could use some review (it's the more
controversial piece).

Brian

Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command

[Baolin Wang]

On 2 December 2016 at 09:17, Lu Baolu  wrote:
> Hi,
>
> On 12/01/2016 04:03 PM, Baolin Wang wrote:
>> On 1 December 2016 at 15:44, Lu Baolu  wrote:
>>> Hi,
>>>
>>> On 12/01/2016 03:35 PM, Baolin Wang wrote:
 On 1 December 2016 at 14:35, Lu Baolu  wrote:
> Hi,
>
> On 12/01/2016 02:04 PM, Baolin Wang wrote:
>> Hi Baolu,
>>
>> On 1 December 2016 at 13:45, Lu Baolu  wrote:
>>> Hi,
>>>
>>> On 11/30/2016 05:02 PM, Baolin Wang wrote:
 If the hardware never responds to the stop endpoint command, the
 URBs will never be completed, and we might hang the USB subsystem.
 The original watchdog timer is used to watch if one stop endpoint
 command is timeout, if timeout, then the watchdog timer will set
 XHCI_STATE_DYING, try to halt the xHCI host, and give back all
 pending URBs.

 But now we already have one command timer to control command timeout,
 thus we can also use the command timer to watch the stop endpoint
 command, instead of one duplicate watchdog timer which need to be
 removed.

 Meanwhile we don't need the 'stop_cmds_pending' flag to identy if
 this is the last stop endpoint command of one endpoint. Since we
 can make sure we only set one stop endpoint command for one endpoint
 by 'EP_HALT_PENDING' flag in xhci_urb_dequeue() function. Thus remove
 this flag.
>>> I am afraid you can't do this. "stop_cmds_pending" was added
>>> to fix the problem described in the comments that you want to
>>> remove. But I didn't find any fix of this problem in your patch.
>> Now we can not pending another stop endpoint command for the same one
>> endpoint, since will check 'EP_HALT_PENDING' flag in
>> xhci_urb_dequeue() function to avoid this. But after some
>> investigation, I think I missed the stop endpoint command in
>> xhci_stop_device() which did not check the 'EP_HALT_PENDING' flag,
>> maybe need to add 'EP_HALT_PENDING' flag checking in
>> xhci_stop_device() function. DId I miss something else? Thanks.
> Consider below three threads running on different CPUs at the same time.
>
> Thread A: xhci_handle_cmd_stop_ep()  --- in interrupt handler
> Thread B: xhci_stop_endpoint_command_timeout() --- timer expired
> Thread C: xhci_urb_dequeue --- called by usb core
>
> They are serialized by xhci->lock. Let's consider below sequence:
>
> Thread A:
> - delete xhci->cmd_timer), but will fail due to Thread B.
> - clear EP_HALT_PENDING bit
>
> Thread B:
> - halt the host controller
>
> Thread C:
> - set EP_HALT_PENDING bit
> - enqueue another stop endpoint command
> - add the timer back
 Ah, thanks for you comments.
 If thread B halted the host, then the thread C xhci_urb_dequeue() will
 check host state failed, then just return and can not set another stop
 endpoint command.
>>> Not so simple. Thread B will release xhci->lock before xhci_halt().
>> Yes.
>>
 But from your example, I think your meaning is we
 should not halt the host by thread B, since we have handled the stop
 endpoint command event.

 So I think we need to check the xhci command of this stop endpoint
 command in xhci_stop_endpoint_command_timeout(), if the xhci command
 of this stop endpoint command is not in the command list (which means
 the stop endpoint command event has been handled), then just return
 and do not halt the controller. Right?

>>> I'd like suggest you to put this change into a separated patch.
>>> It's actually a different topic from the main purpose of this patch.
>> OK, I will. Thanks for your comments.
>>
>
> If you are going to work out a v2 patch, please consider whether
> we can totally leverage the common command mechanism to
> handle this stop endpoint command.
>
> Currently, when a stop endpoint command is issued for urb unlink,
> there are two timers for this command. This is duplicated and we
> should remove the stop-endpoint-only timer. The timeout functions
> are also different. The stop-endpoint-only timer just halt the host
> controller (this should be the last sort of way), while the common
> command timer will try to recover the situation by aborting and
> restart the command ring.

Yes, thanks for your reminding and I will think about that.

-- 
Baolin.wang
Best Regards

Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command

[Baolin Wang]

On 1 December 2016 at 21:28, Mathias Nyman
 wrote:
> On 01.12.2016 06:54, Baolin Wang wrote:
>>
>> On 30 November 2016 at 22:09, Mathias Nyman
>>  wrote:
>>>
>>> On 30.11.2016 11:02, Baolin Wang wrote:


 If the hardware never responds to the stop endpoint command, the
 URBs will never be completed, and we might hang the USB subsystem.
 The original watchdog timer is used to watch if one stop endpoint
 command is timeout, if timeout, then the watchdog timer will set
 XHCI_STATE_DYING, try to halt the xHCI host, and give back all
 pending URBs.

 But now we already have one command timer to control command timeout,
 thus we can also use the command timer to watch the stop endpoint
 command, instead of one duplicate watchdog timer which need to be
 removed.

 Meanwhile we don't need the 'stop_cmds_pending' flag to identy if
 this is the last stop endpoint command of one endpoint. Since we
 can make sure we only set one stop endpoint command for one endpoint
 by 'EP_HALT_PENDING' flag in xhci_urb_dequeue() function. Thus remove
 this flag.

 We also need to clean up the command queue before trying to halt the
 xHCI host in xhci_stop_endpoint_command_timeout() function.
>>>
>>>
>>>
>>> This isn't a bad idea.
>>>
>>> There are anyway some corner cases and details that need to be
>>> checked, such as suspend (which will clear the command queue), module
>>> unload
>>> and abrupt host removal (like pci hotplug removal of host controller)
>>> we need to make sure we can trust the command timer to always return the
>>> canceled URB
>>
>>
>> Yes, you are right, we need to check these carefully.
>>
>> Suspend process, module unload and abrupt host removal, they all will
>> issue usb_disconnect() firstly before clear the command queue, it will
>> check URBs for every endpoint by
>> usb_disconnect()--->usb_disable_device()--->usb_disable_endpoint(),
>> which will make sure every URBs of endpoints will be cancelled by the
>> stop endpoint command responding or the timeout function of stop
>> endpoint command (xhci_stop_endpoint_command_timeout()) in
>> usb_hcd_flush_endpoint(). From that point, we can make sure the
>> command timer will be useful to handle stop endpoint command timeout.
>> Please correct me if I said something wrong. Thanks.
>>
>
> This relies on current queued command that times out to be the stop endpoint
> command.
>
> If host partially, or completely hangs there might be any number of commands
> in the
> command queue, and we would need to wait for each one of them to timeout,
> finish
> before we finally get to the stop endpoint command, and give back the urb.
>
> I think it would be better to first fix the issues with the current watchdog
> function, get
> those fixes into stable, and then think about moving to the command queue
> timer.

OK, make sense. Thanks.

>
> In short, this patch doesn't currently fix any existing issue, but might
> cause the
> timeout to be more unreliable
>
> -Mathias



-- 
Baolin.wang
Best Regards

Re: [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support

[Scott Branden]

Hi Xishi,

Thanks for the reply - please see comments below.

On 16-12-01 05:49 PM, Xishi Qiu wrote:

On 2016/12/2 8:19, Scott Branden wrote:


This patchset is sent for comment to add memory hotplug support for ARM64
based platforms.  It follows hotplug code added for other architectures
in the linux kernel.

I tried testing the memory hotplug feature following documentation from
Documentation/memory-hotplug.txt.  I don't think it is working as expected
- see below:

To add memory to the system I did the following:
echo 0x4 > /sys/devices/system/memory/probe

The memory is displayed as system ram:
cat /proc/iomem:
7400-77ff : System RAM
  7408-748d : Kernel code
  7495-749d2fff : Kernel data
4-43fff : System RAM

But does not seem to be added to the kernel memory.
/proc/meminfo did not change.

What else needs to be done so the memory is added to the kernel memory
pool for normal allocation?



Hi Scott,

Do you mean it still don't support hod-add after apply this patchset?


After applying the patch it appears to partially support hot-add. 
Please let me know if you think it is working as expected?


The memory probe functions in that the memory is registered with the 
system and shows up in /proc/iomem.  But, the memory is not available in 
/proc/meminfo.  Do you think something else needs to be adjusted for 
ARM64 to hotadd the memory


I just found another clue:
under /sys/devices/system/memory I only see one memory entry (before or 
after I try to hotadd additional memory).


/sys/devices/system/memory # ls
auto_online_blocks  memory0uevent
block_size_bytesprobe

In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 
30 to 28 and recompile I get the following:

/sys/devices/system/memory # ls
auto_online_blocks  memory7uevent
block_size_bytesprobe


In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 
30 to 27 and recompile I get the following:

/sys/devices/system/memory # ls
auto_online_blocks  memory14uevent
block_size_bytesprobe

If looks to me like something is not working properly in the ARM64 
implementation.  I should expect to see multiple memoryX entries under 
/sys/devices/system/memory?






Thanks,
Xishi Qiu


Scott Branden (2):
  arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
MEMORY_PROBE
  arm64: defconfig: enable MEMORY_HOTPLUG config options

 arch/arm64/Kconfig   | 10 ++
 arch/arm64/configs/defconfig |  3 +++
 arch/arm64/mm/init.c | 42 ++
 3 files changed, 55 insertions(+)

[PATCH v1] mtk-vcodec: use V4L2_DEC_CMD_STOP to implement flush

[Wu-Cheng Li]

From: Wu-Cheng Li 

This patch uses V4L2_DEC_CMD_STOP to implement flush -- requesting
the remaining images to be returned to userspace. The old unofficial
way was to use a size-0 input buffer and the code is removed.

Tiffany Lin (1):
  mtk-vcodec: use V4L2_DEC_CMD_STOP to implement flush

 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 151 ++---
 .../media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c |  14 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |   2 +
 3 files changed, 117 insertions(+), 50 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

[PATCH v1] mtk-vcodec: use V4L2_DEC_CMD_STOP to implement flush

[Wu-Cheng Li]

From: Tiffany Lin 

Also remove the code using size-0 OUTPUT buffer to flush.

Singed-off-by: Tiffany Lin 
Signed-off-by: Wu-Cheng Li 
Reviewed-by: Kuang-che Wu 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 151 ++---
 .../media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c |  14 ++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |   2 +
 3 files changed, 117 insertions(+), 50 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0746592..407c8ba 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -351,16 +351,6 @@ static void mtk_vdec_worker(struct work_struct *work)
dst_vb2_v4l2 = container_of(dst_buf, struct vb2_v4l2_buffer, vb2_buf);
dst_buf_info = container_of(dst_vb2_v4l2, struct mtk_video_dec_buf, vb);
 
-   buf.va = vb2_plane_vaddr(src_buf, 0);
-   buf.dma_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
-   buf.size = (size_t)src_buf->planes[0].bytesused;
-   if (!buf.va) {
-   v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
-   mtk_v4l2_err("[%d] id=%d src_addr is NULL!!",
-   ctx->id, src_buf->index);
-   return;
-   }
-
pfb = &dst_buf_info->frame_buffer;
pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
@@ -371,8 +361,6 @@ static void mtk_vdec_worker(struct work_struct *work)
pfb->base_c.size = ctx->picinfo.c_bs_sz + ctx->picinfo.c_len_sz;
pfb->status = 0;
mtk_v4l2_debug(3, "===>[%d] vdec_if_decode() ===>", ctx->id);
-   mtk_v4l2_debug(3, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
-   ctx->id, buf.va, &buf.dma_addr, buf.size, src_buf);
 
mtk_v4l2_debug(3,
"id=%d Framebuf  pfb=%p VA=%p Y_DMA=%pad C_DMA=%pad 
Size=%zx",
@@ -381,24 +369,36 @@ static void mtk_vdec_worker(struct work_struct *work)
&pfb->base_c.dma_addr, pfb->base_y.size);
 
if (src_buf_info->lastframe) {
-   /* update src buf status */
+   mtk_v4l2_debug(1, "Got empty flush input buffer.");
src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
-   src_buf_info->lastframe = false;
-   v4l2_m2m_buf_done(&src_buf_info->vb, VB2_BUF_STATE_DONE);
 
/* update dst buf status */
dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
+   mutex_lock(&ctx->lock);
dst_buf_info->used = false;
+   mutex_unlock(&ctx->lock);
 
vdec_if_decode(ctx, NULL, NULL, &res_chg);
clean_display_buffer(ctx);
vb2_set_plane_payload(&dst_buf_info->vb.vb2_buf, 0, 0);
vb2_set_plane_payload(&dst_buf_info->vb.vb2_buf, 1, 0);
+   dst_vb2_v4l2->flags |= V4L2_BUF_FLAG_LAST;
v4l2_m2m_buf_done(&dst_buf_info->vb, VB2_BUF_STATE_DONE);
clean_free_buffer(ctx);
v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
return;
}
+   buf.va = vb2_plane_vaddr(src_buf, 0);
+   buf.dma_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
+   buf.size = (size_t)src_buf->planes[0].bytesused;
+   if (!buf.va) {
+   v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
+   mtk_v4l2_err("[%d] id=%d src_addr is NULL!!",
+   ctx->id, src_buf->index);
+   return;
+   }
+   mtk_v4l2_debug(3, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
+   ctx->id, buf.va, &buf.dma_addr, buf.size, src_buf);
dst_buf_info->vb.vb2_buf.timestamp
= src_buf_info->vb.vb2_buf.timestamp;
dst_buf_info->vb.timecode
@@ -412,10 +412,9 @@ static void mtk_vdec_worker(struct work_struct *work)
 
if (ret) {
mtk_v4l2_err(
-   " <===[%d], src_buf[%d]%d sz=0x%zx pts=%llu dst_buf[%d] 
vdec_if_decode() ret=%d res_chg=%d===>",
+   " <===[%d], src_buf[%d] sz=0x%zx pts=%llu dst_buf[%d] 
vdec_if_decode() ret=%d res_chg=%d===>",
ctx->id,
src_buf->index,
-   src_buf_info->lastframe,
buf.size,
src_buf_info->vb.vb2_buf.timestamp,
dst_buf->index,
@@ -456,6 +455,65 @@ static void mtk_vdec_worker(struct work_struct *work)
v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
 }
 
+static int vidioc_try_decoder_cmd(struct file *file, void *priv,
+   struct v4l2_decoder_cmd *cmd)
+{
+   switch (cmd->cmd) {
+   case V4L2_DEC_CMD_STOP:
+   case V4L2_DEC_CMD_START:
+   if (cmd->flags != 0) {
+  

Re: arm64: dts: zx: support cpu-freq for zx296718

[Shawn Guo]

+ Viresh, the author of the bindings.

On Thu, Dec 01, 2016 at 08:08:55PM +0800, Baoyou Xie wrote:
> This patch adds the CPU clock phandle in CPU's node
> and uses operating-points-v2 to register operating points.
> 
> So it can be used by cpufreq-dt driver.
> 
> Signed-off-by: Baoyou Xie 

Just out of curiosity, why is there no '[PATCH]' prefix in the subject?

> ---
>  arch/arm64/boot/dts/zte/zx296718.dtsi | 37 
> +++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi 
> b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index 7a1aed7..16f7d5e 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  / {
>   compatible = "zte,zx296718";
> @@ -81,6 +82,8 @@
>   compatible = "arm,cortex-a53","arm,armv8";
>   reg = <0x0 0x0>;
>   enable-method = "psci";
> + clocks = <&topcrm A53_GATE>;
> + operating-points-v2 = <&cluster0_opp>;
>   };
>  
>   cpu1: cpu@1 {
> @@ -88,6 +91,7 @@
>   compatible = "arm,cortex-a53","arm,armv8";
>   reg = <0x0 0x1>;
>   enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
>   };
>  
>   cpu2: cpu@2 {
> @@ -95,6 +99,7 @@
>   compatible = "arm,cortex-a53","arm,armv8";
>   reg = <0x0 0x2>;
>   enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
>   };
>  
>   cpu3: cpu@3 {
> @@ -102,6 +107,38 @@
>   compatible = "arm,cortex-a53","arm,armv8";
>   reg = <0x0 0x3>;
>   enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> + };
> + };
> +
> + cluster0_opp: opp_table0 {

I know this is how examples in the bindings doc written, but it's
recommended to use hyphen rather than underscore in node name.  That
said, the following naming form is better.

cluster0_opp: opp-table0

> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@5 {
> + opp-hz = /bits/ 64 <5>;
> + opp-microvolt = <857000>;
> + clock-latency-ns = <50>;
> + };

We prefer to have a newline between nodes.

> + opp@64800 {
> + opp-hz = /bits/ 64 <64800>;
> + opp-microvolt = <857000>;
> + clock-latency-ns = <50>;
> + };
> + opp@8 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <882000>;
> + clock-latency-ns = <50>;
> + };
> + opp@10 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = <892000>;
> + clock-latency-ns = <50>;
> + };
> + opp@118800 {
> + opp-hz = /bits/ 64 <118800>;
> + opp-microvolt = <1009000>;

So we have 5 setpoints with different frequency-voltage pair.  I have
seen 'clocks' specified in cpu0 node and understand how frequency
scaling works.  But what about voltage scaling?  There is no
'cpu-supply' defined, and how does voltage scale among these
opp-microvolt settings?

Another related question: if we do not support voltage scaling for now,
what's the actually voltage when system is up running?  Is that voltage
safe for cpu to run at all those 5 frequencies?

Shawn

> + clock-latency-ns = <50>;
>   };
>   };
>  
> -- 
> 2.7.4
> 

[PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle

[Brian Norris]

We're going to need to amend this table in board files.

Signed-off-by: Brian Norris 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 66a11d1a6eac..28772f6e77f0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -606,7 +606,7 @@
status = "disabled";
};
 
-   thermal-zones {
+   thermal_zones: thermal-zones {
cpu_thermal: cpu {
polling-delay-passive = <100>;
polling-delay = <1000>;
-- 
2.8.0.rc3.226.g39d4020

[PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Brian Norris]

Add the dwc3 usb needed node information for rk3399.

Signed-off-by: Brian Norris 
---
Somewhat rewritten from Caesar's reposting (v2) of my patch.

Changes:
 * Include USB2 PHY (which is now in -next)
 * Don't include USB3 PHY, as extcon support is not ready yet
 * Drop non-upstream properties
 * Fixup whitespace a bit
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60 
 1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4ca8f9a7601c..1e97fb8c6415 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -316,6 +316,66 @@
};
};
 
+   usbdrd3_0: usb@fe80 {
+   compatible = "rockchip,rk3399-dwc3";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+<&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+<&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+   clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
+ "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "aclk_usb3_grf";
+   resets = <&cru SRST_A_USB3_OTG0>;
+   reset-names = "usb3-otg";
+   status = "disabled";
+
+   usbdrd_dwc3_0: dwc3 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0xfe80 0x0 0x10>;
+   interrupts = ;
+   dr_mode = "otg";
+   phys = <&u2phy0_otg>;
+   phy-names = "usb2-phy";
+   snps,dis_enblslpm_quirk;
+   snps,dis-u2-freeclk-exists-quirk;
+   snps,dis_u2_susphy_quirk;
+   snps,dis-del-phy-power-chg-quirk;
+   status = "disabled";
+   };
+   };
+
+   usbdrd3_1: usb@fe90 {
+   compatible = "rockchip,rk3399-dwc3";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+<&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+<&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+   clock-names = "clk_usb3otg1_ref", "clk_usb3otg1_suspend",
+ "aclk_usb3otg1", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "aclk_usb3_grf";
+   resets = <&cru SRST_A_USB3_OTG1>;
+   reset-names = "usb3-otg";
+   status = "disabled";
+
+   usbdrd_dwc3_1: dwc3 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0xfe90 0x0 0x10>;
+   interrupts = ;
+   dr_mode = "otg";
+   phys = <&u2phy1_otg>;
+   phy-names = "usb2-phy";
+   snps,dis_enblslpm_quirk;
+   snps,dis-u2-freeclk-exists-quirk;
+   snps,dis_u2_susphy_quirk;
+   snps,dis-del-phy-power-chg-quirk;
+   status = "disabled";
+   };
+   };
+
usb_host0_ehci: usb@fe38 {
compatible = "generic-ehci";
reg = <0x0 0xfe38 0x0 0x2>;
-- 
2.8.0.rc3.226.g39d4020

[PATCH 7/9] arm64: dts: rockchip: add Gru/Kevin DTS

[Brian Norris]

Kevin is part of a family of boards called Gru. As best as possible, the
properties shared by the Gru family are placed in rk3399-gru.dtsi, while
Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full
support for the base Gru board.

Working and tested (to some extent):
 * EC support -- including keyboard, battery, PWM, and probably more
 * UART / console
 * Thermal
 * Touchscreen
 * Touchpad
 * Digitizer (regulator still WIP)
 * PCIe / Wifi
 * Bluetooth / Webcam
 * SD card
 * eMMC
 * USB2 on TypeC
   - This works much of the time, but USB3 devices may or may not detect
 properly. Waiting on proper extcon support for USB3 over TypeC.
   - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed
 * Backlight

Not working:
 * CPUFreq -- relies on special OVP support for our PWM regulator
   circuits
 * EC / extcon support -- and with it, USB3/TypeC/DP
 * DRM -- won't even build on ARM64, so all display, eDP, etc. is not
   enabled

Not tested:
 * Audio

Signed-off-by: Brian Norris 
---
 arch/arm64/boot/dts/rockchip/Makefile |1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts |  312 +++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi  | 1006 +
 3 files changed, 1319 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index 3a862894ea44..b82f7b61ab6f 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
new file mode 100644
index ..66db785375a8
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -0,0 +1,312 @@
+/*
+ * Google Gru-Kevin Rev 6+ board device tree source
+ *
+ * Copyright 2016 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3399-gru.dtsi"
+#include 
+
+/*
+ * Kevin-specific things
+ *
+ * Things in this section should use names from Kevin schematic since no
+ * equivalent exists in Gru schematic.  If referring to signals that exist
+ * in Gru we use the Gru names, though.  Confusing enough for you?
+ */
+/ {
+   model = "Google Kevin";
+   compatible = "google,kevin-rev15", "google,kevin-rev14",
+"google,kevin-rev13", "google,kevin-rev12",
+"google,kevin-rev11", "google,kevin-rev10",
+"google,kevin-rev9", "google,kevin-rev8",
+"google,kevin-rev7", "google,kevin-rev6",
+"google,kevin", "google,gru",

[PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl

[Brian Norris]

We haven't enabled eDP support yet, but we might as well describe the
pin now.

Signed-off-by: Brian Norris 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 28772f6e77f0..4ca8f9a7601c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1435,6 +1435,13 @@
};
};
 
+   edp {
+   edp_hpd: edp-hpd {
+   rockchip,pins =
+   <4 23 RK_FUNC_2 &pcfg_pull_none>;
+   };
+   };
+
gmac {
rgmii_pins: rgmii-pins {
rockchip,pins =
-- 
2.8.0.rc3.226.g39d4020

[PATCH 0/9] arm64: dts: rockchip: support Google Kevin

[Brian Norris]

Hi,

This series adds basic support for Google Kevin, a board in the Gru device
family. I do not add a leaf .dts board file for Gru, but I have retained the
split between "things that apply to the Gru family" (rk3399-gru.dtsi) and
"things that apply to Kevin only" (rk3399-gru-kevin.dtsi).

I've included resends of two patches (adding cros-ec*.dtsi symlinks, and adding
RK3399 DWC3). The former is unmodified, but the latter is rewritten to match
current upstream bindings better, and to allow it to function w/o extcon
support (USB2 only).

AFAICT, all these bindings are in -next, except for the root node compatible
property (added doc in this series) and some of the HID digitizer bindings (see
patch 9; bindings were sent separately).

I elaborate on what's working/not working below, but one of the big missing
pieces is cpufreq support. We still need some more work on getting good
bindings and driver support upstream for the PWM regulator + OVP circuit on
these boards. See patch 8 for more info.

Working and tested (to some extent):
 * EC support -- including keyboard, battery, PWM, and probably more
 * UART / console
 * Thermal
 * Touchscreen
 * Touchpad
 * Digitizer (regulator still WIP)
 * PCIe / Wifi
 * Bluetooth / Webcam
 * SD card
 * eMMC
 * USB2 on TypeC
   - This works much of the time, but USB3 devices may or may not detect
 properly. Waiting on proper extcon support for USB3 over TypeC.
   - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed
 * Backlight

Not working:
 * CPUFreq -- relies on special OVP support for our PWM regulator
   circuits
 * EC / extcon support -- and with it, USB3/TypeC/DP
 * DRM -- won't even build on ARM64, so all display, eDP, etc. is not
   enabled

Not tested:
 * Audio


Brian Norris (8):
  arm64: dts: rockchip: add rk3399 thermal_zones phandle
  arm64: dts: rockchip: add rk3399 eDP HPD pinctrl
  arm64: dts: rockchip: support dwc3 USB for rk3399
  arm64: dts: rockchip: add rk3399 OPPs
  dt-bindings: Document rk3399 Gru/Kevin
  arm64: dts: rockchip: add Gru/Kevin DTS
  arm64: dts: rockchip: partially describe PWM regulators for Gru
  arm64: dts: rockchip: add regulator info for Kevin digitizer

Douglas Anderson (1):
  arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs

 Documentation/devicetree/bindings/arm/rockchip.txt |   20 +
 .../boot/dts/include/common/cros-ec-keyboard.dtsi  |1 +
 .../arm64/boot/dts/include/common/cros-ec-sbs.dtsi |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  |  315 ++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   | 1152 
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi   |  145 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   70 +-
 8 files changed, 1704 insertions(+), 1 deletion(-)
 create mode 12 arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
 create mode 12 arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

-- 
2.8.0.rc3.226.g39d4020

[PATCH v4 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

[Duc Dang]

PCIe controllers in X-Gene SoCs is not ECAM compliant: software
needs to configure additional controller's register to address
device at bus:dev:function.

The quirk will discover controller MMIO register space and configure
controller registers to select and address the target secondary device.

The quirk will only be applied for X-Gene PCIe MCFG table with
OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).

Signed-off-by: Duc Dang 
---
v4:
  - Rebase on top of pci/ecam tree
  - Introduce xgene_get_csr_resource to discover MMIO register space
  (per Mark's test code).
  - Refactor .init functions for pci_ecam_ops to reuse common code
  - Introduce pcie_bus_to_port to extract X-Gene 'port' information
  from 'bus' device.
  - Kconfig/Makefile changes to only compile required code for ACPI
v3:
  - Rebase on top of pci/ecam-v6 tree.
  - Use DEFINE_RES_MEM_NAMED to declare controller register space
  with name "PCIe CSR"
v2:
  RFC v2: https://patchwork.ozlabs.org/patch/686846/
v1:
  RFC v1: https://patchwork.kernel.org/patch/9337115/
---
 drivers/acpi/pci_mcfg.c  |  25 +
 drivers/pci/host/Kconfig |   4 +-
 drivers/pci/host/Makefile|   2 +-
 drivers/pci/host/pci-xgene.c | 127 ---
 include/linux/pci-ecam.h |   2 +
 5 files changed, 150 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index d34d196..7319188 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -108,6 +108,31 @@ struct mcfg_fixup {
THUNDER_ECAM_QUIRK(2, 11),
THUNDER_ECAM_QUIRK(2, 12),
THUNDER_ECAM_QUIRK(2, 13),
+
+#define XGENE_V1_ECAM_MCFG(rev, seg) \
+   {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
+   &xgene_v1_pcie_ecam_ops }
+#define XGENE_V2_ECAM_MCFG(rev, seg) \
+   {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
+   &xgene_v2_pcie_ecam_ops }
+   /* X-Gene SoC with v1 PCIe controller */
+   XGENE_V1_ECAM_MCFG(1, 0),
+   XGENE_V1_ECAM_MCFG(1, 1),
+   XGENE_V1_ECAM_MCFG(1, 2),
+   XGENE_V1_ECAM_MCFG(1, 3),
+   XGENE_V1_ECAM_MCFG(1, 4),
+   XGENE_V1_ECAM_MCFG(2, 0),
+   XGENE_V1_ECAM_MCFG(2, 1),
+   XGENE_V1_ECAM_MCFG(2, 2),
+   XGENE_V1_ECAM_MCFG(2, 3),
+   XGENE_V1_ECAM_MCFG(2, 4),
+   /* X-Gene SoC with v2.1 PCIe controller */
+   XGENE_V2_ECAM_MCFG(3, 0),
+   XGENE_V2_ECAM_MCFG(3, 1),
+   /* X-Gene SoC with v2.2 PCIe controller */
+   XGENE_V2_ECAM_MCFG(4, 0),
+   XGENE_V2_ECAM_MCFG(4, 1),
+   XGENE_V2_ECAM_MCFG(4, 2),
 };
 
 static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c983892..1fb5518 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -133,8 +133,8 @@ config PCIE_XILINX
 
 config PCI_XGENE
bool "X-Gene PCIe controller"
-   depends on ARCH_XGENE
-   depends on OF
+   depends on ARM64
+   depends on OF || (ACPI && PCI_QUIRKS)
select PCIEPORTBUS
help
  Say Y here if you want internal PCI support on APM X-Gene SoC.
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 639494a..6cc84b4 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
 obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
 obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
-obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
+obj-$(CONFIG_ARM64) += pci-xgene.o
 obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
 obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
 obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 1de23d7..6edcac7 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -64,7 +66,9 @@
 /* PCIe IP version */
 #define XGENE_PCIE_IP_VER_UNKN 0
 #define XGENE_PCIE_IP_VER_11
+#define XGENE_PCIE_IP_VER_22
 
+#if defined(CONFIG_PCI_XGENE) || (defined(CONFIG_ACPI) && 
defined(CONFIG_PCI_QUIRKS))
 struct xgene_pcie_port {
struct device_node  *node;
struct device   *dev;
@@ -91,13 +95,24 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
return (addr & PCI_BASE_ADDRESS_MEM_MASK) | flags;
 }
 
+static inline struct xgene_pcie_port *pcie_bus_to_port(struct pci_bus *bus)
+{
+   struct pci_config_window *cfg;
+
+   if (acpi_disabled)
+   return (struct xgene_pcie_port *)(bus->sysdata);
+
+   cfg = bus->sysdata;
+   return (struct xgene_pcie_port *)(cfg->priv);
+}
+
 /*
  * When the address bit [17:16] is 2'b01, the Configuration access will be
  * treated as Type 1 and it will be forwarded to external PCIe device.
  */
 static void __

[PATCH 5/9] arm64: dts: rockchip: add rk3399 OPPs

[Brian Norris]

Used for Gru/Kevin, but they should be conservative enough for all
boards. (And ideally, any board-to-board differences can be represented
via, e.g., describing regulator offsets.)

Signed-off-by: Brian Norris 
---
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 145 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi |   1 +
 2 files changed, 146 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
new file mode 100644
index ..e1038cd92ce5
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -0,0 +1,145 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+   cluster0_opp: opp-table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <80>;
+   clock-latency-ns = <4>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <80>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <141600>;
+   opp-microvolt = <105>;
+   };
+   opp06 {
+   opp-hz = /bits/ 64 <151200>;
+   opp-microvolt = <1125000>;
+   };
+   };
+
+   cluster1_opp: opp-table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <80>;
+   clock-latency-ns = <4>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <95>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <141600>;
+   opp-

[PATCH 1/9] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs

[Brian Norris]

From: Douglas Anderson 

We'd like to be able to use the cros-ec-keyboard.dtsi and
cros-ec-sbs.dtsi snippets for arm64 devices.  Currently those files live
in the arm/boot/dts directory.

Let's follow the convention set by commit 8ee57b8182c4 ("ARM64: dts:
vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm") and use
a symlink.  Note that in this case we put the files in a new
"include/common" directory since these snippets may need to be
referenced by dts files in many different subdirectories.

Signed-off-by: Douglas Anderson 
Signed-off-by: Brian Norris 
Reviewed-by: Heiko Stueber 
Tested-by: Heiko Stuebner 
---
This was submitted months ago but had no users

 arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi | 1 +
 arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi  | 1 +
 2 files changed, 2 insertions(+)
 create mode 12 arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
 create mode 12 arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi

diff --git a/arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi 
b/arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
new file mode 12
index ..1c1889f0a791
--- /dev/null
+++ b/arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
@@ -0,0 +1 @@
+../../../../../arm/boot/dts/cros-ec-keyboard.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi 
b/arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi
new file mode 12
index ..3d7ae9c88bcd
--- /dev/null
+++ b/arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi
@@ -0,0 +1 @@
+../../../../../arm/boot/dts/cros-ec-sbs.dtsi
\ No newline at end of file
-- 
2.8.0.rc3.226.g39d4020

[PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

[Brian Norris]

We need to add regulators to the CPU nodes, so cpufreq doesn't think it
can crank up the clock speed without changing the voltage. However, we
don't yet have the DT bindings to fully describe the Over Voltage
Protection (OVP) circuits on these boards. Without that description, we
might end up changing the voltage too much, too fast.

Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
them disabled.

Signed-off-by: Brian Norris 
---
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 146 +++
 1 file changed, 146 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 59b452504106..90adfb5cba38 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -172,6 +172,98 @@
vin-supply = <&ppvar_sys>;
};
 
+   ppvar_bigcpu: ppvar-bigcpu {
+   compatible = "pwm-regulator";
+   regulator-name = "ppvar_bigcpu";
+   /*
+* OVP circuit requires special handling which is not yet
+* represented. Keep disabled for now.
+*/
+   status = "disabled";
+
+   pwms = <&pwm1 0 3337 0>;
+
+   /* EC turns on w/ ap_core_en; always on for AP */
+   regulator-always-on;
+   regulator-boot-on;
+
+   regulator-min-microvolt = <798674>;
+   regulator-max-microvolt = <1302172>;
+
+   pwm-supply = <&ppvar_sys>;
+   pwm-dutycycle-range = <100 0>;
+   pwm-dutycycle-unit = <100>;
+   };
+
+   ppvar_litcpu: ppvar-litcpu {
+   compatible = "pwm-regulator";
+   regulator-name = "ppvar_litcpu";
+   /*
+* OVP circuit requires special handling which is not yet
+* represented. Keep disabled for now.
+*/
+   status = "disabled";
+
+   pwms = <&pwm2 0 3337 0>;
+
+   /* EC turns on w/ ap_core_en; always on for AP */
+   regulator-always-on;
+   regulator-boot-on;
+
+   regulator-min-microvolt = <799065>;
+   regulator-max-microvolt = <1303738>;
+
+   pwm-supply = <&ppvar_sys>;
+   pwm-dutycycle-range = <100 0>;
+   pwm-dutycycle-unit = <100>;
+   };
+
+   ppvar_gpu: ppvar-gpu {
+   compatible = "pwm-regulator";
+   regulator-name = "ppvar_gpu";
+   /*
+* OVP circuit requires special handling which is not yet
+* represented. Keep disabled for now.
+*/
+   status = "disabled";
+
+   pwms = <&pwm0 0 3337 0>;
+
+   /* EC turns on w/ ap_core_en; always on for AP */
+   regulator-always-on;
+   regulator-boot-on;
+
+   regulator-min-microvolt = <785782>;
+   regulator-max-microvolt = <1217729>;
+
+   pwm-supply = <&ppvar_sys>;
+   pwm-dutycycle-range = <100 0>;
+   pwm-dutycycle-unit = <100>;
+   };
+
+   ppvar_centerlogic: ppvar-centerlogic {
+   compatible = "pwm-regulator";
+   regulator-name = "ppvar_centerlogic";
+   /*
+* OVP circuit requires special handling which is not yet
+* represented. Keep disabled for now.
+*/
+   status = "disabled";
+
+   pwms = <&pwm3 0 3337 0>;
+
+   /* EC turns on w/ ppvar_centerlogic_en; always on for AP */
+   regulator-always-on;
+   regulator-boot-on;
+
+   regulator-min-microvolt = <800069>;
+   regulator-max-microvolt = <1049692>;
+
+   pwm-supply = <&ppvar_sys>;
+   pwm-dutycycle-range = <100 0>;
+   pwm-dutycycle-unit = <100>;
+   };
+
/* Schematics call this PPVAR even though it's fixed */
ppvar_logic: ppvar-logic {
compatible = "regulator-fixed";
@@ -444,6 +536,60 @@
};
 };
 
+/*
+ * Set some suspend operating points to avoid OVP in suspend
+ *
+ * When we go into S3 ARM Trusted Firmware will transition our PWM regulators
+ * from wherever they're at back to the "default" operating point (whatever
+ * voltage we get when we set the PWM pins to "input").
+ *
+ * This quick transition under light load has the possibility to trigger the
+ * regulator "over voltage protection" (OVP).
+ *
+ * To make extra certain that we don't hit this OVP at suspend time, we'll
+ * transition to a voltage that's much closer to the default (~1.0 V) so that
+ * there will not be a big jump.  Technically we only need to get within 200 mV
+ * of the default voltage, but the speed here should be fast enough and we need
+ * suspend/resume to be rock solid.
+ */
+
+&cluster0_opp {
+