Re: [PATCH v7 02/10] arm: dts: sunxi: Restore EMAC changes

[Maxime Ripard]

On Wed, Oct 18, 2017 at 08:50:49PM +0200, Corentin Labbe wrote:
> On Wed, Oct 18, 2017 at 06:44:50PM +0200, Andrew Lunn wrote:
> > On Wed, Oct 18, 2017 at 01:44:50PM +0200, Corentin Labbe wrote:
> > > The original dwmac-sun8i DT bindings have some issue on how to handle
> > > integrated PHY and was reverted in last RC of 4.13.
> > > But now we have a solution so we need to get back that was reverted.
> > > 
> > > This patch restore arm DT about dwmac-sun8i
> > > This reverts commit fe45174b72ae ("arm: dts: sunxi: Revert EMAC changes")
> > > 
> > > Signed-off-by: Corentin Labbe 
> > > ---
> > >  arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts |  9 
> > >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts   | 19 +
> > >  arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 19 +
> > >  arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts |  7 ++
> > >  arch/arm/boot/dts/sun8i-h3-orangepi-2.dts |  8 +++
> > >  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts   |  8 +++
> > >  arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts   |  5 +
> > >  arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts|  8 +++
> > >  arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts  | 22 
> > > +++
> > >  arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts| 16 ++
> > >  arch/arm/boot/dts/sunxi-h3-h5.dtsi| 26 
> > > +++
> > >  11 files changed, 147 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
> > > b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> > > index b1502df7b509..6713d0f2b3f4 100644
> > > --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> > > @@ -56,6 +56,8 @@
> > >  
> > >   aliases {
> > >   serial0 = &uart0;
> > > + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> > > + ethernet0 = &emac;
> > >   ethernet1 = &xr819;
> > >   };
> > >  
> > > @@ -102,6 +104,13 @@
> > >   status = "okay";
> > >  };
> > >  
> > > +&emac {
> > > + phy-handle = <&int_mii_phy>;
> > > + phy-mode = "mii";
> > > + allwinner,leds-active-low;
> > > + status = "okay";
> > > +};
> > > +
> > >  &mmc0 {
> > >   pinctrl-names = "default";
> > >   pinctrl-0 = <&mmc0_pins_a>;
> > > diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
> > > b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> > > index e1dba9ffa94b..f2292deaa590 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> > > @@ -52,6 +52,7 @@
> > >   compatible = "sinovoip,bpi-m2-plus", "allwinner,sun8i-h3";
> > >  
> > >   aliases {
> > > + ethernet0 = &emac;
> > >   serial0 = &uart0;
> > >   serial1 = &uart1;
> > >   };
> > > @@ -111,6 +112,24 @@
> > >   status = "okay";
> > >  };
> > >  
> > > +&emac {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&emac_rgmii_pins>;
> > > + phy-supply = <®_gmac_3v3>;
> > > + phy-handle = <&ext_rgmii_phy>;
> > > + phy-mode = "rgmii";
> > > +
> > > + allwinner,leds-active-low;
> > > + status = "okay";
> > > +};
> > > +
> > 
> > 
> > > +&external_mdio {
> > > + ext_rgmii_phy: ethernet-phy@1 {
> > > + compatible = "ethernet-phy-ieee802.3-c22";
> > > + reg = <0>;
> > > + };
> > > +};
> > > +
> > 
> > Hi Corentin
> > 
> > I'm wondering about the order of the patches. Does the external_mdio
> > node actually exist at this point? Or only later when other patches
> > are applied?
> > 
> 
> You are right order of patch are wrong, I need to cut this one in two.
> "Revert²" sunxi-h3-h5.dtsi
> apply mdiomux
> "Revert²" all board nodes

I'm not even sure why you're actually adding them that way. Can't you
just create the new binding file, support it in the driver, and add
the matching DT nodes ?

Maxime

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


signature.asc
Description: PGP signature

Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Laurent,

Thank you for the review.

On 18.10.2017 17:11, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Thursday, 28 September 2017 16:07:27 EEST Andrzej Hajda wrote:
>> These bindings allows to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> There are few things for discussion (IMO):
>> 1. vendor specific connectors, I have added them here, but maybe better is
>>to place them in separate files.
> It's useful to have one vendor-specific compatible string to be used in the 
> example. We could split vendor-specific connectors to separate files later if 
> needed, but for now I'm fine keeping them here.
>
>> 2. physical connector description - I have split it to three properties:
>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>This tripled is able to describe all USB-standard connectors, but there
>>are also impossible combinations, for example(c, *, micro). Maybe better
>>would be to just enumerate all possible connectors in include file.
> I don't have a strong opinion on this. The three properties are nicely 
> descriptive. You might want to list the valid combinations in the bindings 
> though.

According to Rob's suggestion in next iteration I will encode USB port
type into compatible ie:
- usb-a-connector,
- usb-b-connector,
- usb-c-connector.

Rob suggested also to encode there speed as well, but I am afraid it
will inflate number of compatibles:
(3 types: a, b, c) x (3 speed modes: hs, ss, ssplus) = 9 combinations

>> 3. Numbering of port/remote nodes, currently only 0 is assigned for
>> Interface Controller. Maybe other functions should be also assigned:
>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>as an additional property of remote node?
> Given that one of the main reasons this binding is needed is to describe MHL 
> connection to a USB connector, I think we'll need to define additional 
> functions, yes. I'm not sure yet how that should look like though.

Current idea is to encode it in port number.

>
>> ---
>>  .../bindings/connector/usb-connector.txt   | 49 +++
>>  1 file changed, 49 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt new file
>> mode 100644
>> index ..f3a4e85122d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,49 @@
>> +USB Connector
>> +=
>> +
>> +Required properties:
>> +- compatible: "usb-connector"
>> +  connectors with vendor specific extensions can add one of additional
>> +  compatibles:
>> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
>> +- type: the USB connector type: "a", "b", "ab", "c"
>> +- max-mode: max USB speed mode supported by the connector:
>> +  "ls", "fs", "hs", "ss", "ss+"
>> +
>> +Optional properties:
>> +- label: a symbolic name for the connector
>> +- size: size of the connector, should be specified in case of
>> +  non-standard USB connectors: "mini", "micro", "powered"
> "non-standard" sounds like "vendor-specific", while I assume you're talking 
> about the size. The USB specification uses the term "standard" for this 
> purpose, so it's hard to use another one that would convey the right meaning 
> precisely. Maybe "non-standard ('large') USB connector sizes" ?

OK.

And answer for your question from other e-mail:
> One more comment, do I assume correctly that the Samsung 11-pin connector 
> carries USB and MHL on different pins ?

Yes, there are three additional pins: MHL_DP, MHL_DN and MHL_ID [1].

[1]:
https://ae01.alicdn.com/kf/HTB1nn.6KVaNXFXXq6xXFXXXc/221542210/HTB1nn.6KVaNXFXXq6xXFXXXc.jpg?size=69211&height=700&width=700&hash=dcababf11610a489d451d7cb0b8ab60e

Thanks
Andrzej

>
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the
>> +  OF graph bindings specified in bindings/graph.txt.
>> +  There should be exactly one port with at least one endpoint to
>> +  different device nodes. The first endpoint (reg = <0>) should
>> +  point to USB Interface Controller.
>> +
>> +Example
>> +---
>> +
>> +musb_con: connector {
>> +compatible = "samsung,usb-connector-11pin", "usb-connector";
>> +label = "usb";
>> +type = "b";
>> +size = "micro";
>> +max-mode = "hs";
>> +
>> +port {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +musb_con_usb_in: endpoint@0 {
>> +reg = <0>;
>> +r

Re: [PATCHv3 1/7] switch dereference_function_descriptor() to `unsigned long'

[Sergey Senozhatsky]

On (10/04/17 10:24), Petr Mladek wrote:
[..]
> To make it clear. All these comments are not a big deal and I do
> not want to invalidate all the acked-by and tested-by just because
> of them.
>
> But please, consider removing this change if we need to do
> another iteration of this patchset. IMHO, there is no real win
> and it would just pollute the git history.

I tend to rather keep it. would that cause any problems on your side?
it saves a ton of ugly casts later in the patch set and lets us to drop
some casts from the modules code/etc. the patch is here because otherwise
I had to add a bunch of new casts.

-ss

Re: [linux-sunxi] [PATCH v2 6/8] ARM: dts: sun8i: a83t: Move mmc1 pinctrl setting to dtsi file

[Chen-Yu Tsai]

On Wed, Oct 18, 2017 at 11:00 PM, Joonas Kylmälä  wrote:
> Hi,
>
> Chen-Yu Tsai:
>> mmc1 only has 1 possible pinmux setting.
>
> What if someone is using the MMC with bus width 1 and then using the
> remaining 3 pins for something else?

I would very much like to see such a design. Currently the devices
we see all follow Allwinner's reference design, with only minor
modifications. As such, mmc1 is used exclusively for connecting
SDIO-based WiFi modules.

If such a radical(?) design is done, the vendor can always add
a "mmc1-1bit-pins" setting and override the default.

ChenYu

IMMEDIATE REPLY NEEDED.

[Alaine Kamba]

Dear,

My name is Mr Alaine Kamba, I am the Bill and Exchange (assistant)
Manager of Bank of Africa Ouagadougou, Burkina Faso. In my department
I discovered an abandoned sum of eighteen million three hundred
thousand United State of American dollars (18.3MILLION USA DOLLARS)
in an account that belongs to one of our foreign customer who died in
airline that crashed on 4th October 2001.

Since I got information about his death I have been expecting his next
of kin to come over and claim his money because we can not release it
unless somebody applies for it as the next of kin or relation to the
deceased as indicated in our banking guidelines, but unfortunately we
learnt that all his supposed next of kin or relation died alongside
with him in the plane crash leaving nobody behind for the claim. It is
therefore upon this discovery that I decided to make this business
proposal to you and release the money to you as next of kin or
relation to the deceased for safety and subsequent disbursement since
nobody is coming for it and I don't want the money to go into the bank
treasury as unclaimed bill.

You will be entitled with 40% of the total sum while 60% will be for
me after which I will visit your Country to invest my own share when
the fund is successfully transferred into your account, Please I would
like you to keep this transaction confidential and as a top secret as
you may wish to know that I am a bank official.

Yours sincerely,
Mr Alaine Kamba.

Re: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey

[Minas Harutyunyan]

On 10/17/2017 12:41 PM, Minas Harutyunyan wrote:
> On 10/17/2017 1:34 AM, John Stultz wrote:
>> On Mon, Oct 16, 2017 at 1:36 AM, Minas Harutyunyan
>>  wrote:
>>> On b-plug disconnect should asserted GOTGINT.SesEndDet interrupt.
>>> According previously sent by you register dump (GHWCFG2 = 0x23affc70)
>>> your core OTG_MODE=0.
>>> Bellow fragment from programming guide on Device disconnect:
>>>
>>> "7.3Device Disconnection
>>> The device session ends when the USB cable is disconnected or if the
>>> VBUS is switched off by the Host. The
>>> device disconnect flow varies depending on the value of the OTG_MODE
>>> configuration parameter.
>>>
>>> When OTG_MODE = 0,1, or 3
>>> When OTG_MODE is set to 0,1, or 3, the device disconnect flow is as follows:
>>> 1. When the USB cable is unplugged or when the VBUS is switched off by
>>> the Host, the Device core
>>> trigger GINTSTS.OTGInt [bit 2] interrupt bit.
>>> 2. When the device application detects GINTSTS.OTGInt interrupt, it
>>> checks that the
>>> GOTGINT.SesEndDet (Session End Detected) bit is set to 1’b1."
>>>
>>> So, you should receive and handle "Session End Detected". In function
>>> dwc2_handle_otg_intr() on this interrupt (in device mode) calling
>>> dwc2_hsotg_disconnect() function. By adding your patch "[PATCH 3/3] usb:
>>> dwc2: Fix UDC state tracking" state changed to not attached as required.
>>
>>
>> So, on the HiKey board (using 4.14-rc5 + Vardan's patch), I'm not
>> seeing the GOTGINT_SES_END_DET in dwc2_handle_otg_intr() when I remove
>> the USB OTG cable.
>>
>> In fact, I'm not seeing any calls to dwc2_handle_otg_intr()... which
>> seems... odd maybe?  Any clues as to what might be going wrong then?
>>
>> thanks
>> -john
>>
> Hi John Stultz,
> So, on Hikey board on unplug B connector GOTGINT.SesEndDet interrupt not
> asserted, instead asserted GINTSTS_CONIDSTSCHNG. Please, confirm.
> 
> In this case without your patch "[PATCH 1/3] usb: dwc2: Improve gadget
> state disconnection handling" but by applying your patch "[PATCH 3/3]
> usb: dwc2: Fix UDC state tracking":
> 1. On B plug connect UDC state will be set to "configured"
> 2. On B plug disconnect - "not attached".
> Is it Ok for you?
> 
> Meantime, I'll check with HW team why GOTGINT.SesEndDet interrupt not
> asserted on unplug B connector.
> 
> Thanks,
> Minas
> 

Hi John Stultz,

Could you please apply this patch. Please not apply your patch series 
"[PATCH 0/3] dwc2 fixes for edge cases on hikey" to check only below patch.
If you confirm that this patch fix your issue with "Transaction Error" 
and " ChHltd set, but reason is unknown" I'll submit to LKML as final patch.
Then can be applied your patch series, without patch 1/3 (changing in 
connector id status change) to correctly set UDC states.

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index 
f4ef159b538e..7da22152df68 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -331,6 +331,9 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
 usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
 usbcfg &= ~(GUSBCFG_HNPCAP | GUSBCFG_SRPCAP);

+   /* Set HS/FS Timeout Calibration */
+   usbcfg |= GUSBCFG_TOUTCAL(7);
+
 switch (hsotg->hw_params.op_mode) {
 case GHWCFG2_OP_MODE_HNP_SRP_CAPABLE:
 if (hsotg->params.otg_cap ==


Thanks,
Minas

Re: [PATCHv3 2/7] sections: split dereference_function_descriptor()

[Sergey Senozhatsky]

On (10/04/17 11:00), Petr Mladek wrote:
[..]
> >  /* random extra sections (if any).  Override
> > diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> > index 4d0cb9bba93e..172904e9cded 100644
> > --- a/include/linux/moduleloader.h
> > +++ b/include/linux/moduleloader.h
> > @@ -85,6 +85,10 @@ void module_arch_cleanup(struct module *mod);
> >  /* Any cleanup before freeing mod->module_init */
> >  void module_arch_freeing_init(struct module *mod);
> >  
> > +/* Dereference module function descriptor */
> > +unsigned long dereference_module_function_descriptor(struct module *mod,
> > +unsigned long addr);
> > +
> 
> The function is used when the module is already loaded. IMHO,
> include/linux/module.h would be a better place.
> 
> One advantage would be that we could use the same trick
> as in include/asm-generic/sections.h. I mean:
> 
> #define dereference_module_function_descriptor(mod, addr) (addr)
> 
> and redefine it in the three affected
> arch//include/asm/module.h headers. Then it might be completely
> optimized out on all architectures.

will take a look.

-ss

Re: [PATCHv3 4/7] powerpc64: Add .opd based function descriptor dereference

[Sergey Senozhatsky]

On (10/04/17 11:21), Petr Mladek wrote:
[..]
> > +#ifdef PPC64_ELF_ABI_v1
> > +unsigned long dereference_module_function_descriptor(struct module *mod,
> > +unsigned long addr)
> > +{
> > +   if (addr < mod->arch.start_opd || addr >= mod->arch.end_opd)
> > +   return addr;
> > +
> > +   return dereference_function_descriptor(addr);
> > +}
> > +#endif /* PPC64_ELF_ABI_v1 */
> 
> I would personally move this up in the source file. It is related to
> the definition of func_desc() and other functions that are
> also PPC_ELF_ABI-specific.
> 
> Otherwise, it looks good to me.
> 
> Reviewed-by: Petr Mladek 

OK, will move.

-ss

Re: [PATCHv3 5/7] parisc64: Add .opd based function descriptor dereference

[Sergey Senozhatsky]

On (10/04/17 12:40), Petr Mladek wrote:
> > +unsigned long dereference_module_function_descriptor(struct module *mod,
> > +unsigned long addr)
> > +{
> > +   unsigned long start_opd = (Elf64_Addr)mod->core_layout.base +
> > +  mod->arch.fdesc_offset;
> > +   unsigned long end_opd = start_opd +
> > +   mod->arch.fdesc_count * sizeof(Elf64_Fdesc);
> 
> I know that this is used in rather slow paths. But it still might
> make sense to have these section borders pre-computed and
> stored in struct mod_arch_specific. I mean to do similar
> thing that we do on powerpc.
> 
> Well, we could do this in a followup patch if parisc people
> wanted it.
> 
> 
> > +   if (addr < start_opd || addr >= end_opd)
> > +   return addr;
> > +
> > +   return dereference_function_descriptor(addr);
> > +}
> > +#endif
> 
> Otherwise the patch looks fine to me.
> 
> Reviewed-by: Petr Mladek 

let's do it later, if need be.

-ss

Re: [PATCHv3 6/7] symbol lookup: use new kernel and module dereference functions

[Sergey Senozhatsky]

Sorry for the delay and thanks for taking a look.

I'll try to re-spin the patch set by the end of this week/early next
week.


On (10/04/17 13:53), Petr Mladek wrote:
[..]
> Note that kallsyms_lookup() and module_address_lookup() is used
> in many other situations.

we dereference only things that can be dereferenced.
so calling it on already dereferenced address, or address
that does need to be dereferenced is OK.

besides, not all of those "other" places are available on
ppc64, ia64, parisc.

[..]
> > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> > index 127e7cfafa55..e2fc09ea9509 100644
> > --- a/kernel/kallsyms.c
> > +++ b/kernel/kallsyms.c
> > @@ -322,6 +322,7 @@ const char *kallsyms_lookup(unsigned long addr,
> > if (is_ksym_addr(addr)) {
> 
> is_ksym_addr() ignores the special .opd elf sections if
> CONFIG_KALLSYMS_ALL is disabled. We should dereference before
> this call.

I'll move it.

> > unsigned long pos;
> >  
> > +   addr = dereference_kernel_function_descriptor(addr);
> > pos = get_symbol_pos(addr, symbolsize, offset);
> 
> I still wonder if doing the dereference in the widely used kallsyms
> might cause any regression.

more testing wouldn't hurt, yes.

> Also get_symbol_pos() is called in several other helpers
> but the dereference is done only here. It would be
> confusing if for example kallsyms_lookup_size_offset()
> and kallsyms_lookup() give different result.

hm, so there is no change in this regard, right? there was no
deference before, there is no dereference now. what am I missing?


I'm touching the pf/pF part in this patch set. if there are cases
of missing dereferences anywhere else then we need to address it
in a separate patch set, I think.

> I would feel much more comfortable if we keep the derefenrece
> only in vsprintf.

at a price of extra module lookup, because we need `struct module *'
for module address dereference.

-ss

RE: [PATCH 1/3] iommu/vt-d: Missing checks for pasid tables if allocation fails

[Liu, Yi L]

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Lu Baolu
> Sent: Thursday, October 19, 2017 8:39 AM
> To: j...@8bytes.org; dw...@infradead.org
> Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 1/3] iommu/vt-d: Missing checks for pasid tables if 
> allocation fails
> 
> intel_svm_alloc_pasid_tables() might return an error but never be checked by 
> the
> callers. Later when intel_svm_bind_mm() is called, there are no checks for 
> valid pasid
> tables before enabling them.
> 
> Signed-off-by: Ashok Raj 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel-svm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c index
> f6697e5..43280ca 100644
> --- a/drivers/iommu/intel-svm.c
> +++ b/drivers/iommu/intel-svm.c
> @@ -292,7 +292,7 @@ int intel_svm_bind_mm(struct device *dev, int *pasid, int
> flags, struct svm_dev_
>   int pasid_max;
>   int ret;
> 
> - if (WARN_ON(!iommu))
> + if (WARN_ON(!iommu || !iommu->pasid_table))

[Liu, Yi L] Hi Baolu, I guess there also need a check to iommu->ecap , see if 
the pasid bit
is reported. thoughts?

Regards,
Yi L

>   return -EINVAL;
> 
>   if (dev_is_pci(dev)) {
> --
> 2.7.4
> 
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] MAINTAINERS: Split Cavium EDAC entry and add myself

[Jan Glauber]

Split the Cavium EDAC entry into MIPS and ARM drivers because
they have different maintainers and mailing lists.

Add myself as additional maintainer to the ThunderX driver.

Signed-off-by: Jan Glauber 
---
 MAINTAINERS | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a74227a..9ea8b89 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4906,13 +4906,19 @@ L:  linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/highbank*
 
-EDAC-CAVIUM
+EDAC-CAVIUM OCTEON
 M: Ralf Baechle 
 M: David Daney 
 L: linux-e...@vger.kernel.org
 L: linux-m...@linux-mips.org
 S: Supported
 F: drivers/edac/octeon_edac*
+
+EDAC-CAVIUM THUNDERX
+M: David Daney 
+M: Jan Glauber 
+L: linux-e...@vger.kernel.org
+S: Supported
 F: drivers/edac/thunderx_edac*
 
 EDAC-CORE
-- 
1.9.1

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Byungchul Park]

On Thu, Oct 19, 2017 at 08:22:12AM +0200, Ingo Molnar wrote:
> There's no current crash regression that I know of - I'm just outlining the 
> conditions of getting all this re-enabled in the next merge window.
> 
> Instead of sending two series, could you please send a series that includes 
> both 
> these fixing + re-enabling patches, plus the false positive fixes?
> 
> In particular I think the cross-release re-enabling should be done as the 
> last 
> patch, so that any future bisections of new false positives won't be made 
> more 
> difficult by re-introducing the old false positives near the end of the 
> bisection.

I agree. But I already sent v2 before you told me..

Do you want me to send patches fixing false positives in the thread
fixing performance regression?

[RFC] scripts: add leaking_addresses.pl

[Tobin C. Harding]

Currently we are leaking addresses from the kernel to user space. This
script as an attempt to find those leakages. Script parses `dmesg`
output and /proc and /sys files for suspicious entries.

Signed-off-by: Tobin C. Harding 
---

My usual disclaimer; I am a long way from being a Perl monger, any tips,
however trivial, most welcome.

Parses dmesg output first then;

Algorithm walks the directory tree of /proc and /sys, opens each file
for reading and parses file line by line. We therefore need to skip
certain files;

 - binary files.
 - relay large files of fixed format that _definitely_ won't leak.
 - non-readable files.

Since I do not know procfs or sysfs extensively I set `DEBUG = 1` within
the script (causes output of file name before parsing) and checked each
file it choked on. Obviously this means there are going to be a bunch of
other files not present on my system. Either more files to skip or a
suggestion of a better way to do this most appreciated.

Like I said, happy to take suggestions, abuse, tweaks etc

Thanks in advance for taking the time to look at this. Oh, I didn't
comment on my regex skills, no further comment required ;)

thanks,
Tobin.

 scripts/leaking_addresses.pl | 139 +++
 1 file changed, 139 insertions(+)
 create mode 100755 scripts/leaking_addresses.pl

diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
new file mode 100755
index ..940547b716e3
--- /dev/null
+++ b/scripts/leaking_addresses.pl
@@ -0,0 +1,139 @@
+#!/usr/bin/env perl
+#
+# leaking_addresses.pl scan kernel for potential leaking addresses.
+
+use warnings;
+use strict;
+use File::Basename;
+use feature 'say';
+
+my $DEBUG = 0;
+my @dirs = ('/proc', '/sys');
+
+parse_dmesg();
+
+foreach(@dirs)
+{
+walk($_);
+}
+
+exit 0;
+
+#
+# TODO
+#
+# - Add support for 32 bit architectures.
+#
+sub may_leak_address
+{
+my $line = $_[0];
+my $regex = '[a-fA-F0-9]{12}';
+my $mask = '';
+
+if ($line =~ /$mask/) {
+return
+}
+
+if ($line =~ /$regex/) {
+return 1;
+}
+return;
+}
+
+sub parse_dmesg
+{
+my $line;
+open my $cmd, '-|', 'dmesg';
+while ($line = <$cmd>) {
+if (may_leak_address($line)) {
+print 'dmesg: ' . $line;
+}
+}
+close $cmd;
+}
+
+# We should skip these files
+sub skip_file
+{
+my $path = $_[0];
+
+my @skip_paths = ('/proc/kmsg', '/proc/kcore', '/proc/kallsyms',
+  '/proc/fs/ext4/sdb1/mb_groups', 
'/sys/kernel/debug/tracing/trace_pipe',
+  '/sys/kernel/security/apparmor/revision');
+my @skip_files = ('pagemap', 'events', 'access','registers', 
'snapshot_raw',
+  'trace_pipe_raw', 'trace_pipe');
+
+foreach(@skip_paths) {
+if ($_ eq $_[0]) {
+return 1;
+}
+}
+
+my($filename, $dirs, $suffix) = fileparse($path);
+
+foreach(@skip_files) {
+if ($_ eq $filename) {
+return 1;
+}
+}
+
+return;
+}
+
+sub parse_file
+{
+my $file = $_[0];
+
+if (! -R $file) {
+return;
+}
+
+if (skip_file($file)) {
+if ($DEBUG == 1) {
+print "skipping file: $file\n";
+}
+return;
+}
+if ($DEBUG == 1) {
+print "parsing $file\n";
+}
+
+open my $fh, $file or return;
+
+while( my $line = <$fh>)  {
+if (may_leak_address($line)) {
+print $file . ': ' . $line;
+}
+}
+
+close $fh;
+}
+
+# Recursively walk directory tree
+sub walk
+{
+my @dirs = ($_[0]);
+my %seen;
+
+while (my $pwd = shift @dirs) {
+if (!opendir(DIR,"$pwd")) {
+print STDERR "Cannot open $pwd\n";  
+next;
+} 
+my @files = readdir(DIR);
+closedir(DIR);
+foreach my $file (@files) {
+next if ($file eq '.' or $file eq '..');
+
+my $path = "$pwd/$file";
+next if (-l $path);
+
+if (-d $path and !$seen{$path}) {
+$seen{$path} = 1;
+push @dirs, "$path";
+} else {
+parse_file("$path");
+}
+}
+}
+}
-- 
2.7.4

[PATCH] tracing: Fix code comment in trace.c

[Chunyu Hu]

Naming in code comments for tracing_snapshot, tracing_snapshot_alloc
and trace_pid_filter_add_remove_task don't match the real function
names.  And latency_trace has been removed from tracing directory.
Fix them.

Fixes: cab5037 ("tracing/ftrace: Enable snapshot function trigger")
Fixes: 886b5b7 ("tracing: remove /debug/tracing/latency_trace")
Signed-off-by: Chunyu Hu 
---
 kernel/trace/trace.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 73e67b6..06429e5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -362,7 +362,7 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
 }
 
 /**
- * trace_pid_filter_add_remove - Add or remove a task from a pid_list
+ * trace_pid_filter_add_remove_task - Add or remove a task from a pid_list
  * @pid_list: The list to modify
  * @self: The current task for fork or NULL for exit
  * @task: The task to add or remove
@@ -925,7 +925,7 @@ static void tracing_snapshot_instance(struct trace_array 
*tr)
 }
 
 /**
- * trace_snapshot - take a snapshot of the current buffer.
+ * tracing_snapshot - take a snapshot of the current buffer.
  *
  * This causes a swap between the snapshot buffer and the current live
  * tracing buffer. You can use this to take snapshots of the live
@@ -1004,9 +1004,9 @@ int tracing_alloc_snapshot(void)
 EXPORT_SYMBOL_GPL(tracing_alloc_snapshot);
 
 /**
- * trace_snapshot_alloc - allocate and take a snapshot of the current buffer.
+ * tracing_snapshot_alloc - allocate and take a snapshot of the current buffer.
  *
- * This is similar to trace_snapshot(), but it will allocate the
+ * This is similar to tracing_snapshot(), but it will allocate the
  * snapshot buffer if it isn't already allocated. Use this only
  * where it is safe to sleep, as the allocation may sleep.
  *
@@ -1303,7 +1303,7 @@ static ssize_t trace_seq_to_buffer(struct trace_seq *s, 
void *buf, size_t cnt)
 /*
  * Copy the new maximum trace into the separate maximum-trace
  * structure. (this way the maximum trace is permanently saved,
- * for later retrieval via /sys/kernel/debug/tracing/latency_trace)
+ * for later retrieval via /sys/kernel/debug/tracing/tracing_max_latency)
  */
 static void
 __update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu)
-- 
1.8.3.1

Re: [PATCH v9 13/29] x86/insn-eval: Add utility functions to get segment selector

[Ricardo Neri]

On Wed, Oct 18, 2017 at 10:29:43PM +0200, Borislav Petkov wrote:
> On Tue, Oct 17, 2017 at 01:31:52PM -0700, Ricardo Neri wrote:
> > I apologize for the inconvenience, I have verified that may mail client
> > works properly this time. I double-checked that it did not wrap.
> 
> But did you try applying the patch which you have sent to yourself first?
> 
> Because it doesn't work here:
> 
> [boris@pd: ~/kernel/linux> test-apply.sh /tmp/ricardo.neri-calderon.13
> checking file arch/x86/include/asm/inat.h
> patch:  malformed patch at line 124:  #define INAT_MAKE_GROUP(grp)  ((grp 
> << INAT_GRP_OFFS) | INAT_MODRM)
> 
> Diffing your original patch which you've sent with git and this one
> which you've sent with evolution gives:
> 
>  diff --git a/arch/x86/include/asm/inat.h b/arch/x86/include/asm/inat.h
>  index 02aff08..1c78580 100644
>  --- a/arch/x86/include/asm/inat.h
>  +++ b/arch/x86/include/asm/inat.h
>  @@ -97,6 +97,16 @@
> - #define INAT_MAKE_GROUP(grp)((grp << INAT_GRP_OFFS) | INAT_MODRM)
> - #define INAT_MAKE_IMM(imm)  (imm << INAT_IMM_OFFS)
> - 
> + #define INAT_MAKE_GROUP(grp)((grp << INAT_GRP_OFFS) | INAT_MODRM)
> + #define INAT_MAKE_IMM(imm)  (imm << INAT_IMM_OFFS)
> + 
> 
> And already those spaces at the beginning of the line must be funky
> because the rest looks identical.
> 
> They should be:
> 
> 1420  2c 31 36 20 40 40 0a 20  23 64 65 66 69 6e 65 20  |,16 @@. #define
> 
> i.e., a 0x0a for LF and 0x20 for space.
> 
> Yours are
> 
> 17b0  36 20 2b 39 37 2c 31 36  20 40 40 0a c2 a0 23 64  |6 +97,16 @@...#d|
> 
> so there's 0x0a LF, but then there's 0xc2, and then there's 0xa0.
> 
> Looking at an UTF-8 table, it says:
> 
> U+00A0c2 a0   NO-BREAK SPACE
> 
> so your patch is utf-8, no wonder it doesn't apply.

I saw that Documentation/process/email-clients.rst that emailed patches
should be in ASCII or UTF-8 encodings only, but my patch in UTF-8
causes problems. Then is UTF-8 not desirable?

> 
> So try sending the patch again. But send it to yourself first and try
> applying it.
> 
> Alternatively, git send-email supports threading with --in-reply-to=
> so that is another possibility. But here you'll have to add the whole
> CC-list.
> 
> Also, Documentation/process/email-clients.rst has some notes on how to
> send patches with Evolution.

Thanks for the detailed explanation and the pointers to fix the problem.
I am sorry for the inconvenience. Here is the patch again. I made sure
that it applies cleanly with git am and patch:

When computing a linear address and segmentation is used, we need to know
the base address of the segment involved in the computation. In most of
the cases, the segment base address will be zero as in USER_DS/USER32_DS.
However, it may be possible that a user space program defines its own
segments via a local descriptor table. In such a case, the segment base
address may not be zero. Thus, the segment base address is needed to
calculate correctly the linear address.

If running in protected mode, the segment selector to be used when
computing a linear address is determined by either any of segment override
prefixes in the instruction or inferred from the registers involved in the
computation of the effective address; in that order. Also, there are cases
when the segment override prefixes shall be ignored (i.e., code segments
are always selected by the CS segment register; string instructions always
use the ES segment register when using rDI register as operand). In long
mode, segment registers are ignored, except for FS and GS. In these two
cases, base addresses are obtained from the respective MSRs.

For clarity, this process can be split into four steps (and an equal
number of functions): determine if segment prefixes overrides can be used;
parse the segment override prefixes, and use them if found; if not found
or cannot be used, use the default segment registers associated with the
operand registers. Once the segment register to use has been identified,
read its value to obtain the segment selector.

The method to obtain the segment selector depends on several factors. In
32-bit builds, segment selectors are saved into a pt_regs structure
when switching to kernel mode. The same is also true for virtual-8086
mode. In 64-bit builds, segmentation is mostly ignored, except when
running a program in 32-bit legacy mode. In this case, CS and SS can be
obtained from pt_regs. DS, ES, FS and GS can be read directly from
the respective segment registers.

In order to identify the segment registers, a new set of #defines is
introduced. It also includes two special identifiers. One of them
indicates when the default segment register associated with instruction
operands shall be used. Another one indicates that the contents of the
segment register shall be ignored; this identifier is used when in long
mode.

Cc: Dave Hansen 
Cc: Adam Buchbinder 
Cc: Colin Ian King 
Cc: Lorenzo Stoakes 
Cc: Qiaowei Ren 
Cc: Arnaldo Carvalho de Melo 
Cc: M

Re: [PATCH] mm: mlock: remove lru_add_drain_all()

[Anshuman Khandual]

On 10/19/2017 04:47 AM, Shakeel Butt wrote:
> Recently we have observed high latency in mlock() in our generic
> library and noticed that users have started using tmpfs files even
> without swap and the latency was due to expensive remote LRU cache
> draining.

With and without this I patch I dont see much difference in number
of instructions executed in the kernel for mlock() system call on
POWER8 platform just after reboot (all the pagevecs might not been
filled by then though). There is an improvement but its very less.

Could you share your latency numbers and how this patch is making
them better.

> 
> Is lru_add_drain_all() required by mlock()? The answer is no and the
> reason it is still in mlock() is to rapidly move mlocked pages to
> unevictable LRU. Without lru_add_drain_all() the mlocked pages which
> were on pagevec at mlock() time will be moved to evictable LRUs but
> will eventually be moved back to unevictable LRU by reclaim. So, we

Wont this affect the performance during reclaim ?

> can safely remove lru_add_drain_all() from mlock(). Also there is no
> need for local lru_add_drain() as it will be called deep inside
> __mm_populate() (in follow_page_pte()).

The following commit which originally added lru_add_drain_all()
during mlock() and mlockall() has similar explanation.

8891d6da ("mm: remove lru_add_drain_all() from the munlock path")

"In addition, this patch add lru_add_drain_all() to sys_mlock()
and sys_mlockall().  it isn't must.  but it reduce the failure
of moving to unevictable list.  its failure can rescue in
vmscan later.  but reducing is better."

Which sounds like either we have to handle the active to inactive
LRU movement during reclaim or it can be done here to speed up
reclaim later on.

Re: [PATCH v3] staging: ccree: fix boolreturn.cocci warning

[Suniel Mahesh]

On Thursday 19 October 2017 02:24 AM, Tobin C. Harding wrote:
> Hi Suniel,
> 
> Well done with you continued versions. I am being particularly nit picky here 
> but since we are
> striving for perfection I'm sure will humour me. If English is not your first 
> language please
> forgive me for picking you up on language subtleties.

Hi Tobin,

First of all, I thank you very much for the reviews, to be honest I enjoyed the 
process. Yes all of 
us, here we are striving for perfection. I am always open to take suggestions 
from the community to 
improve things which I am working on and there by improving myself. Yeah 
English is not my first
language, but all my education was done in English, no issues there.

> 
> On Wed, Oct 18, 2017 at 12:11:55PM +0530, suni...@techveda.org wrote:
>> From: Suniel Mahesh 
>>
>> This fixes the following coccinelle warning:
>> WARNING: return of 0/1 in function 'ssi_is_hw_key' with return type bool.
> 
> This should be a description of the problem, so saying _why_ there is a 
> problem or _what_ is wrong
> with the code currently that warrants a patch. Sometimes while describing the 
> problem you may
> include descriptions of the solution especially it is not immediately obvious 
> why your proposed
> solution fixes the issue being explained. As an extra we shouldn't ever say 
> 'This patch ...' or
> 'This does xyz'.
> 
>> return "false" instead of 0.
> 
> Perfect, this is in imperative mood. Spot on!
> 
>> Signed-off-by: Suniel Mahesh 
>> ---
>> Changes for v3:
>> - Changed the commit log even more to give an accurate
>>   description of the changeset as suggested by Toby C.Harding.
> 
> My name is Tobin :)

how did I blind myself, my bad, will be careful and avoid such mistakes moving 
forward.

> 
>> ---
>> Changes for v2:
>> - Changed the commit log to give a more accurate description
>>   of the changeset as suggested by Toby C.Harding.
>> ---
>> Note:
>> - Patch was built(ARCH=arm) on latest linux-next.
>> - No build issues reported, however it was not
>>   tested on real hardware.
>> - Please discard this changeset, if this is not
>>   helping the code look better.
>> ---
>>  drivers/staging/ccree/ssi_cipher.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/ccree/ssi_cipher.h 
>> b/drivers/staging/ccree/ssi_cipher.h
>> index c9a83df..f499962 100644
>> --- a/drivers/staging/ccree/ssi_cipher.h
>> +++ b/drivers/staging/ccree/ssi_cipher.h
>> @@ -75,7 +75,7 @@ struct arm_hw_key_info {
>>  
>>  static inline bool ssi_is_hw_key(struct crypto_tfm *tfm)
>>  {
>> -return 0;
>> +return false;
>>  }
>>  
>>  #endif /* CRYPTO_TFM_REQ_HW_KEY */
>> -- 
>> 1.9.1
>>
> 
> For what it's worth, Reviewed-by: Tobin C. Harding 
> 
> As stated I am being particularly 'nit picky', the commit log is _probably_ 
> good enough to be
> merged, I am not a maintainer though so it's not really anything to do with 
> me. I do know however
> that sometimes patches go to the bottom of Greg's list if they have 
> comments/suggestions. I mention
> this only so you learn more about the process and to help you with 
> successfully getting you patches
> merged. Keep up the work!

Thanks once again Tobin, I love feedback and that's how we can make this world 
a better workplace.

Suniel

> 
> Good luck,
> Tobin.
> 

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Byungchul Park]

On Thu, Oct 19, 2017 at 03:11:12PM +0900, Byungchul Park wrote:
> On Thu, Oct 19, 2017 at 07:57:30AM +0200, Ingo Molnar wrote:
> > 
> > * Byungchul Park  wrote:
> > 
> > > On Wed, Oct 18, 2017 at 12:09:44PM +0200, Ingo Molnar wrote:
> > > > BTW., have you attempted limiting the depth of the stack traces? I 
> > > > suspect more 
> > > > than 2-4 are rarely required to disambiguate the calling context.
> > > 
> > > I did it for you. Let me show you the result.
> > > 
> > > 1. No lockdep:2.756558155 seconds time 
> > > elapsed( +-  0.09% )
> > > 2. Lockdep:   2.968710420 seconds 
> > > time elapsed( +-  0.12% )
> > > 3. Lockdep + Crossrelease 5 entries:  3.153839636 seconds 
> > > time elapsed( +-  0.31% )
> > > 4. Lockdep + Crossrelease 3 entries:  3.137205534 seconds 
> > > time elapsed( +-  0.87% )
> > > 5. Lockdep + Crossrelease + This patch:   2.963669551 seconds time 
> > > elapsed( +-  0.11% )
> > 
> > I think the lockdep + crossrelease + full-stack numbers are missing?
> 
> Ah, the last version of crossrelease merged into vanilla, records 5
> entries, since I thought it overloads too much if full stack is used,
> and 5 entries are enough. Don't you think so?
> 
> > But yeah, looks like single-entry-stacktrace crossrelease only has a +0.2% 
> > performance cost (with 0.1% noise), while lockdep itself has a +7.7% cost.
> > 
> > That's very reasonable and we can keep the single-entry cross-release 
> > feature 
> > enabled by default as part of CONFIG_PROVE_LOCKING=y - assuming all the 
> > crashes 
> 
> BTW, is there any crash by cross-release I don't know? Of course, I know
> cases of false positives, but I don't about crash.

Are you talking about the oops by 'null pointer dereference' by unwinder a
few weeks ago?

At the time, cross-release was falsely accused. AFAIK, cross-release has
not crashed system yet.

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Ingo Molnar]

* Byungchul Park  wrote:

> On Thu, Oct 19, 2017 at 07:57:30AM +0200, Ingo Molnar wrote:
> > 
> > * Byungchul Park  wrote:
> > 
> > > On Wed, Oct 18, 2017 at 12:09:44PM +0200, Ingo Molnar wrote:
> > > > BTW., have you attempted limiting the depth of the stack traces? I 
> > > > suspect more 
> > > > than 2-4 are rarely required to disambiguate the calling context.
> > > 
> > > I did it for you. Let me show you the result.
> > > 
> > > 1. No lockdep:2.756558155 seconds time 
> > > elapsed( +-  0.09% )
> > > 2. Lockdep:   2.968710420 seconds 
> > > time elapsed( +-  0.12% )
> > > 3. Lockdep + Crossrelease 5 entries:  3.153839636 seconds 
> > > time elapsed( +-  0.31% )
> > > 4. Lockdep + Crossrelease 3 entries:  3.137205534 seconds 
> > > time elapsed( +-  0.87% )
> > > 5. Lockdep + Crossrelease + This patch:   2.963669551 seconds time 
> > > elapsed( +-  0.11% )
> > 
> > I think the lockdep + crossrelease + full-stack numbers are missing?
> 
> Ah, the last version of crossrelease merged into vanilla, records 5
> entries, since I thought it overloads too much if full stack is used,
> and 5 entries are enough. Don't you think so?

Ok, fair enough, I missed that limitation!

> > That's very reasonable and we can keep the single-entry cross-release 
> > feature 
> > enabled by default as part of CONFIG_PROVE_LOCKING=y - assuming all the 
> > crashes 
> 
> BTW, is there any crash by cross-release I don't know? Of course, I know
> cases of false positives, but I don't about crash.

There's no current crash regression that I know of - I'm just outlining the 
conditions of getting all this re-enabled in the next merge window.

Instead of sending two series, could you please send a series that includes 
both 
these fixing + re-enabling patches, plus the false positive fixes?

In particular I think the cross-release re-enabling should be done as the last 
patch, so that any future bisections of new false positives won't be made more 
difficult by re-introducing the old false positives near the end of the 
bisection.

Thanks,

Ingo

RE: [PATCH] checkpatch: Introduce check for format of Fixes line in commit log

[Parav Pandit]

> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Thursday, October 19, 2017 12:57 AM
> To: Parav Pandit ; a...@canonical.com
> Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; Brad Erickson
> 
> Subject: Re: [PATCH] checkpatch: Introduce check for format of Fixes line in
> commit log
> 
> On Thu, 2017-10-19 at 05:52 +, Parav Pandit wrote:
> > Hi Joe,
> 
> Hello Parav
> 
> > > -Original Message-
> > > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> > > ow...@vger.kernel.org] On Behalf Of Parav Pandit
> > > Sent: Tuesday, October 10, 2017 5:44 PM
> > > To: j...@perches.com; a...@canonical.com
> > > Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; Parav
> > > Pandit ; Brad Erickson 
> > > Subject: [PATCH] checkpatch: Introduce check for format of Fixes
> > > line in commit log
> > >
> > > This patch introduces a format check for 'Fixes' line in commit log
> > > for 12 characters commit id and format for Fixes as ("...").
> 
> I think this doesn't handle case like:
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735

I see such commits now. I will cover for such an additional format.
Fixes: 
Will send v1.

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Byungchul Park]

On Thu, Oct 19, 2017 at 07:57:30AM +0200, Ingo Molnar wrote:
> 
> * Byungchul Park  wrote:
> 
> > On Wed, Oct 18, 2017 at 12:09:44PM +0200, Ingo Molnar wrote:
> > > BTW., have you attempted limiting the depth of the stack traces? I 
> > > suspect more 
> > > than 2-4 are rarely required to disambiguate the calling context.
> > 
> > I did it for you. Let me show you the result.
> > 
> > 1. No lockdep:  2.756558155 seconds time 
> > elapsed( +-  0.09% )
> > 2. Lockdep: 2.968710420 seconds time 
> > elapsed( +-  0.12% )
> > 3. Lockdep + Crossrelease 5 entries:3.153839636 seconds 
> > time elapsed( +-  0.31% )
> > 4. Lockdep + Crossrelease 3 entries:3.137205534 seconds 
> > time elapsed( +-  0.87% )
> > 5. Lockdep + Crossrelease + This patch: 2.963669551 seconds time 
> > elapsed( +-  0.11% )
> 
> I think the lockdep + crossrelease + full-stack numbers are missing?

Ah, the last version of crossrelease merged into vanilla, records 5
entries, since I thought it overloads too much if full stack is used,
and 5 entries are enough. Don't you think so?

> But yeah, looks like single-entry-stacktrace crossrelease only has a +0.2% 
> performance cost (with 0.1% noise), while lockdep itself has a +7.7% cost.
> 
> That's very reasonable and we can keep the single-entry cross-release feature 
> enabled by default as part of CONFIG_PROVE_LOCKING=y - assuming all the 
> crashes 

BTW, is there any crash by cross-release I don't know? Of course, I know
cases of false positives, but I don't about crash.

Thanks,
Byungchul

> and false positives are fixed by the next merge window.
> 
> Thanks,
> 
>   Ingo

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Ingo Molnar]

* Byungchul Park  wrote:

> On Wed, Oct 18, 2017 at 12:09:44PM +0200, Ingo Molnar wrote:
> > BTW., have you attempted limiting the depth of the stack traces? I suspect 
> > more 
> > than 2-4 are rarely required to disambiguate the calling context.
> 
> I did it for you. Let me show you the result.
> 
> 1. No lockdep:2.756558155 seconds time 
> elapsed( +-  0.09% )
> 2. Lockdep:   2.968710420 seconds time 
> elapsed( +-  0.12% )
> 3. Lockdep + Crossrelease 5 entries:  3.153839636 seconds time 
> elapsed( +-  0.31% )
> 4. Lockdep + Crossrelease 3 entries:  3.137205534 seconds time 
> elapsed( +-  0.87% )
> 5. Lockdep + Crossrelease + This patch:   2.963669551 seconds time 
> elapsed( +-  0.11% )

I think the lockdep + crossrelease + full-stack numbers are missing?

But yeah, looks like single-entry-stacktrace crossrelease only has a +0.2% 
performance cost (with 0.1% noise), while lockdep itself has a +7.7% cost.

That's very reasonable and we can keep the single-entry cross-release feature 
enabled by default as part of CONFIG_PROVE_LOCKING=y - assuming all the crashes 
and false positives are fixed by the next merge window.

Thanks,

Ingo

Re: [PATCH] checkpatch: Introduce check for format of Fixes line in commit log

[Joe Perches]

On Thu, 2017-10-19 at 05:52 +, Parav Pandit wrote:
> Hi Joe,

Hello Parav

> > -Original Message-
> > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> > ow...@vger.kernel.org] On Behalf Of Parav Pandit
> > Sent: Tuesday, October 10, 2017 5:44 PM
> > To: j...@perches.com; a...@canonical.com
> > Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; Parav Pandit
> > ; Brad Erickson 
> > Subject: [PATCH] checkpatch: Introduce check for format of Fixes line in 
> > commit
> > log
> > 
> > This patch introduces a format check for 'Fixes' line in commit log for 12
> > characters commit id and format for Fixes as ("...").

I think this doesn't handle case like:

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735

[PATCH v2 3/3] lockdep: Add a kernel parameter, crossrelease_fullstack

[Byungchul Park]

Make whether to allow recording full stack, in cross-release feature,
switchable at boot time via a kernel parameter, 'crossrelease_fullstack'.
In case of a splat with no stack trace, one could just reboot and set
the kernel parameter to get the full data without having to recompile
the kernel.

Change CONFIG_CROSSRELEASE_STACK_TRACE default from N to Y, and
introduce the new kernel parameter.

Suggested-by: Thomas Gleixner 
Signed-off-by: Byungchul Park 
---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 kernel/locking/lockdep.c| 18 --
 lib/Kconfig.debug   |  5 +++--
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index ead7f40..4107b01 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -709,6 +709,9 @@
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
 
+   crossrelease_fullstack
+   [KNL] Allow to record full stack trace in cross-release
+
cryptomgr.notests
 [KNL] Disable crypto self-tests
 
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 5c2ddf2..feba887 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -76,6 +76,15 @@
 #define lock_stat 0
 #endif
 
+static int crossrelease_fullstack;
+static int __init allow_crossrelease_fullstack(char *str)
+{
+   crossrelease_fullstack = 1;
+   return 0;
+}
+
+early_param("crossrelease_fullstack", allow_crossrelease_fullstack);
+
 /*
  * lockdep_lock: protects the lockdep graph, the hashes and the
  *   class/list/hash allocators.
@@ -4864,8 +4873,13 @@ static void add_xhlock(struct held_lock *hlock)
xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES;
xhlock->trace.entries = xhlock->trace_entries;
 #ifdef CONFIG_CROSSRELEASE_STACK_TRACE
-   xhlock->trace.skip = 3;
-   save_stack_trace(&xhlock->trace);
+   if (crossrelease_fullstack) {
+   xhlock->trace.skip = 3;
+   save_stack_trace(&xhlock->trace);
+   } else {
+   xhlock->trace.nr_entries = 1;
+   xhlock->trace.entries[0] = hlock->acquire_ip;
+   }
 #else
xhlock->trace.nr_entries = 1;
xhlock->trace.entries[0] = hlock->acquire_ip;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index fe8fceb..132536d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1228,7 +1228,7 @@ config LOCKDEP_COMPLETIONS
 config CROSSRELEASE_STACK_TRACE
bool "Record more than one entity of stack trace in crossrelease"
depends on LOCKDEP_CROSSRELEASE
-   default n
+   default y
help
 The lockdep "cross-release" feature needs to record stack traces
 (of calling functions) for all acquisitions, for eventual later
@@ -1238,7 +1238,8 @@ config CROSSRELEASE_STACK_TRACE
 full analysis. This option turns on the saving of the full stack
 trace entries.
 
-If unsure, say N.
+To make the feature actually on, set "crossrelease_fullstack"
+kernel parameter, too.
 
 config DEBUG_LOCKDEP
bool "Lock dependency engine debugging"
-- 
1.9.1

[tip:locking/core] locking/static_keys: Improve uninitialized key warning

[tip-bot for Borislav Petkov]

Commit-ID:  5cdda5117e125e0dbb020425cc55a4c143c6febc
Gitweb: https://git.kernel.org/tip/5cdda5117e125e0dbb020425cc55a4c143c6febc
Author: Borislav Petkov 
AuthorDate: Wed, 18 Oct 2017 17:24:28 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 19 Oct 2017 07:49:14 +0200

locking/static_keys: Improve uninitialized key warning

Right now it says:

  static_key_disable_cpuslocked used before call to jump_label_init
  [ cut here ]
  WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:161 
static_key_disable_cpuslocked+0x68/0x70
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0-rc5+ #1
  Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
  task: 81c0e480 task.stack: 81c0
  RIP: 0010:static_key_disable_cpuslocked+0x68/0x70
  RSP: :81c03ef0 EFLAGS: 00010096 ORIG_RAX: 
  RAX: 0041 RBX: 81c32680 RCX: 81c5cbf8
  RDX: 0001 RSI: 0092 RDI: 0002
  RBP: 88807fffd240 R08: 726f666562206465 R09: 0136
  R10:  R11: 696e695f6c656261 R12: 82158900
  R13: 8215f760 R14: 0001 R15: 0008
  FS:  () GS:883f7f40() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 88807000 CR3: 01c09000 CR4: 000606b0
  Call Trace:
   static_key_disable+0x16/0x20
   start_kernel+0x15a/0x45d
   ? load_ucode_intel_bsp+0x11/0x2d
   secondary_startup_64+0xa5/0xb0
  Code: 48 c7 c7 a0 15 cf 81 e9 47 53 4b 00 48 89 df e8 5f fc ff ff eb e8 48 c7 
c6 \
c0 97 83 81 48 c7 c7 d0 ff a2 81 31 c0 e8 c5 9d f5 ff <0f> ff eb a7 0f 
ff eb \
b0 e8 eb a2 4b 00 53 48 89 fb e8 42 0e f0

but it doesn't tell me which key it is. So dump the key's name too:

  static_key_disable_cpuslocked(): static key 'virt_spin_lock_key' used before 
call to jump_label_init()

And that makes pinpointing which key is causing that a lot easier.

 include/linux/jump_label.h   |   14 +++---
 include/linux/jump_label_ratelimit.h |6 +++---
 kernel/jump_label.c  |   14 +++---
 3 files changed, 17 insertions(+), 17 deletions(-)

Signed-off-by: Borislav Petkov 
Reviewed-by: Steven Rostedt (VMware) 
Cc: Boris Ostrovsky 
Cc: Hannes Frederic Sowa 
Cc: Jason Baron 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20171018152428.ffjgak4o25f7e...@pd.tnic
Signed-off-by: Ingo Molnar 
---
 include/linux/jump_label.h   | 14 +++---
 include/linux/jump_label_ratelimit.h |  6 +++---
 kernel/jump_label.c  | 14 +++---
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index cd58616..979a2f2 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -81,9 +81,9 @@
 
 extern bool static_key_initialized;
 
-#define STATIC_KEY_CHECK_USE() WARN(!static_key_initialized, \
-   "%s used before call to jump_label_init", \
-   __func__)
+#define STATIC_KEY_CHECK_USE(key) WARN(!static_key_initialized,
  \
+   "%s(): static key '%pS' used before call to 
jump_label_init()", \
+   __func__, (key))
 
 #ifdef HAVE_JUMP_LABEL
 
@@ -211,13 +211,13 @@ static __always_inline bool static_key_true(struct 
static_key *key)
 
 static inline void static_key_slow_inc(struct static_key *key)
 {
-   STATIC_KEY_CHECK_USE();
+   STATIC_KEY_CHECK_USE(key);
atomic_inc(&key->enabled);
 }
 
 static inline void static_key_slow_dec(struct static_key *key)
 {
-   STATIC_KEY_CHECK_USE();
+   STATIC_KEY_CHECK_USE(key);
atomic_dec(&key->enabled);
 }
 
@@ -236,7 +236,7 @@ static inline int jump_label_apply_nops(struct module *mod)
 
 static inline void static_key_enable(struct static_key *key)
 {
-   STATIC_KEY_CHECK_USE();
+   STATIC_KEY_CHECK_USE(key);
 
if (atomic_read(&key->enabled) != 0) {
WARN_ON_ONCE(atomic_read(&key->enabled) != 1);
@@ -247,7 +247,7 @@ static inline void static_key_enable(struct static_key *key)
 
 static inline void static_key_disable(struct static_key *key)
 {
-   STATIC_KEY_CHECK_USE();
+   STATIC_KEY_CHECK_USE(key);
 
if (atomic_read(&key->enabled) != 1) {
WARN_ON_ONCE(atomic_read(&key->enabled) != 0);
diff --git a/include/linux/jump_label_ratelimit.h 
b/include/linux/jump_label_ratelimit.h
index 23da3af..93086df 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -24,18 +24,18 @@ struct static_key_deferred {
 };
 static inline void static_key_slow_dec_deferred(struct static_key_deferred 
*key)
 {
-   STATIC_KEY_CHECK_USE();
+   S

[PATCH v2 0/3] crossrelease: make it not unwind by default

[Byungchul Park]

Change from v1
- Fix kconfig description as Ingo suggested
- Fix commit message writing out CONFIG_ variable
- Introduce a new kernel parameter, crossrelease_fullstack
- Replace the number with the output of *perf*

Byungchul Park (3):
  lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as
default
  lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE
  lockdep: Add a kernel parameter, crossrelease_fullstack

 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 include/linux/lockdep.h |  4 
 kernel/locking/lockdep.c| 23 +--
 lib/Kconfig.debug   | 20 ++--
 4 files changed, 46 insertions(+), 4 deletions(-)

-- 
1.9.1

RE: [PATCH 0/9] Intel Processor Trace virtulization enabling

[Kang, Luwei]

>  Nested virtualization is interesting.  We would like the nested
>  hypervisor to be forced to set the "use GPA for processor tracing"
>  secondary execution control whenever "enable EPT" is set and
>  RTIT_CTL is nonzero.  There is no way to encode that in
>  IA32_VMX_PROCBASED_CTLS2, however.  It would be nice if Intel could
>  reserve a bit in IA32_VMX_EPT_VPID_CAP for KVM to express that
>  constraint.
> >>>
> >>> Do you mean if nested hypervisor get the capability of "Guest PT use
> >>> GPA" and EPT has enable. Highly recommend nested hypervisor set "
> >>> Guest PT use GPA " as well.
> >>
> >> Well, it's required more than recommended.  However, it's only required if 
> >> "enable EPT" is set and RTIT_CTL is nonzero.
> >>
> >>> If nested hypervisor is also KVM, "use GPA for processor tracing"
> >>> will be set for sure. But other hypervisor may not do that. So, we'd
> >>> better add a flag in IA32_VMX_EPT_VPID_CAP to express that constraint.
> >>
> >> Correct.  The constraint would be:
> >>
> >> * RTIT_CTL on entry is zero if EPT is disabled
> >>
> >> * RTIT_CTL on entry is zero if EPT is enabled and "Guest PT uses GPA"
> >> is zero
> >>
> >> Maybe IA32_VMX_EPT_VPID_CAP is not the best place.  I'll let Intel decide 
> >> that.
> >
> > Get it. I have feedback to hardware architect. I hope it can be applied but 
> > it may need wait a long time.
> 
> Note that the hardware need not do anything.  However it would be nice if the 
> SDM can define a bit _for the hypervisors_ to
> enforce the above constraint and fail vmentry if they are not respected.
> 

Hi Paolo,
Thanks for your response. I have a question want to ask for you. As you 
mentioned in previous mail " We would like the nested hypervisor to be forced 
to set the "use GPA for processor tracing"". 
Is there have any problem if we don't set "use GPA for processor tracing" 
in nested hypervisor? If yes, what should we do? In patch 9, I pass though PT 
MSRs ( IA32_RTIT_* ) to guest.

Thanks,
Luwei Kang

[PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE

[Byungchul Park]

Now the performance regression was fixed, re-enable
CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS.

Signed-off-by: Byungchul Park 
---
 lib/Kconfig.debug | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 90ea784..fe8fceb 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1138,8 +1138,8 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE if BROKEN
-   select LOCKDEP_COMPLETIONS if BROKEN
+   select LOCKDEP_CROSSRELEASE
+   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help
-- 
1.9.1

[PATCH v2 1/3] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Byungchul Park]

Johan Hovold reported a performance regression by crossrelease like:

> Boot time (from "Linux version" to login prompt) had in fact doubled
> since 4.13 where it took 17 seconds (with my current config) compared to
> the 35 seconds I now see with 4.14-rc4.
>
> I quick bisect pointed to lockdep and specifically the following commit:
>
>   28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition
>  of a crosslock")
>
> which I've verified is the commit which doubled the boot time (compared
> to 28a903f63ec0^) (added by lockdep crossrelease series [1]).

Currently crossrelease performs unwind on every acquisition. But, that
overloads systems too much. So this patch makes unwind optional and set
it to N as default. Instead, it records only acquire_ip normally. Of
course, unwind is sometimes required for full analysis. In that case, we
can set CROSSRELEASE_STACK_TRACE to Y and use it.

In my qemu ubuntu machin (x86_64, 4 cores, 512M), the regression was
fixed like, measuring booting times with 'perf stat --null --repeat 10
$QEMU', where $QEMU launchs a kernel with init=/bin/true:

1. No lockdep enabled

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   2.756558155 seconds time elapsed( +-  0.09% )

2. Lockdep enabled

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   2.968710420 seconds time elapsed( +-  0.12% )

3. Lockdep enabled + crossrelease enabled

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   3.153839636 seconds time elapsed( +-  0.31% )

4. Lockdep enabled + crossrelease enabled + this patch applied

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   2.963669551 seconds time elapsed( +-  0.11% )

Signed-off-by: Byungchul Park 
---
 include/linux/lockdep.h  |  4 
 kernel/locking/lockdep.c |  5 +
 lib/Kconfig.debug| 15 +++
 3 files changed, 24 insertions(+)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index bfa8e0b..70358b5 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -278,7 +278,11 @@ struct held_lock {
 };
 
 #ifdef CONFIG_LOCKDEP_CROSSRELEASE
+#ifdef CONFIG_CROSSRELEASE_STACK_TRACE
 #define MAX_XHLOCK_TRACE_ENTRIES 5
+#else
+#define MAX_XHLOCK_TRACE_ENTRIES 1
+#endif
 
 /*
  * This is for keeping locks waiting for commit so that true dependencies
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index e36e652..5c2ddf2 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4863,8 +4863,13 @@ static void add_xhlock(struct held_lock *hlock)
xhlock->trace.nr_entries = 0;
xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES;
xhlock->trace.entries = xhlock->trace_entries;
+#ifdef CONFIG_CROSSRELEASE_STACK_TRACE
xhlock->trace.skip = 3;
save_stack_trace(&xhlock->trace);
+#else
+   xhlock->trace.nr_entries = 1;
+   xhlock->trace.entries[0] = hlock->acquire_ip;
+#endif
 }
 
 static inline int same_context_xhlock(struct hist_lock *xhlock)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 3db9167..90ea784 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1225,6 +1225,21 @@ config LOCKDEP_COMPLETIONS
 A deadlock caused by wait_for_completion() and complete() can be
 detected by lockdep using crossrelease feature.
 
+config CROSSRELEASE_STACK_TRACE
+   bool "Record more than one entity of stack trace in crossrelease"
+   depends on LOCKDEP_CROSSRELEASE
+   default n
+   help
+The lockdep "cross-release" feature needs to record stack traces
+(of calling functions) for all acquisitions, for eventual later
+use during analysis. By default only a single caller is recorded,
+because the unwind operation can be very expensive with deeper
+stack chains. However, sometimes deeper traces are required for
+full analysis. This option turns on the saving of the full stack
+trace entries.
+
+If unsure, say N.
+
 config DEBUG_LOCKDEP
bool "Lock dependency engine debugging"
depends on DEBUG_KERNEL && LOCKDEP
-- 
1.9.1

Re: [PATCH v5] printk: hash addresses printed with %p

[Jason A. Donenfeld]

A small detail carried over from the other thread:

>
> but a bigger problem might the following thing:
>
> vscnprintf()
>  pointer()
>   ptr_to_id()
>initialize_ptr_secret()
> get_random_bytes()
>  _get_random_bytes()
>   extract_crng()
>_extract_crng()
> spin_lock_irqsave(&crng->lock, flags);   <
>
>
> this, once again, can deadlock. can it? just like before:

So, actually, then, we need to do this as an initcall. Fortunately,
that simplifies things greatly. Here's a rough sketch of what that
looks like, which you'll probably need to debug and refine:



static siphash_key_t ptr_secret __ro_after_init;
static DEFINE_STATIC_KEY_TRUE(no_ptr_secret);

static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec spec)
{
if (static_branch_unlikely(&no_ptr_secret))
return "(pointer value)";

hashval = 

}

static void fill_random_ptr_key(struct random_ready_callback *rdy)
{
get_random_bytes(&ptr_secret, sizeof(ptr_secret));
static_branch_disable(&no_ptr_secret);
}

static struct random_ready_callback random_ready = {
.func = fill_random_ptr_key
};

static int __init initialize_ptr_random(void)
{
int ret = add_random_ready_callback(&random_ready);

if (!ret)
return 0;
else if (ret == -EALREADY) {
fill_random_ptr_key(&random_ready);
return 0;
}

return ret;
}
early_initcall(initialize_ptr_random);

RE: [PATCH] checkpatch: Introduce check for format of Fixes line in commit log

[Parav Pandit]

Hi Joe,

> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Parav Pandit
> Sent: Tuesday, October 10, 2017 5:44 PM
> To: j...@perches.com; a...@canonical.com
> Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; Parav Pandit
> ; Brad Erickson 
> Subject: [PATCH] checkpatch: Introduce check for format of Fixes line in 
> commit
> log
> 
> This patch introduces a format check for 'Fixes' line in commit log for 12
> characters commit id and format for Fixes as ("...").
> 
> Its created against linux-rdma Doug's tree [1].
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> 
> Signed-off-by: Parav Pandit 
> Signed-off-by: Brad Erickson 
> ---
>  scripts/checkpatch.pl | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index
> dd2c262..7d933e4 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2548,6 +2548,14 @@ sub process {
> "Remove Gerrit Change-Id's before submitting
> upstream.\n" . $herecurr);
>   }
> 
> +# Check for incorrect format for Fixes line in commit log
> + if ($in_commit_log && $line =~ /^\s*Fixes:/i) {
> + if ($line !~ /^\s*Fixes: [a-z0-9]{12} \(\".*?\"\)$/i) {
> + ERROR("FIXES_FORMAT",
> +   "Follow format of Fixes: <12 characters
> commit id> (\"...\")\n" . $herecurr);
> + }
> + }
> +
>  # Check if the commit log is in a possible stack dump
>   if ($in_commit_log && !$commit_log_possible_stack_dump &&
>   ($line =~ /^\s*(?:WARNING:|BUG:)/ ||
> --

Did you get a chance to review this minor improvement patch?
Does it look ok?
Can it be pushed to Linux-rdma tree?

Re: [PATCH] powerpc: ipic - fix status get and status clear

[Christophe LEROY]

Le 19/10/2017 à 07:06, Michael Ellerman a écrit :

Christophe Leroy  writes:


IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
which is the mask register.


This seems like it would be a bad bug. But I guess it hasn't mattered
for some reason?


As far as I can see, this function has been added in kernel 2.6.12 but 
has never been used in-tree.


I have discovered this error while implementing NMI watchdog on a 832x 
board, ie this function is needed to know when a machine check exception 
is generated by the watchdog timer.


Christophe



cheers


diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 16f1edd78c40..535cf1f6941c 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -846,12 +846,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq mcp_irq)
  
  u32 ipic_get_mcp_status(void)

  {
-   return ipic_read(primary_ipic->regs, IPIC_SERMR);
+   return ipic_read(primary_ipic->regs, IPIC_SERSR);
  }
  
  void ipic_clear_mcp_status(u32 mask)

  {
-   ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
+   ipic_write(primary_ipic->regs, IPIC_SERSR, mask);
  }
  
  /* Return an interrupt vector or 0 if no interrupt is pending. */

--
2.13.3

[PATCH V2] bcma: Use bcma_debug and not pr_cont in MIPS driver

[Joe Perches]

Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
converted a printk(KERN_DEBUG to bcma_debug.

bcma_debug is guarded by a #define DEBUG via pr_debug.

This means that the bcma_debug will generally not be emitted
but any pr_cont following the bcma_debug will be emitted.

Correct this by removing the uses of pr_cont by using a temporary.

Signed-off-by: Joe Perches 
---

v2: Fix whitespace damage
I hear there's this checkpatch tool...

 drivers/bcma/driver_mips.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 5904ef1aa624..f040aba48d50 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device 
*dev, unsigned int irq)
 {
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
+   char interrupts[20];
+   char *ints = interrupts;
 
-   bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
-   for (i = 0; i <= 6; i++)
-   pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
-   pr_cont("\n");
+   for (i = 0; i < ARRAY_SIZE(irq_name); i++)
+   ints += sprintf(ints, " %s%c",
+   irq_name[i], i == irq ? '*' : ' ');
+
+   bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id, interrupts);
 }
 
 static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
-- 
2.10.0.rc2.1.g053435c

Re: [PATCH] bcma: Use bcma_debug and not pr_cont in MIPS driver

[James Cameron]

On Wed, Oct 18, 2017 at 10:12:18PM -0700, Joe Perches wrote:
> Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
> converted a printk(KERN_DEBUG to bcma_debug.
> 
> bcma_debug is guarded by a #define DEBUG via pr_debug.
> 
> This means that the bcma_debug will generally not be emitted
> but any pr_cont following the bcma_debug will be emitted.
> 
> Correct this by removing the uses of pr_cont by using a temporary.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/bcma/driver_mips.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index 5904ef1aa624..a929956150eb 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device 
> *dev, unsigned int irq)
>  {
>   int i;
>   static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> +char interrupts[20];
> +char *ints = interrupts;

Tabs were changed to spaces.

>  
> - bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
> - for (i = 0; i <= 6; i++)
> - pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> - pr_cont("\n");
> +for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> +ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');

But not on this line.

> +
> +bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id, 
> interrupts);
>  }
>  
>  static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> -- 
> 2.10.0.rc2.1.g053435c
> 

-- 
James Cameron
http://quozl.netrek.org/

Re: [PATCH] Documentation: Add myself to the enforcement statement list

[Greg Kroah-Hartman]

On Wed, Oct 18, 2017 at 04:20:47PM -0700, Laura Abbott wrote:
> I already Acked the patch, add my name to the list as well.
> 
> Signed-off-by: Laura Abbott 
> ---
>  Documentation/process/kernel-enforcement-statement.rst | 1 +
>  1 file changed, 1 insertion(+)

Thanks, now queued up.

greg k-h

Re: [PATCH v2] static_key: Improve uninizialized key warning

[Ingo Molnar]

* Steven Rostedt  wrote:

> On Wed, 18 Oct 2017 12:06:59 -0400
> Steven Rostedt  wrote:
> 
> > > Signed-off-by: Borislav Petkov 
> > > Cc: Hannes Frederic Sowa 
> > > Cc: Ingo Molnar 
> > > Cc: Juergen Gross 
> > > Cc: "Steven Rostedt (VMware)"   
> > 
> > Reviewed-by: Steven Rostedt (VMware) 
> > 
> 
> 
> Ingo, you may want to fix the typo in the subject "uninitialized".

Yeah, I also changed it to %pS to help debug arrays, or cases where somehow a 
non-data symbol ends up being passed to it. Plus I changed the message from:

  static_key_disable_cpuslocked, key virt_spin_lock_key used before call to 
jump_label_init.

to:

  static_key_disable_cpuslocked() static key 'virt_spin_lock_key' used before 
call to jump_label_init()

to make it all obviously readable. I mean, what if the symbol is named 'key' 
and 
we'd get confusing printouts like:

  static_key_disable_cpuslocked, key key used before call to jump_label_init.

Plus functions should be referred to with () to disambiguate them from other 
symbol names. Also, proper use of punctuation symbols.

Thanks,

Ingo

Re: [PATCH v7 4/4] remoteproc: qcom: Add support for mss remoteproc on msm8996

[Sricharan R]

Hi Bjorn,

On 10/17/2017 12:28 AM, Bjorn Andersson wrote:
> On Mon 16 Oct 06:19 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
>> On 10/12/2017 11:50 PM, Bjorn Andersson wrote:
> [..]
>>> Please fix this and add my Acked-by
>> Sure will do, just want to ask, when i am sending updated patches, should i
>> sent all the 4 patches in series or should skip those which are acked by
>> you.
> 
> Please include all the patches in each submission (unless the maintainer
> tells you that he/she applied some of them already).
> 
> Make sure to add any "Acked-by", "Reviewed-by" and "Tested-by" on your
> patches, so that people know that they are already reviewed/tested.
> 
> 
> And finally, when resending patches, add a section between "---" and the
> diff-stat describing changes since the last version - that makes it
> easier to see what changed since last time and will help the reviewer
> look at the "new" things.

 So i was having the ipq8074 q6 remoteproc support based on this series last 
time.
 With the msm8996 now getting cleared, i will rebase my patches and repost.
 Otherwise, just hope that you were ok with the approach [1].

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1481961.html


Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same core id

[Guenter Roeck]

On 10/18/2017 07:28 PM, Shu Wang wrote:

From: "Guenter Roeck" 
To: "Shu Wang" 
Cc: "fenghua yu" , jdelv...@suse.com, 
linux-hw...@vger.kernel.org,
linux-kernel@vger.kernel.org, ch...@redhat.com, yiz...@redhat.com
Sent: Wednesday, October 18, 2017 9:14:39 PM
Subject: Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same core 
id

On 10/17/2017 08:21 PM, Shu Wang wrote:

From: "Guenter Roeck" 
To: shuw...@redhat.com
Cc: "fenghua yu" , jdelv...@suse.com,
linux-hw...@vger.kernel.org,
linux-kernel@vger.kernel.org, ch...@redhat.com, yiz...@redhat.com
Sent: Tuesday, October 17, 2017 11:25:50 PM
Subject: Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same
core id

On Tue, Oct 17, 2017 at 04:44:50PM +0800, shuw...@redhat.com wrote:

From: Shu Wang 

Fix kernel warning on my 4cpus 2core_id system. The cpu0 and cpu1 have
same core_id 0, so both cpu0 and cpu1 will try to create file temp2_label
when it's online.


What system/cpu is that ?

Normally I would assume that each CPU (package) instantiates
a separate instance of the driver.


The system is ThinkPad X1 Carbon 3rd laptop, model 20BTS1N70F.




- coretemp_cpu_online(cpu=0)
- create_core_data(cpu=0, attr_no=2)
 - create_core_attrs(attr_no=2)
- coretemp_cpu_online(cpu=1)
- create_core_data(cpu=1, attr_no=2)
 - create_core_attrs(attr_no=2)

$ grep -e processor -e 'core id' /proc/cpuinfo
processor   : 0
core id : 0
processor   : 1
core id : 0
processor   : 2
core id : 1
processor   : 3
core id : 1


Complete output of /proc/cpuinfo might be helpful.


$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz


This is a hyperthreading CPU, which should already be handled,


Do you mean that for my system, coretemp_cpu_online should only
be called twice instead of four times to create two core attrs?



coretemp_add_core() should only be called twice, and cpumask_intersects()
should filter out the duplicate ones.

/*
 * Check whether a thread sibling is already online. If not add the
 * interface for this CPU core.
 */
if (!cpumask_intersects(&pdata->cpumask, topology_sibling_cpumask(cpu)))
coretemp_add_core(pdev, cpu, 0);

Thomas, is it possible that something is wrong with this code ?

Guenter


and the problem would affect pretty much everyone. I'll have
to look into this more closely. Is this with the ToT kernel ?


What's a ToT kernel? The kernel I built was the latest
kernel-4.14.0_rc5+ from linus repo.



ToT => Top Of Tree. My apologies, I thought that was a commonly used acronym.

Guenter

Re: [PATCH v2 2/2] extcon: add optional debounce-timeout-ms attribute

[Chanwoo Choi]

On 2017년 10월 19일 13:59, Chanwoo Choi wrote:
> Hi,
> 
> On 2017년 10월 19일 12:26, Raveendra Padasalagi wrote:
>> Add changes to capture optional dt attribute "debounce-timeout-ms"
>> provided in extcon node and used the same value if provided otherwise
>> default value of 20ms is used for id and vbus gpios debounce time.
>>
>> Signed-off-by: Raveendra Padasalagi 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Srinath Mannam 
>> ---
>>
>> Changes in v2:
>>  Rename gpio_debounce_timeout_ms to debounce_usecs
>>
>>  drivers/extcon/extcon-usb-gpio.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-usb-gpio.c 
>> b/drivers/extcon/extcon-usb-gpio.c
>> index 9c925b0..76ef1da 100644
>> --- a/drivers/extcon/extcon-usb-gpio.c
>> +++ b/drivers/extcon/extcon-usb-gpio.c
>> @@ -41,6 +41,7 @@ struct usb_extcon_info {
>>  
>>  unsigned long debounce_jiffies;
>>  struct delayed_work wq_detcable;
>> +unsigned int debounce_usecs;
>>  };
>>  
>>  static const unsigned int usb_extcon_cable[] = {
>> @@ -133,6 +134,11 @@ static int usb_extcon_probe(struct platform_device 
>> *pdev)
>>  if (IS_ERR(info->vbus_gpiod))
>>  return PTR_ERR(info->vbus_gpiod);
>>  
>> +ret = of_property_read_u32(np, "input-debounce",
>> + &info->debounce_usecs);
>> +if (ret)
>> +info->debounce_usecs = USB_GPIO_DEBOUNCE_MS;
> 
> The USB_GPIO_DEBOUNCE_MS indicates 20 millisecond.
> You need to redefine it as following:
>   -#define USB_GPIO_DEBOUNCE_MS   20  /* ms */
>   +#define USB_GPIO_DEBOUNCE_USEC 2
> 
>   info->debounce_usecs = USB_GPIO_DEBOUNCE_USEC;
> 
> or
>   info->debounce_usecs = USB_GPIO_DEBOUNCE_MS * 1000;
> 
> 
>> +
>>  info->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
>>  if (IS_ERR(info->edev)) {
>>  dev_err(dev, "failed to allocate extcon device\n");
>> @@ -147,13 +153,13 @@ static int usb_extcon_probe(struct platform_device 
>> *pdev)
>>  
>>  if (info->id_gpiod)
>>  ret = gpiod_set_debounce(info->id_gpiod,
>> - USB_GPIO_DEBOUNCE_MS * 1000);
>> + info->debounce_usecs * 1000);
> 
> The debounce_usecs is already microsecond, You don't need to mutiply with 
> 1000.
> 
> 
>>  if (!ret && info->vbus_gpiod)
>>  ret = gpiod_set_debounce(info->vbus_gpiod,
>> - USB_GPIO_DEBOUNCE_MS * 1000);
>> + info->debounce_usecs * 1000);

You don't need to mutiply with 1000.

>>  
>>  if (ret < 0)
>> -info->debounce_jiffies = msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
>> +info->debounce_jiffies = msecs_to_jiffies(info->debounce_usecs);

You should you the 'usecs_to_jiffies' because info->debounce_usecs indicates 
the usec.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v3 1/6] remoteproc: qcom: mdt_loader: Make the firmware authentication optional

[Sricharan R]

Hi Bjorn,

On 10/12/2017 11:56 PM, Bjorn Andersson wrote:
> On Wed 30 Aug 21:45 PDT 2017, Sricharan R wrote:
> 
>> qcom_mdt_load function loads the mdt type firmware and
>> initialises the secure memory as well. Make the initialisation only
>> when requested by the caller, so that the function can be used
>> by self-authenticating remoteproc as well.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  drivers/soc/qcom/mdt_loader.c   | 70 
>> +++--
>>  include/linux/soc/qcom/mdt_loader.h |  3 ++
>>  2 files changed, 62 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
>> index bd63df0..851f5d7 100644
>> --- a/drivers/soc/qcom/mdt_loader.c
>> +++ b/drivers/soc/qcom/mdt_loader.c
>> @@ -86,9 +86,9 @@ ssize_t qcom_mdt_get_size(const struct firmware *fw)
>>   *
>>   * Returns 0 on success, negative errno otherwise.
>>   */
> 
> This kerneldoc is now lacks @pas_init, but as it's just an internal
> function and you have kerneldoc on the public functions I suggest that
> you drop it.
> 

 Sure. Will change.

>> -int qcom_mdt_load(struct device *dev, const struct firmware *fw,
>> -  const char *firmware, int pas_id, void *mem_region,
>> -  phys_addr_t mem_phys, size_t mem_size)
>> +static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>> +   const char *firmware, int pas_id, void *mem_region,
>> +   phys_addr_t mem_phys, size_t mem_size, bool pas_init)
> 
> With this you have my Acked-by.
> 

 Thanks.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing

[Tomasz Nowicki]

On 18.10.2017 19:30, Jeremy Linton wrote:

On 10/18/2017 05:24 AM, Tomasz Nowicki wrote:

On 18.10.2017 07:39, Tomasz Nowicki wrote:

Hi,

On 17.10.2017 17:22, Jeremy Linton wrote:

Hi,

On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:

Hi Jeremy,

I did second round of review and have some more comments, please 
see below:


On 12.10.2017 21:48, Jeremy Linton wrote:

ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.

Add the code to parse the cache hierarchy and report the total
number of levels of cache for a given core using
acpi_find_last_cache_level() as well as fill out the individual
cores cache information with cache_setup_acpi() once the
cpu_cacheinfo structure has been populated by the arch specific
code.

Further, report peers in the topology using setup_acpi_cpu_topology()
to report a unique ID for each processing unit at a given level
in the tree. These unique id's can then be used to match related
processing units which exist as threads, COD (clusters
on die), within a given package, etc.

Signed-off-by: Jeremy Linton 
---
  drivers/acpi/pptt.c | 485 


  1 file changed, 485 insertions(+)
  create mode 100644 drivers/acpi/pptt.c

diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
new file mode 100644
index ..c86715fed4a7
--- /dev/null
+++ b/drivers/acpi/pptt.c
@@ -0,1 +1,485 @@
+/*
+ * Copyright (C) 2017, ARM
+ *
+ * This program is free software; you can redistribute it and/or 
modify it

+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but 
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License for

+ * more details.
+ *
+ * This file implements parsing of Processor Properties Topology 
Table (PPTT)
+ * which is optionally used to describe the processor and cache 
topology.
+ * Due to the relative pointers used throughout the table, this 
doesn't

+ * leverage the existing subtable parsing in the kernel.
+ */
+#define pr_fmt(fmt) "ACPI PPTT: " fmt
+
+#include 
+#include 
+#include 
+
+/*
+ * Given the PPTT table, find and verify that the subtable entry
+ * is located within the table
+ */
+static struct acpi_subtable_header *fetch_pptt_subtable(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    struct acpi_subtable_header *entry;
+
+    /* there isn't a subtable at reference 0 */
+    if (!pptt_ref)
+    return NULL;
+
+    if (pptt_ref + sizeof(struct acpi_subtable_header) > 
table_hdr->length)

+    return NULL;
+
+    entry = (struct acpi_subtable_header *)((u8 *)table_hdr + 
pptt_ref);

+
+    if (pptt_ref + entry->length > table_hdr->length)
+    return NULL;
+
+    return entry;
+}
+
+static struct acpi_pptt_processor *fetch_pptt_node(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    return (struct acpi_pptt_processor 
*)fetch_pptt_subtable(table_hdr, pptt_ref);

+}
+
+static struct acpi_pptt_cache *fetch_pptt_cache(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    return (struct acpi_pptt_cache 
*)fetch_pptt_subtable(table_hdr, pptt_ref);

+}
+
+static struct acpi_subtable_header *acpi_get_pptt_resource(
+    struct acpi_table_header *table_hdr,
+    struct acpi_pptt_processor *node, int resource)
+{
+    u32 ref;
+
+    if (resource >= node->number_of_priv_resources)
+    return NULL;
+
+    ref = *(u32 *)((u8 *)node + sizeof(struct acpi_pptt_processor) +
+  sizeof(u32) * resource);
+
+    return fetch_pptt_subtable(table_hdr, ref);
+}
+
+/*
+ * given a pptt resource, verify that it is a cache node, then walk
+ * down each level of caches, counting how many levels are found
+ * as well as checking the cache type (icache, dcache, unified). 
If a

+ * level & type match, then we set found, and continue the search.
+ * Once the entire cache branch has been walked return its max
+ * depth.
+ */
+static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr,
+    int local_level,
+    struct acpi_subtable_header *res,
+    struct acpi_pptt_cache **found,
+    int level, int type)
+{
+    struct acpi_pptt_cache *cache;
+
+    if (res->type != ACPI_PPTT_TYPE_CACHE)
+    return 0;
+
+    cache = (struct acpi_pptt_cache *) res;
+    while (cache) {
+    local_level++;
+
+    if ((local_level == level) &&
+    (cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) &&
+    ((cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) == 
type)) {


Attributes have to be shifted:

(cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) >> 2


Hmmm, I'm not sure that 

[PATCH] bcma: Use bcma_debug and not pr_cont in MIPS driver

[Joe Perches]

Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
converted a printk(KERN_DEBUG to bcma_debug.

bcma_debug is guarded by a #define DEBUG via pr_debug.

This means that the bcma_debug will generally not be emitted
but any pr_cont following the bcma_debug will be emitted.

Correct this by removing the uses of pr_cont by using a temporary.

Signed-off-by: Joe Perches 
---
 drivers/bcma/driver_mips.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 5904ef1aa624..a929956150eb 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device 
*dev, unsigned int irq)
 {
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
+char interrupts[20];
+char *ints = interrupts;
 
-   bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
-   for (i = 0; i <= 6; i++)
-   pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
-   pr_cont("\n");
+for (i = 0; i < ARRAY_SIZE(irq_name); i++)
+ints += sprintf(ints, " %s%c",
+   irq_name[i], i == irq ? '*' : ' ');
+
+bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id, interrupts);
 }
 
 static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
-- 
2.10.0.rc2.1.g053435c

Re: [PATCH] perf test shell: trace+probe_libc_inet_pton.sh: force to use /bin/bash to load this script

[Li Zhijian]

ignore this patch please, it will broken the test description which is read 
from the first line of this script

Thanks


On 10/19/2017 11:53 AM, Li Zhijian wrote:

this script contains Array, but not all sh support Array. by default, dash 
provides sh at ubuntu/debian
which can not support Array. so force to use /bin/bash

it can fix following issue:
lizhijian@localhost:~/lkp/linux/tools/perf/tests/shell$ sudo 
./trace+probe_libc_inet_pton.sh
[sudo] password for lizhijian: PING ::1(::1) 56 data bytes
./trace+probe_libc_inet_pton.sh: 30: ./trace+probe_libc_inet_pton.sh: Bad 
substitution
./trace+probe_libc_inet_pton.sh: 32: ./trace+probe_libc_inet_pton.sh: Bad 
substitution

Signed-off-by: Li Zhijian 
---
  tools/perf/tests/shell/trace+probe_libc_inet_pton.sh | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
index 7a84d73..df04cc1 100755
--- a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
@@ -1,3 +1,5 @@
+#!/bin/bash
+
  # probe libc's inet_pton & backtrace it with ping
  
  # Installs a probe on libc's inet_pton function, that will use uprobes,

Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

[Sekhar Nori]

On Wednesday 18 October 2017 07:47 PM, Franklin S Cooper Jr wrote:
> 
> 
> On 10/18/2017 08:24 AM, Sekhar Nori wrote:
>> Hi Marc,
>>
>> On Wednesday 18 October 2017 06:14 PM, Marc Kleine-Budde wrote:
>>> On 09/21/2017 02:48 AM, Franklin S Cooper Jr wrote:


 On 09/20/2017 04:37 PM, Mario Hüttel wrote:
>
>
> On 09/20/2017 10:19 PM, Franklin S Cooper Jr wrote:
>> Hi Wenyou,
>>
>> On 09/17/2017 10:47 PM, Yang, Wenyou wrote:
>>>
>>> On 2017/9/14 13:06, Sekhar Nori wrote:
 On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
>> resulted in errors. Scoping the signals I noticed that only a single
>> bit
>> was being transmitted and with a bit more investigation realized the
>> actual
>> MCAN IP would go back to initialization mode automatically.
>>
>> It appears this issue is due to the MCAN needing to use the 
>> Transmitter
>> Delay Compensation Mode as defined in the MCAN User's Guide. When 
>> this
>> mode is used the User's Guide indicates that the Transmitter Delay
>> Compensation Offset register should be set. The document mentions
>> that this
>> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>>
>> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document
>> indicates
>> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
>> Therefore, only enable this mode and only set TDCO when the data bit
>> rate
>> is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> ---
>> I'm pretty surprised that this hasn't been implemented already since
>> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
>> supports up to 10 Mbps.
>>
>> So it will be nice to get comments from users of this driver to
>> understand
>> if they have been able to use CAN-FD beyond 2.5 Mbps without this
>> patch.
>> If they haven't what did they do to get around it if they needed 
>> higher
>> speeds.
>>
>> Meanwhile I plan on testing this using a more "realistic" CAN bus to
>> insure
>> everything still works at 5 Mbps which is the max speed of my CAN
>> transceiver.
> ping. Anyone has any thoughts on this?
 I added Dong who authored the m_can driver and Wenyou who added the 
 only
 in-kernel user of the driver for any help.
>>> I tested it on SAMA5D2 Xplained board both with and without this patch, 
>>> both work with the 4M bps data bit rate.
>> Thank you for testing this out. Its interesting that you have been able
>> to use higher speeds without this patch. What is the CAN transceiver
>> being used on the SAMA5D2 Xplained board? I tried looking at the
>> schematic but it seems the CAN signals are used on an extension board
>> which I can't find the schematic for. Also do you mind sharing your test
>> setup? Were you doing a short point to point test?
>>
>> Thank You,
>> Franklin
> Hello Franklin,
>
> your patch definitely makes sense.
>
> I forgot the TDC in my patches because it was not present in the
> previous driver versions and because I didn't encounter any
> problems when testing it myself.
>
> The error is highly dependent on the hardware (transceiver) setup.
> So it is definitely possible that some people don't encounter errors
> without your patch.

 So the Transmission Delay Compensation feature Value register is suppose
 to take into consideration the transceiver delay automatically and add
 the value of TDCO on top of that. So why would TDCO be dependent on the
 transceiver? I've heard conflicting things regarding TDC so any
 clarification on what actually impacts it would be appreciated.

 Also part of the issue I'm having is how can we properly configure TDCO?
 Configuring TDCO is essentially figuring out what Secondary Sample Point
 to use. However, it is unclear what value to set SSP to and which use
 cases a given SSP will work or doesn't work. I've seen various
 recommendations from Bosch on choosing SSP but ultimately it seems they
 suggestion "real world testing" to come up with a proper value. Not
 setting TDCO causes problems for my device and improperly setting TDCO
 causes problems for my device. So its likely any value I use could end
 up breaking something for someone else.

 Currently I leaning to a DT property that can be used for setting SSP.
 Perhaps use a generic default value and allow individuals to override it
 via DT?
>>>
>>> Sou

Re: [PATCH] powerpc: ipic - fix status get and status clear

[Michael Ellerman]

Christophe Leroy  writes:

> IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
> which is the mask register.

This seems like it would be a bad bug. But I guess it hasn't mattered
for some reason?

cheers

> diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
> index 16f1edd78c40..535cf1f6941c 100644
> --- a/arch/powerpc/sysdev/ipic.c
> +++ b/arch/powerpc/sysdev/ipic.c
> @@ -846,12 +846,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq mcp_irq)
>  
>  u32 ipic_get_mcp_status(void)
>  {
> - return ipic_read(primary_ipic->regs, IPIC_SERMR);
> + return ipic_read(primary_ipic->regs, IPIC_SERSR);
>  }
>  
>  void ipic_clear_mcp_status(u32 mask)
>  {
> - ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
> + ipic_write(primary_ipic->regs, IPIC_SERSR, mask);
>  }
>  
>  /* Return an interrupt vector or 0 if no interrupt is pending. */
> -- 
> 2.13.3

Re: [PATCH v2 1/2] Documentation: dt: extcon: add optional debounce-timeout-ms attribute

[Chanwoo Choi]

Hi,

On 2017년 10월 19일 13:47, Chanwoo Choi wrote:
> On 2017년 10월 19일 12:25, Raveendra Padasalagi wrote:
>> Add documentation on optional dt attribute "debounce-timeout-ms"
>> in extcon node to capture user specified timeout value for id
>> and vbus gpio detection.
>>
>> Signed-off-by: Raveendra Padasalagi 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Srinath Mannam 
>> ---
>>
>> Changes in v2:
>>  Rename debounce-timeout-ms to input-debounce
>>
>>  Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt 
>> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> index dfc14f7..d115900 100644
>> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
>> @@ -10,6 +10,9 @@ Either one of id-gpio or vbus-gpio must be present. Both 
>> can be present as well.
>>  - id-gpio: gpio for USB ID pin. See gpio binding.
>>  - vbus-gpio: gpio for USB VBUS pin.
>>  
>> +Optional properties:
>> +- input-debounce: debounce timeout value for id and vbus gpio in 
>> microseconds.
> 
> The pinctrl-bindings.txt[1] specify the unit of 'input-debounce'.
> The unit is usec instead of 'microsecond'. You need to modify the description 
> of unit.
> [1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

Sorry. My mistake. I confused the 'nsec' with 'usec'. This patch is right.
Please ignore my comment.

> 
>> +
>>  Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
>>  extcon_usb1 {
>>  compatible = "linux,extcon-usb-gpio";
>>
> 
> 

Looks good to me.
Reviewed-by: Chanwoo Choi 

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2 2/2] extcon: add optional debounce-timeout-ms attribute

[Chanwoo Choi]

Hi,

On 2017년 10월 19일 12:26, Raveendra Padasalagi wrote:
> Add changes to capture optional dt attribute "debounce-timeout-ms"
> provided in extcon node and used the same value if provided otherwise
> default value of 20ms is used for id and vbus gpios debounce time.
> 
> Signed-off-by: Raveendra Padasalagi 
> Reviewed-by: Ray Jui 
> Reviewed-by: Srinath Mannam 
> ---
> 
> Changes in v2:
>  Rename gpio_debounce_timeout_ms to debounce_usecs
> 
>  drivers/extcon/extcon-usb-gpio.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-usb-gpio.c 
> b/drivers/extcon/extcon-usb-gpio.c
> index 9c925b0..76ef1da 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -41,6 +41,7 @@ struct usb_extcon_info {
>  
>   unsigned long debounce_jiffies;
>   struct delayed_work wq_detcable;
> + unsigned int debounce_usecs;
>  };
>  
>  static const unsigned int usb_extcon_cable[] = {
> @@ -133,6 +134,11 @@ static int usb_extcon_probe(struct platform_device *pdev)
>   if (IS_ERR(info->vbus_gpiod))
>   return PTR_ERR(info->vbus_gpiod);
>  
> + ret = of_property_read_u32(np, "input-debounce",
> +  &info->debounce_usecs);
> + if (ret)
> + info->debounce_usecs = USB_GPIO_DEBOUNCE_MS;

The USB_GPIO_DEBOUNCE_MS indicates 20 millisecond.
You need to redefine it as following:
-#define USB_GPIO_DEBOUNCE_MS   20  /* ms */
+#define USB_GPIO_DEBOUNCE_USEC 2

info->debounce_usecs = USB_GPIO_DEBOUNCE_USEC;

or
info->debounce_usecs = USB_GPIO_DEBOUNCE_MS * 1000;


> +
>   info->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
>   if (IS_ERR(info->edev)) {
>   dev_err(dev, "failed to allocate extcon device\n");
> @@ -147,13 +153,13 @@ static int usb_extcon_probe(struct platform_device 
> *pdev)
>  
>   if (info->id_gpiod)
>   ret = gpiod_set_debounce(info->id_gpiod,
> -  USB_GPIO_DEBOUNCE_MS * 1000);
> +  info->debounce_usecs * 1000);

The debounce_usecs is already microsecond, You don't need to mutiply with 1000.


>   if (!ret && info->vbus_gpiod)
>   ret = gpiod_set_debounce(info->vbus_gpiod,
> -  USB_GPIO_DEBOUNCE_MS * 1000);
> +  info->debounce_usecs * 1000);
>  
>   if (ret < 0)
> - info->debounce_jiffies = msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
> + info->debounce_jiffies = msecs_to_jiffies(info->debounce_usecs);

ditto.

>  
>   INIT_DELAYED_WORK(&info->wq_detcable, usb_extcon_detect_cable);
>  
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2 1/2] Documentation: dt: extcon: add optional debounce-timeout-ms attribute

[Chanwoo Choi]

On 2017년 10월 19일 12:25, Raveendra Padasalagi wrote:
> Add documentation on optional dt attribute "debounce-timeout-ms"
> in extcon node to capture user specified timeout value for id
> and vbus gpio detection.
> 
> Signed-off-by: Raveendra Padasalagi 
> Reviewed-by: Ray Jui 
> Reviewed-by: Srinath Mannam 
> ---
> 
> Changes in v2:
>  Rename debounce-timeout-ms to input-debounce
> 
>  Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> index dfc14f7..d115900 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -10,6 +10,9 @@ Either one of id-gpio or vbus-gpio must be present. Both 
> can be present as well.
>  - id-gpio: gpio for USB ID pin. See gpio binding.
>  - vbus-gpio: gpio for USB VBUS pin.
>  
> +Optional properties:
> +- input-debounce: debounce timeout value for id and vbus gpio in 
> microseconds.

The pinctrl-bindings.txt[1] specify the unit of 'input-debounce'.
The unit is usec instead of 'microsecond'. You need to modify the description 
of unit.
[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

> +
>  Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
>   extcon_usb1 {
>   compatible = "linux,extcon-usb-gpio";
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [V14,1/4] powerpc/vphn: Update CPU topology when VPHN enabled

[Michael Ellerman]

On Fri, 2017-09-08 at 20:47:27 UTC, Michael Bringmann wrote:
> powerpc/vphn: On Power systems with shared configurations of CPUs
> and memory, there are some issues with the association of additional
> CPUs and memory to nodes when hot-adding resources.  This patch
> corrects the currently broken capability to set the topology for
> shared CPUs in LPARs.  At boot time for shared CPU lpars, the
> topology for each CPU was being set to node zero.  Now when
> numa_update_cpu_topology() is called appropriately, the Virtual
> Processor Home Node (VPHN) capabilities information provided by the
> pHyp allows the appropriate node in the shared configuration to be
> selected for the CPU.
> 
> Signed-off-by: Michael Bringmann 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/17f444c0549f2ce037646871e748cf

cheers

Re: [PATCH 01/14] Documentation: Add SoundWire summary

[Vinod Koul]

Thanks for the quick review Randy,

On Wed, Oct 18, 2017 at 08:33:08PM -0700, Randy Dunlap wrote:
> On 10/18/17 20:03, Vinod Koul wrote:

> > +SoundWire is a new interface ratified in 2015 by the MIPI Alliance.
> > +SoundWire is used for transporting data typically related to audio
> > +functions. SoundWire interface is optimized to integrate audio devices in
> > +mobile or mobile inspired systems.
> > +
> > +SoundWire is a 2-Pin multi-drop interface with data and clock line. It
> 
>   2-pin

ok

> > +The SoundWire protocol supports up to eleven Slave interfaces. All the
> > +interfaces share the common Bus containing data and clock line. Each of the
> > +Slaves can support up to 14 Data Ports. 13 Data Ports are dedicated to 
> > audio
> > +transport. Data Port0 is dedicated to transport of Bulk control 
> > information,
> > +each of the audio Data Ports (1..14) can support up to 8 Channels in
> 
> (1..13) ??

nope. 1 to 14, both inclusive, thats why 14 Data Ports

> > +Bus:
> > +Implements SoundWire Linux Bus which handles the SoundWire protocol.
> > +It programs all the MIPI defined Slave registers. It represents a SoundWire
> 
>MIPI-defined
> 
> > +Master. There can be multiple instances of Bus maybe present in a system.
> 
> eh?
>Multiple instances of Bus may be present in a system.

sounds better

> > +int sdw_add_bus_master(struct sdw_bus *bus)
> > +{
> > +if (!bus->dev)
> > +return -ENODEV;
> > +
> > +mutex_init(&bus->lock);
> > +INIT_LIST_HEAD(&bus->slaves);
> > +
> > +   /* Check ACPI for Slave devices */
> > +sdw_acpi_find_slaves(bus);
> > +
> > +   /* Check DT for Slave devices */
> > +   sdw_of_find_slaves(bus);
> 
> Please use same indentation as sdw_acpi_find_slaves().

ah not sure why it came like this, thanks for pointing out

> > +The MIPI specification requires each Slave interface to expose a unique
> > +48-bit identifier, stored in 6 read only dev_id registers. This dev_id
> 
>   read-only

right

> > +identifier, Bus enumerates the Slave device based on the 48-bit identifier.
> > +Slave device and driver match is done based on this 48-bit identifier. 
> > Probe
> > +of the Slave driver is called by Bus on successful match between device and
> > +driver id. A parent/child relationship is enforced between Slave and Master
> 
> maybe reverse this order. Master and Slave
> 
> to be in the "parent/child" order?  Unless I have them backwards?

right, will update this

> > +devices (the logical representation is aligned with the physical
> > +connectivity).
> > +
> > +The information on Master/Slave dependencies is stored in platform data,
> > +board-file, ACPI or DT. The MIPI Software specification defines an
> 

ok

-- 
~Vinod

Re: [PATCH v5 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

[AKASHI Takahiro]

On Sat, Oct 14, 2017 at 07:37:04PM +0800, kbuild test robot wrote:
> Hi AKASHI,
> 
> [auto build test WARNING on arm64/for-next/core]
> [also build test WARNING on v4.14-rc4 next-20171013]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/AKASHI-Takahiro/arm64-kexec-add-kexec_file_load-support/20171012-003448
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> for-next/core
> config: x86_64-randconfig-in0-10141752 (attached as .config)
> compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
> >> kernel/kexec_file.o: warning: objtool: _kexec_kernel_image_load()+0x31: 
> >> unsupported stack register modification

I talked to Josh (objtool maintainer) and confirmed this is an issue
of objtool, not a bug in my patch.

-Takahiro AKASHI

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

Re: [PATCH 1/2] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default

[Byungchul Park]

On Wed, Oct 18, 2017 at 12:09:44PM +0200, Ingo Molnar wrote:
> BTW., have you attempted limiting the depth of the stack traces? I suspect 
> more 
> than 2-4 are rarely required to disambiguate the calling context.

I did it for you. Let me show you the result.

1. No lockdep

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   2.756558155 seconds time elapsed( +-  0.09% )

2. Lockdep

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   2.968710420 seconds time elapsed( +-  0.12% )

3. Lockdep + Crossrelease 5 entries

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   3.153839636 seconds time elapsed( +-  0.31% )

4. Lockdep + Crossrelease 3 entries

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   3.137205534 seconds time elapsed( +-  0.87% )

5. Lockdep + Crossrelease + This patch

 Performance counter stats for 'qemu_booting_time.sh bzImage' (10 runs):

   2.963669551 seconds time elapsed( +-  0.11% )

And I will add the result in commit message at the next spin.

Thanks,
Byungchul

Re: [PATCH] zswap: Same-filled pages handling

[Andi Kleen]

> Yes.  Every 64-bit repeating pattern is also a 32-bit repeating pattern.
> Supporting a 64-bit pattern on a 32-bit kernel is painful, but it makes
> no sense to *not* support a 64-bit pattern on a 64-bit kernel.  

But a 32bit repeating pattern is not necessarily a 64bit pattern.

>This is the same approach used in zram, fwiw.

Sounds bogus.

-Andi

Re: [PATCH v1] mm/mempolicy.c: Fix get_nodes() off-by-one error.

[Andi Kleen]

On Thu, Oct 19, 2017 at 03:48:09AM +, Sandoval Castro, Luis Felipe wrote:
> On Tue 18-10-17 10:42:34, Luis Felipe Sandoval Castro wrote:
> 
> Sorry for the delayed replay, from your feedback I don't think my
> patch has any chances of being merged... I'm wondering though,
> if a note in the man pages "range non inclusive" or something
> like that would help to avoid confusions? Thanks

Yes fixing the man pages is a good idea.

-Andi

[patch-rt] drivers/zram: pass num_pages to zram_meta_init_table_locks()

[Mike Galbraith]

zram cleanup forgot to adjust passed argument when changing
zram_meta_init_table_locks() to expect page count instead
of disk size.  Doing so fixes ltp inspired explosions.

Signed-off-by: Mike Galbraith 
---
 drivers/block/zram/zram_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -819,7 +819,7 @@ static bool zram_meta_alloc(struct zram
return false;
}
 
-   zram_meta_init_table_locks(zram, disksize);
+   zram_meta_init_table_locks(zram, num_pages);
return true;
 }
 

[PATCH] perf test shell: trace+probe_libc_inet_pton.sh: force to use /bin/bash to load this script

[Li Zhijian]

this script contains Array, but not all sh support Array. by default, dash 
provides sh at ubuntu/debian
which can not support Array. so force to use /bin/bash

it can fix following issue:
lizhijian@localhost:~/lkp/linux/tools/perf/tests/shell$ sudo 
./trace+probe_libc_inet_pton.sh
[sudo] password for lizhijian: PING ::1(::1) 56 data bytes
./trace+probe_libc_inet_pton.sh: 30: ./trace+probe_libc_inet_pton.sh: Bad 
substitution
./trace+probe_libc_inet_pton.sh: 32: ./trace+probe_libc_inet_pton.sh: Bad 
substitution

Signed-off-by: Li Zhijian 
---
 tools/perf/tests/shell/trace+probe_libc_inet_pton.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
index 7a84d73..df04cc1 100755
--- a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
@@ -1,3 +1,5 @@
+#!/bin/bash
+
 # probe libc's inet_pton & backtrace it with ping
 
 # Installs a probe on libc's inet_pton function, that will use uprobes,
-- 
2.7.4

Re: [PATCH] KVM: X86: #GP when guest attempts to write MCi banks w/o 0

[Jim Mattson]

MCi_STATUS sounds fine, or any other Intel constraints that are
guarded by checks for virtualizing an Intel CPU.

On Wed, Oct 18, 2017 at 8:04 PM, Wanpeng Li  wrote:
> On 10/19/17 10:49 AM, Jim Mattson wrote:
>
> Right. I was side-tracked by the code above yours for MCi_CTL.
> However, does writing a non-zero value to MCi_STATUS/ADDR/MISC raise
> #GP on AMD hardware? It is not clear from the APM. For MCi_MISC0, the
>
>
> AMD Volume 2:
>
> 9.3.2 Error-Reporting Register Bank:
>
> Attempting to write a value other than 0 to an MCi_STATUS register will
> raise a general protection (#GP) exception.
>
> So maybe my patch can just handle MCi_STATUS or current patch is ok, what's
> your opinion?
>
>
> Regards,
> Wanpeng Li
>
>
> APM says:
> "In some implementations, the MCi_MISC0 register is used for error
> thresholding." Figure 9-8: Miscellaneous Information Register
> (Thresholding Register Format) suggests that non-zero value can, in
> fact, be written to MCi_MISC0 in such implementations.
>
> Do any of the AMD contributors want to weigh in?
>
> On Wed, Oct 18, 2017 at 6:39 PM, Wanpeng Li  wrote:
>
> Hi Jim，
> On 10/19/17 12:28 AM, Jim Mattson wrote:
>
> The AMD APM says, "For each error-reporting register bank, software
> should set the enable bits to 1 in the MCi_CTL register for the error
> types it wants the processor to report. Software can write each
> MCi_CTL with all 1s to enable all error-reporting mechanisms.' It does
> not say that only all 1's or all 0's are allowed, and it implies that
> any value is allowed.
>
> Since this is a vendor-agnostic function, the Intel-specific
> constraints should only be applied when virtualizing Intel CPUs (in
> particular, Intel P6 family CPUs). The same comment applies to the
> existing constraints from commit 890ca9aefa78 ("KVM: Add MCE
>
> I have a discuss with the author of ("KVM: Add MCE support") face to
> face today in a kernel meeting held in our country. He told me his patch
> is against Intel architecture and not consider AMD when he introduced
> the patch. In addition, the difference which you mentioned is about
> MCi_CTL, however, my patches just focus on MCi_STATUS/ADDR/MISC.
>
> Regards,
> Wanpeng Li
>
> support"), which were only partially relaxed by commit 114be429c8cd4
> ("KVM: allow bit 10 to be cleared in MSR_IA32_MC4_CTL").
>
> On Wed, Oct 18, 2017 at 2:49 AM, Wanpeng Li  wrote:
>
> From: Wanpeng Li 
>
> SDM section 15.3.2.2~15.3.2.4 mentioned that MCi_STATUS/ADDR/MISC, when the
> registers are implemented, these registers can be cleared by explicitly
> writing
> 0s to these registers. Writing 1s to these registers will cause a
> general-protection exception.
>
> The mce is emulated in qemu, so just the guest attempts to write 1 to these
> registers should cause a #GP, this patch does it.
>
> Cc: Radim Krčmář 
> Cc: Jim Mattson 
> Signed-off-by: Wanpeng Li 
> ---
>   arch/x86/kvm/x86.c | 9 +++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 5669af0..a8680ea 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2006,10 +2006,12 @@ static void kvmclock_sync_fn(struct work_struct
> *work)
>  KVMCLOCK_SYNC_PERIOD);
>   }
>
> -static int set_msr_mce(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> +static int set_msr_mce(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>   {
>  u64 mcg_cap = vcpu->arch.mcg_cap;
>  unsigned bank_num = mcg_cap & 0xff;
> +   u32 msr = msr_info->index;
> +   u64 data = msr_info->data;
>
>  switch (msr) {
>  case MSR_IA32_MCG_STATUS:
> @@ -2034,6 +2036,9 @@ static int set_msr_mce(struct kvm_vcpu *vcpu, u32 msr,
> u64 data)
>  if ((offset & 0x3) == 0 &&
>  data != 0 && (data | (1 << 10)) != ~(u64)0)
>  return -1;
> +   if (!msr_info->host_initiated &&
> +   (offset & 0x3) != 0 && data != 0)
> +   return -1;
>  vcpu->arch.mce_banks[offset] = data;
>  break;
>  }
> @@ -2283,7 +2288,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
>  case MSR_IA32_MCG_CTL:
>  case MSR_IA32_MCG_STATUS:
>  case MSR_IA32_MC0_CTL ... MSR_IA32_MCx_CTL(KVM_MAX_MCE_BANKS) - 1:
> -   return set_msr_mce(vcpu, msr, data);
> +   return set_msr_mce(vcpu, msr_info);
>
>  case MSR_K7_PERFCTR0 ... MSR_K7_PERFCTR3:
>  case MSR_P6_PERFCTR0 ... MSR_P6_PERFCTR1:
> --
> 2.7.4
>
>

[PATCH v6 00/10] rockchip: kevin: Enable edp display

[Jeffy Chen]

Make edp display works on chromebook kevin(at least for boot animation).

Also solve some issues i meet during the bringup.

Changes in v6:
Don't change order of rockchip_drm_psr_register().

Changes in v5:
Call the destroy hook in the error handling path like in unbind().
Call the destroy hook in the error handling path like in unbind().
Update cleanup order in unbind().
Add disable to unbind(), and inline clk_prepare_enable() with bind().

Jeffy Chen (10):
  arm64: dts: rockchip: Enable edp disaplay on kevin
  drm/rockchip: analogix_dp: Remove unnecessary init code
  drm/bridge: analogix: Do not use device's drvdata
  drm/bridge: analogix_dp: Fix connector and encoder cleanup
  drm/rockchip: analogix_dp: Add a sanity check for
rockchip_drm_psr_register()
  drm/rockchip: dw-mipi-dsi: Fix error handling path
  drm/rockchip: inno_hdmi: Fix error handling path
  drm/bridge/synopsys: dw-hdmi: Add missing bridge detach
  drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata
  drm/rockchip: dw_hdmi: Fix error handling path

 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  | 29 +++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   | 16 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 52 +---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  | 53 ++--
 drivers/gpu/drm/exynos/exynos_dp.c | 29 ---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  | 22 +++--
 drivers/gpu/drm/meson/meson_dw_hdmi.c  | 20 +++--
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 +++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 95 +++---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +++--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 39 +
 drivers/gpu/drm/rockchip/inno_hdmi.c   | 22 +++--
 include/drm/bridge/analogix_dp.h   | 19 +++--
 include/drm/bridge/dw_hdmi.h   | 17 ++--
 14 files changed, 265 insertions(+), 183 deletions(-)

-- 
2.11.0

[PATCH v6 01/10] arm64: dts: rockchip: Enable edp disaplay on kevin

[Jeffy Chen]

Add edp panel and enable related nodes on kevin.

Signed-off-by: Jeffy Chen 
Reviewed-by: Mark Yao 

---

Changes in v6: None
Changes in v5: None

 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 +++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi  | 16 +
 2 files changed, 45 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index a3d3cea7dc4f..bc67b19f0af5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -93,6 +93,18 @@
pwm-delay-us = <1>;
};
 
+   edp_panel: edp-panel {
+   compatible = "sharp,lq123p1jx31", "simple-panel";
+   backlight = <&backlight>;
+   power-supply = <&pp3300_disp>;
+
+   ports {
+   panel_in_edp: endpoint {
+   remote-endpoint = <&edp_out_panel>;
+   };
+   };
+   };
+
thermistor_ppvar_bigcpu: thermistor-ppvar-bigcpu {
compatible = "murata,ncp15wb473";
pullup-uv = <180>;
@@ -264,6 +276,23 @@ ap_i2c_dig: &i2c2 {
};
 };
 
+&edp {
+   status = "okay";
+
+   ports {
+   edp_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   edp_out_panel: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&panel_in_edp>;
+   };
+   };
+   };
+};
+
 &ppvar_bigcpu_pwm {
regulator-min-microvolt = <798674>;
regulator-max-microvolt = <1302172>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 5772c52fbfd3..470105d651c2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -927,6 +927,22 @@ ap_i2c_audio: &i2c8 {
dr_mode = "host";
 };
 
+&vopb {
+   status = "okay";
+};
+
+&vopb_mmu {
+   status = "okay";
+};
+
+&vopl {
+   status = "okay";
+};
+
+&vopl_mmu {
+   status = "okay";
+};
+
 #include 
 #include 
 
-- 
2.11.0

[PATCH v6 04/10] drm/bridge: analogix_dp: Fix connector and encoder cleanup

[Jeffy Chen]

Since we are initing connector in the core driver and encoder in the
plat driver, let's clean them up in the right places.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
---

Changes in v6:
Don't change order of rockchip_drm_psr_register().

Changes in v5: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  2 --
 drivers/gpu/drm/exynos/exynos_dp.c |  7 +--
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 +---
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 74d274b6d31d..3f910ab36ff6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1409,7 +1409,6 @@ analogix_dp_bind(struct device *dev, struct drm_device 
*drm_dev,
ret = analogix_dp_create_bridge(drm_dev, dp);
if (ret) {
DRM_ERROR("failed to create bridge (%d)\n", ret);
-   drm_encoder_cleanup(dp->encoder);
goto err_disable_pm_runtime;
}
 
@@ -1432,7 +1431,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
 {
analogix_dp_bridge_disable(dp->bridge);
dp->connector.funcs->destroy(&dp->connector);
-   dp->encoder->funcs->destroy(dp->encoder);
 
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index f7e5b2c405ed..33319a858f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -185,8 +185,10 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
dp->plat_data.encoder = encoder;
 
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
-   if (IS_ERR(dp->adp))
+   if (IS_ERR(dp->adp)) {
+   dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+   }
 
return 0;
 }
@@ -196,7 +198,8 @@ static void exynos_dp_unbind(struct device *dev, struct 
device *master,
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
-   return analogix_dp_unbind(dp->adp);
+   analogix_dp_unbind(dp->adp);
+   dp->encoder.funcs->destroy(&dp->encoder);
 }
 
 static const struct component_ops exynos_dp_ops = {
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index fa0365de31d2..117585df73e1 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -261,13 +261,8 @@ static struct drm_encoder_helper_funcs 
rockchip_dp_encoder_helper_funcs = {
.atomic_check = rockchip_dp_drm_encoder_atomic_check,
 };
 
-static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
 static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
-   .destroy = rockchip_dp_drm_encoder_destroy,
+   .destroy = drm_encoder_cleanup,
 };
 
 static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
@@ -364,8 +359,10 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
 
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
-   if (IS_ERR(dp->adp))
+   if (IS_ERR(dp->adp)) {
+   dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+   }
 
return 0;
 }
@@ -377,6 +374,7 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
 
rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dp->adp);
+   dp->encoder.funcs->destroy(&dp->encoder);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
-- 
2.11.0

Re: [PATCH] KVM: PPC: Book3S HV: Delete an error message for a failed memory allocation in kvmppc_allocate_hpt()

[Paul Mackerras]

On Thu, Oct 05, 2017 at 01:23:30PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 5 Oct 2017 13:16:51 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Thanks, applied to my kvm-ppc-next branch.

Paul.

[PATCH v6 06/10] drm/rockchip: dw-mipi-dsi: Fix error handling path

[Jeffy Chen]

Add missing pm_runtime_disable() in bind()'s error handling path.

Also cleanup encoder & connector in unbind().

Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5:
Call the destroy hook in the error handling path like in unbind().

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index b15755b6129c..e72d4e2b61aa 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
ret = dw_mipi_dsi_register(drm, dsi);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
-   goto err_pllref;
+   goto err_disable_pllref;
}
 
pm_runtime_enable(dev);
@@ -1292,23 +1292,24 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
ret = mipi_dsi_host_register(&dsi->dsi_host);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
-   goto err_cleanup;
+   goto err_disable_pm_runtime;
}
 
if (!dsi->panel) {
ret = -EPROBE_DEFER;
-   goto err_mipi_dsi_host;
+   goto err_unreg_mipi_dsi_host;
}
 
dev_set_drvdata(dev, dsi);
return 0;
 
-err_mipi_dsi_host:
+err_unreg_mipi_dsi_host:
mipi_dsi_host_unregister(&dsi->dsi_host);
-err_cleanup:
-   drm_encoder_cleanup(&dsi->encoder);
-   drm_connector_cleanup(&dsi->connector);
-err_pllref:
+err_disable_pm_runtime:
+   pm_runtime_disable(dev);
+   dsi->connector.funcs->destroy(&dsi->connector);
+   dsi->encoder.funcs->destroy(&dsi->encoder);
+err_disable_pllref:
clk_disable_unprepare(dsi->pllref_clk);
return ret;
 }
@@ -1320,6 +1321,10 @@ static void dw_mipi_dsi_unbind(struct device *dev, 
struct device *master,
 
mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
+
+   dsi->connector.funcs->destroy(&dsi->connector);
+   dsi->encoder.funcs->destroy(&dsi->encoder);
+
clk_disable_unprepare(dsi->pllref_clk);
 }
 
-- 
2.11.0

Re: [PATCH 1/10] KVM: PPC: Book3S HV: Use ARRAY_SIZE macro

[Paul Mackerras]

On Sun, Sep 03, 2017 at 02:19:31PM +0200, Thomas Meyer wrote:
> Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
> yourself.
> Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
> 's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
> /ARRAY_SIZE(\1)/g' and manual check/verification.
> 
> Signed-off-by: Thomas Meyer 

Thanks, applied to my kvm-ppc-next branch.

Paul.

[PATCH v6 10/10] drm/rockchip: dw_hdmi: Fix error handling path

[Jeffy Chen]

Add missing clk_disable_unprepare() in bind()'s error handling path and
unbind().

Also inline clk_prepare_enable() with bind().

Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5:
Add disable to unbind(), and inline clk_prepare_enable() with bind().

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 791ab938f998..e936dfe6c03d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -193,13 +193,6 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
-   ret = clk_prepare_enable(hdmi->vpll_clk);
-   if (ret) {
-   DRM_DEV_ERROR(hdmi->dev,
- "Failed to enable HDMI vpll: %d\n", ret);
-   return ret;
-   }
-
return 0;
 }
 
@@ -374,6 +367,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   ret = clk_prepare_enable(hdmi->vpll_clk);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev,
+ "Failed to enable HDMI vpll: %d\n", ret);
+   return ret;
+   }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
@@ -381,6 +381,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
if (IS_ERR(hdmi->hdmi)) {
encoder->funcs->destroy(encoder);
+   clk_disable_unprepare(hdmi->vpll_clk);
return PTR_ERR(hdmi->hdmi);
}
 
@@ -396,6 +397,7 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, 
struct device *master,
 
dw_hdmi_unbind(hdmi->hdmi);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
+   clk_disable_unprepare(hdmi->vpll_clk);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {
-- 
2.11.0

[PATCH v6 09/10] drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata

[Jeffy Chen]

Let plat drivers own the drvdata, so that they could cleanup resources
in their unbind().

Signed-off-by: Jeffy Chen 
Reviewed-by: Neil Armstrong 
---

Changes in v6: None
Changes in v5: None

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 43 ++---
 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 22 +--
 drivers/gpu/drm/meson/meson_dw_hdmi.c   | 20 ++
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 14 --
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 23 ---
 include/drm/bridge/dw_hdmi.h| 17 ++--
 6 files changed, 77 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ff1b3d2b5d06..6fbfafc5832b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2072,7 +2072,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
 }
 
-void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
 {
mutex_lock(&hdmi->mutex);
 
@@ -2098,13 +2098,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool 
hpd, bool rx_sense)
}
mutex_unlock(&hdmi->mutex);
 }
-
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
-{
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
-   __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
-}
 EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
 
 static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
@@ -2140,9 +2133,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
 */
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
-   __dw_hdmi_setup_rx_sense(hdmi,
-phy_stat & HDMI_PHY_HPD,
-phy_stat & HDMI_PHY_RX_SENSE);
+   dw_hdmi_setup_rx_sense(hdmi, phy_stat & HDMI_PHY_HPD,
+  phy_stat & HDMI_PHY_RX_SENSE);
 
if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
cec_notifier_set_phys_addr(hdmi->cec_notifier,
@@ -2512,8 +2504,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
 
-   platform_set_drvdata(pdev, hdmi);
-
return hdmi;
 
 err_iahb:
@@ -2559,25 +2549,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
 /* 
-
  * Probe/remove API, used from platforms based on the DRM bridge API.
  */
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
 {
struct dw_hdmi *hdmi;
 
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
 
drm_bridge_add(&hdmi->bridge);
 
-   return 0;
+   return hdmi;
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_probe);
 
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
 {
-   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(&hdmi->bridge);
 
__dw_hdmi_remove(hdmi);
@@ -2587,31 +2575,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
 /* 
-
  * Bind/unbind API, used from platforms based on the component framework.
  */
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+   struct drm_encoder *encoder,
+   const struct dw_hdmi_plat_data *plat_data)
 {
struct dw_hdmi *hdmi;
int ret;
 
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
 
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
__dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
 
-   return 0;
+   return hdmi;
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_bind);
 
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
 {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..b01d03e02ce0 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-i

[PATCH v6 08/10] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach

[Jeffy Chen]

We inited connector in attach(), so need a detach() to cleanup.

Also fix wrong use of dw_hdmi_remove() in bind().

Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5: None

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..ff1b3d2b5d06 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1966,6 +1966,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }
 
+static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   drm_connector_cleanup(&hdmi->connector);
+}
+
 static enum drm_mode_status
 dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
  const struct drm_display_mode *mode)
@@ -2022,6 +2029,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge 
*bridge)
 
 static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.attach = dw_hdmi_bridge_attach,
+   .detach = dw_hdmi_bridge_detach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
@@ -2591,7 +2599,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
 
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
-   dw_hdmi_remove(pdev);
+   __dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
return ret;
}
-- 
2.11.0

[PATCH v6 07/10] drm/rockchip: inno_hdmi: Fix error handling path

[Jeffy Chen]

Add missing error handling in bind().

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5:
Call the destroy hook in the error handling path like in unbind().
Update cleanup order in unbind().

 drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index ee584d87111f..9a96ff6b022b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -851,8 +851,10 @@ static int inno_hdmi_bind(struct device *dev, struct 
device *master,
}
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return irq;
+   if (irq < 0) {
+   ret = irq;
+   goto err_disable_clk;
+   }
 
inno_hdmi_reset(hdmi);
 
@@ -860,7 +862,7 @@ static int inno_hdmi_bind(struct device *dev, struct device 
*master,
if (IS_ERR(hdmi->ddc)) {
ret = PTR_ERR(hdmi->ddc);
hdmi->ddc = NULL;
-   return ret;
+   goto err_disable_clk;
}
 
/*
@@ -874,7 +876,7 @@ static int inno_hdmi_bind(struct device *dev, struct device 
*master,
 
ret = inno_hdmi_register(drm, hdmi);
if (ret)
-   return ret;
+   goto err_put_adapter;
 
dev_set_drvdata(dev, hdmi);
 
@@ -884,7 +886,17 @@ static int inno_hdmi_bind(struct device *dev, struct 
device *master,
ret = devm_request_threaded_irq(dev, irq, inno_hdmi_hardirq,
inno_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
+   if (ret < 0)
+   goto err_cleanup_hdmi;
 
+   return 0;
+err_cleanup_hdmi:
+   hdmi->connector.funcs->destroy(&hdmi->connector);
+   hdmi->encoder.funcs->destroy(&hdmi->encoder);
+err_put_adapter:
+   i2c_put_adapter(hdmi->ddc);
+err_disable_clk:
+   clk_disable_unprepare(hdmi->pclk);
return ret;
 }
 
@@ -896,8 +908,8 @@ static void inno_hdmi_unbind(struct device *dev, struct 
device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
 
-   clk_disable_unprepare(hdmi->pclk);
i2c_put_adapter(hdmi->ddc);
+   clk_disable_unprepare(hdmi->pclk);
 }
 
 static const struct component_ops inno_hdmi_ops = {
-- 
2.11.0

[PATCH v6 05/10] drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register()

[Jeffy Chen]

The rockchip_drm_psr_register() can fail, so add a sanity check for that.

Also reorder the calls in unbind() to match bind().

Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 117585df73e1..bd3567ad8b53 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -356,15 +356,22 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
 
-   rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
+   ret = rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
+   if (ret < 0)
+   goto err_cleanup_encoder;
 
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
if (IS_ERR(dp->adp)) {
-   dp->encoder.funcs->destroy(&dp->encoder);
-   return PTR_ERR(dp->adp);
+   ret = PTR_ERR(dp->adp);
+   goto err_unreg_psr;
}
 
return 0;
+err_unreg_psr:
+   rockchip_drm_psr_unregister(&dp->encoder);
+err_cleanup_encoder:
+   dp->encoder.funcs->destroy(&dp->encoder);
+   return ret;
 }
 
 static void rockchip_dp_unbind(struct device *dev, struct device *master,
@@ -372,8 +379,8 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
 
-   rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dp->adp);
+   rockchip_drm_psr_unregister(&dp->encoder);
dp->encoder.funcs->destroy(&dp->encoder);
 }
 
-- 
2.11.0

Re: [PATCH 6/7] KVM: PPC: Cocci spatch "vma_pages"

[Paul Mackerras]

On Thu, Sep 21, 2017 at 12:29:36AM +0200, Thomas Meyer wrote:
> Use vma_pages function on vma object instead of explicit computation.
> Found by coccinelle spatch "api/vma_pages.cocci"
> 
> Signed-off-by: Thomas Meyer 

Thanks, applied to my kvm-ppc-next branch, with the headline "KVM:
PPC: BookE: Use vma_pages function".

Paul.

[PATCH v6 02/10] drm/rockchip: analogix_dp: Remove unnecessary init code

[Jeffy Chen]

Remove unnecessary init code, since we would do it in the power_on()
callback.

Also move of parse code to probe().

Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip platform dp driver")
Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 27 ++---
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 4d3f6ad0abdd..8cae5ad926cd 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -269,7 +269,7 @@ static struct drm_encoder_funcs rockchip_dp_encoder_funcs = 
{
.destroy = rockchip_dp_drm_encoder_destroy,
 };
 
-static int rockchip_dp_init(struct rockchip_dp_device *dp)
+static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
 {
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
@@ -303,19 +303,6 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->rst);
}
 
-   ret = clk_prepare_enable(dp->pclk);
-   if (ret < 0) {
-   DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
-   return ret;
-   }
-
-   ret = rockchip_dp_pre_init(dp);
-   if (ret < 0) {
-   DRM_DEV_ERROR(dp->dev, "failed to pre init %d\n", ret);
-   clk_disable_unprepare(dp->pclk);
-   return ret;
-   }
-
return 0;
 }
 
@@ -361,10 +348,6 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
if (!dp_data)
return -ENODEV;
 
-   ret = rockchip_dp_init(dp);
-   if (ret < 0)
-   return ret;
-
dp->data = dp_data;
dp->drm_dev = drm_dev;
 
@@ -398,7 +381,6 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
rockchip_drm_psr_unregister(&dp->encoder);
 
analogix_dp_unbind(dev, master, data);
-   clk_disable_unprepare(dp->pclk);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
@@ -414,7 +396,7 @@ static int rockchip_dp_probe(struct platform_device *pdev)
int ret;
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, &panel, NULL);
-   if (ret)
+   if (ret < 0)
return ret;
 
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
@@ -422,9 +404,12 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return -ENOMEM;
 
dp->dev = dev;
-
dp->plat_data.panel = panel;
 
+   ret = rockchip_dp_of_probe(dp);
+   if (ret < 0)
+   return ret;
+
/*
 * We just use the drvdata until driver run into component
 * add function, and then we would set drvdata to null, so
-- 
2.11.0

[PATCH v6 03/10] drm/bridge: analogix: Do not use device's drvdata

[Jeffy Chen]

The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is barely
a good practice and in fact has led to many bugs in this driver.

Let's clean up this mess and change Analogix entry points to simply
accept some opaque struct pointer, adjusting their users at the same
time to avoid breaking the compilation.

Signed-off-by: Tomasz Figa 
Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Sean Paul 
Acked-by: Jingoo Han 
Acked-by: Archit Taneja 
---

Changes in v6: None
Changes in v5: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +-
 drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 49 -
 include/drm/bridge/analogix_dp.h   | 19 
 4 files changed, 74 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5dd3f1cd074a..74d274b6d31d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,17 +98,15 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 }
 
-int analogix_dp_psr_supported(struct device *dev)
+int analogix_dp_psr_supported(struct analogix_dp_device *dp)
 {
-   struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
return dp->psr_support;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
 
-int analogix_dp_enable_psr(struct device *dev)
+int analogix_dp_enable_psr(struct analogix_dp_device *dp)
 {
-   struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
 
if (!dp->psr_support)
@@ -129,9 +127,8 @@ int analogix_dp_enable_psr(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
 
-int analogix_dp_disable_psr(struct device *dev)
+int analogix_dp_disable_psr(struct analogix_dp_device *dp)
 {
-   struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
int ret;
 
@@ -1281,8 +1278,9 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux 
*aux,
return analogix_dp_transfer(dp, msg);
 }
 
-int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
-struct analogix_dp_plat_data *plat_data)
+struct analogix_dp_device *
+analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
+struct analogix_dp_plat_data *plat_data)
 {
struct platform_device *pdev = to_platform_device(dev);
struct analogix_dp_device *dp;
@@ -1292,14 +1290,12 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
 
if (!plat_data) {
dev_err(dev, "Invalided input plat_data\n");
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
dp = devm_kzalloc(dev, sizeof(struct analogix_dp_device), GFP_KERNEL);
if (!dp)
-   return -ENOMEM;
-
-   dev_set_drvdata(dev, dp);
+   return ERR_PTR(-ENOMEM);
 
dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1316,7 +1312,7 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
 
ret = analogix_dp_dt_parse_pdata(dp);
if (ret)
-   return ret;
+   return ERR_PTR(ret);
 
dp->phy = devm_phy_get(dp->dev, "dp");
if (IS_ERR(dp->phy)) {
@@ -1330,14 +1326,14 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
if (ret == -ENOSYS || ret == -ENODEV)
dp->phy = NULL;
else
-   return ret;
+   return ERR_PTR(ret);
}
}
 
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
-   return PTR_ERR(dp->clock);
+   return ERR_CAST(dp->clock);
}
 
clk_prepare_enable(dp->clock);
@@ -1346,7 +1342,7 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
 
dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dp->reg_base))
-   return PTR_ERR(dp->reg_base);
+   return ERR_CAST(dp->reg_base);
 
dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
 
@@ -1367,7 +1363,7 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
"hpd_gpio");
if (ret) {
dev_err(&pdev->dev, "failed to get hpd gpio\n");
-   return ret;
+   

RE: [PATCH v1] mm/mempolicy.c: Fix get_nodes() off-by-one error.

[Sandoval Castro, Luis Felipe]

On Tue 18-10-17 10:42:34, Luis Felipe Sandoval Castro wrote:

Sorry for the delayed replay, from your feedback I don't think my
patch has any chances of being merged... I'm wondering though,
if a note in the man pages "range non inclusive" or something
like that would help to avoid confusions? Thanks

> On Thu 12-10-17 08:28:25, Andi Kleen wrote:
> > On Thu, Oct 12, 2017 at 10:46:33AM +0200, Michal Hocko wrote:
> > > [CC Christoph who seems to be the author of the code]
> >
> > Actually you can blame me. I did the mistake originally.
> > It was found many years ago, but then it was already too late
> > to change.
> >
> > > Andi has voiced a concern about backward compatibility but I am not
> sure
> > > the risk is very high. The current behavior is simply broken unless you
> > > use a large maxnode anyway. What kind of breakage would you envision
> > > Andi?
> >
> > libnuma uses the available number of nodes as max.
> >
> > So it would always lose the last one with your chance.
> 
> I must be missing something because libnuma does
> if (set_mempolicy(policy, bmp->maskp, bmp->size + 1) < 0)
> 
> so it sets max as size + 1 which is exactly what the man page describes.
> 
> > Your change would be catastrophic.
> 
> I am not sure which change do you mean here. I wasn't proposing any
> patch (yet). All I was saying is that the docuementation diagrees with
> the in kernel implementation. The only applications that would break
> would be those which do not comply to the documentation AFAICS, no?
> --
> Michal Hocko
> SUSE Labs

Best Regards,
Luis

Re: [PATCH 01/14] Documentation: Add SoundWire summary

[Randy Dunlap]

On 10/18/17 20:03, Vinod Koul wrote:
> From: Sanyog Kale 
> 
> SoundWire is a new Linux bus which implements a new MIPI bus protocol
> 'SoundWire'. The summary of SoundWire bus and registration APIs is
> documented in the 'summary' file.
> 
> Signed-off-by: Sanyog Kale 
> Signed-off-by: Hardik T Shah 
> Signed-off-by: Pierre-Louis Bossart 
> Signed-off-by: Vinod Koul 
> ---
>  Documentation/soundwire/summary.txt | 192 
> 
>  1 file changed, 192 insertions(+)
>  create mode 100644 Documentation/soundwire/summary.txt
> 
> diff --git a/Documentation/soundwire/summary.txt 
> b/Documentation/soundwire/summary.txt
> new file mode 100644
> index ..15b78e6e3347
> --- /dev/null
> +++ b/Documentation/soundwire/summary.txt
> @@ -0,0 +1,192 @@
> +SoundWire
> +===
> +
> +SoundWire is a new interface ratified in 2015 by the MIPI Alliance.
> +SoundWire is used for transporting data typically related to audio
> +functions. SoundWire interface is optimized to integrate audio devices in
> +mobile or mobile inspired systems.
> +
> +SoundWire is a 2-Pin multi-drop interface with data and clock line. It

  2-pin

> +facilitates development of low cost, efficient, high performance systems.
> +Broad level key features of SoundWire interface include:
> +  1. Transporting all of payload data channels, control information, and 
> setup
> +  commands over a single two-pin interface.
> +  2. Lower clock frequency, and hence lower power consumption, by use of DDR
> +  (Dual Data Rate) data transmission.
> +  3. Clock scaling and optional multiple data lanes to give wide flexibility
> +  in data rate to match system requirements.
> +  4. Device status monitoring, including interrupt-style alerts to the 
> Master.
> +
> +The SoundWire protocol supports up to eleven Slave interfaces. All the
> +interfaces share the common Bus containing data and clock line. Each of the
> +Slaves can support up to 14 Data Ports. 13 Data Ports are dedicated to audio
> +transport. Data Port0 is dedicated to transport of Bulk control information,
> +each of the audio Data Ports (1..14) can support up to 8 Channels in

(1..13) ??

> +transmit or receiving mode (typically fixed direction but configurable
> +direction is enabled by the specification).  Bandwidth restrictions to
> +~19.2..24.576Mbits/s don't however allow for 11*13*8 channels to be
> +transmitted simultaneously.
> +
> +Below figure shows an example of connectivity between a SoundWire Master and
> +two Slave devices.
> +
> ++---+   +---+
> +|   |   Clock Signal|   |
> +|Master |---+---|Slave  |
> +|   Interface   |   |   Data Signal |  Interface 1  |
> +|   |---|---+---|   |
> ++---+   |   |   +---+
> +|   |
> +|   |
> +|   |
> + +--+---+--+
> + | |
> + |   Slave |
> + | Interface 2 |
> + | |
> + +-+
> +
> +Terminology
> +=
> +
> +The MIPI SoundWire specification uses the term 'device' to refer to a Master
> +or Slave interface, which of course can be confusing. In this summary and
> +code we use the term interface only to refer to the hardware. We follow the
> +Linux device model by mapping each Slave interface connected on the bus as a
> +device managed by a specific driver. The Linux SoundWire subsystem provides
> +a framework to implement a SoundWire Slave driver with an API allowing
> +3rd-party vendors to enable implementation-defined functionality while
> +common setup/configuration tasks are handled by the bus.
> +
> +Bus:
> +Implements SoundWire Linux Bus which handles the SoundWire protocol.
> +It programs all the MIPI defined Slave registers. It represents a SoundWire

   MIPI-defined

> +Master. There can be multiple instances of Bus maybe present in a system.

eh?
   Multiple instances of Bus may be present in a system.

> +
> +Slave:
> +Registers as SoundWire Slave device (Linux Device). Multiple Slave devices
> +can register to a Bus instance.
> +
> +Slave driver:
> +Driver controlling the Slave device. MIPI-specified registers are controlled
> +directly by the Bus (and transmitted through the Master driver/interface).
> +Any implementation-defined Slave register is controlled by Slave driver. In
> +practice, it is expected that the Slave driver relies on regmap and does not
> +request direct register access.
> +
> +Programming interfaces (SoundWire Master interface Driver)
> +==

[PATCH net] hv_sock: add locking in the open/close/release code paths

[Dexuan Cui]

Without the patch, when hvs_open_connection() hasn't completely established
a connection (e.g. it has changed sk->sk_state to SS_CONNECTED, but hasn't
inserted the sock into the connected queue), vsock_stream_connect() may see
the sk_state change and return the connection to the userspace, and next
when the userspace closes the connection quickly, hvs_release() may not see
the connection in the connected queue; finally hvs_open_connection()
inserts the connection into the queue, but we won't be able to purge the
connection for ever.

Signed-off-by: Dexuan Cui 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Vitaly Kuznetsov 
Cc: Cathy Avery 
Cc: Rolf Neugebauer 
Cc: Marcelo Cerri 
---

Please consider this for v4.14.

 net/vmw_vsock/hyperv_transport.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 14ed5a3..e21991f 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -310,11 +310,15 @@ static void hvs_close_connection(struct vmbus_channel 
*chan)
struct sock *sk = get_per_channel_state(chan);
struct vsock_sock *vsk = vsock_sk(sk);
 
+   lock_sock(sk);
+
sk->sk_state = SS_UNCONNECTED;
sock_set_flag(sk, SOCK_DONE);
vsk->peer_shutdown |= SEND_SHUTDOWN | RCV_SHUTDOWN;
 
sk->sk_state_change(sk);
+
+   release_sock(sk);
 }
 
 static void hvs_open_connection(struct vmbus_channel *chan)
@@ -344,6 +348,8 @@ static void hvs_open_connection(struct vmbus_channel *chan)
if (!sk)
return;
 
+   lock_sock(sk);
+
if ((conn_from_host && sk->sk_state != VSOCK_SS_LISTEN) ||
(!conn_from_host && sk->sk_state != SS_CONNECTING))
goto out;
@@ -395,9 +401,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
 
vsock_insert_connected(vnew);
 
-   lock_sock(sk);
vsock_enqueue_accept(sk, new);
-   release_sock(sk);
} else {
sk->sk_state = SS_CONNECTED;
sk->sk_socket->state = SS_CONNECTED;
@@ -410,6 +414,8 @@ static void hvs_open_connection(struct vmbus_channel *chan)
 out:
/* Release refcnt obtained when we called vsock_find_bound_socket() */
sock_put(sk);
+
+   release_sock(sk);
 }
 
 static u32 hvs_get_local_cid(void)
@@ -476,13 +482,21 @@ static int hvs_shutdown(struct vsock_sock *vsk, int mode)
 
 static void hvs_release(struct vsock_sock *vsk)
 {
+   struct sock *sk = sk_vsock(vsk);
struct hvsock *hvs = vsk->trans;
-   struct vmbus_channel *chan = hvs->chan;
+   struct vmbus_channel *chan;
 
+   lock_sock(sk);
+
+   sk->sk_state = SS_DISCONNECTING;
+   vsock_remove_sock(vsk);
+
+   release_sock(sk);
+
+   chan = hvs->chan;
if (chan)
hvs_shutdown(vsk, RCV_SHUTDOWN | SEND_SHUTDOWN);
 
-   vsock_remove_sock(vsk);
 }
 
 static void hvs_destruct(struct vsock_sock *vsk)
-- 
2.7.4

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

[Jerome Glisse]

On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote:
> On Mon, 16 Oct 2017 23:10:02 -0400
> jgli...@redhat.com wrote:
> 
> > From: Jérôme Glisse 
> > 
> > +   /*
> > +* No need to call mmu_notifier_invalidate_range() as we are
> > +* downgrading page table protection not changing it to point
> > +* to a new page.
> > +*
> > +* See Documentation/vm/mmu_notifier.txt
> > +*/
> > if (pmdp) {
> >  #ifdef CONFIG_FS_DAX_PMD
> > pmd_t pmd;
> > @@ -628,7 +635,6 @@ static void dax_mapping_entry_mkclean(struct 
> > address_space *mapping,
> > pmd = pmd_wrprotect(pmd);
> > pmd = pmd_mkclean(pmd);
> > set_pmd_at(vma->vm_mm, address, pmdp, pmd);
> > -   mmu_notifier_invalidate_range(vma->vm_mm, start, end);
> 
> Could the secondary TLB still see the mapping as dirty and propagate the 
> dirty bit back?

I am assuming hardware does sane thing of setting the dirty bit only
when walking the CPU page table when device does a write fault ie
once the device get a write TLB entry the dirty is set by the IOMMU
when walking the page table before returning the lookup result to the
device and that it won't be set again latter (ie propagated back
latter).

I should probably have spell that out and maybe some of the ATS/PASID
implementer did not do that.

> 
> >  unlock_pmd:
> > spin_unlock(ptl);
> >  #endif
> > @@ -643,7 +649,6 @@ static void dax_mapping_entry_mkclean(struct 
> > address_space *mapping,
> > pte = pte_wrprotect(pte);
> > pte = pte_mkclean(pte);
> > set_pte_at(vma->vm_mm, address, ptep, pte);
> > -   mmu_notifier_invalidate_range(vma->vm_mm, start, end);
> 
> Ditto
> 
> >  unlock_pte:
> > pte_unmap_unlock(ptep, ptl);
> > }
> > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> > index 6866e8126982..49c925c96b8a 100644
> > --- a/include/linux/mmu_notifier.h
> > +++ b/include/linux/mmu_notifier.h
> > @@ -155,7 +155,8 @@ struct mmu_notifier_ops {
> >  * shared page-tables, it not necessary to implement the
> >  * invalidate_range_start()/end() notifiers, as
> >  * invalidate_range() alread catches the points in time when an
> > -* external TLB range needs to be flushed.
> > +* external TLB range needs to be flushed. For more in depth
> > +* discussion on this see Documentation/vm/mmu_notifier.txt
> >  *
> >  * The invalidate_range() function is called under the ptl
> >  * spin-lock and not allowed to sleep.
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index c037d3d34950..ff5bc647b51d 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1186,8 +1186,15 @@ static int do_huge_pmd_wp_page_fallback(struct 
> > vm_fault *vmf, pmd_t orig_pmd,
> > goto out_free_pages;
> > VM_BUG_ON_PAGE(!PageHead(page), page);
> >  
> > +   /*
> > +* Leave pmd empty until pte is filled note we must notify here as
> > +* concurrent CPU thread might write to new page before the call to
> > +* mmu_notifier_invalidate_range_end() happens which can lead to a
> > +* device seeing memory write in different order than CPU.
> > +*
> > +* See Documentation/vm/mmu_notifier.txt
> > +*/
> > pmdp_huge_clear_flush_notify(vma, haddr, vmf->pmd);
> > -   /* leave pmd empty until pte is filled */
> >  
> > pgtable = pgtable_trans_huge_withdraw(vma->vm_mm, vmf->pmd);
> > pmd_populate(vma->vm_mm, &_pmd, pgtable);
> > @@ -2026,8 +2033,15 @@ static void __split_huge_zero_page_pmd(struct 
> > vm_area_struct *vma,
> > pmd_t _pmd;
> > int i;
> >  
> > -   /* leave pmd empty until pte is filled */
> > -   pmdp_huge_clear_flush_notify(vma, haddr, pmd);
> > +   /*
> > +* Leave pmd empty until pte is filled note that it is fine to delay
> > +* notification until mmu_notifier_invalidate_range_end() as we are
> > +* replacing a zero pmd write protected page with a zero pte write
> > +* protected page.
> > +*
> > +* See Documentation/vm/mmu_notifier.txt
> > +*/
> > +   pmdp_huge_clear_flush(vma, haddr, pmd);
> 
> Shouldn't the secondary TLB know if the page size changed?

It should not matter, we are talking virtual to physical on behalf
of a device against a process address space. So the hardware should
not care about the page size.

Moreover if any of the new 512 (assuming 2MB huge and 4K pages) zero
4K pages is replace by something new then a device TLB shootdown will
happen before the new page is set.

Only issue i can think of is if the IOMMU TLB (if there is one) or
the device TLB (you do expect that there is one) does not invalidate
TLB entry if the TLB shootdown is smaller than the TLB entry. That
would be idiotic but yes i know hardware bug.


> 
> >  
> > pgtable = pg

[PATCH] iommu/amd: Fix alloc_irq_index() increment

[Alex Williamson]

On an is_allocated() interrupt index, we ALIGN() the current index and
then increment it via the for loop, guaranteeing that it is no longer
aligned for alignments >1.  We instead need to align the next index,
to guarantee forward progress, moving the increment-only to the case
where the index was found to be unallocated.

Fixes: 37946d95fc1a ('iommu/amd: Add align parameter to alloc_irq_index()')
Signed-off-by: Alex Williamson 
---
 drivers/iommu/amd_iommu.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 9dc7facfd2e5..3c1a29104f0e 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3682,13 +3682,12 @@ static int alloc_irq_index(u16 devid, int count, bool 
align)
 
/* Scan table for free entries */
for (index = ALIGN(table->min_index, alignment), c = 0;
-index < MAX_IRQS_PER_TABLE;
-index++) {
+index < MAX_IRQS_PER_TABLE;) {
if (!iommu->irte_ops->is_allocated(table, index)) {
c += 1;
} else {
c = 0;
-   index = ALIGN(index, alignment);
+   index = ALIGN(index + 1, alignment);
continue;
}
 
@@ -3699,6 +3698,8 @@ static int alloc_irq_index(u16 devid, int count, bool 
align)
index -= count - 1;
goto out;
}
+
+   index++;
}
 
index = -ENOSPC;

[PATCH v2 2/2] extcon: add optional debounce-timeout-ms attribute

[Raveendra Padasalagi]

Add changes to capture optional dt attribute "debounce-timeout-ms"
provided in extcon node and used the same value if provided otherwise
default value of 20ms is used for id and vbus gpios debounce time.

Signed-off-by: Raveendra Padasalagi 
Reviewed-by: Ray Jui 
Reviewed-by: Srinath Mannam 
---

Changes in v2:
 Rename gpio_debounce_timeout_ms to debounce_usecs

 drivers/extcon/extcon-usb-gpio.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index 9c925b0..76ef1da 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -41,6 +41,7 @@ struct usb_extcon_info {
 
unsigned long debounce_jiffies;
struct delayed_work wq_detcable;
+   unsigned int debounce_usecs;
 };
 
 static const unsigned int usb_extcon_cable[] = {
@@ -133,6 +134,11 @@ static int usb_extcon_probe(struct platform_device *pdev)
if (IS_ERR(info->vbus_gpiod))
return PTR_ERR(info->vbus_gpiod);
 
+   ret = of_property_read_u32(np, "input-debounce",
+&info->debounce_usecs);
+   if (ret)
+   info->debounce_usecs = USB_GPIO_DEBOUNCE_MS;
+
info->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
if (IS_ERR(info->edev)) {
dev_err(dev, "failed to allocate extcon device\n");
@@ -147,13 +153,13 @@ static int usb_extcon_probe(struct platform_device *pdev)
 
if (info->id_gpiod)
ret = gpiod_set_debounce(info->id_gpiod,
-USB_GPIO_DEBOUNCE_MS * 1000);
+info->debounce_usecs * 1000);
if (!ret && info->vbus_gpiod)
ret = gpiod_set_debounce(info->vbus_gpiod,
-USB_GPIO_DEBOUNCE_MS * 1000);
+info->debounce_usecs * 1000);
 
if (ret < 0)
-   info->debounce_jiffies = msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
+   info->debounce_jiffies = msecs_to_jiffies(info->debounce_usecs);
 
INIT_DELAYED_WORK(&info->wq_detcable, usb_extcon_detect_cable);
 
-- 
1.9.1

[PATCH v2 1/2] Documentation: dt: extcon: add optional debounce-timeout-ms attribute

[Raveendra Padasalagi]

Add documentation on optional dt attribute "debounce-timeout-ms"
in extcon node to capture user specified timeout value for id
and vbus gpio detection.

Signed-off-by: Raveendra Padasalagi 
Reviewed-by: Ray Jui 
Reviewed-by: Srinath Mannam 
---

Changes in v2:
 Rename debounce-timeout-ms to input-debounce

 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
index dfc14f7..d115900 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -10,6 +10,9 @@ Either one of id-gpio or vbus-gpio must be present. Both can 
be present as well.
 - id-gpio: gpio for USB ID pin. See gpio binding.
 - vbus-gpio: gpio for USB VBUS pin.
 
+Optional properties:
+- input-debounce: debounce timeout value for id and vbus gpio in microseconds.
+
 Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
extcon_usb1 {
compatible = "linux,extcon-usb-gpio";
-- 
1.9.1

[PATCH 2/2] misc: rtsx: Add support for RTS5260

[rui_feng]

From: Rui Feng 

Add support for new chip rts5260.
In order to support rts5260, the definitions of
some internal registers and workflow have to be
modified and are different from its predecessors
and OCP function is added for RTS5260. So we need
this patch to ensure RTS5260 can work.

Signed-off-by: Rui Feng 
---
 drivers/misc/realtek/Makefile   |   2 +-
 drivers/misc/realtek/rts5260.c  | 747 
 drivers/misc/realtek/rts5260.h  |  45 +++
 drivers/misc/realtek/rtsx_pcr.c | 123 ++-
 drivers/misc/realtek/rtsx_pcr.h |  10 +
 include/linux/rtsx_pci.h| 236 -
 6 files changed, 1156 insertions(+), 7 deletions(-)
 create mode 100644 drivers/misc/realtek/rts5260.c
 create mode 100644 drivers/misc/realtek/rts5260.h

diff --git a/drivers/misc/realtek/Makefile b/drivers/misc/realtek/Makefile
index 67c5cf3..4ec6c21 100644
--- a/drivers/misc/realtek/Makefile
+++ b/drivers/misc/realtek/Makefile
@@ -1,3 +1,3 @@
-rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o
+rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o rts5227.o rts5249.o 
rts5260.o
 
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
\ No newline at end of file
diff --git a/drivers/misc/realtek/rts5260.c b/drivers/misc/realtek/rts5260.c
new file mode 100644
index 000..899b6be
--- /dev/null
+++ b/drivers/misc/realtek/rts5260.c
@@ -0,0 +1,747 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2016-2017 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Steven FENG 
+ *   Rui FENG 
+ *   Wei WANG 
+ */
+
+#include 
+#include 
+
+#include "rts5260.h"
+#include "rtsx_pcr.h"
+
+static u8 rts5260_get_ic_version(struct rtsx_pcr *pcr)
+{
+   u8 val;
+
+   rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, &val);
+   return val & IC_VERSION_MASK;
+}
+
+static void rts5260_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
+{
+   u8 driving_3v3[6][3] = {
+   {0x94, 0x94, 0x94},
+   {0x11, 0x11, 0x18},
+   {0x55, 0x55, 0x5C},
+   {0x94, 0x94, 0x94},
+   {0x94, 0x94, 0x94},
+   {0xFF, 0xFF, 0xFF},
+   };
+   u8 driving_1v8[6][3] = {
+   {0x9A, 0x89, 0x89},
+   {0xC4, 0xC4, 0xC4},
+   {0x3C, 0x3C, 0x3C},
+   {0x9B, 0x99, 0x99},
+   {0x9A, 0x89, 0x89},
+   {0xFE, 0xFE, 0xFE},
+   };
+   u8 (*driving)[3], drive_sel;
+
+   if (voltage == OUTPUT_3V3) {
+   driving = driving_3v3;
+   drive_sel = pcr->sd30_drive_sel_3v3;
+   } else {
+   driving = driving_1v8;
+   drive_sel = pcr->sd30_drive_sel_1v8;
+   }
+
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_CLK_DRIVE_SEL,
+0xFF, driving[drive_sel][0]);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_CMD_DRIVE_SEL,
+0xFF, driving[drive_sel][1]);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD30_DAT_DRIVE_SEL,
+0xFF, driving[drive_sel][2]);
+}
+
+static void rtsx_base_fetch_vendor_settings(struct rtsx_pcr *pcr)
+{
+   u32 reg;
+
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, ®);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
+
+   if (!rtsx_vendor_setting_valid(reg)) {
+   pcr_dbg(pcr, "skip fetch vendor setting\n");
+   return;
+   }
+
+   pcr->aspm_en = rtsx_reg_to_aspm(reg);
+   pcr->sd30_drive_sel_1v8 = rtsx_reg_to_sd30_drive_sel_1v8(reg);
+   pcr->card_drive_sel &= 0x3F;
+   pcr->card_drive_sel |= rtsx_reg_to_card_drive_sel(reg);
+
+   rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, ®);
+   pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+   pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
+   if (rtsx_reg_check_reverse_socket(reg))
+   pcr->flags |= PCR_REVERSE_SOCKET;
+}
+
+static void rtsx_base_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
+{
+   /* Set relink_time to 0 */
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, MASK_8_BIT_DEF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, MASK_8_BIT_DEF, 0);
+   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3,
+   R

[PATCH 1/2] misc: rtsx: Move Realtek Card Reader Driver to misc

[rui_feng]

From: Rui Feng 

Because Realtek PCIE card reader driver is a pcie driver,
and it bridges mmc subsystem and memstick subsystem, it's
not a mfd driver. Greg and Lee Jones had a discussion about
where to put the driver, the result is that misc is a good
place for it, so I move all files to misc. If I don't move
it to a right place, I can't add any patch for this driver.

Signed-off-by: Rui Feng 
---
 drivers/memstick/host/rtsx_pci_ms.c  |  2 +-
 drivers/mfd/Kconfig  | 11 ---
 drivers/mfd/Makefile |  2 --
 drivers/misc/Kconfig |  1 +
 drivers/misc/Makefile|  1 +
 drivers/misc/realtek/Kconfig | 10 ++
 drivers/misc/realtek/Makefile|  3 +++
 drivers/{mfd => misc/realtek}/rtl8411.c  |  1 -
 drivers/{mfd => misc/realtek}/rts5209.c  |  1 -
 drivers/{mfd => misc/realtek}/rts5227.c  |  1 -
 drivers/{mfd => misc/realtek}/rts5229.c  |  1 -
 drivers/{mfd => misc/realtek}/rts5249.c  |  2 --
 drivers/{mfd => misc/realtek}/rtsx_pcr.c |  1 -
 drivers/{mfd => misc/realtek}/rtsx_pcr.h |  2 +-
 drivers/mmc/host/rtsx_pci_sdmmc.c|  2 +-
 include/linux/{mfd => }/rtsx_common.h|  0
 include/linux/{mfd => }/rtsx_pci.h   |  0
 17 files changed, 18 insertions(+), 23 deletions(-)
 create mode 100644 drivers/misc/realtek/Kconfig
 create mode 100644 drivers/misc/realtek/Makefile
 rename drivers/{mfd => misc/realtek}/rtl8411.c (99%)
 rename drivers/{mfd => misc/realtek}/rts5209.c (99%)
 rename drivers/{mfd => misc/realtek}/rts5227.c (99%)
 rename drivers/{mfd => misc/realtek}/rts5229.c (99%)
 rename drivers/{mfd => misc/realtek}/rts5249.c (99%)
 rename drivers/{mfd => misc/realtek}/rtsx_pcr.c (99%)
 rename drivers/{mfd => misc/realtek}/rtsx_pcr.h (99%)
 rename include/linux/{mfd => }/rtsx_common.h (100%)
 rename include/linux/{mfd => }/rtsx_pci.h (100%)

diff --git a/drivers/memstick/host/rtsx_pci_ms.c 
b/drivers/memstick/host/rtsx_pci_ms.c
index 818fa94..a44b457 100644
--- a/drivers/memstick/host/rtsx_pci_ms.c
+++ b/drivers/memstick/host/rtsx_pci_ms.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 struct realtek_pci_ms {
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fc5e4fe..97c0ee5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -916,17 +916,6 @@ config MFD_RDC321X
  southbridge which provides access to GPIOs and Watchdog using the
  southbridge PCI device configuration space.
 
-config MFD_RTSX_PCI
-   tristate "Realtek PCI-E card reader"
-   depends on PCI
-   select MFD_CORE
-   help
- This supports for Realtek PCI-Express card reader including rts5209,
- rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
- Realtek card reader supports access to many types of memory cards,
- such as Memory Stick, Memory Stick Pro, Secure Digital and
- MultiMediaCard.
-
 config MFD_RT5033
tristate "Richtek RT5033 Power Management IC"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c3d0a1b..5398aca 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -18,8 +18,6 @@ obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
 
-rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
-obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
 obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
 
 obj-$(CONFIG_HTC_PASIC3)   += htc-pasic3.o
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8136dc7..5389d62 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -518,4 +518,5 @@ source "drivers/misc/mic/Kconfig"
 source "drivers/misc/genwqe/Kconfig"
 source "drivers/misc/echo/Kconfig"
 source "drivers/misc/cxl/Kconfig"
+source "drivers/misc/realtek/Kconfig"
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d84819d..1900ca9 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)+= cxl/
 obj-$(CONFIG_ASPEED_LPC_CTRL)  += aspeed-lpc-ctrl.o
 obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
 obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
+obj-$(CONFIG_MFD_RTSX_PCI) +=realtek/
 
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_bugs.o
diff --git a/drivers/misc/realtek/Kconfig b/drivers/misc/realtek/Kconfig
new file mode 100644
index 000..10a8f97
--- /dev/null
+++ b/drivers/misc/realtek/Kconfig
@@ -0,0 +1,10 @@
+config MFD_RTSX_PCI
+   tristate "Realtek PCI-E card reader"
+   depends on PCI
+   select MFD_CORE
+   help
+ This supports for Realtek PCI-Express card reader including rts5209,
+ rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
+ Realtek card reader supports access to

Re: [PATCH v2 2/3] iommu/arm-smmu-v3: add support for unmap an iova range with only one tlb sync

[Leizhen (ThunderTown)]

On 2017/10/18 21:00, Will Deacon wrote:
> On Tue, Sep 12, 2017 at 09:00:37PM +0800, Zhen Lei wrote:
>> This patch is base on: 
>> (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing")
>>
>> Because iotlb_sync is moved out of ".unmap = arm_smmu_unmap", some interval
>> ".unmap" calls should explicitly followed by a iotlb_sync operation.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  drivers/iommu/arm-smmu-v3.c| 10 ++
>>  drivers/iommu/io-pgtable-arm.c | 30 --
>>  drivers/iommu/io-pgtable.h |  1 +
>>  3 files changed, 31 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index ef42c4b..e92828e 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -1772,6 +1772,15 @@ arm_smmu_unmap(struct iommu_domain *domain, unsigned 
>> long iova, size_t size)
>>  return ops->unmap(ops, iova, size);
>>  }
>>  
>> +static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
>> +{
>> +struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> +struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
>> +
>> +if (ops && ops->iotlb_sync)
>> +ops->iotlb_sync(ops);
>> +}
>> +
>>  static phys_addr_t
>>  arm_smmu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
>>  {
>> @@ -1991,6 +2000,7 @@ static struct iommu_ops arm_smmu_ops = {
>>  .attach_dev = arm_smmu_attach_dev,
>>  .map= arm_smmu_map,
>>  .unmap  = arm_smmu_unmap,
>> +.iotlb_sync = arm_smmu_iotlb_sync,
>>  .map_sg = default_iommu_map_sg,
>>  .iova_to_phys   = arm_smmu_iova_to_phys,
>>  .add_device = arm_smmu_add_device,
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index e8018a3..805efc9 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -304,6 +304,8 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
>> *data,
>>  WARN_ON(!selftest_running);
>>  return -EEXIST;
>>  } else if (iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_TABLE) {
>> +size_t unmapped;
>> +
>>  /*
>>   * We need to unmap and free the old table before
>>   * overwriting it with a block entry.
>> @@ -312,7 +314,9 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
>> *data,
>>  size_t sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
>>  
>>  tblp = ptep - ARM_LPAE_LVL_IDX(iova, lvl, data);
>> -if (WARN_ON(__arm_lpae_unmap(data, iova, sz, lvl, tblp) != sz))
>> +unmapped = __arm_lpae_unmap(data, iova, sz, lvl, tblp);
>> +io_pgtable_tlb_sync(&data->iop);
>> +if (WARN_ON(unmapped != sz))
>>  return -EINVAL;
>>  }
>>  
>> @@ -584,7 +588,6 @@ static int __arm_lpae_unmap(struct arm_lpae_io_pgtable 
>> *data,
>>  /* Also flush any partial walks */
>>  io_pgtable_tlb_add_flush(iop, iova, size,
>>  ARM_LPAE_GRANULE(data), false);
>> -io_pgtable_tlb_sync(iop);
>>  ptep = iopte_deref(pte, data);
>>  __arm_lpae_free_pgtable(data, lvl + 1, ptep);
>>  } else {
>> @@ -609,7 +612,6 @@ static int __arm_lpae_unmap(struct arm_lpae_io_pgtable 
>> *data,
>>  static int arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
>>size_t size)
>>  {
>> -size_t unmapped;
>>  struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
>>  arm_lpae_iopte *ptep = data->pgd;
>>  int lvl = ARM_LPAE_START_LVL(data);
>> @@ -617,11 +619,14 @@ static int arm_lpae_unmap(struct io_pgtable_ops *ops, 
>> unsigned long iova,
>>  if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
>>  return 0;
>>  
>> -unmapped = __arm_lpae_unmap(data, iova, size, lvl, ptep);
>> -if (unmapped)
>> -io_pgtable_tlb_sync(&data->iop);
>> +return __arm_lpae_unmap(data, iova, size, lvl, ptep);
>> +}
> 
> This change is already queued in Joerg's tree, due to a patch from Robin.
Yes, I see. So this one can be skipped.

> 
> Will
> 
> .
> 

-- 
Thanks!
BestRegards

Re: [PATCH] mm: mlock: remove lru_add_drain_all()

[Balbir Singh]

On Wed, 18 Oct 2017 16:17:30 -0700
Shakeel Butt  wrote:

> Recently we have observed high latency in mlock() in our generic
> library and noticed that users have started using tmpfs files even
> without swap and the latency was due to expensive remote LRU cache
> draining.
> 
> Is lru_add_drain_all() required by mlock()? The answer is no and the
> reason it is still in mlock() is to rapidly move mlocked pages to
> unevictable LRU. Without lru_add_drain_all() the mlocked pages which
> were on pagevec at mlock() time will be moved to evictable LRUs but
> will eventually be moved back to unevictable LRU by reclaim. So, we
> can safely remove lru_add_drain_all() from mlock(). Also there is no
> need for local lru_add_drain() as it will be called deep inside
> __mm_populate() (in follow_page_pte()).
> 
> Signed-off-by: Shakeel Butt 
> ---

Does this perturb statistics around LRU pages in cgroups and meminfo
about where the pages actually belong?

Balbir Singh.

[PATCH] kbuild doc: a bundle of fixes on makefiles.txt

[Cao jin]

It does several fixes:
1. move the displaced ld example to its reasonale place.
2. add new example for command gzip.
3. fix 2 number errors.
4. fix format of chapter 7.x, make it looks the same as other chapters.

Signed-off-by: Cao jin 
---
 Documentation/kbuild/makefiles.txt | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 329e740..f6f8038 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1108,14 +1108,6 @@ When kbuild executes, the following steps are followed 
(roughly):
 ld
Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
 
-objcopy
-   Copy binary. Uses OBJCOPYFLAGS usually specified in
-   arch/$(ARCH)/Makefile.
-   OBJCOPYFLAGS_$@ may be used to set additional options.
-
-gzip
-   Compress target. Use maximum compression to compress target.
-
Example:
#arch/x86/boot/Makefile
LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
@@ -1139,6 +1131,19 @@ When kbuild executes, the following steps are followed 
(roughly):
  resulting in the target file being recompiled for no
  obvious reason.
 
+objcopy
+   Copy binary. Uses OBJCOPYFLAGS usually specified in
+   arch/$(ARCH)/Makefile.
+   OBJCOPYFLAGS_$@ may be used to set additional options.
+
+gzip
+   Compress target. Use maximum compression to compress target.
+
+   Example:
+   #arch/x86/boot/compressed/Makefile
+   $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
+   $(call if_changed,gzip)
+
 dtc
Create flattened device tree blob object suitable for linking
into vmlinux. Device tree blobs linked into vmlinux are placed
@@ -1219,7 +1224,7 @@ When kbuild executes, the following steps are followed 
(roughly):
that may be shared between individual architectures.
The recommended approach how to use a generic header file is
to list the file in the Kbuild file.
-   See "7.3 generic-y" for further info on syntax etc.
+   See "7.2 generic-y" for further info on syntax etc.
 
 --- 6.11 Post-link pass
 
@@ -1254,13 +1259,13 @@ A Kbuild file may be defined under 
arch//include/uapi/asm/ and
 arch//include/asm/ to list asm files coming from asm-generic.
 See subsequent chapter for the syntax of the Kbuild file.
 
-   --- 7.1 no-export-headers
+--- 7.1 no-export-headers
 
no-export-headers is essentially used by include/uapi/linux/Kbuild to
avoid exporting specific headers (e.g. kvm.h) on architectures that do
not support it. It should be avoided as much as possible.
 
-   --- 7.2 generic-y
+--- 7.2 generic-y
 
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
@@ -1287,7 +1292,7 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
-   --- 7.3 generated-y
+--- 7.3 generated-y
 
If an architecture generates other header files alongside generic-y
wrappers, generated-y specifies them.
@@ -1299,7 +1304,7 @@ See subsequent chapter for the syntax of the Kbuild file.
#arch/x86/include/asm/Kbuild
generated-y += syscalls_32.h
 
-   --- 7.5 mandatory-y
+--- 7.4 mandatory-y
 
mandatory-y is essentially used by include/uapi/asm-generic/Kbuild.asm
to define the minimum set of headers that must be exported in
-- 
2.1.0

Re: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios communication over WMI

[Edward O'Callaghan]

Just my 2c, I like this simplification Mario.
Reviewed-by: Edward O'Callaghan 

On Thu, Oct 19, 2017 at 9:27 AM,   wrote:
>> -Original Message-
>> From: Limonciello, Mario
>> Sent: Wednesday, October 18, 2017 8:56 AM
>> To: 'Pali Rohár' ; Greg KH ; Alan Cox
>> 
>> Cc: dvh...@infradead.org; Andy Shevchenko ;
>> LKML ; platform-driver-...@vger.kernel.org; 
>> Andy
>> Lutomirski ; quasi...@google.com; r...@rjwysocki.net;
>> mj...@google.com; h...@lst.de
>> Subject: RE: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios
>> communication over WMI
>>
>> > -Original Message-
>> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
>> > Sent: Wednesday, October 18, 2017 2:29 AM
>> > To: Greg KH ; Alan Cox 
>> > Cc: dvh...@infradead.org; Andy Shevchenko ;
>> > LKML ; platform-driver-...@vger.kernel.org;
>> Andy
>> > Lutomirski ; quasi...@google.com; r...@rjwysocki.net;
>> > mj...@google.com; h...@lst.de; Limonciello, Mario
>> > 
>> > Subject: Re: [PATCH v9 17/17] tools/wmi: add a sample for dell smbios
>> > communication over WMI
>> >
>> > On Tuesday 17 October 2017 13:22:01 Mario Limonciello wrote:
>> > > diff --git a/tools/wmi/dell-smbios-example.c b/tools/wmi/dell-smbios-
>> example.c
>> > > new file mode 100644
>> > > index ..69c4dd9c6056
>> > > --- /dev/null
>> > > +++ b/tools/wmi/dell-smbios-example.c
>> > > @@ -0,0 +1,214 @@
>> > > +/*
>> > > + *  Sample application for SMBIOS communication over WMI interface
>> > > + *  Performs the following:
>> > > + *  - Simple class/select lookup for TPM information
>> > > + *  - Simple query of known tokens and their values
>> > > + *  - Simple activation of a token
>> > > + *
>> > > + *  Copyright (C) 2017 Dell, Inc.
>> > > + *
>> > > + *  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.
>> > > + */
>> > > +
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +
>> > > +/* if uapi header isn't installed, this might not yet exist */
>> > > +#ifndef __packed
>> > > +#define __packed __attribute__((packed))
>> > > +#endif
>> > > +#include 
>> > > +
>> > > +/* It would be better to discover these using udev, but for a simple
>> > > + * application they're hardcoded
>> > > + */
>> > > +static const char *ioctl_devfs = "/dev/wmi/dell-smbios";
>> > > +static const char *token_sysfs =
>> > > + "/sys/bus/platform/devices/dell-smbios.0/tokens";
>> > > +static const char *buffer_sysfs =
>> > > + "/sys/bus/wmi/devices/A80593CE-A997-11DA-B012-
>> > B622A1EF5492/required_buffer_size";
>> >
>> > Greg, Alan, could userspace expects those paths to be part of kernel
>> > <--> userspace ABI? Looking e.g. at "dell-smbios.0" name and I'm not
>> > sure if this is something which is going to be stable between kernel
>> > versions and forever as part of ABI.
>>
>> In my sample application to be distributed with the kernel these are
>> hardcoded paths, but if more dependencies were used, I would
>> expect all 3 of these paths to be discovered using udev.
>> I do include a comment for that point specifically.
>>
>> >
>> > Also if everything is part of smbios API, would not it better to provide
>> > everything via IOCTL over /dev/wmi/dell-smbios? I think this code is too
>> > complicated, just because for correct IOCTL buffer size it needs to read
>> > other properties via sysfs, etc... For me it looks like that it is not a
>> > good API for userspace developers.
>> >
>> > --
>>
>> This does give me an idea, how about a read on the character device
>> will return required buffer size instead of needing to find a sysfs
>> attribute?  This seems more intuitive to me.
>
> So as to not send the whole series again only to get this idea shot down,
> this is what it looks like (minus documentation updates).
> Thoughts?
>
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index c7de80f96183..922a87d7cf34 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -799,23 +799,12 @@ static int wmi_dev_match(struct device *dev, struct 
> device_driver *driver)
>
> return 0;
>  }
> -
> -static long match_ioctl(struct file *filp, unsigned int cmd, unsigned long 
> arg,
> -   int compat)
> +static int wmi_char_open(struct inode *inode, struct file *filp)
>  {
> -   struct wmi_ioctl_buffer __user *input =
> -   (struct wmi_ioctl_buffer __user *) arg;
> +   const char *driver_name = filp->f_path.dentry->d_iname;
> struct wmi_driver *wdriver = NULL;
> struct wmi_block *wblock = NULL;
> struct wmi_block *next = NULL;
> -   const char *driver_name;
> -   u64 size;
> -   int ret;
> -
> -   if (_IOC_TYPE(cmd) != WMI_IOC)
> -   return -ENOTTY;
> -
> -   driver_name = filp->f_path.dentry->d_iname;
>

Re: [PATCH] md: Convert timers to use timer_setup()

[Jens Axboe]

> On Oct 18, 2017, at 9:06 PM, Kees Cook  wrote:
> 
>> On Mon, Oct 16, 2017 at 8:06 PM, Michael Lyle  wrote:
>>> On 10/16/2017 05:01 PM, Kees Cook wrote:
>>> In preparation for unconditionally passing the struct timer_list pointer to
>>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>>> to pass the timer pointer explicitly.
>>> 
>>> Cc: Kent Overstreet 
>>> Cc: Shaohua Li 
>>> Cc: Alasdair Kergon 
>>> Cc: Mike Snitzer 
>>> Cc: dm-de...@redhat.com
>>> Cc: linux-bca...@vger.kernel.org
>>> Cc: linux-r...@vger.kernel.org
>>> Signed-off-by: Kees Cook 
>> 
>> This looks good to me-- I'm fine with Jens or someone else picking this
>> up directly, or would take a bcache-specific one to apply to my tree.
>> 
>> Reviewed-by: Michael Lyle 
> 
> Jens, can you pick this up, or would you prefer I split it up?

I can pick it up, but I don’t think I was ever cc’ed on
the original.

Re: [PATCH 0/2] Optimize mmu_notifier->invalidate_range callback

[Jerome Glisse]

On Thu, Oct 19, 2017 at 01:43:19PM +1100, Balbir Singh wrote:
> On Mon, 16 Oct 2017 23:10:01 -0400
> jgli...@redhat.com wrote:
> 
> > From: Jérôme Glisse 
> > 
> > (Andrew you already have v1 in your queue of patch 1, patch 2 is new,
> >  i think you can drop it patch 1 v1 for v2, v2 is bit more conservative
> >  and i fixed typos)
> > 
> > All this only affect user of invalidate_range callback (at this time
> > CAPI arch/powerpc/platforms/powernv/npu-dma.c, IOMMU ATS/PASID in
> > drivers/iommu/amd_iommu_v2.c|intel-svm.c)
> > 
> > This patchset remove useless double call to mmu_notifier->invalidate_range
> > callback wherever it is safe to do so. The first patch just remove useless
> > call
> 
> As in an extra call? Where does that come from?

Before this patch you had the following pattern:
  mmu_notifier_invalidate_range_start();
  take_page_table_lock()
  ...
  update_page_table()
  mmu_notifier_invalidate_range()
  ...
  drop_page_table_lock()
  mmu_notifier_invalidate_range_end();

It happens that mmu_notifier_invalidate_range_end() also make an
unconditional call to mmu_notifier_invalidate_range() so in the
above scenario you had 2 calls to mmu_notifier_invalidate_range()

Obviously one of the 2 call is useless. In some case you can drop
the first call (under the page table lock) this is what patch 1
does.

In other cases you can drop the second call that happen inside
mmu_notifier_invalidate_range_end() that is what patch 2 does.

Hence why i am referring to useless double call. I have added
more documentation to explain all this in the code and also under
Documentation/vm/mmu_notifier.txt


> 
> > and add documentation explaining why it is safe to do so. The second
> > patch go further by introducing mmu_notifier_invalidate_range_only_end()
> > which skip callback to invalidate_range this can be done when clearing a
> > pte, pmd or pud with notification which call invalidate_range right after
> > clearing under the page table lock.
> >
> 
> Balbir Singh.
> 

Re: [PATCH] md: Convert timers to use timer_setup()

[Kees Cook]

On Mon, Oct 16, 2017 at 8:06 PM, Michael Lyle  wrote:
> On 10/16/2017 05:01 PM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>> to pass the timer pointer explicitly.
>>
>> Cc: Kent Overstreet 
>> Cc: Shaohua Li 
>> Cc: Alasdair Kergon 
>> Cc: Mike Snitzer 
>> Cc: dm-de...@redhat.com
>> Cc: linux-bca...@vger.kernel.org
>> Cc: linux-r...@vger.kernel.org
>> Signed-off-by: Kees Cook 
>
> This looks good to me-- I'm fine with Jens or someone else picking this
> up directly, or would take a bcache-specific one to apply to my tree.
>
> Reviewed-by: Michael Lyle 

Jens, can you pick this up, or would you prefer I split it up?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

[Balbir Singh]

On Mon, 16 Oct 2017 23:10:02 -0400
jgli...@redhat.com wrote:

> From: Jérôme Glisse 
> 
> + /*
> +  * No need to call mmu_notifier_invalidate_range() as we are
> +  * downgrading page table protection not changing it to point
> +  * to a new page.
> +  *
> +  * See Documentation/vm/mmu_notifier.txt
> +  */
>   if (pmdp) {
>  #ifdef CONFIG_FS_DAX_PMD
>   pmd_t pmd;
> @@ -628,7 +635,6 @@ static void dax_mapping_entry_mkclean(struct 
> address_space *mapping,
>   pmd = pmd_wrprotect(pmd);
>   pmd = pmd_mkclean(pmd);
>   set_pmd_at(vma->vm_mm, address, pmdp, pmd);
> - mmu_notifier_invalidate_range(vma->vm_mm, start, end);

Could the secondary TLB still see the mapping as dirty and propagate the dirty 
bit back?

>  unlock_pmd:
>   spin_unlock(ptl);
>  #endif
> @@ -643,7 +649,6 @@ static void dax_mapping_entry_mkclean(struct 
> address_space *mapping,
>   pte = pte_wrprotect(pte);
>   pte = pte_mkclean(pte);
>   set_pte_at(vma->vm_mm, address, ptep, pte);
> - mmu_notifier_invalidate_range(vma->vm_mm, start, end);

Ditto

>  unlock_pte:
>   pte_unmap_unlock(ptep, ptl);
>   }
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index 6866e8126982..49c925c96b8a 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -155,7 +155,8 @@ struct mmu_notifier_ops {
>* shared page-tables, it not necessary to implement the
>* invalidate_range_start()/end() notifiers, as
>* invalidate_range() alread catches the points in time when an
> -  * external TLB range needs to be flushed.
> +  * external TLB range needs to be flushed. For more in depth
> +  * discussion on this see Documentation/vm/mmu_notifier.txt
>*
>* The invalidate_range() function is called under the ptl
>* spin-lock and not allowed to sleep.
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index c037d3d34950..ff5bc647b51d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1186,8 +1186,15 @@ static int do_huge_pmd_wp_page_fallback(struct 
> vm_fault *vmf, pmd_t orig_pmd,
>   goto out_free_pages;
>   VM_BUG_ON_PAGE(!PageHead(page), page);
>  
> + /*
> +  * Leave pmd empty until pte is filled note we must notify here as
> +  * concurrent CPU thread might write to new page before the call to
> +  * mmu_notifier_invalidate_range_end() happens which can lead to a
> +  * device seeing memory write in different order than CPU.
> +  *
> +  * See Documentation/vm/mmu_notifier.txt
> +  */
>   pmdp_huge_clear_flush_notify(vma, haddr, vmf->pmd);
> - /* leave pmd empty until pte is filled */
>  
>   pgtable = pgtable_trans_huge_withdraw(vma->vm_mm, vmf->pmd);
>   pmd_populate(vma->vm_mm, &_pmd, pgtable);
> @@ -2026,8 +2033,15 @@ static void __split_huge_zero_page_pmd(struct 
> vm_area_struct *vma,
>   pmd_t _pmd;
>   int i;
>  
> - /* leave pmd empty until pte is filled */
> - pmdp_huge_clear_flush_notify(vma, haddr, pmd);
> + /*
> +  * Leave pmd empty until pte is filled note that it is fine to delay
> +  * notification until mmu_notifier_invalidate_range_end() as we are
> +  * replacing a zero pmd write protected page with a zero pte write
> +  * protected page.
> +  *
> +  * See Documentation/vm/mmu_notifier.txt
> +  */
> + pmdp_huge_clear_flush(vma, haddr, pmd);

Shouldn't the secondary TLB know if the page size changed?

>  
>   pgtable = pgtable_trans_huge_withdraw(mm, pmd);
>   pmd_populate(mm, &_pmd, pgtable);
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 1768efa4c501..63a63f1b536c 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3254,9 +3254,14 @@ int copy_hugetlb_page_range(struct mm_struct *dst, 
> struct mm_struct *src,
>   set_huge_swap_pte_at(dst, addr, dst_pte, entry, sz);
>   } else {
>   if (cow) {
> + /*
> +  * No need to notify as we are downgrading page
> +  * table protection not changing it to point
> +  * to a new page.
> +  *
> +  * See Documentation/vm/mmu_notifier.txt
> +  */
>   huge_ptep_set_wrprotect(src, addr, src_pte);

OK.. so we could get write faults on write accesses from the device.

> - mmu_notifier_invalidate_range(src, mmun_start,
> -mmun_end);
>   }
>  

Re: [PATCH v2 1/3] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

[Leizhen (ThunderTown)]

On 2017/10/18 20:58, Will Deacon wrote:
> Hi Thunder,
> 
> On Tue, Sep 12, 2017 at 09:00:36PM +0800, Zhen Lei wrote:
>> Because all TLBI commands should be followed by a SYNC command, to make
>> sure that it has been completely finished. So we can just add the TLBI
>> commands into the queue, and put off the execution until meet SYNC or
>> other commands. To prevent the followed SYNC command waiting for a long
>> time because of too many commands have been delayed, restrict the max
>> delayed number.
>>
>> According to my test, I got the same performance data as I replaced writel
>> with writel_relaxed in queue_inc_prod.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  drivers/iommu/arm-smmu-v3.c | 42 +-
>>  1 file changed, 37 insertions(+), 5 deletions(-)
> 
> If we want to go down the route of explicit command batching, I'd much
> rather do it by implementing the iotlb_range_add callback in the driver,
> and have a fixed-length array of batched ranges on the domain. We could
I think even if iotlb_range_add callback is implemented, this patch is still 
valuable. The main purpose
of this patch is to reduce dsb operation. So in the scenario with 
iotlb_range_add implemented:
.iotlb_range_add:
spin_lock_irqsave(&smmu->cmdq.lock, flags);
...
add tlbi range-1 to cmq-queue
...
add tlbi range-n to cmq-queue   //n
dsb
...
spin_unlock_irqrestore(&smmu->cmdq.lock, flags);

.iotlb_sync
spin_lock_irqsave(&smmu->cmdq.lock, flags);
...
add cmd_sync to cmq-queue
dsb
...
spin_unlock_irqrestore(&smmu->cmdq.lock, flags);

Although iotlb_range_add can reduce n-1 dsb operations, but there are still 1 
left. If n is not large enough,
this patch is helpful.


> potentially toggle this function pointer based on the compatible string too,
> if it shows only to benefit some systems.
[
On 2017/9/19 12:31, Nate Watterson wrote:
I tested these (2) patches on QDF2400 hardware and saw performance
improvements in line with those I reported when testing the original
series.
]

I'm not sure whether this patch can improve performance on QDF2400, because 
there are two patches. But at least
it seems harmless, maybe the other hardware platforms are the same.

> 
> Will
> 
> .
> 

-- 
Thanks!
BestRegards

[PATCH 03/14] soundwire: Add Master registration

[Vinod Koul]

A Master registers with SoundWire bus and scans the firmware provided
for device description. In this patch we scan the ACPI namespaces and
create the SoundWire Slave devices based on the ACPI description

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Makefile|   2 +-
 drivers/soundwire/bus.c   | 150 
 drivers/soundwire/bus.h   |  20 +
 drivers/soundwire/slave.c | 172 ++
 include/linux/soundwire/sdw.h |   3 +
 5 files changed, 346 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soundwire/bus.c
 create mode 100644 drivers/soundwire/slave.c

diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index d1281def7662..c875e434f8b3 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -3,5 +3,5 @@
 #
 
 #Bus Objs
-soundwire-bus-objs := bus_type.o
+soundwire-bus-objs := bus_type.o bus.o slave.o
 obj-$(CONFIG_SOUNDWIRE_BUS) += soundwire-bus.o
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
new file mode 100644
index ..57250f38a8d4
--- /dev/null
+++ b/drivers/soundwire/bus.c
@@ -0,0 +1,150 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public 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.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "bus.h"
+
+/**
+ * sdw_add_bus_master: add a bus Master instance
+ *
+ * @bus: bus instance
+ *
+ * Initializes the bus instance, read properties and create child
+ * devices.
+ */
+int sdw_add_bus_master(struct sdw_bus *bus)
+{
+   int ret;
+
+   if (!bus->dev) {
+   pr_err("SoundWire bus has no device");
+   return -ENODEV;
+   }
+
+   mutex_init(&bus->bus_lock);
+   INIT_LIST_HEAD(&bus->slaves);
+
+   /*
+* SDW is an enumerable bus, but devices can be powered off. So,
+* they won't be able to report as present.
+*
+* Create Slave devices based on Slaves described in
+* the respective firmware (ACPI/DT)
+*/
+
+   if (IS_ENABLED(CONFIG_ACPI) && bus->dev && ACPI_HANDLE(bus->dev))
+   ret = sdw_acpi_find_slaves(bus);
+   else if (IS_ENABLED(CONFIG_OF) && bus->dev && bus->dev->of_node)
+   ret = sdw_of_find_slaves(bus);
+   else
+   ret = -ENOTSUPP; /* No ACPI/DT so error out */
+
+   if (ret) {
+   dev_err(bus->dev, "Finding slaves failed:%d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(sdw_add_bus_master);
+
+static int sdw_delete_slave(struct device *dev, void *data)
+{
+   struct sdw_slave *slave = dev_to_sdw_dev(dev);
+   struct sdw_bus *bus = slav

[PATCH 06/14] soundwire: Add IO transfer

[Vinod Koul]

SoundWire bus supports read and write register(s) for SoundWire
Slave device. sdw_read() and sdw_write() APIs are provided for single
register read/write. sdw_nread() and sdw_nwrite() for operations on
contiguous register read/write.

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/bus.c   | 265 ++
 drivers/soundwire/bus.h   |  33 ++
 include/linux/soundwire/sdw.h |  67 +++
 3 files changed, 365 insertions(+)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 5b13d96b67b8..9ac22eab11bb 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -73,6 +73,12 @@ int sdw_add_bus_master(struct sdw_bus *bus)
return -ENODEV;
}
 
+   if (!bus->ops) {
+   dev_err(bus->dev, "SoundWire Bus ops are not set");
+   return -EINVAL;
+   }
+
+   mutex_init(&bus->msg_lock);
mutex_init(&bus->bus_lock);
INIT_LIST_HEAD(&bus->slaves);
 
@@ -128,6 +134,265 @@ void sdw_delete_bus_master(struct sdw_bus *bus)
 }
 EXPORT_SYMBOL(sdw_delete_bus_master);
 
+/*
+ * SDW IO Calls
+ */
+
+static bool sdw_get_page(struct sdw_slave *slave, struct sdw_msg *msg)
+{
+   bool page = false, paging_support = false;
+
+   if (slave && slave->prop.paging_support)
+   paging_support = true;
+
+   /*
+* Programme SCP page addr for:
+* 1. addr_page1 and addr_page2 contains non-zero values.
+* 2. Paging supported by Slave.
+*/
+   switch (msg->dev_num) {
+   case SDW_ENUM_DEV_NUM:
+   case SDW_BROADCAST_DEV_NUM:
+   break;
+
+   default:
+   if (paging_support && ((msg->addr_page1) || (msg->addr_page2)))
+   page = true;
+   }
+
+   return page;
+}
+
+static inline int find_error_code(unsigned int sdw_ret)
+{
+   switch (sdw_ret) {
+   case SDW_CMD_OK:
+   return 0;
+
+   case SDW_CMD_IGNORED:
+   return -ENODATA;
+
+   case SDW_CMD_TIMEOUT:
+   return -ETIMEDOUT;
+   }
+
+   return -EIO;
+}
+
+static inline int do_transfer(struct sdw_bus *bus,
+   struct sdw_msg *msg, bool page)
+{
+   int retry = bus->prop.err_threshold;
+   int ret, i;
+
+   for (ret = 0, i = 0; i <= retry; i++) {
+   ret = bus->ops->xfer_msg(bus, msg, page);
+   ret = find_error_code(ret);
+   /* if cmd is ok or ignored return */
+   if (ret == 0 || ret == -ENODATA)
+   return ret;
+   }
+
+   return ret;
+}
+
+static inline int do_transfer_defer(struct sdw_bus *bus,
+   struct sdw_msg *msg, bool page,
+   struct sdw_defer *defer)
+{
+   int retry = bus->prop.err_threshold;
+   int ret, i;
+
+   defer->msg = msg;
+   defer->length = msg->len;
+
+   for (ret = 0, i = 0; i <= retry; i++) {
+
+   ret = bus->ops->xfer_msg_defer(bus, msg, page, defer);
+   ret = find_error_code(ret);
+   /* if cmd is ok or ignored return */
+   if (ret == 0 || ret == -ENODATA)
+   return ret;
+   }
+
+   return ret;
+}
+
+static int sdw_reset_page(struct sdw_bus *bus, u16 dev_num)
+{
+   int retry = bus->prop.err_threshold;
+   int ret, i;
+
+   for (ret = 0, i = 0; i <= retry; i++) {
+   ret = bus->ops->reset_page_addr(bus, dev_num);
+   ret = find_error_code(ret);
+   /* if cmd is ok or ignored return */
+   if (ret == 0 || ret == -ENODATA)
+   return ret;
+   }
+
+   return ret;
+}
+
+/**
+ * sdw_transfer: Synchronous transfer message to a SDW Slave device
+ *
+ * @bus: SDW bus
+ * @slave: SDW Slave
+ * @msg: SDW message to be xfered
+ */
+int sdw_transfer(struct sdw_bus *bus, struct sdw_slave *slave,
+   struct sdw_msg *msg)
+{
+   bool page;
+   int ret;
+
+   mutex_lock(&bus->msg_lock);
+
+   page = sdw_get_page(slave, msg);
+
+   ret = do_transfer(bus, msg, page);
+   if (ret != 0 && ret != -ENODATA) {
+   dev_err(bus->dev, "trf on Slave %d failed:%d\n",
+   msg->dev_num, ret);
+   goto error;
+   }
+
+   if (page)
+   ret = sdw_reset_page(bus, msg->dev_num);
+
+error:
+   mutex_unlock(&bus->msg_lock);
+
+   return ret;
+}
+
+/**
+ * sdw_transfer_defer: Asynchronously transfer message to a SDW Slave device
+ *
+ * @bus: SDW bus
+ * @slave: SDW Slave
+ * @msg: SDW message to be xfered
+ * @defer: Defer block for signal completion
+ *
+ * Caller needs to hold the msg_lock lock while calling this
+ */
+int sdw_transfer_defer(struct sdw_bus *bus, struct sdw_slave *slave,
+   struct sdw_msg *msg, struct sdw_defer *defer)
+{
+   bool page;
+   

[PATCH 08/14] soundwire: Add Slave status handling helpers

[Vinod Koul]

From: Sanyog Kale 

SoundWire Slaves report status to bus. Add helpers to handle
the status changes.

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/bus.c   | 211 ++
 include/linux/soundwire/sdw.h |   1 +
 2 files changed, 212 insertions(+)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 9ac22eab11bb..f206e78d4b68 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -393,6 +393,95 @@ int sdw_write(struct sdw_slave *slave, u32 addr, u8 value)
 }
 EXPORT_SYMBOL(sdw_write);
 
+/*
+ * SDW alert handling
+ */
+static struct sdw_slave *sdw_get_slave(struct sdw_bus *bus, int i)
+{
+   struct sdw_slave *slave;
+
+   list_for_each_entry(slave, &bus->slaves, node) {
+   if (slave->dev_num == i)
+   return slave;
+   }
+
+   return NULL;
+}
+
+static int sdw_compare_devid(struct sdw_slave *slave, struct sdw_slave_id id)
+{
+
+   if ((slave->id.unique_id != id.unique_id) ||
+   (slave->id.mfg_id != id.mfg_id) ||
+   (slave->id.part_id != id.part_id) ||
+   (slave->id.class_id != id.class_id))
+   return -ENODEV;
+
+   return 0;
+}
+
+static int sdw_get_device_num(struct sdw_slave *slave)
+{
+   bool assigned = false;
+   int i;
+
+   mutex_lock(&slave->bus->bus_lock);
+   for (i = 1; i <= SDW_MAX_DEVICES; i++) {
+   if (slave->bus->assigned[i] == true)
+   continue;
+
+   slave->bus->assigned[i] = true;
+   assigned = true;
+
+   /*
+* Do not update dev_num in Slave data structure here,
+* Update once program dev_num is successful
+*/
+   break;
+   }
+
+   mutex_unlock(&slave->bus->bus_lock);
+   if (assigned)
+   return i;
+   else
+   return -ENODEV;
+}
+
+static int sdw_assign_device_num(struct sdw_slave *slave)
+{
+   int ret, dev_num;
+
+   /* check first if device number is assigned, if so reuse that */
+   if (!slave->dev_num) {
+   dev_num = sdw_get_device_num(slave);
+   if (dev_num < 0) {
+   dev_err(slave->bus->dev, "Get dev_num failed: %d",
+   dev_num);
+   return dev_num;
+   }
+   } else {
+   dev_info(slave->bus->dev,
+   "Slave already registered dev_num:%d",
+   slave->dev_num);
+
+   /* Clear the slave->dev_num to transfer message on device 0 */
+   dev_num = slave->dev_num;
+   slave->dev_num = 0;
+
+   }
+
+   ret = sdw_write(slave, SDW_SCP_DEVNUMBER, dev_num);
+   if (ret < 0) {
+   dev_err(&slave->dev, "Program device_num failed: %d", ret);
+   return ret;
+   }
+
+   /* After xfer of msg, restore dev_num */
+   slave->dev_num = dev_num;
+
+   return 0;
+}
+
 void sdw_extract_slave_id(struct sdw_bus *bus,
unsigned long long addr, struct sdw_slave_id *id)
 {
@@ -421,3 +510,125 @@ void sdw_extract_slave_id(struct sdw_bus *bus,
id->unique_id, id->sdw_version);
 
 }
+
+static int sdw_program_device_num(struct sdw_bus *bus)
+{
+   u8 buf[SDW_NUM_DEV_ID_REGISTERS] = {0};
+   unsigned long long addr;
+   struct sdw_slave *slave;
+   struct sdw_slave_id id;
+   struct sdw_msg msg;
+   bool found = false;
+   int ret;
+
+   /* No Slave, so use raw xfer api */
+   sdw_fill_msg(&msg, SDW_SCP_DEVID_0, SDW_NUM_DEV_ID_REGISTERS,
+   0, SDW_MSG_FLAG_READ, buf);
+
+   do {
+   ret = sdw_transfer(bus, NULL, &msg);
+   if (ret == -ENODATA)
+   break;
+   if (ret < 0) {
+   dev_err(bus->dev, "DEVID read fail:%d\n", ret);
+   break;
+   }
+
+   /*
+* Construct the addr and extract. Cast the higher shift
+* bits to avoid truncation due to size limit.
+*/
+   addr = buf[5] | (buf[4] << 8) | (buf[3] << 16) |
+   (buf[2] << 24) | ((unsigned long long)buf[1] << 32) |
+   ((unsigned long long)buf[0] << 40);
+
+   sdw_extract_slave_id(bus, addr, &id);
+
+   /* Now compare with entries */
+   list_for_each_entry(slave, &bus->slaves, node) {
+   if (sdw_compare_devid(slave, id) == 0) {
+   found = true;
+
+   /*
+* Assign a new dev_num to this Slave and
+*

[PATCH 12/14] soundwire: cdns: Add sdw_master_ops and IO transfer support

[Vinod Koul]

From: Sanyog Kale 

Implement sdw_master_ops with support for xfer_msg, xfer_msg_defer and
reset_page_addr. Since Cadence module doesn't know the systems it will be
used, set the read_prop to the bus helper.

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/cadence_master.c | 323 +
 drivers/soundwire/cadence_master.h |  14 ++
 2 files changed, 337 insertions(+)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index fc287cca9579..638f4f8165d7 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -267,9 +267,262 @@ static int cdns_clear_bit(struct sdw_cdns *cdns, int 
offset, u32 value)
 }
 
 /*
+ * IO Calls
+ */
+static enum sdw_command_response cdns_fill_msg_resp(
+   struct sdw_cdns *cdns,
+   struct sdw_msg *msg, int count, int offset)
+{
+   int nack = 0, no_ack = 0;
+   int i;
+
+   /* check message response */
+   for (i = 0; i < count; i++) {
+   if (!(cdns->response_buf[i] & CDNS_MCP_RESP_ACK)) {
+   no_ack = 1;
+   dev_dbg(cdns->dev, "Msg Ack not received\n");
+   if (cdns->response_buf[i] & CDNS_MCP_RESP_NACK) {
+   nack = 1;
+   dev_err(cdns->dev, "Msg NACK received\n");
+   }
+   }
+   }
+
+   if (nack) {
+   dev_err(cdns->dev, "Msg NACKed for Slave %d\n", msg->dev_num);
+   return SDW_CMD_FAIL;
+   } else if (no_ack) {
+   dev_dbg(cdns->dev, "Msg ignored for Slave %d\n", msg->dev_num);
+   return SDW_CMD_IGNORED;
+   }
+
+   /* fill response */
+   for (i = 0; i < count; i++)
+   msg->buf[i + offset] = cdns->response_buf[i] >>
+   SDW_REG_SHIFT(CDNS_MCP_RESP_RDATA);
+
+   return SDW_CMD_OK;
+}
+
+static enum sdw_command_response
+_cdns_xfer_msg(struct sdw_cdns *cdns, struct sdw_msg *msg, int cmd,
+   int offset, int count, bool defer)
+{
+   unsigned long time;
+   u32 base, i, data;
+   u16 addr;
+
+   /* Program the watermark level for RX FIFO */
+   if (cdns->msg_count != count) {
+   cdns_writel(cdns, CDNS_MCP_FIFOLEVEL, count);
+   cdns->msg_count = count;
+   }
+
+   base = CDNS_MCP_CMD_BASE;
+   addr = msg->addr;
+
+   for (i = 0; i < count; i++) {
+   data = msg->dev_num << SDW_REG_SHIFT(CDNS_MCP_CMD_DEV_ADDR);
+   data |= cmd << SDW_REG_SHIFT(CDNS_MCP_CMD_COMMAND);
+   data |= addr++  << SDW_REG_SHIFT(CDNS_MCP_CMD_REG_ADDR_L);
+
+   if (msg->flags == SDW_MSG_FLAG_WRITE)
+   data |= msg->buf[i + offset];
+
+   data |= msg->ssp_sync << SDW_REG_SHIFT(CDNS_MCP_CMD_SSP_TAG);
+   cdns_writel(cdns, base, data);
+   base += CDNS_MCP_CMD_WORD_LEN;
+   }
+
+   if (defer)
+   return SDW_CMD_OK;
+
+   /* wait for timeout or response */
+   time = wait_for_completion_timeout(&cdns->tx_complete,
+   msecs_to_jiffies(CDNS_TX_TIMEOUT));
+   if (!time) {
+   dev_err(cdns->dev, "IO transfer timed out\n");
+   msg->len = 0;
+   return SDW_CMD_TIMEOUT;
+   }
+
+   return cdns_fill_msg_resp(cdns, msg, count, offset);
+}
+
+static enum sdw_command_response cdns_program_scp_addr(
+   struct sdw_cdns *cdns, struct sdw_msg *msg)
+{
+   int nack = 0, no_ack = 0;
+   unsigned long time;
+   u32 data[2], base;
+   int i;
+
+   /* Program the watermark level for RX FIFO */
+   if (cdns->msg_count != CDNS_SCP_RX_FIFOLEVEL) {
+   cdns_writel(cdns, CDNS_MCP_FIFOLEVEL, CDNS_SCP_RX_FIFOLEVEL);
+   cdns->msg_count = CDNS_SCP_RX_FIFOLEVEL;
+   }
+
+   data[0] = msg->dev_num << SDW_REG_SHIFT(CDNS_MCP_CMD_DEV_ADDR);
+   data[0] |= 0x3 << SDW_REG_SHIFT(CDNS_MCP_CMD_COMMAND);
+   data[1] = data[0];
+
+   data[0] |= SDW_SCP_ADDRPAGE1 << SDW_REG_SHIFT(CDNS_MCP_CMD_REG_ADDR_L);
+   data[1] |= SDW_SCP_ADDRPAGE2 << SDW_REG_SHIFT(CDNS_MCP_CMD_REG_ADDR_L);
+
+   data[0] |= msg->addr_page1;
+   data[1] |= msg->addr_page2;
+
+   base = CDNS_MCP_CMD_BASE;
+   cdns_writel(cdns, base, data[0]);
+   base += CDNS_MCP_CMD_WORD_LEN;
+   cdns_writel(cdns, base, data[1]);
+
+   time = wait_for_completion_timeout(&cdns->tx_complete,
+   msecs_to_jiffies(CDNS_TX_TIMEOUT));
+   if (!time) {
+   dev_err(cdns->dev, "SCP Msg trf timed out\n");
+   msg->len = 0;
+   return SDW_CMD_TIMEOUT;
+   }
+
+   /* check response the writes */
+   for (i = 0; i < 2; i++) {
+  

[PATCH 13/14] soundwire: intel: Add Intel Master driver

[Vinod Koul]

Some Intel platforms have SoundWire Master, so add Intel SoundWire
Master driver which uses Cadence module. This patch adds probe and
initialization routines for Intel Master driver.

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Kconfig   |  11 +
 drivers/soundwire/Makefile  |   4 +
 drivers/soundwire/intel.c   | 395 
 drivers/soundwire/intel.h   |  70 +++
 include/linux/soundwire/sdw_intel.h |  69 +++
 5 files changed, 549 insertions(+)
 create mode 100644 drivers/soundwire/intel.c
 create mode 100644 drivers/soundwire/intel.h
 create mode 100644 include/linux/soundwire/sdw_intel.h

diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
index 677789cf4745..8ce6b9ebaded 100644
--- a/drivers/soundwire/Kconfig
+++ b/drivers/soundwire/Kconfig
@@ -23,4 +23,15 @@ config SOUNDWIRE_BUS
 config SOUNDWIRE_CADENCE
tristate
 
+config SOUNDWIRE_INTEL
+   tristate "Intel SoundWire Master driver"
+   select SOUNDWIRE_CADENCE
+   select SOUNDWIRE_BUS
+   depends on X86 && ACPI
+   ---help---
+ SoundWire Intel Master driver.
+ If you have an Intel platform which has a SoundWire Master then
+ enable this config option to get the SoundWire support for that
+ device.
+
 endif
diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index f9a1ce3a860e..0813b2c74426 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -9,3 +9,7 @@ obj-$(CONFIG_SOUNDWIRE_BUS) += soundwire-bus.o
 #Cadence Objs
 soundwire-cadence-objs := cadence_master.o
 obj-$(CONFIG_SOUNDWIRE_CADENCE) += soundwire-cadence.o
+
+#Intel driver
+soundwire-intel-objs :=intel.o
+obj-$(CONFIG_SOUNDWIRE_INTEL) += soundwire-intel.o
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
new file mode 100644
index ..c92847dad5cd
--- /dev/null
+++ b/drivers/soundwire/intel.c
@@ -0,0 +1,395 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public 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.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * Soundwire Intel Master Driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cadence_master.h"
+#include "intel.h"
+
+/* Intel SHIM Registers Definition */
+#define SDW_SHIM_LCAP  0x0
+#define SDW_SHIM_LCTL  0x4
+#define SDW_SHIM_IPPTR 0x8
+#define SDW_SHIM_SYNC  0xC
+
+#define SDW_SHIM_CTLSCAP(x)(0x010 + 0x60 * x)
+#define SDW_SHIM_CTLS0CM(x)(0x012 + 0x60 * x)
+#define SDW_SHIM_CTLS1CM(x)(0x014 + 0x60 * x)
+#define SDW_SHIM_CTLS2CM(x)

Re: [PATCH v2 1/4] dt-bindings: rtc: mediatek: add bindings for MediaTek SoC based RTC

[Sean Wang]

On Wed, 2017-10-18 at 21:32 +0800, Yingjoe Chen wrote:
> On Tue, 2017-10-17 at 17:40 +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > Add device-tree binding for MediaTek SoC based RTC
> > 
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Sean Wang 
> > Acked-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/rtc/rtc-mediatek.txt| 21 
> > +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mediatek.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc-mediatek.txt 
> > b/Documentation/devicetree/bindings/rtc/rtc-mediatek.txt
> > new file mode 100644
> > index 000..09fe8f5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-mediatek.txt
> 
> 
> How about change this filename to match driver filename change?
> 
> Joe.C
> 

Will be improved together with the other patches

[PATCH 14/14] soundwire: intel: Add Intel init module

[Vinod Koul]

The SoundWire Master is implemented as part of Audio controller in
Intel platforms. Add a init module which creates SoundWire Master
platform devices based on the links supported in the hardware.

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Makefile  |   3 +
 drivers/soundwire/intel_init.c  | 230 
 include/linux/soundwire/sdw_intel.h |   3 +
 3 files changed, 236 insertions(+)
 create mode 100644 drivers/soundwire/intel_init.c

diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index 0813b2c74426..94272c965d6c 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -13,3 +13,6 @@ obj-$(CONFIG_SOUNDWIRE_CADENCE) += soundwire-cadence.o
 #Intel driver
 soundwire-intel-objs :=intel.o
 obj-$(CONFIG_SOUNDWIRE_INTEL) += soundwire-intel.o
+
+soundwire-intel-init-objs := intel_init.o
+obj-$(CONFIG_SOUNDWIRE_INTEL) += soundwire-intel-init.o
diff --git a/drivers/soundwire/intel_init.c b/drivers/soundwire/intel_init.c
new file mode 100644
index ..188cb2052842
--- /dev/null
+++ b/drivers/soundwire/intel_init.c
@@ -0,0 +1,230 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public 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.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * SDW Intel Init Routines
+ *
+ * Initializes and creates SDW devices based on ACPI and Hardware values
+ */
+
+#include 
+#include 
+#include 
+#include "intel.h"
+
+#define SDW_MAX_LINKS  4
+#define SDW_SHIM_LCAP  0x0
+#define SDW_SHIM_BASE  0x2C000
+#define SDW_ALH_BASE   0x2C800
+#define SDW_LINK_BASE  0x3
+#define SDW_LINK_SIZE  0x1
+
+struct sdw_link_data {
+   struct sdw_intel_link_res res;
+   struct platform_device *pdev;
+};
+
+struct sdw_intel_ctx {
+   int count;
+   struct sdw_link_data *links;
+};
+
+static int sdw_intel_cleanup_pdev(struct sdw_intel_ctx *ctx)
+{
+   struct sdw_link_data *link = ctx->links;
+   int i;
+
+   if (!link)
+   return 0;
+
+   for (i = 0; i < ctx->count; i++) {
+   if (link->pdev)
+   platform_device_unregister(link->pdev);
+   link++;
+   }
+
+   kfree(ctx->links);
+   ctx->links = NULL;
+
+   return 0;
+}
+
+static struct sdw_intel_ctx
+*sdw_intel_add_controller(struct sdw_intel_res *res)
+{
+   struct platform_device_info pdevinfo;
+   struct platform_device *pdev;
+   struct sdw_link_data *link;
+   struct sdw_intel_ctx *ctx;
+   struct acpi_device *adev;
+   int ret, i;
+   u8 count;
+   u32 caps;
+
+   if (acpi_bus_get_device(res->handle, &adev))
+   return NULL;
+
+   /* Found controller, find links suppor

[PATCH 11/14] soundwire: cdns: Add cadence module

[Vinod Koul]

Cadence IP implements SoundWire Master. Add base cadence module
initialization and interrupt handling

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Kconfig  |   3 +
 drivers/soundwire/Makefile |   4 +
 drivers/soundwire/cadence_master.c | 470 +
 drivers/soundwire/cadence_master.h |  80 +++
 4 files changed, 557 insertions(+)
 create mode 100644 drivers/soundwire/cadence_master.c
 create mode 100644 drivers/soundwire/cadence_master.h

diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
index d63295015331..677789cf4745 100644
--- a/drivers/soundwire/Kconfig
+++ b/drivers/soundwire/Kconfig
@@ -20,4 +20,7 @@ config SOUNDWIRE_BUS
default SOUNDWIRE
select REGMAP_SOUNDWIRE
 
+config SOUNDWIRE_CADENCE
+   tristate
+
 endif
diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index 67dc7b546258..f9a1ce3a860e 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -5,3 +5,7 @@
 #Bus Objs
 soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o sysfs.o
 obj-$(CONFIG_SOUNDWIRE_BUS) += soundwire-bus.o
+
+#Cadence Objs
+soundwire-cadence-objs := cadence_master.o
+obj-$(CONFIG_SOUNDWIRE_CADENCE) += soundwire-cadence.o
diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
new file mode 100644
index ..fc287cca9579
--- /dev/null
+++ b/drivers/soundwire/cadence_master.c
@@ -0,0 +1,470 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public 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.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * Cadence SoundWire Master module
+ * Used by Master driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "bus.h"
+#include "cadence_master.h"
+
+#define CDNS_MCP_CONFIG0x0
+
+#define CDNS_MCP_CONFIG_MCMD_RETRY GENMASK(27, 24)
+#define CDNS_MCP_CONFIG_MPREQ_DELAYGENMASK(20, 16)
+#define CDNS_MCP_CONFIG_MMASTERBIT(7)
+#define CDNS_MCP_CONFIG_BUS_RELBIT(6)
+#define CDNS_MCP_CONFIG_SNIFFERBIT(5)
+#define CDNS_MCP_CONFIG_SSPMOD BIT(4)
+#define CDNS_MCP_CONFIG_CMDBIT(3)
+#define CDNS_MCP_CONFIG_OP GENMASK(2, 0)
+#define CDNS_MCP_CONFIG_OP_NORMAL  0
+
+#define CDNS_MCP_CONTROL   0x4
+
+#define CDNS_MCP_CONTROL_RST_DELAY GENMASK(10, 8)
+#define CDNS_MCP_CONTROL_CMD_RST   BIT(7)
+#define CDNS_MCP_CONTROL_SOFT_RST  BIT(6)
+#define CDNS_MCP_CONTROL_SW_RSTBIT(5)
+#define CDNS_MCP_CONTROL_HW_RST  

[PATCH 10/14] soundwire: Add sysfs for SoundWire DisCo properties

[Vinod Koul]

It helps to read the properties for understanding and debug
SoundWire systems, so add sysfs files for SoundWire DisCo
properties.

TODO: Add ABI files for sysfs

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Makefile|   2 +-
 drivers/soundwire/bus.c   |   5 +
 drivers/soundwire/bus.h   |   2 +
 drivers/soundwire/slave.c |   1 +
 drivers/soundwire/sysfs.c | 396 ++
 include/linux/soundwire/sdw.h |  15 ++
 6 files changed, 420 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soundwire/sysfs.c

diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index bcde0d26524c..67dc7b546258 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -3,5 +3,5 @@
 #
 
 #Bus Objs
-soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o
+soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o sysfs.o
 obj-$(CONFIG_SOUNDWIRE_BUS) += soundwire-bus.o
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 6c4f41b64744..e3d7aea18892 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -90,6 +90,8 @@ int sdw_add_bus_master(struct sdw_bus *bus)
}
}
 
+   sdw_sysfs_bus_init(bus);
+
/*
 * SDW is an enumerable bus, but devices can be powered off. So,
 * they won't be able to report as present.
@@ -119,6 +121,8 @@ static int sdw_delete_slave(struct device *dev, void *data)
struct sdw_slave *slave = dev_to_sdw_dev(dev);
struct sdw_bus *bus = slave->bus;
 
+   sdw_sysfs_slave_exit(slave);
+
mutex_lock(&bus->bus_lock);
if (!list_empty(&bus->slaves))
list_del(&slave->node);
@@ -130,6 +134,7 @@ static int sdw_delete_slave(struct device *dev, void *data)
 
 void sdw_delete_bus_master(struct sdw_bus *bus)
 {
+   sdw_sysfs_bus_init(bus);
device_for_each_child(bus->dev, NULL, sdw_delete_slave);
 }
 EXPORT_SYMBOL(sdw_delete_bus_master);
diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h
index 2e9f84209879..2c1f64415a5b 100644
--- a/drivers/soundwire/bus.h
+++ b/drivers/soundwire/bus.h
@@ -79,6 +79,8 @@ int sdw_slave_modalias(struct sdw_slave *slave, char *buf, 
size_t size);
 void sdw_extract_slave_id(struct sdw_bus *bus,
unsigned long long addr, struct sdw_slave_id *id);
 
+extern const struct attribute_group *sdw_slave_dev_attr_groups[];
+
 enum {
SDW_MSG_FLAG_READ = 0,
SDW_MSG_FLAG_WRITE,
diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
index ee8e0e848f64..1b4e7f1b66e1 100644
--- a/drivers/soundwire/slave.c
+++ b/drivers/soundwire/slave.c
@@ -85,6 +85,7 @@ static int sdw_slave_add(struct sdw_bus *bus,
slave->dev.fwnode = fwnode;
dev_set_name(&slave->dev, "%s", name);
slave->dev.release = sdw_slave_release;
+   slave->dev.groups = sdw_slave_dev_attr_groups;
slave->dev.bus = &sdw_bus_type;
slave->bus = bus;
slave->status = SDW_SLAVE_UNATTACHED;
diff --git a/drivers/soundwire/sysfs.c b/drivers/soundwire/sysfs.c
new file mode 100644
index ..29e2f1db08ec
--- /dev/null
+++ b/drivers/soundwire/sysfs.c
@@ -0,0 +1,396 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public 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.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR

[PATCH 09/14] soundwire: Add slave status handling

[Vinod Koul]

Add status handling API sdw_handle_slave_status() to handle
Slave status changes.

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/bus.c   | 344 ++
 drivers/soundwire/bus.h   |   2 +
 include/linux/soundwire/sdw.h |  21 +++
 3 files changed, 367 insertions(+)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index f206e78d4b68..6c4f41b64744 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -632,3 +632,347 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
 
return 0;
 }
+
+static int sdw_handle_dp0_interrupt(struct sdw_slave *slave, u8 *slave_status)
+{
+   u8 clear = 0, impl_int_mask;
+   int status, ret, count = 0;
+
+   status = sdw_read(slave, SDW_DP0_INT);
+   if (status < 0) {
+   dev_err(slave->bus->dev,
+   "SDW_DP0_INT read failed:%d", status);
+   return status;
+   }
+
+   do {
+
+   if (status & SDW_DP0_INT_TEST_FAIL) {
+   dev_err(&slave->dev, "Test fail for port 0");
+   clear |= SDW_DP0_INT_TEST_FAIL;
+   }
+
+   /*
+* Assumption: PORT_READY interrupt will be received only for
+* ports implementing Channel Prepare state machine (CP_SM)
+*/
+
+   if (status & SDW_DP0_INT_PORT_READY) {
+   complete(&slave->port_ready[0]);
+   clear |= SDW_DP0_INT_PORT_READY;
+   }
+
+   if (status & SDW_DP0_INT_BRA_FAILURE) {
+   dev_err(&slave->dev, "BRA failed");
+   clear |= SDW_DP0_INT_BRA_FAILURE;
+   }
+
+   impl_int_mask = SDW_DP0_INT_IMPDEF1 |
+   SDW_DP0_INT_IMPDEF2 | SDW_DP0_INT_IMPDEF3;
+
+   if (status & impl_int_mask) {
+   clear |= impl_int_mask;
+   *slave_status = clear;
+   }
+
+   /* clear the interrupt */
+   ret = sdw_write(slave, SDW_DP0_INT, clear);
+   if (ret < 0) {
+   dev_err(slave->bus->dev,
+   "SDW_DP0_INT write failed:%d", ret);
+   return ret;
+   }
+
+   /* Read DP0 interrupt again */
+   status = sdw_read(slave, SDW_DP0_INT);
+   if (status < 0) {
+   dev_err(slave->bus->dev,
+   "SDW_DP0_INT read failed:%d", status);
+   return status;
+   }
+
+   count++;
+
+   /* we can get alerts while processing so keep retrying */
+   } while (status != 0 && count < SDW_READ_INTR_CLEAR_RETRY);
+
+   if (count == SDW_READ_INTR_CLEAR_RETRY)
+   dev_warn(slave->bus->dev, "Reached MAX_RETRY on DP0 read");
+
+   return ret;
+}
+
+static int sdw_handle_port_interrupt(struct sdw_slave *slave,
+   int port, u8 *slave_status)
+{
+   u8 clear = 0, impl_int_mask;
+   int status, ret, count = 0;
+   u32 addr;
+
+   if (port == 0)
+   return sdw_handle_dp0_interrupt(slave, slave_status);
+
+   addr = SDW_DPN_INT(port);
+   status = sdw_read(slave, addr);
+   if (status < 0) {
+   dev_err(slave->bus->dev,
+   "SDW_DPN_INT read failed:%d", status);
+
+   return status;
+   }
+
+   do {
+
+   if (status & SDW_DPN_INT_TEST_FAIL) {
+   dev_err(&slave->dev, "Test fail for port:%d", port);
+   clear |= SDW_DPN_INT_TEST_FAIL;
+   }
+
+   /*
+* Assumption: PORT_READY interrupt will be received only
+* for ports implementing CP_SM.
+*/
+   if (status & SDW_DPN_INT_PORT_READY) {
+   complete(&slave->port_ready[port]);
+   clear |= SDW_DPN_INT_PORT_READY;
+   }
+
+   impl_int_mask = SDW_DPN_INT_IMPDEF1 |
+   SDW_DPN_INT_IMPDEF2 | SDW_DPN_INT_IMPDEF3;
+
+
+   if (status & impl_int_mask) {
+   clear |= impl_int_mask;
+   *slave_status = clear;
+   }
+
+   /* clear the interrupt */
+   ret = sdw_write(slave, addr, clear);
+   if (ret < 0) {
+   dev_err(slave->bus->dev,
+   "SDW_DPN_INT write failed:%d", ret);
+   return ret;
+   }
+
+   /* Read DPN interrupt again */
+   status = sdw_read(slave, addr);
+   if (status < 0) {
+   dev_err(slave->bus->dev,
+   "SDW_DPN_INT