Re: [PATCH] efi: make const array 'apple' static

[Ard Biesheuvel]

On 2 March 2018 at 14:35, Colin King  wrote:
> From: Colin Ian King 
>
> Don't populate the const read-only array 'buf' on the stack but instead
> make it static. Makes the object code smaller by 64 bytes:
>
> Before:
>textdata bss dec hex filename
>9264   1  1692812441 arch/x86/boot/compressed/eboot.o
>
> After:
>textdata bss dec hex filename
>9200   1  1692172401 arch/x86/boot/compressed/eboot.o
>
> (gcc version 7.2.0 x86_64)
>
> Signed-off-by: Colin Ian King 

Thanks Colin

Queued in efi-next.


> ---
>  arch/x86/boot/compressed/eboot.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index 886a9115af62..f2251c1c9853 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -423,7 +423,7 @@ static void retrieve_apple_device_properties(struct 
> boot_params *boot_params)
>
>  static void setup_quirks(struct boot_params *boot_params)
>  {
> -   efi_char16_t const apple[] = { 'A', 'p', 'p', 'l', 'e', 0 };
> +   static efi_char16_t const apple[] = { 'A', 'p', 'p', 'l', 'e', 0 };
> efi_char16_t *fw_vendor = (efi_char16_t *)(unsigned long)
> efi_table_attr(efi_system_table, fw_vendor, sys_table);
>
> --
> 2.15.1
>

Re: [PATCH v4 4/6] vfio/type1: check dma map request is within a valid iova range

[Alex Williamson]

On Fri, 2 Mar 2018 13:19:58 +
Shameerali Kolothum Thodi  wrote:

> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, February 28, 2018 3:24 PM
> > To: Auger Eric 
> > Cc: Shameerali Kolothum Thodi ;
> > pmo...@linux.vnet.ibm.com; k...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Linuxarm ; John Garry
> > ; xuwei (O) ; Robin Murphy
> > 
> > Subject: Re: [PATCH v4 4/6] vfio/type1: check dma map request is within a 
> > valid
> > iova range
> > 
> > On Wed, 28 Feb 2018 12:53:27 +0100
> > Auger Eric  wrote:
> >   
> > > Hi Shameer,
> > >
> > > On 28/02/18 10:25, Shameerali Kolothum Thodi wrote:  
> > > >
> > > >  
> > > >> -Original Message-
> > > >> From: Auger Eric [mailto:eric.au...@redhat.com]
> > > >> Sent: Wednesday, February 28, 2018 9:02 AM
> > > >> To: Shameerali Kolothum Thodi  
> > ;  
> > > >> Alex Williamson 
> > > >> Cc: pmo...@linux.vnet.ibm.com; k...@vger.kernel.org; linux-
> > > >> ker...@vger.kernel.org; Linuxarm ; John Garry
> > > >> ; xuwei (O) ; Robin  
> > Murphy  
> > > >> 
> > > >> Subject: Re: [PATCH v4 4/6] vfio/type1: check dma map request is 
> > > >> within a  
> > valid  
> > > >> iova range
> > > >>
> > > >> Hi Shameer,
> > > >>
> > > >> On 27/02/18 10:57, Shameerali Kolothum Thodi wrote:  
> > > >>>
> > > >>>  
> > >  -Original Message-
> > >  From: Auger Eric [mailto:eric.au...@redhat.com]
> > >  Sent: Tuesday, February 27, 2018 8:27 AM
> > >  To: Alex Williamson 
> > >  Cc: Shameerali Kolothum Thodi  
> > ;  
> > >  pmo...@linux.vnet.ibm.com; k...@vger.kernel.org; linux-
> > >  ker...@vger.kernel.org; Linuxarm ; John  
> > Garry  
> > >  ; xuwei (O) ; Robin  
> > > >> Murphy  
> > >  
> > >  Subject: Re: [PATCH v4 4/6] vfio/type1: check dma map request is 
> > >  within  
> > a  
> > > >> valid  
> > >  iova range
> > > 
> > >  Hi,
> > >  On 27/02/18 00:13, Alex Williamson wrote:  
> > > > On Mon, 26 Feb 2018 23:05:43 +0100
> > > > Auger Eric  wrote:
> > > >  
> > > >> Hi Shameer,
> > > >>
> > > >> [Adding Robin in CC]
> > > >> On 21/02/18 13:22, Shameer Kolothum wrote:  
> > > >>> This checks and rejects any dma map request outside valid iova
> > > >>> range.
> > > >>>
> > > >>> Signed-off-by: Shameer Kolothum  
> > >    
> > > >>> ---
> > > >>>  drivers/vfio/vfio_iommu_type1.c | 22 ++
> > > >>>  1 file changed, 22 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/vfio/vfio_iommu_type1.c  
> > >  b/drivers/vfio/vfio_iommu_type1.c  
> > > >>> index a80884e..3049393 100644
> > > >>> --- a/drivers/vfio/vfio_iommu_type1.c
> > > >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> > > >>> @@ -970,6 +970,23 @@ static int vfio_pin_map_dma(struct  
> > vfio_iommu  
> > >  *iommu, struct vfio_dma *dma,  
> > > >>>   return ret;
> > > >>>  }
> > > >>>
> > > >>> +/*
> > > >>> + * Check dma map request is within a valid iova range
> > > >>> + */
> > > >>> +static bool vfio_iommu_iova_dma_valid(struct vfio_iommu  
> > *iommu,  
> > > >>> + dma_addr_t start, dma_addr_t end)
> > > >>> +{
> > > >>> + struct list_head *iova = >iova_list;
> > > >>> + struct vfio_iova *node;
> > > >>> +
> > > >>> + list_for_each_entry(node, iova, list) {
> > > >>> + if ((start >= node->start) && (end <= node->end))
> > > >>> + return true;  
> > > >> I am now confused by the fact this change will prevent existing 
> > > >> QEMU
> > > >> from working with this series on some platforms. For instance QEMU 
> > > >>  
> > virt  
> > > >> machine GPA space collides with Seattle PCI host bridge windows. 
> > > >> On  
> > > >> ARM  
> > > >> the smmu and smmuv3 drivers report the PCI host bridge windows as
> > > >> reserved regions which does not seem to be the case on other  
> > platforms.  
> > > >> The change happened in commit  
> > >  273df9635385b2156851c7ee49f40658d7bcb29d  
> > > >> (iommu/dma: Make PCI window reservation generic).
> > > >>
> > > >> For background, we already discussed the topic after LPC 2016. See
> > > >> https://www.spinics.net/lists/kernel/msg2379607.html.
> > > >>
> > > >> So is it the right choice to 

Re: [PATCH 05/10] ARM64: dts: hi6220: Remove "cooling-{min|max}-level" for CPU nodes

[Wei Xu]

Hi Viresh,

On 2018/2/9 8:58, Viresh Kumar wrote:
> The "cooling-min-level" and "cooling-max-level" properties are not
> parsed by any part of the kernel currently and the max cooling state of
> a CPU cooling device is found by referring to the cpufreq table instead.
> 
> Moreover, the entries are incorrect here as min level is 4 and the max
> level is 0.
> 
> Remove the unused properties from the CPU nodes.
> 
> Signed-off-by: Viresh Kumar 
> ---

Applied into hisilicon dt tree.
Thanks!

BR,
Wei

>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 6a180d1926e8..fca8e4ee98e7 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -88,8 +88,6 @@
>   next-level-cache = <_L2>;
>   clocks = <_clock 0>;
>   operating-points-v2 = <_opp_table>;
> - cooling-min-level = <4>;
> - cooling-max-level = <0>;
>   #cooling-cells = <2>; /* min followed by max */
>   cpu-idle-states = <_SLEEP _SLEEP>;
>   dynamic-power-coefficient = <311>;
> 

Re: [PATCH RESEND] arm64: dts: hi6220: enable watchdog

[Wei Xu]

Hi Leo, Dmitry,

On 2018/3/1 12:18, Leo Yan wrote:
> From: Dmitry Shmidt 
> 
> This patch is to add watchdog binding for Hi6220 on Hikey board.
> 
> Signed-off-by: Dmitry Shmidt 
> ---

Applied into hisilicon dt tree.
Thanks!

BR,
Wei

>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 6a180d1..e9d5bb6 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -817,6 +817,14 @@
>   pinctrl-1 = <_pmx_idle _clk_cfg_idle 
> _cfg_idle>;
>   };
>  
> + watchdog0: watchdog@f8005000 {
> + compatible = "arm,sp805-wdt", "arm,primecell";
> + reg = <0x0 0xf8005000 0x0 0x1000>;
> + interrupts = ;
> + clocks = <_ctrl HI6220_WDT0_PCLK>;
> + clock-names = "apb_pclk";
> + };
> +
>   tsensor: tsensor@0,f7030700 {
>   compatible = "hisilicon,tsensor";
>   reg = <0x0 0xf7030700 0x0 0x1000>;
> 

Re: [PATCH v2 00/11] perf events patches for improved ARM64 support

[William Cohen]

On 03/02/2018 03:24 AM, John Garry wrote:
> On 27/02/2018 09:50, Jiri Olsa wrote:
>> On Sat, Feb 24, 2018 at 12:05:21AM +0800, John Garry wrote:
>>> This patchset adds support for some perf events features,
>>> targeted at ARM64, implemented in a generic fashion.
>>>
>>> The two main features are as follows:
>>> - support for arch/vendor/platform pmu events directory structure
>>>    - to support this, topic subdirectory support needs to be dropped
>>> - support for parsing standard architecture pmu events
>>>
>>> On the back of these, the Cavium ThunderX2, ARM Cortex-A53,
>>> and HiSilicon hip08 JSONs are relocated/added/updated.
>>>
>>> In addition, there is a patch to drop mutli-mapfile.csv support and
>>> also a bugfix in jevents.c for an error code value.
>>>
>>> Differences to v1:
>>> - Address coding issues from Jiri Olsa in adding arch std event
>>>    support (https://lkml.org/lkml/2018/2/6/501)
>>> - add patch to drop topic subdirectory support
>>> - add patch for bug fix in json_events()
>>> - add review tags from Jiri Olsa
>>
>> can't tell if those json file changes are ok, but for all the code changes:
>>
> 
> Hi William, Ganapatrao,
> 
> Can you check the modifications to the ARM64 JSONs you originally submitted 
> in the patchset please?> 
> If they are not checked, I'll have to see if the maintainers will accept 
> without your review. If not, I'll have to drop them.

Hi John,

I will take a look at the patches this weekend and give feedback beginning of 
next week. -Will

> 
> Thanks,
> John
> 
>> Acked-by: Jiri Olsa 
>>
>> thanks,
>> jirka
>>
>> .
>>
> 
> 

Het Microsoft-accountteam.

[Αφροδίτη Αμβροσίου]

MICROSOFT WEBMASTERS UPDATE


Uw twee inkomende e-mails zijn in afwachting van de status geplaatst vanwege de 
recente upgrade in onze database,

Om de berichten vriendelijk te ontvangen, klikt u op: 
UPDATE om u in staat te stellen de 
teams te verifiëren
.
Bedankt voor je medewerking.
Het Microsoft-accountteam.
Webmail (c) 2018.

Re: [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable

[Robin Murphy]

On 02/03/18 14:55, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 

Many of the rpmsg clients like audio drivers need to allocate
dma memory. Make this bus DMA capable so that the child devices
can use dma apis.


AFAICS after 15 minutes in the docs and code, the rpmsg "bus" is a 
virtual one based around shared-memory mailbox communication, so I don't 
really see how DMA exists in that context - I think maybe that 
abstraction needs looking at.


However, from grepping through the DTs it seems at first glance like the 
non-trivial things under the "qcom,smd" bus mostly map to actual 
platform devices via the "qcom,smd-edge" property - if those platform 
devices are the physical DMA masters, they should be the ones used for 
DMA API operations.



Signed-off-by: Srinivas Kandagatla 
---
  drivers/rpmsg/rpmsg_core.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index e84c71f8d6ab..540a3f3567b8 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = {
.uevent = rpmsg_uevent,
.probe  = rpmsg_dev_probe,
.remove = rpmsg_dev_remove,
+   .force_dma  = true,


Regardless of the above, would you really need to use this brute force 
hack instead of just fixing the DTs? I'm struggling to find which 
drivers might currently be relying on this :/


Robin.


  };
  EXPORT_SYMBOL(rpmsg_bus);
  

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

[Kani, Toshi]

On Fri, 2018-03-02 at 09:34 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-01 at 14:31 -0800, Linus Torvalds wrote:
> > On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt  
> > wrote:
> > > 
> > > Could be that x86 has the smarts to do the right thing, still trying to
> > > untangle the code :-)
> > 
> > Afaik, x86 will not cache PCI unless the system is misconfigured, and
> > even then it's more likely to just raise a machine check exception
> > than cache things.
> > 
> > The last-level cache is going to do fills and spills directly to the
> > memory controller, not to the PCIe side of things.
> > 
> > (I guess you *can* do things differently, and I wouldn't be surprised
> > if some people inside Intel did try to do things differently with
> > trying nvram over PCIe, but in general I think the above is true)
> > 
> > You won't find it in the kernel code either. It's in hardware with
> > firmware configuration of what addresses are mapped to the memory
> > controllers (and _how_ they are mapped) and which are not.
> 
> Ah thanks ! Thanks explains. We can fix that on ppc64 in our linear
> mapping code by checking the address vs. memblocks to chose the right
> page table attributes.

FWIW, this thing is called MTRRs on x86, which are initialized by BIOS.
These registers effectively overwrite page table setups.  Intel SDM
defines the effect as follows.  'PAT Entry Value' is the page table
setup.

MTRR Memory Type  PAT Entry Value  Effective Memory Type

UCUC   UC
UCWC   WC
UCWT   UC
UCWB   UC
UCWP   UC 

On my system, BIOS sets MTRRs to cover the entire MMIO ranges with UC.
Other BIOSes may simply set the MTRR default type to UC, i.e. uncovered
ranges become UC.

# cat /proc/mtrr
 :
reg01: base=0xc00 (12582912MB), size=2097152MB, count=1:
uncachable
 :

# cat /proc/iomem | grep 'PCI Bus'
 :
c00-c3f : PCI Bus :00
c40-c7f : PCI Bus :11
c80-cbf : PCI Bus :36
cc0-cff : PCI Bus :5b
d00-d3f : PCI Bus :80
d40-d7f : PCI Bus :85
d80-dbf : PCI Bus :ae
dc0-dff : PCI Bus :d7

-Toshi

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

[Mark Rutland]

On Fri, Mar 02, 2018 at 03:32:22PM +, Russell King - ARM Linux wrote:
> How do we break this status quo and finally solve the IRQ 0 and
> NO_IRQ issue?

> Another possibility would be to change platform_get_irq() and
> suffer the regressions that will cause, telling people that fixing
> their platform IRQ numbering is the only solution (but this
> requires breaking our ideals about regressions.)

How about we start with a warning? That'll be visible, but shouldn't
result in broken systems while we wait for people to fix things up.

e.g. something like the below.

Mark.

>8
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f1bf7b38d91c..bd42eeffd2aa 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -126,7 +126,12 @@ int platform_get_irq(struct platform_device *dev, unsigned 
int num)
irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS);
}
 
-   return r ? r->start : -ENXIO;
+   if (!r)
+   return -ENXIO;
+
+   WARN_ONCE(!r->start, "Platform uses zero as a valid IRQ.");
+
+   return r->start;
 #endif
 }
 EXPORT_SYMBOL_GPL(platform_get_irq);

Re: [PATCH v2 00/11] perf events patches for improved ARM64 support

[Ganapatrao Kulkarni]

Hi John,

On Fri, Mar 2, 2018 at 9:35 PM, William Cohen  wrote:
> On 03/02/2018 03:24 AM, John Garry wrote:
>> On 27/02/2018 09:50, Jiri Olsa wrote:
>>> On Sat, Feb 24, 2018 at 12:05:21AM +0800, John Garry wrote:
 This patchset adds support for some perf events features,
 targeted at ARM64, implemented in a generic fashion.

 The two main features are as follows:
 - support for arch/vendor/platform pmu events directory structure
- to support this, topic subdirectory support needs to be dropped
 - support for parsing standard architecture pmu events

 On the back of these, the Cavium ThunderX2, ARM Cortex-A53,
 and HiSilicon hip08 JSONs are relocated/added/updated.

 In addition, there is a patch to drop mutli-mapfile.csv support and
 also a bugfix in jevents.c for an error code value.

 Differences to v1:
 - Address coding issues from Jiri Olsa in adding arch std event
support (https://lkml.org/lkml/2018/2/6/501)
 - add patch to drop topic subdirectory support
 - add patch for bug fix in json_events()
 - add review tags from Jiri Olsa
>>>
>>> can't tell if those json file changes are ok, but for all the code changes:
>>>
>>
>> Hi William, Ganapatrao,
>>
>> Can you check the modifications to the ARM64 JSONs you originally submitted 
>> in the patchset please?>
>> If they are not checked, I'll have to see if the maintainers will accept 
>> without your review. If not, I'll have to drop them.

I am seeing issue(log below) with this patchset on our platfrom.
i have tried using your v2 branch [1]

root@borg-1>perf_acme>> ./perf --version
perf version 4.16.rc1.g087f7ca
root@borg-1>perf_acme>> ./perf stat -e bus_access_rd sleep 1

 Performance counter stats for 'sleep 1':

23,099  bus_access_rd

   1.000708516 seconds time elapsed

root@borg-1>perf_acme>> cd -
/ganapat/perf/linux-hisi/tools/perf
root@borg-1>perf>> ./perf --version
perf version 4.16.rc1.gcb5a74
root@borg-1>perf>> ./perf stat -e bus_access_rd sleep 1

 Performance counter stats for 'sleep 1':

 0  bus_access_rd

   1.000709162 seconds time elapsed

root@borg-1>perf>>


[1] https://github.com/hisilicon/linux-hisi.git

>
> Hi John,
>
> I will take a look at the patches this weekend and give feedback beginning of 
> next week. -Will
>
>>
>> Thanks,
>> John
>>
>>> Acked-by: Jiri Olsa 
>>>
>>> thanks,
>>> jirka
>>>
>>> .

thanks
Ganapat
>>>
>>
>>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/5] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112

[Jacopo Mondi]

Hello,
   now that CEU has been picked up for inclusion in v4.17, we can start moving
users of old sh_mobile_ceu_camera driver to use the newly introduced one.

Migo-R has been first, now it's SH7724 ECOVEC board turn.

ECOVEC has a camera board with two MT9T112 image sensor and one TW9910 video
decoder input. This series moves the mt9t112 driver away from soc_camera
framework and remove dependencies on it in mach-ecovec board code.

As per Migo-R, memory for CEU is reserved using memblocks APIs and declared
as DMA-capable in board code, power up/down routines have been removed from
board code, and GPIOs lookup table registered for sensor drivers.

As in the previous series, still no code has been removed or changed in
drivers/media/i2c/soc_camera/ until we do not remove all dependencies on it
in all board files.

Hans, since you asked me to add frame rate interval support for ov772x I expect
to receive the same request for mt9t112. Unfortunately I do not have access to
register level documentation, nor can perform any testing as I don't have the
camera modules. For the same reason I cannot run any v4l2-compliance test on
that driver, but just make sure the ECOVEC boots cleanly with the new board
file. I'm in favour of moving the driver to staging if you think that's the 
case.

Series based on media-tree master, and as per Migo-R I would ask SH arch/
changes to go through media tree as SH maintainers are un-responsive.

Thanks
  j

Jacopo Mondi (5):
  media: i2c: Copy mt9t112 soc_camera sensor driver
  media: i2c: mt9t112: Remove soc_camera dependencies
  media: i2c: mt9t112: Fix code style issues
  arch: sh: ecovec: Use new renesas-ceu camera driver
  media: MAINTAINERS: Add entry for Aptina MT9T112

 MAINTAINERS|7 +
 arch/sh/boards/mach-ecovec24/setup.c   |  338 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c |4 +-
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/mt9t112.c| 1136 
 include/media/i2c/mt9t112.h|   17 +-
 7 files changed, 1333 insertions(+), 181 deletions(-)
 create mode 100644 drivers/media/i2c/mt9t112.c

--
2.7.4

Re: [PATCH 0/4] cleanups and new HW rev support

[Herbert Xu]

On Mon, Feb 19, 2018 at 02:51:20PM +, Gilad Ben-Yossef wrote:
> This patch set introduces backward compatible support for the older
> CryptoCell hardware revision 710 and 630 along some minor code
> cleanups.
> 
> Gilad Ben-Yossef (4):
>   crypto: ccree: remove unused definitions
>   dt-bindings: Add DT bindings for ccree 710 and 630p
>   crypto: ccree: add support for older HW revs
>   crypto: ccree: replace memset+kfree with kzfree
> 
>  .../devicetree/bindings/crypto/arm-cryptocell.txt  |   3 +-
>  drivers/crypto/Kconfig |   6 +-
>  drivers/crypto/ccree/cc_aead.c |  34 +++--
>  drivers/crypto/ccree/cc_cipher.c   |  25 +++-
>  drivers/crypto/ccree/cc_crypto_ctx.h   |  36 -
>  drivers/crypto/ccree/cc_driver.c   |  68 --
>  drivers/crypto/ccree/cc_driver.h   |  23 +++-
>  drivers/crypto/ccree/cc_fips.c |  13 +-
>  drivers/crypto/ccree/cc_hash.c | 149 
> +++--
>  drivers/crypto/ccree/cc_hash.h |  12 +-
>  drivers/crypto/ccree/cc_host_regs.h|   3 +
>  drivers/crypto/ccree/cc_hw_queue_defs.h|   2 +-
>  drivers/crypto/ccree/cc_kernel_regs.h  |   1 +
>  drivers/crypto/ccree/cc_request_mgr.c  |   9 +-
>  drivers/crypto/ccree/cc_sram_mgr.c |  14 ++
>  15 files changed, 240 insertions(+), 158 deletions(-)

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

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

[Pavel Machek]

On Fri 2018-03-02 08:22:52, Andrew F. Davis wrote:
> On 03/02/2018 05:10 AM, Pavel Machek wrote:
> > Hi!
> > 
> >>> If this is taking longer to fix, should c85823390215 be reverted in
> >>> the meantime? It does not seem particulary important/urgent...
> >>
> >> No patience between the v4.16 release candidates eh ;)
> >>
> >> commit 6662ae6af82df10259a70c7569b4c12ea7f3ba93
> >> ("gpiolib: Keep returning EPROBE_DEFER when we should")
> >>
> >> and
> >>
> >> commit ce27fb2c56db6ccfe8099343bb4afdab15e77e7b
> >> ("gpio: Handle deferred probing in of_find_gpio() properly")
> >>
> >> that are both in Torvalds' tree since yesterday should be fixing
> >> this, I think? Did you try just using the upstream HEAD?
> > 
> > Ok, so this code looks pretty crazy to me: I tried removing the
> > "of_find_spi_gpio" part, and audio started working.
> > 
> > What is going on with the ()s around == s? You made me look up C
> > operator precedence.
> > 
> > Hmm, and it is also wrong, right? It turns any error code into ENOENT,
> > as it tries to do the "special handling".
> > 
> >  *  
> > 
> >  * This means we don't need to look any further for 
> > 
> >  * alternate name conventions, and we should really 
> > 
> >  * preserve the return code for our user to be able to  
> > 
> >  * retry probing later. 
> > 
> >  */
> > if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
> > return desc;
> > 
> > if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
> > break;
> > }
> > 
> > /* Special handling for SPI GPIOs if used */
> > if (IS_ERR(desc))
> > desc = of_find_spi_gpio(dev, con_id, _flags);
> > 
> > /* Special handling for regulator GPIOs if used */
> > if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER)
> > desc = of_find_regulator_gpio(dev, con_id, _flags);
> > 
> > Something like this?
> > 
> > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> > index 84e5a9d..f0fab26 100644
> > --- a/drivers/gpio/gpiolib-of.c
> > +++ b/drivers/gpio/gpiolib-of.c
> > @@ -241,29 +241,17 @@ struct gpio_desc *of_find_gpio(struct device *dev, 
> > const char *con_id,
> >  
> > desc = of_get_named_gpiod_flags(dev->of_node, prop_name, idx,
> > _flags);
> > -   /*
> > -* -EPROBE_DEFER in our case means that we found a
> > -* valid GPIO property, but no controller has been
> > -* registered so far.
> > -*
> > -* This means we don't need to look any further for
> > -* alternate name conventions, and we should really
> > -* preserve the return code for our user to be able to
> > -* retry probing later.
> > -*/
> > -   if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
> > -   return desc;
> >  
> > -   if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
> > +   if (!IS_ERR(desc) || PTR_ERR(desc) != -ENOENT)
> 
> 
> I rather like the () so one doesn't always have to look up C operator
> precedence to verify..

Well, Ok, but then the ()s should be at the other ifs nearby, too. See?

> 
> > break;
> > }
> >  
> > /* Special handling for SPI GPIOs if used */
> > -   if (IS_ERR(desc))
> > +   if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT)
> > desc = of_find_spi_gpio(dev, con_id, _flags);
> >  
> > /* Special handling for regulator GPIOs if used */
> > -   if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER)
> > +   if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT)
> > desc = of_find_regulator_gpio(dev, con_id, _flags);
> >  
> > if (IS_ERR(desc))
> >
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 2/2] auxdisplay: make PANEL a menuconfig

[Miguel Ojeda]

On Thu, Mar 1, 2018 at 3:33 AM, Randy Dunlap  wrote:
> From: Randy Dunlap 
>
> This change makes xconfig present the PANEL drivers immediately
> following the AUXDISPLAY drivers instead of under the major menu
> item "Device Drivers". It also unclutters the Device Drivers menu in
> nconfig and menuconfig by moving the PANEL drivers to a sub-menu.
>
> Signed-off-by: Randy Dunlap 
> Cc: Miguel Ojeda Sandonis 
> Acked-by: Geert Uytterhoeven 
> Reviewed-by: Andy Shevchenko 

Picking it up.

Cheers,
Miguel

> ---
>  drivers/auxdisplay/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20180228.orig/drivers/auxdisplay/Kconfig
> +++ linux-next-20180228/drivers/auxdisplay/Kconfig
> @@ -166,7 +166,7 @@ config ARM_CHARLCD
>
>  endif # AUXDISPLAY
>
> -config PANEL
> +menuconfig PANEL
> tristate "Parallel port LCD/Keypad Panel support"
> depends on PARPORT
> select CHARLCD
>
>

Re: [PATCH v2 2/2] ARM: ftrace: Add MODULE_PLTS support

[Steven Rostedt]

On Thu,  1 Mar 2018 17:43:43 +0100
Alexander Sverdlin  wrote:

> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index 9e842ff..3e663f9 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -19,6 +19,7 @@ struct dyn_arch_ftrace {
>  #ifdef CONFIG_OLD_MCOUNT
>   boolold_mcount;
>  #endif

I think you want to add:

#ifdef CONFIG_ARM_MODULE_PLTS
> + struct module *mod;
#endif

This will add more memory overhead, and we don't want to add that if it
is not needed.

-- Steve

Re: [PATCH] selftests: memory-hotplug: fix emit_tests regression

[Shuah Khan]

On 03/02/2018 01:31 AM, Anders Roxell wrote:
> On 1 March 2018 at 21:16, Shuah Khan  wrote:
>> Commit 16c513b13477
>> ("selftests: memory-hotplug: silence test command echo")
>>
>> introduced regression in emit_tests and results in the following
>> failure when selftests are installed and run. Fix it.
>>
>> Running tests in memory-hotplug
>> 
>> ./run_kselftest.sh: line 121: @./mem-on-off-test.sh: No such file or
>> directory
>> selftests: memory-hotplug [FAIL]
>>
>> Fixes: 16c513b13477 (selftests: memory-hotplug: silence test command echo")
>> Reported-by: Naresh Kamboju 
>> Signed-off-by: Shuah Khan 
> 
> Tested-by: Anders Roxell 
> 

Thanks for testing. It is now in linux-kselftest fixes for the next
4.16-rc

thanks,
-- Shuah

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

[Andrew F. Davis]

On 03/02/2018 11:08 AM, Russell King - ARM Linux wrote:
> On Fri, Mar 02, 2018 at 08:22:52AM -0600, Andrew F. Davis wrote:
>>> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
>>> index 84e5a9d..f0fab26 100644
>>> --- a/drivers/gpio/gpiolib-of.c
>>> +++ b/drivers/gpio/gpiolib-of.c
>>> @@ -241,29 +241,17 @@ struct gpio_desc *of_find_gpio(struct device *dev, 
>>> const char *con_id,
>>>  
>>> desc = of_get_named_gpiod_flags(dev->of_node, prop_name, idx,
>>> _flags);
>>> -   /*
>>> -* -EPROBE_DEFER in our case means that we found a
>>> -* valid GPIO property, but no controller has been
>>> -* registered so far.
>>> -*
>>> -* This means we don't need to look any further for
>>> -* alternate name conventions, and we should really
>>> -* preserve the return code for our user to be able to
>>> -* retry probing later.
>>> -*/
>>> -   if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
>>> -   return desc;
>>>  
>>> -   if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
>>> +   if (!IS_ERR(desc) || PTR_ERR(desc) != -ENOENT)
>>
>>
>> I rather like the () so one doesn't always have to look up C operator
>> precedence to verify..
> 
> Too many make it impossible to see which close paren ties up with
> which open paren.  I've spent way too long in the past reformatting
> code, where people think that () are a good thing, to work out what
> the comparison is actually doing before then rewriting the damn
> thing with less () and in a much clearer way.  I'm now convinced
> that unnecessary () are a very bad thing as they severely harm
> readability as test complexity increases.
> 


Fair enough, I personally prefer always having a new line per condition
when doing chained conditionals:

if (something &&
this == that &&
!not_this)


>>
>>
>>> break;
>>> }
>>>  
>>> /* Special handling for SPI GPIOs if used */
>>> -   if (IS_ERR(desc))
>>> +   if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT)
> 
> These can be simplified to:
> 
>   if (desc == ERR_PTR(-ENOENT))
> 
> since error pointers are unique - ERR_PTR(-ENOENT) is what was
> returned as an error-pointer, and if IS_ERR(ERR_PTR(-ENOMENT)) etc
> were false, we'd have big problems as it'd mean we couldn't detect
> error pointers!
> 
> As an added bonus, they don't involve any operator precedence
> questions either.
> 

Looks like your suggestion clears up this one anyway.

[GIT PULL] xen: fixes for v4.16-rc4

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.16a-rc4-tag

xen: fixes for v4.16-rc4

It contains 5 minor fixes for Xen-specific drivers.


Thanks.

Juergen

 arch/x86/xen/enlighten_pv.c  |  6 --
 drivers/net/xen-netfront.c   |  7 ++-
 drivers/xen/events/events_base.c |  4 ++--
 drivers/xen/pvcalls-back.c   |  2 +-
 drivers/xen/pvcalls-front.c  | 11 ---
 5 files changed, 21 insertions(+), 9 deletions(-)

Colin Ian King (1):
  xen/pvcalls: fix null pointer dereference on map->sock

Jason Andryuk (1):
  xen-netfront: Fix hang on device removal

Juergen Gross (2):
  x86/xen: add tty0 and hvc0 as preferred consoles for dom0

Roger Pau Monne (1):
  xen/pirq: fix error path cleanup when binding MSIs

Stefano Stabellini (1):
  pvcalls-front: 64-bit align flags

Re: [PATCH v5 08/12] xfs, dax: replace IS_DAX() with IS_FSDAX()

[Darrick J. Wong]

On Thu, Mar 01, 2018 at 07:54:16PM -0800, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
> 
> Cc: "Darrick J. Wong" 
> Cc: linux-...@vger.kernel.org
> Cc: Matthew Wilcox 
> Cc: Ross Zwisler 
> Cc: 
> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
> Reviewed-by: Jan Kara 
> Signed-off-by: Dan Williams 

Looks ok,
Reviewed-by: Darrick J. Wong 

--D

> ---
>  fs/xfs/xfs_file.c|   14 +++---
>  fs/xfs/xfs_ioctl.c   |4 ++--
>  fs/xfs/xfs_iomap.c   |6 +++---
>  fs/xfs/xfs_reflink.c |2 +-
>  4 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 9ea08326f876..46a098b90fd0 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -288,7 +288,7 @@ xfs_file_read_iter(
>   if (XFS_FORCED_SHUTDOWN(mp))
>   return -EIO;
>  
> - if (IS_DAX(inode))
> + if (IS_FSDAX(inode))
>   ret = xfs_file_dax_read(iocb, to);
>   else if (iocb->ki_flags & IOCB_DIRECT)
>   ret = xfs_file_dio_aio_read(iocb, to);
> @@ -726,7 +726,7 @@ xfs_file_write_iter(
>   if (XFS_FORCED_SHUTDOWN(ip->i_mount))
>   return -EIO;
>  
> - if (IS_DAX(inode))
> + if (IS_FSDAX(inode))
>   ret = xfs_file_dax_write(iocb, from);
>   else if (iocb->ki_flags & IOCB_DIRECT) {
>   /*
> @@ -1045,7 +1045,7 @@ __xfs_filemap_fault(
>   }
>  
>   xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
> - if (IS_DAX(inode)) {
> + if (IS_FSDAX(inode)) {
>   pfn_t pfn;
>  
>   ret = dax_iomap_fault(vmf, pe_size, , NULL, _iomap_ops);
> @@ -1070,7 +1070,7 @@ xfs_filemap_fault(
>  {
>   /* DAX can shortcut the normal fault path on write faults! */
>   return __xfs_filemap_fault(vmf, PE_SIZE_PTE,
> - IS_DAX(file_inode(vmf->vma->vm_file)) &&
> + IS_FSDAX(file_inode(vmf->vma->vm_file)) &&
>   (vmf->flags & FAULT_FLAG_WRITE));
>  }
>  
> @@ -1079,7 +1079,7 @@ xfs_filemap_huge_fault(
>   struct vm_fault *vmf,
>   enum page_entry_sizepe_size)
>  {
> - if (!IS_DAX(file_inode(vmf->vma->vm_file)))
> + if (!IS_FSDAX(file_inode(vmf->vma->vm_file)))
>   return VM_FAULT_FALLBACK;
>  
>   /* DAX can shortcut the normal fault path on write faults! */
> @@ -1124,12 +1124,12 @@ xfs_file_mmap(
>* We don't support synchronous mappings for non-DAX files. At least
>* until someone comes with a sensible use case.
>*/
> - if (!IS_DAX(file_inode(filp)) && (vma->vm_flags & VM_SYNC))
> + if (!IS_FSDAX(file_inode(filp)) && (vma->vm_flags & VM_SYNC))
>   return -EOPNOTSUPP;
>  
>   file_accessed(filp);
>   vma->vm_ops = _file_vm_ops;
> - if (IS_DAX(file_inode(filp)))
> + if (IS_FSDAX(file_inode(filp)))
>   vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE;
>   return 0;
>  }
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 89fb1eb80aae..234279ff66ce 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -1108,9 +1108,9 @@ xfs_ioctl_setattr_dax_invalidate(
>   }
>  
>   /* If the DAX state is not changing, we have nothing to do here. */
> - if ((fa->fsx_xflags & FS_XFLAG_DAX) && IS_DAX(inode))
> + if ((fa->fsx_xflags & FS_XFLAG_DAX) && IS_FSDAX(inode))
>   return 0;
> - if (!(fa->fsx_xflags & FS_XFLAG_DAX) && !IS_DAX(inode))
> + if (!(fa->fsx_xflags & FS_XFLAG_DAX) && !IS_FSDAX(inode))
>   return 0;
>  
>   /* lock, flush and invalidate mapping in preparation for flag change */
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 66e1edbfb2b2..cf794d429aec 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -241,7 +241,7 @@ xfs_iomap_write_direct(
>* the reserve block pool for bmbt block allocation if there is no space
>* left but we need to do unwritten extent conversion.
>*/
> - if (IS_DAX(VFS_I(ip))) {
> + if (IS_FSDAX(VFS_I(ip))) {
>   bmapi_flags = XFS_BMAPI_CONVERT | XFS_BMAPI_ZERO;
>   if (imap->br_state == XFS_EXT_UNWRITTEN) {
>   tflags |= XFS_TRANS_RESERVE;
> @@ -952,7 +952,7 @@ static inline bool imap_needs_alloc(struct inode *inode,
>   return !nimaps ||
>   imap->br_startblock == HOLESTARTBLOCK ||
>   imap->br_startblock == DELAYSTARTBLOCK ||
> - (IS_DAX(inode) && imap->br_state == XFS_EXT_UNWRITTEN);
> + (IS_FSDAX(inode) && imap->br_state == XFS_EXT_UNWRITTEN);
>  }
>  
>  static inline bool need_excl_ilock(struct 

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

[Alex Williamson]

On Fri, 2 Mar 2018 06:54:17 +
"Tian, Kevin"  wrote:

> > From: Alex Williamson
> > Sent: Friday, March 2, 2018 4:22 AM  
> > >
> > > I am pretty sure that you are describing is true of some, but not for
> > > all. I think the Amazon solutions and the virtio solution are doing
> > > hard partitioning of the part. I will leave it to those guys to speak
> > > for themselves since I don't know anything about the hardware design
> > > of those parts.  
> > 
> > I think we'd need device specific knowledge and enablement to be able
> > to take advantage of any hardware partitioning, otherwise we need to
> > assume the pf is privileged, as implemented in other sriov devices.
> > 
> > I'm also trying to imagine whether there's a solution via the new
> > vfio/mdev interface, where the mdev vendor driver would bind to the pf
> > and effectively present itself as the mdev device.  The vendor driver
> > could provide sriov capabilities and bear the burden of ensuring that
> > the pf is used cooperatively.  The only existing mdev vendor drivers are
> > vGPUs and rely on on-device DMA translation and isolation, such as
> > through GTTs, but there have been some thoughts on providing IOMMU
> > based
> > isolation of mdev/sriov mixed devices (assuming DMA is even required
> > for userspace management of the pf in this use case).  [Cc Kirti]
> > Thanks,
> >   
> 
> Hope not distracting this thread, but above sounds like an interesting
> idea. Actually we ever brainstormed similar thought for another 
> potential usage - supporting VF live migration. We are already working
> on an generic extension to allow state save/restore of mdev instance.
> If vendor driver could further wrap pf as a mdev instance, it could 
> leverage the same framework for a clean state migration on VF. based
> on mmap callback the vendor driver can easily switch back-and-forth
> between pass through and trap/emulation of the VF resources. Of
> course doing so alone doesn't address all the demands of VF live
> migration (e.g. dirty page tracking still requires other techniques), 
> but it does pave a way toward a general framework to support VF
> live migration.
> 
> If above is feasible, finally we could use one mdev framework to
> manage both mdev and pf/vf assignment, while providing added
> values which are difficult to achieve today. :-)

mdev drivers may be the first to support migration, but I wonder if a
full mdev implementation is necessary for it.  Once the vfio api is
define, device specific extensions to vfio-pci might be able to
implement migration more directly.  Thanks,

Alex

Re: [PATCH v2] Documentation/sphinx: Fix Directive import error

[Matthew Wilcox]

On Fri, Mar 02, 2018 at 08:42:54AM -0800, Matthew Wilcox wrote:
> On Fri, Mar 02, 2018 at 06:01:50PM +0200, Jani Nikula wrote:
> > On Fri, 02 Mar 2018, Takashi Iwai  wrote:
> > > The sphinx.util.compat for Directive stuff was deprecated in the
> > > recent Sphinx version, and now we get a build error.
> > >
> > > Let's import from the new place, docutils.parsers.rst, while keeping
> > > the old sphinx.util.compat as fallback.
> > >
> > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
> > > Signed-off-by: Takashi Iwai 
> > > ---
> > > v1->v2: Change the fallback order as Matthew suggested, the new one at 
> > > first
> > 
> > So this crossed my mind as well... and then I thought it'll probably
> > succeed on older Sphinx, and the fallback is not needed. The question
> > is, are these equal? Can we just import from docutils.parsers.rst?
> 
> I found a github page which implies that docutils.parsers.rst.Directive
> was added 12 years ago (!) so we're probably safe to rely on it:
> 
> https://github.com/docutils-mirror/docutils/commit/9649abee47b4ce4db51be1d90fcb1fb500fa78b3
> 
> Again, I'm no pythonista, so I may have muddled this.

I spent some time delving through the Sphinx codebase.  The compat
version was added so you could use Directive with docutils 0.4 onwards.
docutils 0.5 onwards has Directive.  So as long as we're comfortable
mandating docutils from 2009, we're fine ;-)

Re: [PATCH v5 02/12] dax: introduce IS_DEVDAX() and IS_FSDAX()

[Dan Williams]

On Fri, Mar 2, 2018 at 9:45 AM, Darrick J. Wong  wrote:
> On Thu, Mar 01, 2018 at 07:53:44PM -0800, Dan Williams wrote:
>> The current IS_DAX() helper that checks if a file is in DAX mode serves
>> two purposes. It is a control flow branch condition for DAX vs
>> non-DAX paths and it is a mechanism to perform dead code elimination. The
>> dead code elimination is required in the CONFIG_FS_DAX=n case since
>> there are symbols in fs/dax.c that will be elided. While the
>> dead code elimination can be addressed with nop stubs for the fs/dax.c
>> symbols that does not address the need for a DAX control flow helper
>> where fs/dax.c symbols are not involved.
>>
>> Moreover, the control flow changes, in some cases, need to be cognizant
>> of whether the DAX file is a typical file or a Device-DAX special file.
>> Introduce IS_DEVDAX() and IS_FSDAX() to simultaneously address the
>> file-type control flow and dead-code elimination use cases. IS_DAX()
>> will be deleted after all sites are converted to use the file-type
>> specific helper.
>>
>> Note, this change is also a pre-requisite for fixing the definition of
>> the S_DAX inode flag in the CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case.
>> The flag needs to be defined, non-zero, if either DAX facility is
>> enabled.
>>
>> Cc: "Theodore Ts'o" 
>> Cc: Andreas Dilger 
>> Cc: Alexander Viro 
>> Cc: "Darrick J. Wong" 
>> Cc: linux-...@vger.kernel.org
>> Cc: Matthew Wilcox 
>> Cc: Ross Zwisler 
>> Cc: 
>> Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
>> Reported-by: Jan Kara 
>> Reviewed-by: Jan Kara 
>> Signed-off-by: Dan Williams 
>> ---
>>  include/linux/fs.h |   22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 79c413985305..bd0c46880572 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1909,6 +1909,28 @@ static inline bool sb_rdonly(const struct super_block 
>> *sb) { return sb->s_flags
>>  #define IS_WHITEOUT(inode)   (S_ISCHR(inode->i_mode) && \
>>(inode)->i_rdev == WHITEOUT_DEV)
>>
>> +static inline bool IS_DEVDAX(struct inode *inode)
>> +{
>> + if (!IS_ENABLED(CONFIG_DEV_DAX))
>> + return false;
>> + if ((inode->i_flags & S_DAX) == 0)
>> + return false;
>> + if (!S_ISCHR(inode->i_mode))
>> + return false;
>> + return true;
>> +}
>> +
>> +static inline bool IS_FSDAX(struct inode *inode)
>> +{
>> + if (!IS_ENABLED(CONFIG_FS_DAX))
>> + return false;
>
> I echo Jan's complaint from the last round that the dead code
> elimination here is subtle, as compared to:
>
> #if IS_ENABLED(CONFIG_FS_DAX)
> static inline bool IS_FSDAX(struct inode *inode) { ... }
> #else
> # define IS_FSDAX(inode) (false)
> #endif
>
> But I guess even with that we're relying on dead code elimination higher
> up in the call stack...

If IS_FSDAX() was only a dead-code elimination mechanism rather than a
runtime branch condition then I agree. Otherwise I think IS_ENABLED()
is suitable and not subtle, especially when used in a header file.

>> + if ((inode->i_flags & S_DAX) == 0)
>> + return false;
>> + if (S_ISCHR(inode->i_mode))
>> + return false;
>
> I'm curious, do we have character devices with S_DAX set?

Yes, Device-DAX, see:

ab68f2622136 /dev/dax, pmem: direct access to persistent memory

> I /think/ we're expecting that only block/char devices and files will
> ever have S_DAX set, so IS_FSDAX is only true for block devices and
> files.  Right?

We had S_DAX on block-devices for a short while, but deleted it and
went with the Device-DAX interface instead. So it's only regular files
and /dev/daxX.Y nodes these days.

> (A comment here about why S_ISCHR->false here would be helpful.)

Ok.

Re: [PATCH v1 19/19] arm: dts: mediatek: converted to using SPDX identifiers

[Rob Herring]

On Fri, Feb 23, 2018 at 06:16:39PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Convert boilerplate license statement into proper SPDX identifier style.
> 
> Signed-off-by: Sean Wang 
> Cc: Philippe Ombredanne 
> ---
>  arch/arm/boot/dts/mt2701-evb.dts  |  9 +
>  arch/arm/boot/dts/mt2701.dtsi |  9 +
>  arch/arm/boot/dts/mt6323.dtsi |  8 +---
>  arch/arm/boot/dts/mt6580-evbp1.dts|  9 +
>  arch/arm/boot/dts/mt6580.dtsi |  9 +
>  arch/arm/boot/dts/mt6589-aquaris5.dts | 10 +-
>  arch/arm/boot/dts/mt6589.dtsi | 12 ++--
>  arch/arm/boot/dts/mt6592-evb.dts  |  9 +
>  arch/arm/boot/dts/mt6592.dtsi |  9 +
>  arch/arm/boot/dts/mt7623.dtsi |  9 +
>  arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts |  2 +-
>  arch/arm/boot/dts/mt7623n-rfb-nand.dts|  9 +
>  arch/arm/boot/dts/mt7623n-rfb.dtsi|  9 +
>  arch/arm/boot/dts/mt8127-moose.dts|  9 +
>  arch/arm/boot/dts/mt8127.dtsi |  9 +
>  arch/arm/boot/dts/mt8135-evbp1.dts|  9 +
>  arch/arm/boot/dts/mt8135.dtsi |  9 +
>  17 files changed, 18 insertions(+), 131 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts 
> b/arch/arm/boot/dts/mt2701-evb.dts
> index 63af4b1..be0edb3 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -1,15 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (c) 2015 MediaTek Inc.
>   * Author: Erin Lo 
>   *
> - * 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.
> - *
> - * 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.
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 9109a2b..0c8a17c1 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -1,15 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (c) 2015 MediaTek Inc.
>   * Author: Erin.Lo 
>   *
> - * 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.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
>   */
>  
>  #include 
> diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
> index 44c5642..0ebc132 100644
> --- a/arch/arm/boot/dts/mt6323.dtsi
> +++ b/arch/arm/boot/dts/mt6323.dtsi
> @@ -1,15 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (c) 2017-2018 MediaTek Inc.
>   * Author: John Crispin 
>   *  Sean Wang 
> - * 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.
>   *
> - * 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.
>   */
>  
>   {
> diff --git a/arch/arm/boot/dts/mt6580-evbp1.dts 
> b/arch/arm/boot/dts/mt6580-evbp1.dts
> index 17daeae..ca13789 100644
> --- a/arch/arm/boot/dts/mt6580-evbp1.dts
> +++ b/arch/arm/boot/dts/mt6580-evbp1.dts
> @@ -1,15 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright (c) 2015 MediaTek Inc.
>   * Author: Mars.C 
>   *
> - * 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.
> - *
> - * 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.
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm/boot/dts/mt6580.dtsi b/arch/arm/boot/dts/mt6580.dtsi
> index a349dba..2bdc5ed 100644
> --- a/arch/arm/boot/dts/mt6580.dtsi
> +++ 

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

[Petr Mladek]

On Fri 2018-03-02 16:07:32, Stephen Rothwell wrote:
> Hi Petr,
> 
> After merging the printk tree, today's linux-next build (bfin
> BF518F-EZBRD_defconfig) failed like this:
> 
> lib/dump_stack.o: In function `dump_stack':
> lib/dump_stack.c:122: multiple definition of `dump_stack'
> arch/blackfin/kernel/dumpstack.o:arch/blackfin/kernel/dumpstack.c:166: first 
> defined here
> 
> Presumably caused by commit
> 
>   8040af489957 ("printk: move dump stack related code to lib/dump_stack.c")

I could confirm that it is caused by this commit. I have temporary
removed it from printk.git.

> (Though it is not immediately obvious why.)

It is a mistery to me. The error appears when I move any of
dump_stack_print_info() or show_regs_print_info() function
definitions from kernel/printk/printk.c to lib/dump_stack.c.
All the other changes seems unrelated.

The thing is that we basically do not touch dump_stack() definition
by that patch.

> This fails all the blackfin builds.  nds32 (a new architecture) also
> has a dump_stack function.

Good to know!

Best Regards,
Petr

Re: [PATCH v3 3/3] arm64: dts: Hi3660: Add binding for stub clock

[Wei Xu]

Hi Leo, YiPing,

On 2018/2/28 5:06, Leo Yan wrote:
> Hi Wei,
> 
> On Fri, Nov 17, 2017 at 05:27:32PM +0800, Xu YiPing wrote:
>> From: Kaihua Zhong 
>>
>> Add DT binding for Hi3660 stub clock driver.
>>
>> Reviewed-by: Leo Yan 
>> Signed-off-by: Kai Zhao 
>> Signed-off-by: Tao Wang 
>> Signed-off-by: Ruyi Wang 
>> Signed-off-by: Kaihua Zhong 
> 
> Could you help to pick up this patch? Thanks!

It failed to merge because of the mailbox part.
Once the mailbox driver is accepted, I will pick up this.
Thanks!

Best Regards,
Wei

> 
>> ---
>>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
>> b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> index 451b6bf..cbbc7f1 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> @@ -293,6 +293,13 @@
>>  #mbox-cells = <3>;
>>  };
>>  
>> +stub_clock: stub_clock@e896b500 {
>> +compatible = "hisilicon,hi3660-stub-clk";
>> +reg = <0x0 0xe896b500 0x0 0x0100>;
>> +#clock-cells = <1>;
>> +mboxes = < 13 3 0>;
>> +};
>> +
>>  dual_timer0: timer@fff14000 {
>>  compatible = "arm,sp804", "arm,primecell";
>>  reg = <0x0 0xfff14000 0x0 0x1000>;
>> -- 
>> 1.9.1
>>
> 
> .
> 

[RFC 1/3] arch/x86/kvm: SVM: Introduce pause filter threshold

[Babu Moger]

This patch adds the support for pause filtering threshold. This feature
support is indicated by CPUID Fn8000_000A_EDX. See AMD APM Vol 2 Section
15.14.4 Pause Intercept Filtering for more details

In this mode, a 16-bit pause filter threshold field is added in VMCB.
The threshold value is a cycle count that is used to reset the pause
counter.  As with simple pause filtering, VMRUN loads the pause count
value from VMCB into an internal counter. Then, on each pause instruction
the hardware checks the elapsed number of cycles since the most recent
pause instruction against the pause Filter Threshold. If the elapsed cycle
count is greater than the pause filter threshold, then the internal pause
count is reloaded from VMCB and execution continues. If the elapsed cycle
count is less than the pause filter threshold, then the internal pause
count is decremented. If the count value is less than zero and pause
intercept is enabled, a #VMEXIT is triggered. If advanced pause filtering
is supported and pause Filter Threshold field is set to zero, the filter
will operate in the simpler, count only mode.

Signed-off-by: Babu Moger 
---
 arch/x86/include/asm/svm.h | 3 ++-
 arch/x86/kvm/svm.c | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 78dd9df..7a3d9c7 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -60,7 +60,8 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
u32 intercept_dr;
u32 intercept_exceptions;
u64 intercept;
-   u8 reserved_1[42];
+   u8 reserved_1[40];
+   u16 pause_filter_thresh;
u16 pause_filter_count;
u64 iopm_base_pa;
u64 msrpm_base_pa;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f40d0da..50a4e95 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4175,6 +4175,8 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
pr_err("%-20s%08x\n", "exceptions:", control->intercept_exceptions);
pr_err("%-20s%016llx\n", "intercepts:", control->intercept);
pr_err("%-20s%d\n", "pause filter count:", control->pause_filter_count);
+   pr_err("%-20s%d\n", "pause filter threshold:",
+  control->pause_filter_thresh);
pr_err("%-20s%016llx\n", "iopm_base_pa:", control->iopm_base_pa);
pr_err("%-20s%016llx\n", "msrpm_base_pa:", control->msrpm_base_pa);
pr_err("%-20s%016llx\n", "tsc_offset:", control->tsc_offset);
-- 
1.8.3.1

[RFC 3/3] arch/x86/kvm: SVM: Introduce pause loop exit logic in SVM

[Babu Moger]

Bring the PLE(pause loop exit) logic to AMD svm driver.
We have noticed it help in situations where numerous pauses are generated
due to spinlock or other scenarios. Tested it with idle=poll and noticed
pause interceptions go down considerably.

Signed-off-by: Babu Moger 
---
 arch/x86/kvm/svm.c | 114 -
 arch/x86/kvm/x86.h |   1 +
 2 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 50a4e95..30bc851 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -263,6 +263,55 @@ struct amd_svm_iommu_ir {
 static bool npt_enabled;
 #endif
 
+/*
+ * These 2 parameters are used to config the controls for Pause-Loop Exiting:
+ * pause_filter_thresh: On processors that support Pause filtering(indicated
+ * by CPUID Fn8000_000A_EDX), the VMCB provides a 16 bit pause filter
+ * count value. On VMRUN this value is loaded into an internal counter.
+ * Each time a pause instruction is executed, this counter is decremented
+ * until it reaches zero at which time a #VMEXIT is generated if pause
+ * intercept is enabled. Refer to  AMD APM Vol 2 Section 15.14.4 Pause
+ * Intercept Filtering for more details.
+ * This also indicate if ple logic enabled.
+ *
+ * pause_filter_count: In addition, some processor families support advanced
+ * pause filtering (indicated by CPUID Fn8000_000A_EDX) upper bound on
+ * the amount of time a guest is allowed to execute in a pause loop.
+ * In this mode, a 16-bit pause filter threshold field is added in the
+ * VMCB. The threshold value is a cycle count that is used to reset the
+ * pause counter. As with simple pause filtering, VMRUN loads the pause
+ * count value from VMCB into an internal counter. Then, on each pause
+ * instruction the hardware checks the elapsed number of cycles since
+ * the most recent pause instruction against the pause filter threshold.
+ * If the elapsed cycle count is greater than the pause filter threshold,
+ * then the internal pause count is reloaded from the VMCB and execution
+ * continues. If the elapsed cycle count is less than the pause filter
+ * threshold, then the internal pause count is decremented. If the count
+ * value is less than zero and PAUSE intercept is enabled, a #VMEXIT is
+ * triggered. If advanced pause filtering is supported and pause filter
+ * threshold field is set to zero, the filter will operate in the simpler,
+ * count only mode.
+ */
+
+static int pause_filter_thresh = KVM_DEFAULT_PLE_GAP;
+module_param(pause_filter_thresh, int, S_IRUGO);
+
+static int pause_filter_count = KVM_DEFAULT_PLE_WINDOW;
+module_param(pause_filter_count, int, S_IRUGO);
+
+/* Default doubles per-vcpu window every exit. */
+static int ple_window_grow = KVM_DEFAULT_PLE_WINDOW_GROW;
+module_param(ple_window_grow, int, S_IRUGO);
+
+/* Default resets per-vcpu window every exit to ple_window. */
+static int ple_window_shrink = KVM_DEFAULT_PLE_WINDOW_SHRINK;
+module_param(ple_window_shrink, int, S_IRUGO);
+
+/* Default is to compute the maximum so we can never overflow. */
+static int ple_window_actual_max = KVM_SVM_DEFAULT_PLE_WINDOW_MAX;
+static int ple_window_max= KVM_SVM_DEFAULT_PLE_WINDOW_MAX;
+module_param(ple_window_max, int, S_IRUGO);
+
 /* allow nested paging (virtualized MMU) for all guests */
 static int npt = true;
 module_param(npt, int, S_IRUGO);
@@ -1046,6 +1095,58 @@ static int avic_ga_log_notifier(u32 ga_tag)
return 0;
 }
 
+static void grow_ple_window(struct kvm_vcpu *vcpu)
+{
+   struct vcpu_svm *svm = to_svm(vcpu);
+   struct vmcb_control_area *control = >vmcb->control;
+   int old = control->pause_filter_count;
+
+   control->pause_filter_count = __grow_ple_window(old,
+   pause_filter_count,
+   ple_window_grow,
+   ple_window_actual_max);
+
+   if (control->pause_filter_count != old)
+   mark_dirty(svm->vmcb, VMCB_INTERCEPTS);
+
+   trace_kvm_ple_window_grow(vcpu->vcpu_id,
+ control->pause_filter_count, old);
+}
+
+static void shrink_ple_window(struct kvm_vcpu *vcpu)
+{
+   struct vcpu_svm *svm = to_svm(vcpu);
+   struct vmcb_control_area *control = >vmcb->control;
+   int old = control->pause_filter_count;
+
+   control->pause_filter_count = __shrink_ple_window(old,
+ pause_filter_count,
+ ple_window_shrink,
+ pause_filter_count);
+
+   if (control->pause_filter_count != old)
+   mark_dirty(svm->vmcb, VMCB_INTERCEPTS);
+
+   trace_kvm_ple_window_shrink(vcpu->vcpu_id,
+ 

Re: [PATCH v3 2/2] timers: Don't search for expired timers while TIMER_SOFTIRQ is scheduled

[Haris Okanovic]

Could please point me to the code/patches or something?


I rebase onto v4.14.20-rt17, running some sanity test before reposting 
to ml (cyclictest & Anna's timertest). Will post V4 sometime today (US 
Central Time) if everything goes well.


Are you also asking for a 4.9 version? I'm fine leaving it out of 4.9.

-- Haris


On 03/02/2018 08:52 AM, Sebastian Andrzej Siewior wrote:

On 2018-03-01 12:37:49 [-0600], Haris Okanovic wrote:

It was added back into 4.9 at some point after v4.9.30-rt20. I see an older
version in v4.9.68-rt60, for example, hence my original email. It was
dropped sometime thereafter, presumably because it no longer cleanly
applies. I don't see it in v4.14.20-rt17, for example.


It was removed in v4.9.34-rt24 via 95d4a348841d ("Revert "timers: Don't
wake ktimersoftd on every tick""). I don't see any leftovers or an older
version.
Looking at the queue I see two patches from you and that is:
  timers: Don't wake ktimersoftd on every tick
  tpm_tis: fix stall after iowrite*()s

and the former is reverted. This was v4.9.84-rt62 that I've been looking
at. Could please point me to the code/patches or something?


Is there a newer patch pending on your side?


Not yet. The latest version on patchwork is OK, just needs to be rebased
post-4.9. I'll post a new version when I get a chance to build and retest
it.

okay.

Sebastian

[PATCH v3 00/10] drivers/qcom: add RPMH communication support

[Lina Iyer]

Chagnes in v3:
- Address Steven's comments in FTRACE
- Fix DT documentation as suggested by Rob H
- Fix error handling in IRQ handler as suggested by Evan
- Remove locks in rpmh_flush()
- Improve comments

Changes in v2:
- Added sleep/wake, async and batch requests support
- Addressed Bjorn's comments
- Private FTRACE for drivers/soc/qcom as suggested by Steven
- Sparse checked on these patches
- Use SPDX license commenting sytle

This set of patches add the ability for platform drivers to make use of shared
resources in newer Qualcomm SoCs like SDM845. Resources that are shared between
multiple processors in a SoC are generally controlled by a dedicated remote
processor. The remote processor (Resource Power Manager or RPM in previous QCOM
SoCs) receives requests for resource state from other processors using the
shared resource, aggregates the request and applies the result on the shared
resource. SDM845 advances this concept and uses h/w (hardened I/P) blocks for
aggregating requests and applying the result on the resource. The resources
could be clocks, regulators or bandwidth requests for buses. This new
architecture is called RPM-hardened or RPMH in short.

Since this communication mechanism is completely hardware driven without a
processor intervention on the remote end, existing mechanisms like RPM-SMD are
no longer useful. Also, there is no serialization of data or is data is written
to a shared memory in this new format. The data used is different, unsigned 32
bits are used for representing an address, data and header. Each resource's
property is a unique u32 address and have pre-defined set of property specific
valid values. A request that comprises of  is sent by
writing to a set of registers from Linux and transmitted to the remote slave
through an internal bus. The remote end aggregates this request along with
requests from other processors for the  and applies the result.

The hardware block that houses this functionality is called Resource State
Coordinator or RSC. Inside the RSC are set of slots for sending RPMH requests
called Trigger Commands Sets (TCS). The set of patches are for writing the
requests into these TCSes and sending them to hardened IP blocks.

The driver design is split into two components. The RSC driver housed in
rpmh-rsc.c and the set of library functions in rpmh.c that frame the request and
transmit it using the controller. This first set of patches allow a simple
synchronous request to be made by the platform drivers. Future patches will add
more functionality that cater to complex drivers and use cases.

Please consider reviewing this patchset.

v1: https://www.spinics.net/lists/devicetree/msg210980.html
v2: https://lkml.org/lkml/2018/2/15/852

Lina Iyer (10):
  drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs
  dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs
  drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE
  drivers: qcom: rpmh: add RPMH helper functions
  drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS
  drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS
  drivers: qcom: rpmh: cache sleep/wake state requests
  drivers: qcom: rpmh: allow requests to be sent asynchronously
  drivers: qcom: rpmh: add support for batch RPMH request
  drivers: qcom: rpmh-rsc: allow active requests from wake TCS

 .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 
 drivers/soc/qcom/Kconfig   |  10 +
 drivers/soc/qcom/Makefile  |   4 +
 drivers/soc/qcom/rpmh-internal.h   |  97 +++
 drivers/soc/qcom/rpmh-rsc.c| 796 +
 drivers/soc/qcom/rpmh.c| 665 +
 drivers/soc/qcom/trace-rpmh.h  |  89 +++
 include/dt-bindings/soc/qcom,rpmh-rsc.h|  14 +
 include/soc/qcom/rpmh.h|  60 ++
 include/soc/qcom/tcs.h |  56 ++
 10 files changed, 1922 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
 create mode 100644 drivers/soc/qcom/rpmh-internal.h
 create mode 100644 drivers/soc/qcom/rpmh-rsc.c
 create mode 100644 drivers/soc/qcom/rpmh.c
 create mode 100644 drivers/soc/qcom/trace-rpmh.h
 create mode 100644 include/dt-bindings/soc/qcom,rpmh-rsc.h
 create mode 100644 include/soc/qcom/rpmh.h
 create mode 100644 include/soc/qcom/tcs.h

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

Re: [PATCH v2] Documentation/sphinx: Fix Directive import error

[Matthew Wilcox]

On Fri, Mar 02, 2018 at 06:01:50PM +0200, Jani Nikula wrote:
> On Fri, 02 Mar 2018, Takashi Iwai  wrote:
> > The sphinx.util.compat for Directive stuff was deprecated in the
> > recent Sphinx version, and now we get a build error.
> >
> > Let's import from the new place, docutils.parsers.rst, while keeping
> > the old sphinx.util.compat as fallback.
> >
> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
> > Signed-off-by: Takashi Iwai 
> > ---
> > v1->v2: Change the fallback order as Matthew suggested, the new one at first
> 
> So this crossed my mind as well... and then I thought it'll probably
> succeed on older Sphinx, and the fallback is not needed. The question
> is, are these equal? Can we just import from docutils.parsers.rst?

I found a github page which implies that docutils.parsers.rst.Directive
was added 12 years ago (!) so we're probably safe to rely on it:

https://github.com/docutils-mirror/docutils/commit/9649abee47b4ce4db51be1d90fcb1fb500fa78b3

Again, I'm no pythonista, so I may have muddled this.

Re: [PATCH 2/2] drm/sun4i: add lvds mode_valid function

[Giulio Benetti]

Hi,

Il 02/03/2018 15:37, Maxime Ripard ha scritto:

On Fri, Mar 02, 2018 at 12:42:14PM +0100, Giulio Benetti wrote:

Hi,

Il 01/03/2018 10:57, Maxime Ripard ha scritto:

On Wed, Feb 28, 2018 at 06:53:52PM +0100, Giulio Benetti wrote:

   static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
.get_modes  = sun4i_lvds_get_modes,
+   .mode_valid = sun4i_lvds_mode_valid,
   };


This should be on the encoder, not the connector.


I've seen it is bound to connector in rgb and to encoder in hdmi.
Is it correct rgb mode_valid under connector funcs?
Otherwise I send a patch also for that one.


This would need to be fixed as well. Bridges attach to encoder, not
connectors, so if you ever have a bridge connected to the RGB output
(like on the A13-Olinuxino), mode_valid isn't called at the moment.


Ok, I will do the same for rgb and submit a patchset,
need some time to test both lvds and rgb.

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

Re: [PATCH] ARM: dts: tpc: Device tree description of the TPC board

[Fabio Estevam]

Hi Lukasz,

In addition to Sascha's comments:

On Fri, Mar 2, 2018 at 9:17 AM, Lukasz Majewski  wrote:

> diff --git a/arch/arm/boot/dts/imx6q-kp-tpc.dts 
> b/arch/arm/boot/dts/imx6q-kp-tpc.dts
> new file mode 100644
> index ..955462e778c9
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-kp-tpc.dts
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +

Please consider using SPDX tag instead.

> +/dts-v1/;
> +
> +#include "imx6q-kp.dtsi"
> +
> +/ {
> +   model = "Freescale i.MX6 Quad K+P TPC Board";
> +   compatible = "fsl,imx6q-tpc", "fsl,imx6q";

Use the board manufacturer symbol instead.

If needed, add an entry for the vendor at
Documentation/devicetree/bindings/vendor-prefixes.txt

> +};
> +
> +_display {
> +   display-timings {
> +   800x480x60 {
> +   clock-frequency = <34209000>;
> +   hactive = <800>;
> +   vactive = <480>;
> +   hback-porch = <85>;
> +   hfront-porch = <15>;
> +   vback-porch = <34>;
> +   vfront-porch = <10>;
> +   hsync-len = <28>;
> +   vsync-len = <1>;
> +   hsync-active = <1>;
> +   vsync-active = <1>;
> +   de-active = <1>;
> +   };
> +   };
> +};

We prefer to use a compatible panel entry instead of keeping the panel
timings inside the dts.

> +
> +_di0_disp0 {
> +   remote-endpoint = <_display_in>;
> +};
> +
> + {
> +   status = "disabled";
> +};
> +
> + {
> +   status = "disabled";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/imx6q-kp.dtsi b/arch/arm/boot/dts/imx6q-kp.dtsi
> new file mode 100644
> index ..47a10fb1d46b
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-kp.dtsi
> @@ -0,0 +1,468 @@
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE 

Re: [PATCH v3 2/2] timers: Don't search for expired timers while TIMER_SOFTIRQ is scheduled

[Haris Okanovic]

On 03/02/2018 10:39 AM, Sebastian Andrzej Siewior wrote:

On 2018-03-02 10:29:56 [-0600], Haris Okanovic wrote:

Could please point me to the code/patches or something?


I rebase onto v4.14.20-rt17, running some sanity test before reposting to ml
(cyclictest & Anna's timertest). Will post V4 sometime today (US Central
Time) if everything goes well.

Are you also asking for a 4.9 version? I'm fine leaving it out of 4.9.


Hmmm. Maybe this is a form of miscommunication here :)


Yea, I agree :) Let me try to summarize: When I originally asked this 
question back in March, rt was on 4.9. I was asking back then to pull 
the V3 revision of my timer patch (replacing the old V2). Given that RT 
already moved to 4.14 in the meantime, backed out V3, and V3 no longer 
applies 4.14, I'm fine leaving everything as-is! I post a V4 (for 4.14) 
when I finish retesting it.



So my understanding is that you complain/ask why there is an older
version of the patch still in v4.9-RT:

|It was added back into 4.9 at some point after v4.9.30-rt20. I see an older
|version in v4.9.68-rt60, for example, hence my original email. It was dropped
|sometime thereafter, presumably because it no longer cleanly applies. I don't
|see it in v4.14.20-rt17, for example.

So I ask where you see the old version of your patch in v4.9-RT. Yes it
was added, then removed and it never appeared back in. However, I don't
see anymore in v4.9.68-rt60.


-- Haris


Sebastian

Re: [PATCH] Support the nonstring variable attribute (gcc >= 8)

[Miguel Ojeda]

On Thu, Mar 1, 2018 at 10:57 AM, Arnd Bergmann  wrote:
> On Mon, Feb 19, 2018 at 1:01 AM, Miguel Ojeda
>  wrote:
>> On Mon, Feb 19, 2018 at 12:20 AM, David Rientjes  wrote:
>>> On Sat, 17 Feb 2018, Miguel Ojeda wrote:
>>>
 From the GCC manual:

 The nonstring variable attribute specifies that an object or member
 declaration with type array of char or pointer to char is intended to
 store character arrays that do not necessarily contain a terminating NUL
 character. This is useful in detecting uses of such arrays or pointers
 with functions that expect NUL-terminated strings, and to avoid warnings
 when such an array or pointer is used as an argument to a bounded string
 manipulation function such as strncpy.

   https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html

 Some reports are already coming to the LKML regarding these
 warnings. When they are false positives, we can use __nonstring to let
 gcc know a NUL character is not required; like in this case:

   https://lkml.org/lkml/2018/1/16/135

 Signed-off-by: Miguel Ojeda 
 Cc: Ingo Molnar 
 Cc: Josh Poimboeuf 
 Cc: Kees Cook 
 Cc: Andrew Morton 
 Cc: Geert Uytterhoeven 
 Cc: Will Deacon 
 Cc: Greg Kroah-Hartman 
 Cc: David Rientjes 
>>>
>>> I would have expected to have seen __nonstring used somewhere as part of
>>> this patch.
>>
>> Do you mean to expand the commit message with an actual code example
>> instead of the links to the docs and the discussion about the report?
>> Otherwise, if you mean in the actual commit, I think in that case it
>> should be a patch series, not a single commit.
>>
>> In any case, the key point here is to agree on the short-term policy:
>> i.e. whether we want to disable the upcoming warning or try to take
>> advantage of it (which not *necessarily* implies using __nonstring,
>> there are other workarounds; though where applicable, __nonstring is
>> probably the right thing to use).
>
> What David was asking for is to have a couple of users of the
> __nonstring attribute in places for which it is the right solution.
>

I understood :-) My question was regarding where he was asking to see it.

> I would suggest making it a patch series, with patch 1/x introducing
> the attribute (i.e. your patch), and followed by additional patches
> that add the attribute to individual header files or drivers for which
> it is the right solution.

Yep, that is what I suggested too.

>
> When I looked at the warning, I found that we have around 120 file
> for which we warn. The majority of them are actually questionable
> uses of strncpy() that probably should have been strscpy(), but
> most of those do not actually cause undefined behavior.

Then it looks like enabling the warning by default is useful and not
too noisy (at least for just char).

>
> A smaller number like the example from ext4 are nonstrings
> (i.e. character arrays without nul-termination) that would benefit
> from the nonstring attribute. About half of those are actually
> arrays of u8/__u8/uint8_t/__uint8_t for which the currently
> implemented nonstring attribute is invalid, and it seems odd
> to convert those to 'char', e.g.
>
> struct ext4_super_block {
> __le32  s_first_error_time; /* first time an error happened */
> __le32  s_first_error_ino;  /* inode involved in first error */
> __le64  s_first_error_block;/* block involved of first error */
> -   __u8s_first_error_func[32]; /* function where the error happened 
> */
> +   chars_first_error_func[32] __nonstring; /* function
> where the error happened */
> __le32  s_first_error_line; /* line number where error happened */
> __le32  s_last_error_time;  /* most recent time of an error */
> __le32  s_last_error_ino;   /* inode involved in last error */
> __le32  s_last_error_line;  /* line number where error happened */
> __le64  s_last_error_block; /* block involved of last error */
> -   __u8s_last_error_func[32];  /* function where the error happened 
> */
> +   chars_last_error_func[32] __nonstring;  /* function
> where the error happened */
>
> doesn't feel right. Maybe we can extend gcc to also accept
> the attribute on arrays of other 8-bit types.

Hum... On one hand, the warning is meant to protect against misuses of
the typical string handling functions, and those take pointers to
char. Therefore, one could argue that using signed or unsigned char
already marks an array/pointer as "not a string" (for the purposes of
the attribute).

On the other hand, people *will* call 

Re: [PATCH net V2] virtio-net: re enable XDP_REDIRECT for mergeable buffer

[Michael S. Tsirkin]

On Fri, Mar 02, 2018 at 05:29:14PM +0800, Jason Wang wrote:
> XDP_REDIRECT support for mergeable buffer was removed since commit
> 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable()
> case"). This is because we don't reserve enough tailroom for struct
> skb_shared_info which breaks XDP assumption. So this patch fixes this
> by reserving enough tailroom and using fixed size of rx buffer.
> 
> Signed-off-by: Jason Wang 

Acked-by: Michael S. Tsirkin 

I think the next incremental step is to look at splitting
out fast path XDP processing to a separate set of functions.

> ---
> Changes from V1:
> - do not add duplicated tracepoint when redirection fails
> ---
>  drivers/net/virtio_net.c | 54 
> +---
>  1 file changed, 42 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9bb9e56..426dcf7 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -504,6 +504,7 @@ static struct page *xdp_linearize_page(struct 
> receive_queue *rq,
>   page_off += *len;
>  
>   while (--*num_buf) {
> + int tailroom = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>   unsigned int buflen;
>   void *buf;
>   int off;
> @@ -518,7 +519,7 @@ static struct page *xdp_linearize_page(struct 
> receive_queue *rq,
>   /* guard against a misconfigured or uncooperative backend that
>* is sending packet larger than the MTU.
>*/
> - if ((page_off + buflen) > PAGE_SIZE) {
> + if ((page_off + buflen + tailroom) > PAGE_SIZE) {
>   put_page(p);
>   goto err_buf;
>   }
> @@ -690,6 +691,7 @@ static struct sk_buff *receive_mergeable(struct 
> net_device *dev,
>   unsigned int truesize;
>   unsigned int headroom = mergeable_ctx_to_headroom(ctx);
>   bool sent;
> + int err;
>  
>   head_skb = NULL;
>  
> @@ -701,7 +703,12 @@ static struct sk_buff *receive_mergeable(struct 
> net_device *dev,
>   void *data;
>   u32 act;
>  
> - /* This happens when rx buffer size is underestimated */
> + /* This happens when rx buffer size is underestimated
> +  * or headroom is not enough because of the buffer
> +  * was refilled before XDP is set. This should only
> +  * happen for the first several packets, so we don't
> +  * care much about its performance.
> +  */
>   if (unlikely(num_buf > 1 ||
>headroom < virtnet_get_headroom(vi))) {
>   /* linearize data for XDP */
> @@ -736,9 +743,6 @@ static struct sk_buff *receive_mergeable(struct 
> net_device *dev,
>  
>   act = bpf_prog_run_xdp(xdp_prog, );
>  
> - if (act != XDP_PASS)
> - ewma_pkt_len_add(>mrg_avg_pkt_len, len);
> -
>   switch (act) {
>   case XDP_PASS:
>   /* recalculate offset to account for any header
> @@ -770,6 +774,18 @@ static struct sk_buff *receive_mergeable(struct 
> net_device *dev,
>   goto err_xdp;
>   rcu_read_unlock();
>   goto xdp_xmit;
> + case XDP_REDIRECT:
> + err = xdp_do_redirect(dev, , xdp_prog);
> + if (err) {
> + if (unlikely(xdp_page != page))
> + put_page(xdp_page);
> + goto err_xdp;
> + }
> + *xdp_xmit = true;
> + if (unlikely(xdp_page != page))
> + goto err_xdp;
> + rcu_read_unlock();
> + goto xdp_xmit;
>   default:
>   bpf_warn_invalid_xdp_action(act);
>   case XDP_ABORTED:
> @@ -1013,13 +1029,18 @@ static int add_recvbuf_big(struct virtnet_info *vi, 
> struct receive_queue *rq,
>  }
>  
>  static unsigned int get_mergeable_buf_len(struct receive_queue *rq,
> -   struct ewma_pkt_len *avg_pkt_len)
> +   struct ewma_pkt_len *avg_pkt_len,
> +   unsigned int room)
>  {
>   const size_t hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>   unsigned int len;
>  
> - len = hdr_len + clamp_t(unsigned int, ewma_pkt_len_read(avg_pkt_len),
> + if (room)
> + return PAGE_SIZE - room;
> +
> + len = hdr_len + clamp_t(unsigned int, ewma_pkt_len_read(avg_pkt_len),
>   rq->min_buf_len, PAGE_SIZE - hdr_len);
> +
>   return ALIGN(len, L1_CACHE_BYTES);
>  }
>  
> @@ -1028,21 +1049,27 @@ static int add_recvbuf_mergeable(struct 

[PATCH] staging: rtl8712: match alignment with open parenthesis

[Arushi Singhal]

This patch fixes the checks reported by checkpatch.pl for alignment
should match open parenthesis.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/rtl8712/mlme_linux.c | 2 +-
 drivers/staging/rtl8712/os_intfs.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/mlme_linux.c 
b/drivers/staging/rtl8712/mlme_linux.c
index 3c7c4a4..baaa52f 100644
--- a/drivers/staging/rtl8712/mlme_linux.c
+++ b/drivers/staging/rtl8712/mlme_linux.c
@@ -36,7 +36,7 @@ static void sitesurvey_ctrl_handler(struct timer_list *t)
 {
struct _adapter *adapter =
from_timer(adapter, t,
-   mlmepriv.sitesurveyctrl.sitesurvey_ctrl_timer);
+  mlmepriv.sitesurveyctrl.sitesurvey_ctrl_timer);
 
_r8712_sitesurvey_ctrl_handler(adapter);
mod_timer(>mlmepriv.sitesurveyctrl.sitesurvey_ctrl_timer,
diff --git a/drivers/staging/rtl8712/os_intfs.c 
b/drivers/staging/rtl8712/os_intfs.c
index e7df5d7..d6d27da 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -230,7 +230,7 @@ struct net_device *r8712_init_netdev(void)
 static u32 start_drv_threads(struct _adapter *padapter)
 {
padapter->cmdThread = kthread_run(r8712_cmd_thread, padapter, "%s",
- padapter->pnetdev->name);
+ padapter->pnetdev->name);
if (IS_ERR(padapter->cmdThread))
return _FAIL;
return _SUCCESS;
-- 
2.7.4

Re: [PATCH v3 05/25] ASoC: qcom: qdsp6: Add support to Q6AFE

[Mark Brown]

On Fri, Mar 02, 2018 at 01:13:17PM +, Srinivas Kandagatla wrote:
> On 01/03/18 20:59, Mark Brown wrote:
> > On Tue, Feb 13, 2018 at 04:58:17PM +, srinivas.kandaga...@linaro.org 
> > wrote:

> > > +static struct afe_port_map port_maps[AFE_PORT_MAX] = {
> > > + [AFE_PORT_HDMI_RX] = { AFE_PORT_ID_MULTICHAN_HDMI_RX,
> > > + AFE_PORT_HDMI_RX, 1, 1},
> > > +};

> > Is this not device specific in any way?  It looks likely to be.

> It is specific to Audio firmware build.
> AFAIK, DSP port IDs are consistent across a given range of AVS firmware
> builds. So far I have seen them not change in any of the B family SoCs.
> However on older A family SOCs these are very different numbers. Which is
> where ADSP version info would help select correct map.

Can we have some documentation of this in the code please?

> > > +static struct q6afe_port *afe_find_port(struct q6afe *afe, int token)
> > > +{
> > > + struct q6afe_port *p = NULL;
> > > +
> > > + spin_lock(>port_list_lock);
> > > + list_for_each_entry(p, >port_list, node)
> > > + if (p->token == token)
> > > + break;
> > > +
> > > + spin_unlock(>port_list_lock);

> > Why do we need to lock the port list, what are we protecting it against?

> This is just to protect the list from anyone deleting this.

> Its very rare but the use case could be somelike the adsp is up and we are
> in the middle of finding a port and then adsp went down or crashed we would
> delete an entry in the list.

If that's what we're protecting against then this also needs to do
something to ensure that the port we looked up doesn't get deallocated
before or while we look at it.

> > > +int q6afe_port_start(struct q6afe_port *port)
> > > +{
> > > + return afe_port_start(port, >port_cfg);
> > > +}
> > > +EXPORT_SYMBOL_GPL(q6afe_port_start);

> > This is the third level of wrapper for the port start command in this
> > file.  Do we *really* need all these wrappers?

> Intention here is that we have plans to support different version of ADSP,
> on A family this command is different, so having this wrapper would help
> tackle this use-case.

Why not just take out the level of wrapper for now then add it in when
there's actually an abstraction in there?  The code might end up looking
different anyway.


signature.asc
Description: PGP signature

Re: [PATCH] arm64/debug: Fix registers on sleeping tasks

[Will Deacon]

On Thu, Mar 01, 2018 at 11:38:03AM -0800, Douglas Anderson wrote:
> This is the equivalent of commit 001bf455d206 ("ARM: 8428/1: kgdb: Fix
> registers on sleeping tasks") but for arm64.  Nuff said.

It's a pity that 001bf455d206 doesn't explain *why* past_pt_regs doesn't
work.

Anyway, does this mean you're actually using kgdb on arm64? Does the rest of
it appear to work?

Will

> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index 2122cd187f19..01285d4dcdc3 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -138,14 +138,26 @@ int dbg_set_reg(int regno, void *mem, struct pt_regs 
> *regs)
>  void
>  sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct 
> *task)
>  {
> - struct pt_regs *thread_regs;
> + struct thread_struct *thread = >thread;
> + struct cpu_context *cpu_context = >cpu_context;
>  
>   /* Initialize to zero */
>   memset((char *)gdb_regs, 0, NUMREGBYTES);
> - thread_regs = task_pt_regs(task);
> - memcpy((void *)gdb_regs, (void *)thread_regs->regs, GP_REG_BYTES);
> - /* Special case for PSTATE (check comments in asm/kgdb.h for details) */
> - dbg_get_reg(33, gdb_regs + GP_REG_BYTES, thread_regs);
> +
> + gdb_regs[19] = cpu_context->x19;
> + gdb_regs[20] = cpu_context->x20;
> + gdb_regs[21] = cpu_context->x21;
> + gdb_regs[22] = cpu_context->x22;
> + gdb_regs[23] = cpu_context->x23;
> + gdb_regs[24] = cpu_context->x24;
> + gdb_regs[25] = cpu_context->x25;
> + gdb_regs[26] = cpu_context->x26;
> + gdb_regs[27] = cpu_context->x27;
> + gdb_regs[28] = cpu_context->x28;
> + gdb_regs[29] = cpu_context->fp;
> +
> + gdb_regs[31] = cpu_context->sp;
> + gdb_regs[32] = cpu_context->pc;
>  }
>  
>  void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc)
> -- 
> 2.16.2.395.g2e18187dfd-goog
> 

Re: [PATCH v2 8/8] arm64: zynqmp: Add support for Xilinx zc1751

[Rob Herring]

On Fri, Feb 23, 2018 at 03:40:30PM +0100, Michal Simek wrote:
> Xilinx zc1751 boards is used for silicon validation. Board can be
> extended with 5 FMCs/DCs cards to connect various IPs. Describe all
> these combinations.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Record compatible string to xilinx.txt
> 
>  Documentation/devicetree/bindings/arm/xilinx.txt   |   3 +
>  arch/arm64/boot/dts/xilinx/Makefile|   5 +
>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts| 133 +++
>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts| 170 +++
>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts| 153 +
>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts| 181 
> +
>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts| 126 ++
>  7 files changed, 771 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt 
> b/Documentation/devicetree/bindings/arm/xilinx.txt
> index aceccf2bf43b..0cf6fb61631d 100644
> --- a/Documentation/devicetree/bindings/arm/xilinx.txt
> +++ b/Documentation/devicetree/bindings/arm/xilinx.txt
> @@ -28,6 +28,9 @@ Additional compatible strings:
>  - Xilinx internal board zc1275
>"xlnx,zynqmp-zc1275-revA", "xlnx,zynqmp-zc1275"
>  
> +- Xilinx internal board zc1751
> +  "xlnx,zynqmp-zc1751"
> +
>  - Xilinx 96boards compatible board zcu100
>"xlnx,zynqmp-zcu100-revC", "xlnx,zynqmp-zcu100"
>  
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile 
> b/arch/arm64/boot/dts/xilinx/Makefile
> index bdda451afaad..c2a0c00272e2 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -3,6 +3,11 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-ep108.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1232-revA.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1254-revA.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1275-revA.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1751-xm015-dc1.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1751-xm016-dc2.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1751-xm017-dc3.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1751-xm018-dc4.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1751-xm019-dc5.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu100-revC.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revA.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts 
> b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
> new file mode 100644
> index ..41f9e987c559
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Xilinx ZynqMP zc1751-xm015-dc1
> + *
> + * (C) Copyright 2015 - 2018, Xilinx, Inc.
> + *
> + * Michal Simek 
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp.dtsi"
> +#include "zynqmp-clk.dtsi"
> +#include 
> +
> +/ {
> + model = "ZynqMP zc1751-xm015-dc1 RevA";
> + compatible = "xlnx,zynqmp-zc1751", "xlnx,zynqmp";
> +
> + aliases {
> + ethernet0 = 
> + gpio0 = 
> + i2c0 = 
> + mmc0 = 
> + mmc1 = 
> + rtc0 = 
> + serial0 = 
> + usb0 = 

Same alias comments.

> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 0x8000>;
> + };
> +};
> +
> +_dma_chan1 {
> + status = "okay";
> +};
> +
> +_dma_chan2 {
> + status = "okay";
> +};
> +
> +_dma_chan3 {
> + status = "okay";
> +};
> +
> +_dma_chan4 {
> + status = "okay";
> +};
> +
> +_dma_chan5 {
> + status = "okay";
> +};
> +
> +_dma_chan6 {
> + status = "okay";
> +};
> +
> +_dma_chan7 {
> + status = "okay";
> +};
> +
> +_dma_chan8 {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + phy-handle = <>;
> + phy-mode = "rgmii-id";
> + phy0: phy@0 {
> + reg = <0>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +
> + {
> + status = "okay";
> + clock-frequency = <40>;
> +
> + eeprom: eeprom@55 {
> + compatible = "atmel,24c64"; /* 24AA64 */
> + reg = <0x55>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + /* SATA phy OOB timing settings */
> + 

Re: [PATCH v2 1/5] arm: zynq: Add Xilinx cc108 board

[Rob Herring]

On Fri, Feb 23, 2018 at 04:00:19PM +0100, Michal Simek wrote:
> The board contains 7z010 with 512MB memory, ethernet, qspi, uart, usbs
> and sd. But board is not supporting booting from sd card.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Record compatible string to xilinx.txt
> 
>  Documentation/devicetree/bindings/arm/xilinx.txt |  5 ++
>  arch/arm/boot/dts/Makefile   |  1 +
>  arch/arm/boot/dts/zynq-cc108.dts | 75 
> 
>  3 files changed, 81 insertions(+)
>  create mode 100644 arch/arm/boot/dts/zynq-cc108.dts

Reviewed-by: Rob Herring 

[PATCH] powercap / RAPL: add support for Cannon Lake

[Joe Konno]

From: Joe Konno 

RAPL MSRs and handling for Cannon Lake are similar to Sky Lake and Kaby
Lake.

Signed-off-by: Joe Konno 
---
 drivers/powercap/intel_rapl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 35636e1d8a3d..295d8dcba48c 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1162,6 +1162,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
RAPL_CPU(INTEL_FAM6_SKYLAKE_X,  rapl_defaults_hsw_server),
RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core),
RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,   rapl_defaults_core),
+   RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE,  rapl_defaults_core),
 
RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT1,   rapl_defaults_byt),
RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,   rapl_defaults_cht),
-- 
2.14.1

Re: Regression in IPMI on 4.15.6

[Laura Abbott]

On 03/02/2018 05:46 AM, Corey Minyard wrote:

On 02/28/2018 01:07 PM, Corey Minyard wrote:

On 02/28/2018 08:17 AM, Corey Minyard wrote:

On 02/28/2018 07:53 AM, Corey Minyard wrote:

On 02/27/2018 05:55 PM, Laura Abbott wrote:

Hi,

Fedora got a bug report of a crash in IPMI on 4.15.6
https://bugzilla.redhat.com/show_bug.cgi?id=1549316
Unfortunately, it's only a screenshot but it's fairly
clear. It looks like a panic in the error handling path
in platform_device_unregister. Any ideas?





You may also run into another issue.  You can pull the
individual patch at

https://github.com/cminyard/linux-ipmi.git 
c8a1972e77dbe321ce5ce0247056e727234cbaec


Actually, it needed a few more tweaks.  Can you do change
426fa6179dae677134dfb37b21d057819418515b
instead?  It's "ipmi: Fix some error cleanup issues"

I can send you patches, if you like.  If you could test and get back
to me, that would be great.


Laura, have you had a chance to test this?  I'd like to get it in soon,
if possible.

Thanks,

-corey



Sorry, this got missed. I'll ask the reporter to reproduce today.



BTW, the IPMI setup in your system is incorrect.  SMBIOS says it's at a
memory address, but it's at an I/O address.  And the address given
doesn't appear to be a valid address, the value read doesn't appear
to be a valid value.

-corey



for that fix.

-corey


Yeah, this is fixed by 174134ac7602 "ipmi_si: Fix error
handling of platform device" in mainstream.

I guess I need to request a backport of this.

Thanks for reporting.

-corey



Thanks,
Laura

Re: [PATCH net V2] virtio-net: re enable XDP_REDIRECT for mergeable buffer

[Jesper Dangaard Brouer]

On Fri,  2 Mar 2018 17:29:14 +0800
Jason Wang  wrote:

> XDP_REDIRECT support for mergeable buffer was removed since commit
> 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable()
> case"). This is because we don't reserve enough tailroom for struct
> skb_shared_info which breaks XDP assumption. So this patch fixes this
> by reserving enough tailroom and using fixed size of rx buffer.
> 
> Signed-off-by: Jason Wang 
> ---
> Changes from V1:
> - do not add duplicated tracepoint when redirection fails

Acked-by: Jesper Dangaard Brouer 

I gave it a quick spin on my testlab, and cpumap seems to
work/not-crash now (if I managed to turn back config to
receive_mergeable() correctly ;-)).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net-next 5/5] net: mvpp2: jumbo frames support

[Thomas Petazzoni]

Hello,

On Fri,  2 Mar 2018 16:40:44 +0100, Antoine Tenart wrote:

>  /* Attach long pool to rxq */
> @@ -4551,7 +4559,7 @@ mvpp2_bm_pool_use(struct mvpp2_port *port, int pool, 
> int pkt_size)
>   struct mvpp2_bm_pool *new_pool = >priv->bm_pools[pool];
>   int num;
>  
> - if (pool < MVPP2_BM_SHORT || pool > MVPP2_BM_LONG) {
> + if (pool < MVPP2_BM_SHORT || pool > MVPP2_BM_JUMBO) {

pool could be an unsigned, which would avoid the need for
MVPP2_BM_SHORT.

And for the upper limit, you have a convenient MVPP2_BM_POOLS_NUM in
your mvpp2_bm_pool_log_num enum, so why not use if ?



>   netdev_err(port->dev, "Invalid pool %d\n", pool);
>   return NULL;
>   }
> @@ -4596,11 +4604,24 @@ mvpp2_bm_pool_use(struct mvpp2_port *port, int pool, 
> int pkt_size)
>  static int mvpp2_swf_bm_pool_init(struct mvpp2_port *port)
>  {
>   int rxq;
> + enum mvpp2_bm_pool_log_num long_log_pool, short_log_pool;
> +
> + /* If port pkt_size is higher than 1518B:
> +  * HW Long pool - SW Jumbo pool, HW Short pool - SW Short pool

The comment is wrong. In this case, the HW short pool is the SW long
pool.

> +  * else: HW Long pool - SW Long pool, HW Short pool - SW Short pool
> +  */
> + if (port->pkt_size > MVPP2_BM_LONG_PKT_SIZE) {
> + long_log_pool = MVPP2_BM_JUMBO;
> + short_log_pool = MVPP2_BM_LONG;

See here.

> + } else {
> + long_log_pool = MVPP2_BM_LONG;
> + short_log_pool = MVPP2_BM_SHORT;
> + }


> + /* If port MTU is higher than 1518B:
> +  * HW Long pool - SW Jumbo pool, HW Short pool - SW Short pool

And the comment is wrong here as well :)

> +  * else: HW Long pool - SW Long pool, HW Short pool - SW Short pool
> +  */
> + if (pkt_size > MVPP2_BM_LONG_PKT_SIZE)
> + new_long_pool = MVPP2_BM_JUMBO;
> + else
> + new_long_pool = MVPP2_BM_LONG;
> +
> + if (new_long_pool != port->pool_long->id) {
> + /* Remove port from old short & long pool */
> + port->pool_long = mvpp2_bm_pool_use(port, port->pool_long->id,
> + port->pool_long->pkt_size);
> + port->pool_long->port_map &= ~(1 << port->id);

BIT(port->id) ?

> + port->pool_long = NULL;
> +
> + port->pool_short = mvpp2_bm_pool_use(port, port->pool_short->id,
> +  
> port->pool_short->pkt_size);
> + port->pool_short->port_map &= ~(1 << port->id);

Ditto.

> + if (port->pool_long->id == MVPP2_BM_JUMBO && port->id != 0) {

Again, all over the place we hardcode the fact that Jumbo frames can
only be used on port 0. I know port 0 is the only one that can do 10G,
but are there possibly some use cases where you may want Jumbo frame on
another port ?

This all really feels very hardcoded to me.

> + dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
> + dev->hw_features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
> + }
> +
>   dev->vlan_features |= features;
>   dev->gso_max_segs = MVPP2_MAX_TSO_SEGS;
>  
> - /* MTU range: 68 - 9676 */
> + /* MTU range: 68 - 9704 */
>   dev->min_mtu = ETH_MIN_MTU;
> - /* 9676 == 9700 - 20 and rounding to 8 */
> - dev->max_mtu = 9676;

How come we already had a max_mtu of 9676 without Jumbo frame support ?

> + /* 9704 == 9728 - 20 and rounding to 8 */
> + dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;

Is this correct for all ports ? Shouldn't the maximum MTU be different
between port 0 (that supports Jumbo frames) and the other ports ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

[PATCH 3/5] media: i2c: mt9t112: Fix code style issues

[Jacopo Mondi]

Fix code style issues reported by checkpatch run with --strict
options. Also fix other non reported style issues manually.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/mt9t112.c | 256 
 1 file changed, 118 insertions(+), 138 deletions(-)

diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index 6b77dff..6eaf3c6 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -35,8 +35,8 @@
 /* #define EXT_CLOCK 2400 */
 
 /
-   macro
-/
+ * macro
+ ***/
 /*
  * frame size
  */
@@ -74,8 +74,8 @@
 #define VAR8(id, offset) _VAR(id, offset, 0x8000)
 
 /
-   struct
-/
+ * struct
+ ***/
 struct mt9t112_format {
u32 code;
enum v4l2_colorspace colorspace;
@@ -96,8 +96,8 @@ struct mt9t112_priv {
 };
 
 /
-   supported format
-/
+ * supported format
+ ***/
 
 static const struct mt9t112_format mt9t112_cfmts[] = {
{
@@ -134,8 +134,8 @@ static const struct mt9t112_format mt9t112_cfmts[] = {
 };
 
 /
-   general function
-/
+ * general function
+ ***/
 static struct mt9t112_priv *to_mt9t112(const struct i2c_client *client)
 {
return container_of(i2c_get_clientdata(client),
@@ -162,15 +162,15 @@ static int __mt9t112_reg_read(const struct i2c_client 
*client, u16 command)
msg[1].buf   = buf;
 
/*
-* if return value of this function is < 0,
-* it mean error.
-* else, under 16bit is valid data.
+* If return value of this function is < 0, it means error, else,
+* below 16bit is valid data.
 */
ret = i2c_transfer(client->adapter, msg, 2);
if (ret < 0)
return ret;
 
memcpy(, buf, 2);
+
return swab16(ret);
 }
 
@@ -193,22 +193,19 @@ static int __mt9t112_reg_write(const struct i2c_client 
*client,
msg.buf   = buf;
 
/*
-* i2c_transfer return message length,
-* but this function should return 0 if correct case
+* i2c_transfer return message length, but this function should
+* return 0 if correct case.
 */
ret = i2c_transfer(client->adapter, , 1);
-   if (ret >= 0)
-   ret = 0;
 
-   return ret;
+   return ret >= 0 ? 0 : ret;
 }
 
 static int __mt9t112_reg_mask_set(const struct i2c_client *client,
- u16  command,
- u16  mask,
- u16  set)
+ u16  command, u16  mask, u16  set)
 {
int val = __mt9t112_reg_read(client, command);
+
if (val < 0)
return val;
 
@@ -243,11 +240,10 @@ static int __mt9t112_mcu_write(const struct i2c_client 
*client,
 }
 
 static int __mt9t112_mcu_mask_set(const struct i2c_client *client,
- u16  command,
- u16  mask,
- u16  set)
+ u16  command, u16  mask, u16  set)
 {
int val = __mt9t112_mcu_read(client, command);
+
if (val < 0)
return val;
 
@@ -262,7 +258,7 @@ static int mt9t112_reset(const struct i2c_client *client)
int ret;
 
mt9t112_reg_mask_set(ret, client, 0x001a, 0x0001, 0x0001);
-   msleep(1);
+   usleep_range(1000, 5000);
mt9t112_reg_mask_set(ret, client, 0x001a, 0x0001, 0x);
 
return ret;
@@ -301,38 +297,38 @@ static int mt9t112_clock_info(const struct i2c_client 
*client, u32 ext)
m = n & 0x00ff;
n = (n >> 8) & 0x003f;
 
-   enable = ((6000 > ext) || (54000 < ext)) ? "X" : "";
+   enable = ((ext < 6000) || (ext > 54000)) ? "X" : "";
dev_dbg(>dev, "EXTCLK  : %10u K %s\n", ext, enable);
 
-   vco = 2 * m * ext / (n+1);
-   enable = ((384000 > vco) || (768000 < vco)) ? "X" : "";
+   vco = 2 * m * ext / (n + 1);
+   enable = ((vco < 384000) || (vco > 768000)) 

[PATCH 2/5] media: i2c: mt9t112: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from mt9t112 sensor driver.
- Handle clk, gpios and power routines
- Register async subdev
- Remove deprecated g/s_mbus_config operations
- Remove driver flags
- Change driver interface and add kernel doc
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera framework.

As I don't have access to a working camera module, this change has only
been compile tested.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig   |  11 
 drivers/media/i2c/Makefile  |   1 +
 drivers/media/i2c/mt9t112.c | 147 +---
 include/media/i2c/mt9t112.h |  17 +++--
 4 files changed, 89 insertions(+), 87 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d7bba0e..541f0d28 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -788,6 +788,17 @@ config VIDEO_MT9T001
  This is a Video4Linux2 sensor-level driver for the Aptina
  (Micron) mt0t001 3 Mpixel camera.

+config VIDEO_MT9T112
+   tristate "Aptina MT9T111/MT9T112 support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Aptina
+ (Micron) MT9T111 and MT9T112 3 Mpixel camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mt9t112.
+
 config VIDEO_MT9V011
tristate "Micron mt9v011 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index cc30178..ea34aee 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
+obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
 obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index 297d22e..6b77dff 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * mt9t112 Camera Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2009 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -11,13 +14,11 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * 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 
@@ -26,10 +27,9 @@
 #include 

 #include 
-#include 
-#include 
 #include 
 #include 
+#include 

 /* you can check PLL/clock info */
 /* #define EXT_CLOCK 2400 */
@@ -85,16 +85,14 @@ struct mt9t112_format {

 struct mt9t112_priv {
struct v4l2_subdev   subdev;
-   struct mt9t112_camera_info  *info;
+   struct mt9t112_platform_data*info;
struct i2c_client   *client;
struct v4l2_rect frame;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
+   struct gpio_desc*standby_gpio;
const struct mt9t112_format *format;
int  num_formats;
-   u32  flags;
-/* for flags */
-#define INIT_DONE  (1 << 0)
-#define PCLK_RISING(1 << 1)
+   bool init_done;
 };

 /
@@ -341,12 +339,6 @@ static int mt9t112_clock_info(const struct i2c_client 
*client, u32 ext)
 }
 #endif

-static void mt9t112_frame_check(u32 *width, u32 *height, u32 *left, u32 *top)
-{
-   soc_camera_limit_side(left, width, 0, 0, MAX_WIDTH);
-   soc_camera_limit_side(top, height, 0, 0, MAX_HEIGHT);
-}
-
 static int mt9t112_set_a_frame_size(const struct i2c_client *client,
   u16 width,
   u16 height)
@@ -764,13 +756,40 @@ static int mt9t112_s_register(struct v4l2_subdev *sd,
 }
 #endif

+static int mt9t112_power_on(struct mt9t112_priv *priv)
+{
+   int ret;
+
+   ret = clk_prepare_enable(priv->clk);
+   if (ret)
+   return ret;
+
+   if (priv->standby_gpio) {
+   gpiod_set_value(priv->standby_gpio, 0);
+   msleep(100);
+   }
+
+   return 0;
+}
+
+static int mt9t112_power_off(struct mt9t112_priv *priv)
+{
+   

Re: [PATCH] xfs: Correctly invert xfs_buftarg LRU isolation logic

[Darrick J. Wong]

On Thu, Mar 01, 2018 at 02:48:00PM -0800, Darrick J. Wong wrote:
> On Wed, Feb 28, 2018 at 04:49:51PM +0100, Vratislav Bendel wrote:
> > The function xfs_buftarg_isolate() used by xfs buffer schrinkers 
> > to determine whether a buffer should be isolated and disposed 
> > from LRU list, has inverted logic.
> > 
> > Excerpt from xfs_buftarg_isolate():
> > /*
> >  * Decrement the b_lru_ref count unless the value is already
> >  * zero. If the value is already zero, we need to reclaim the
> >  * buffer, otherwise it gets another trip through the LRU.
> >  */
> > if (!atomic_add_unless(>b_lru_ref, -1, 0)) {
> > spin_unlock(>b_lock);
> > return LRU_ROTATE;
> > }
> > 
> > However, as per documentation, atomic_add_unless() returns _zero_
> > if the atomic value was originally equal to the specified *unsless* value.
> > 
> > Ultimately causing a xfs_buffer with ->b_lru_ref == 0, to take another 
> > trip around LRU, while isolating buffers with non-zero b_lru_ref.
> > 
> > Signed-off-by: Vratislav Bendel 
> > CC: Brian Foster 
> 
> Looks ok, will test...
> Reviewed-by: Darrick J. Wong 

This tests ok, but please address Brian and Luis' comments before I put
this in the upstream tream.

--D

> --D
> 
> > ---
> >  fs/xfs/xfs_buf.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> > index d1da2ee9e6db..ac669a10c62f 100644
> > --- a/fs/xfs/xfs_buf.c
> > +++ b/fs/xfs/xfs_buf.c
> > @@ -1708,7 +1708,7 @@ xfs_buftarg_isolate(
> >  * zero. If the value is already zero, we need to reclaim the
> >  * buffer, otherwise it gets another trip through the LRU.
> >  */
> > -   if (!atomic_add_unless(>b_lru_ref, -1, 0)) {
> > +   if (atomic_add_unless(>b_lru_ref, -1, 0)) {
> > spin_unlock(>b_lock);
> > return LRU_ROTATE;
> > }
> > -- 
> > 2.14.3
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] media: i2c: Copy mt9t112 soc_camera sensor driver

[Jacopo Mondi]

Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/mt9t112.c | 1163 +++
 1 file changed, 1163 insertions(+)
 create mode 100644 drivers/media/i2c/mt9t112.c

diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
new file mode 100644
index 000..297d22e
--- /dev/null
+++ b/drivers/media/i2c/mt9t112.c
@@ -0,0 +1,1163 @@
+/*
+ * mt9t112 Camera Driver
+ *
+ * Copyright (C) 2009 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver, mt9m111 driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright (C) 2008, Robert Jarzmik 
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * 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 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* you can check PLL/clock info */
+/* #define EXT_CLOCK 2400 */
+
+/
+   macro
+/
+/*
+ * frame size
+ */
+#define MAX_WIDTH   2048
+#define MAX_HEIGHT  1536
+
+/*
+ * macro of read/write
+ */
+#define ECHECKER(ret, x)   \
+   do {\
+   (ret) = (x);\
+   if ((ret) < 0)  \
+   return (ret);   \
+   } while (0)
+
+#define mt9t112_reg_write(ret, client, a, b) \
+   ECHECKER(ret, __mt9t112_reg_write(client, a, b))
+#define mt9t112_mcu_write(ret, client, a, b) \
+   ECHECKER(ret, __mt9t112_mcu_write(client, a, b))
+
+#define mt9t112_reg_mask_set(ret, client, a, b, c) \
+   ECHECKER(ret, __mt9t112_reg_mask_set(client, a, b, c))
+#define mt9t112_mcu_mask_set(ret, client, a, b, c) \
+   ECHECKER(ret, __mt9t112_mcu_mask_set(client, a, b, c))
+
+#define mt9t112_reg_read(ret, client, a) \
+   ECHECKER(ret, __mt9t112_reg_read(client, a))
+
+/*
+ * Logical address
+ */
+#define _VAR(id, offset, base) (base | (id & 0x1f) << 10 | (offset & 0x3ff))
+#define VAR(id, offset)  _VAR(id, offset, 0x)
+#define VAR8(id, offset) _VAR(id, offset, 0x8000)
+
+/
+   struct
+/
+struct mt9t112_format {
+   u32 code;
+   enum v4l2_colorspace colorspace;
+   u16 fmt;
+   u16 order;
+};
+
+struct mt9t112_priv {
+   struct v4l2_subdev   subdev;
+   struct mt9t112_camera_info  *info;
+   struct i2c_client   *client;
+   struct v4l2_rect frame;
+   struct v4l2_clk *clk;
+   const struct mt9t112_format *format;
+   int  num_formats;
+   u32  flags;
+/* for flags */
+#define INIT_DONE  (1 << 0)
+#define PCLK_RISING(1 << 1)
+};
+
+/
+   supported format
+/
+
+static const struct mt9t112_format mt9t112_cfmts[] = {
+   {
+   .code   = MEDIA_BUS_FMT_UYVY8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 0,
+   }, {
+   .code   = MEDIA_BUS_FMT_VYUY8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 1,
+   }, {
+   .code   = MEDIA_BUS_FMT_YUYV8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 2,
+   }, {
+   .code   = MEDIA_BUS_FMT_YVYU8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 3,
+   }, {
+   .code   = MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 8,
+   .order  = 2,
+   }, {
+   .code   = MEDIA_BUS_FMT_RGB565_2X8_LE,
+   

Re: [PATCH 1/7] genalloc: track beginning of allocations

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20180223]
[also build test ERROR on v4.16-rc3]
[cannot apply to linus/master mmotm/master char-misc/char-misc-testing 
v4.16-rc3 v4.16-rc2 v4.16-rc1]
[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/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20180302-232215
config: i386-randconfig-x004-201808 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c: In function 'gen_pool_free':
>> lib/genalloc.c:616:10: warning: format '%s' expects argument of type 'char 
>> *', but argument 2 has type 'struct gen_pool *' [-Wformat=]
 "Trying to free unallocated memory"
 ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
>> lib/genalloc.c:615:5: note: in expansion of macro 'WARN'
WARN(true,
^~~~
   lib/genalloc.c:617:23: note: format string is defined here
 " from pool %s", pool);
 ~^
   In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
>> lib/genalloc.c:624:17: error: implicit declaration of function 'exit_test'; 
>> did you mean 'exit_sem'? [-Werror=implicit-function-declaration]
   if (unlikely(exit_test(boundary < 0))) {
^
   include/linux/compiler.h:77:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c:626:16: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
WARN(true, "Corrupted pool %s", pool);
   ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   lib/genalloc.c:626:5: note: in expansion of macro 'WARN'
WARN(true, "Corrupted pool %s", pool);
^~~~
   lib/genalloc.c:634:10: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
 "Size provided differs from size "
 ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   lib/genalloc.c:633:5: note: in expansion of macro 'WARN'
WARN(true,
^~~~
   lib/genalloc.c:635:31: note: format string is defined here
 "measured from pool %s", pool);
 ~^
   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c:643:10: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
 "Unexpected bitmap collision while"
 ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   lib/genalloc.c:642:5: note: in expansion of macro 'WARN'
WARN(true,
^~~~
   lib/genalloc.c:644:36: note: format string is defined here
 " freeing memory in pool %s", pool);
 

[PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112

[Jacopo Mondi]

Add entry for Aptina/Micron MT9T112 camera sensor. The driver is
currently orphaned.

Signed-off-by: Jacopo Mondi 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 91ed6ad..1d8be25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9385,6 +9385,13 @@ S:   Maintained
 F: drivers/media/i2c/mt9t001.c
 F: include/media/i2c/mt9t001.h
 
+MT9T112 APTINA CAMERA SENSOR
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Orphan
+F: drivers/media/i2c/mt9t112.c
+F: include/media/i2c/mt9t112.h
+
 MT9V032 APTINA CAMERA SENSOR
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
-- 
2.7.4

Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash_shutdown

[Mark Rutland]

On Fri, Mar 02, 2018 at 04:44:13PM +, Mark Rutland wrote:
> On Fri, Mar 02, 2018 at 02:52:07PM +0100, Grzegorz Jaszczyk wrote:
> > 2018-03-02 14:15 GMT+01:00 Mark Rutland :
> > > Do you see this for a panic() in *any* interrupt handler?
> > 
> > I only test with this two interrupt handlers: watchdog and i2c but I
> > think it will behave the same with others - I can try with other if
> > you want, any suggestion which? Maybe with some PPI interrupt instead?
> > >
> > > Can you trigger the issue with magic-sysrq c, for example?
> > 
> > There is no problem when I trigger it via 'echo c >
> > /proc/sysrq-trigger' - it works well all the time. The problem appears
> > only, when the kexec/kdump procedure is triggered from interrupt
> > context
> 
> I'd meant that you'd send sysrq + c over serial, rather than writing to
> /proc/sysrq-trigger. That way, the panic will be in the context of the
> UART IRQ handler.
> 
> If that shows the issue, that's ilikely to be the easiest way for
> someone else to reproduce and investigate this.

FWIW, having just given this a go on my Juno R1 with v4.16-rc3
defconfig, the UART IRQs work fine in the crash kernel. That crash
happened in IRQ context:

[  384.653153] Call trace:
[  384.655581]  sysrq_handle_crash+0x20/0x30
[  384.659559]  __handle_sysrq+0xa8/0x1a0
[  384.663278]  handle_sysrq+0x28/0x38
[  384.666738]  pl011_fifo_to_tty+0x150/0x1a8
[  384.670801]  pl011_int+0x30c/0x430
[  384.674177]  __handle_irq_event_percpu+0x5c/0x148
[  384.678843]  handle_irq_event_percpu+0x34/0x88
[  384.683250]  handle_irq_event+0x48/0x78
[  384.687056]  handle_fasteoi_irq+0xa8/0x180
[  384.691119]  generic_handle_irq+0x24/0x38
[  384.695095]  __handle_domain_irq+0x5c/0xb0
[  384.699158]  gic_handle_irq+0x58/0xa8
[  384.702790]  el1_irq+0xb0/0x128
[  384.705907]  cpuidle_enter_state+0x138/0x220
[  384.710142]  cpuidle_enter+0x18/0x20
[  384.713690]  call_cpuidle+0x1c/0x38
[  384.717151]  do_idle+0x1b0/0x1e8
[  384.720354]  cpu_startup_entry+0x20/0x28
[  384.724246]  rest_init+0xd0/0xe0
[  384.727450]  start_kernel+0x3e4/0x410

On a separate note, the crashkernel complained:

[0.224730] CPU: CPUs started in inconsistent modes

... which is a separate disaster. I suspect the kexec code failed to punt the
crash CPU back to EL2 as it should have.

Thanks,
Mark.

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

[Linus Torvalds]

On Fri, Mar 2, 2018 at 8:22 AM, Kani, Toshi  wrote:
>
> FWIW, this thing is called MTRRs on x86, which are initialized by BIOS.

No.

Or rather, that's simply just another (small) part of it all - and an
architected and documented one at that.

Like the page table caching entries, the memory type range registers
are really just "secondary information". They don't actually select
between PCIe and RAM, they just affect the behavior on top of that.

The really nitty-gritty stuff is not architected, and generally not
documented outside (possibly) the BIOS writer's guide that is not made
public.

Those magical registers contain details like how the DRAM is
interleaved (if it is), what the timings are, where which memory
controller handles which memory range, and what are goes to PCIe etc.

Basically all the actual *steering* information is very much hidden
away from the kernel (and often from the BIOS too). The parts we see
at a higher level are just tuning and tweaks.

Note: the details differ _enormously_ between different chips. The
setup can be very different, with things like Knights Landing having
the external cache that can also act as local memory that isn't a
cache but maps at a different physical address instead etc. That's the
kind of steering I'm talking about - at a low level how physical
addresses get mapped to different cache partitions, memory
controllers, or to the IO system etc.

  Linus

Re: [PATCH 4.14 000/115] 4.14.24-stable review

[Greg Kroah-Hartman]

On Fri, Mar 02, 2018 at 05:58:12PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 02, 2018 at 07:24:09AM -0600, Dan Murphy wrote:
> > Greg
> > 
> > On 03/02/2018 02:50 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.14.24 release.
> > > There are 115 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > 
> > It seems we missed the patch.  It was supposed to be queued up for 4.14.24.
> > 
> >  ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds
> > 
> > [ commit 863204cfdae98626a92535ac928ad79f4d6b74ff upstream ]
> 
> I don't see the request to backport this, when was it sent?

Ah, I see it now, sorry about that.  Will get it next round.

thanks,

greg k-h

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

[Russell King - ARM Linux]

On Fri, Mar 02, 2018 at 08:22:52AM -0600, Andrew F. Davis wrote:
> > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> > index 84e5a9d..f0fab26 100644
> > --- a/drivers/gpio/gpiolib-of.c
> > +++ b/drivers/gpio/gpiolib-of.c
> > @@ -241,29 +241,17 @@ struct gpio_desc *of_find_gpio(struct device *dev, 
> > const char *con_id,
> >  
> > desc = of_get_named_gpiod_flags(dev->of_node, prop_name, idx,
> > _flags);
> > -   /*
> > -* -EPROBE_DEFER in our case means that we found a
> > -* valid GPIO property, but no controller has been
> > -* registered so far.
> > -*
> > -* This means we don't need to look any further for
> > -* alternate name conventions, and we should really
> > -* preserve the return code for our user to be able to
> > -* retry probing later.
> > -*/
> > -   if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
> > -   return desc;
> >  
> > -   if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
> > +   if (!IS_ERR(desc) || PTR_ERR(desc) != -ENOENT)
> 
> 
> I rather like the () so one doesn't always have to look up C operator
> precedence to verify..

Too many make it impossible to see which close paren ties up with
which open paren.  I've spent way too long in the past reformatting
code, where people think that () are a good thing, to work out what
the comparison is actually doing before then rewriting the damn
thing with less () and in a much clearer way.  I'm now convinced
that unnecessary () are a very bad thing as they severely harm
readability as test complexity increases.

> 
> 
> > break;
> > }
> >  
> > /* Special handling for SPI GPIOs if used */
> > -   if (IS_ERR(desc))
> > +   if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT)

These can be simplified to:

if (desc == ERR_PTR(-ENOENT))

since error pointers are unique - ERR_PTR(-ENOENT) is what was
returned as an error-pointer, and if IS_ERR(ERR_PTR(-ENOMENT)) etc
were false, we'd have big problems as it'd mean we couldn't detect
error pointers!

As an added bonus, they don't involve any operator precedence
questions either.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] xfs: Change URL for the project in xfs.txt

[Darrick J. Wong]

On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote:
> The oss.sgi.com doesn't exist any more.
> Change it to current project URL, https://xfs.wiki.kernel.org/
> 
> Signed-off-by: Masanari Iida 
> ---
>  Documentation/filesystems/xfs.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/filesystems/xfs.txt 
> b/Documentation/filesystems/xfs.txt
> index 3b9b5c149f32..4d9ff0a7f8e1 100644
> --- a/Documentation/filesystems/xfs.txt
> +++ b/Documentation/filesystems/xfs.txt
> @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive 
> use of
>  Btrees (directories, extents, free space) to aid both performance
>  and scalability.
>  
> -Refer to the documentation at http://oss.sgi.com/projects/xfs/
> +Refer to the documentation at https://xfs.wiki.kernel.org/
>  for further details.  This implementation is on-disk compatible
>  with the IRIX version of XFS.

Looks ok,
Reviewed-by: Darrick J. Wong 

--D

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

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

[Linus Torvalds]

On Fri, Mar 2, 2018 at 8:57 AM, Linus Torvalds
 wrote:
>
> Like the page table caching entries, the memory type range registers
> are really just "secondary information". They don't actually select
> between PCIe and RAM, they just affect the behavior on top of that.

Side note: historically the two may have been almost the same, since
the CPU only had one single unified bus for "memory" (whether that was
memory-mapped PCI or actual RAM). The steering was external.

But even back then you had extended bits to specify things like how
the 640k-1M region got remapped - which could depend on not just the
address, but on whether you read or wrote to it.  The "lost" 384kB of
RAM could either be remapped at a different address, or could be used
for shadowing the (slow) ROM contents, or whatever.

  Linus

Re: [PATCH v4 04/10] pinctrl: actions: Add Actions S900 pinctrl driver

[Manivannan Sadhasivam]

Hi Linus,

On Fri, Mar 02, 2018 at 02:21:37PM +0100, Linus Walleij wrote:
> On Fri, Mar 2, 2018 at 4:50 AM, Manivannan Sadhasivam
>  wrote:
> 
> > Add pinctrl driver for Actions Semi S900 SoC. The driver supports
> > pinctrl, pinmux and pinconf functionalities through a range of registers
> > common to both gpio driver and pinctrl driver.
> >
> > Pinmux functionality is available only for the pin groups while the
> > pinconf functionality is available for both pin groups and individual
> > pins.
> >
> > Signed-off-by: Manivannan Sadhasivam 
> 
> Seems like this is pretty much finished.
> 
> Let's see if you can collect some ACKs before we apply it.
> 

Andreas is at Embedded World conference. I hope once he is
back, he will have a look at this patchset.

> Now just minor things remain.
> 
> Random chosen example:
> 
> > +static unsigned int lvds_e_drv_pads[] = {
> > +   LVDS_EEP,
> > +   LVDS_EEN,
> > +   LVDS_EDP,
> > +   LVDS_EDN,
> > +   LVDS_ECP,
> > +   LVDS_ECN,
> > +   LVDS_EBP,
> > +   LVDS_EBN,
> > +};
> > +
> > +static unsigned int sd0_d3_d0_drv_pads[] = {
> > +   SD0_D3,
> > +   SD0_D2,
> > +   SD0_D1,
> > +   SD0_D0,
> > +};
> 
> People (e.g. Torvalds) sometimes get upset with files with too many lines
> in them. This file has a lot of lines. A lot of pin control drivers try to cut
> down the lines with macros, and you do it in some places too,
> would you consider to see if you can cut down these tables with
> macros?
> 
> S900_PADS(LVDS_EEP, LVDS_EEN, LVDS_EDP, LVDS_EDN,
> LVDS_ECP, LVDS_ECN, LVDS_EBP, LVDS_EBN);
> S900_PADS(SD0_D3, SD0_D2, SD0_D1, SD0_D0);
> 

I don't think it would be efficient to use macros here. However, I can
align the pads and func definitions in a single line. This will also
save a considerable amount of space.

Thanks,
Mani

> Would be so much more compact.
> 
> It's not the biggest problem though.
> 
> Yours,
> Linus Walleij

Re: [PATCH v4 3/3] mm/free_pcppages_bulk: prefetch buddy while not holding lock

[Vlastimil Babka]

On 03/01/2018 03:00 PM, Michal Hocko wrote:
> On Thu 01-03-18 14:28:45, Aaron Lu wrote:
>> When a page is freed back to the global pool, its buddy will be checked
>> to see if it's possible to do a merge. This requires accessing buddy's
>> page structure and that access could take a long time if it's cache cold.
>>
>> This patch adds a prefetch to the to-be-freed page's buddy outside of
>> zone->lock in hope of accessing buddy's page structure later under
>> zone->lock will be faster. Since we *always* do buddy merging and check
>> an order-0 page's buddy to try to merge it when it goes into the main
>> allocator, the cacheline will always come in, i.e. the prefetched data
>> will never be unused.
>>
>> In the meantime, there are two concerns:
>> 1 the prefetch could potentially evict existing cachelines, especially
>>   for L1D cache since it is not huge;
>> 2 there is some additional instruction overhead, namely calculating
>>   buddy pfn twice.
>>
>> For 1, it's hard to say, this microbenchmark though shows good result but
>> the actual benefit of this patch will be workload/CPU dependant;
>> For 2, since the calculation is a XOR on two local variables, it's expected
>> in many cases that cycles spent will be offset by reduced memory latency
>> later. This is especially true for NUMA machines where multiple CPUs are
>> contending on zone->lock and the most time consuming part under zone->lock
>> is the wait of 'struct page' cacheline of the to-be-freed pages and their
>> buddies.
>>
>> Test with will-it-scale/page_fault1 full load:
>>
>> kernel  Broadwell(2S)  Skylake(2S)   Broadwell(4S)  Skylake(4S)
>> v4.16-rc2+  90342157971818   13667135   15677465
>> patch2/39536374 +5.6%  8314710 +4.3% 14070408 +3.0% 16675866 +6.4%
>> this patch 10338868 +8.4%  8544477 +2.8% 14839808 +5.5% 17155464 +2.9%
>> Note: this patch's performance improvement percent is against patch2/3.
> 
> I am really surprised that this has such a big impact.

It's even stranger to me. Struct page is 64 bytes these days, exactly a
a cache line. Unless that changed, Intel CPUs prefetched a "buddy" cache
line (that forms an aligned 128 bytes block with the one we touch).
Which is exactly a order-0 buddy struct page! Maybe that implicit
prefetching stopped at L2 and explicit goes all the way to L1, can't
remember. Would that make such a difference? It would be nice to do some
perf tests with cache counters to see what is really going on...

Vlastimil

> Is this a win on
> other architectures as well?
>  
>> [changelog stole from Dave Hansen and Mel Gorman's comments]
>> https://lkml.org/lkml/2018/1/24/551
> 
> Please use http://lkml.kernel.org/r/ for references because
> lkml.org is quite unstable. It would be
> http://lkml.kernel.org/r/148a42d8-8306-2f2f-7f7c-86bc118f8...@intel.com
> here.
> 

Re: [PATCH v2 6/8] arm64: zynqmp: Add support for Xilinx zcu111-revA

[Rob Herring]

On Fri, Feb 23, 2018 at 03:40:28PM +0100, Michal Simek wrote:
> Xilinx zcu111 is a customer board. It is reusing some parts from zcu102.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Remove i2c mw u-boot commands
> - Use i2c-mux instead of i2cswitch
> - Use clock generator without numbers.
> - Record compatible string to xilinx.txt
> 
>  Documentation/devicetree/bindings/arm/xilinx.txt  |   3 +
>  arch/arm64/boot/dts/xilinx/Makefile   |   1 +
>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts | 446 
> ++
>  3 files changed, 450 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt 
> b/Documentation/devicetree/bindings/arm/xilinx.txt
> index 8503fabf90ee..c2bc75774010 100644
> --- a/Documentation/devicetree/bindings/arm/xilinx.txt
> +++ b/Documentation/devicetree/bindings/arm/xilinx.txt
> @@ -32,3 +32,6 @@ Additional compatible strings:
>  
>  - Xilinx evaluation board zcu106
>"xlnx,zynqmp-zcu106-revA", "xlnx,zynqmp-zcu106"
> +
> +- Xilinx evaluation board zcu111
> +  "xlnx,zynqmp-zcu111-revA", "xlnx,zynqmp-zcu111"
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile 
> b/arch/arm64/boot/dts/xilinx/Makefile
> index 922c5da39600..d15c9dc1d8f2 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-revB.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu111-revA.dtb
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts 
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
> new file mode 100644
> index ..f07f6dafb417
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
> @@ -0,0 +1,446 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Xilinx ZynqMP ZCU111
> + *
> + * (C) Copyright 2017 - 2018, Xilinx, Inc.
> + *
> + * Michal Simek 
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp.dtsi"
> +#include "zynqmp-clk.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + model = "ZynqMP ZCU111 RevA";
> + compatible = "xlnx,zynqmp-zcu111-revA", "xlnx,zynqmp-zcu111", 
> "xlnx,zynqmp";
> +
> + aliases {
> + ethernet0 = 
> + gpio0 = 
> + i2c0 = 
> + i2c1 = 
> + mmc0 = 
> + rtc0 = 
> + serial0 = 
> + serial1 = 
> + usb0 = 

Same comments on aliases.

Otherwise,

Reviewed-by: Rob Herring 

Re: [PATCH v2 7/8] arm64: zynqmp: Add support for Xilinx zc12XX boards

[Rob Herring]

On Fri, Feb 23, 2018 at 03:40:29PM +0100, Michal Simek wrote:
> These 3 boards requires minimal support to get Linux up and running.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Record compatible string to xilinx.txt
> 
>  Documentation/devicetree/bindings/arm/xilinx.txt  |  9 
>  arch/arm64/boot/dts/xilinx/Makefile   |  3 ++
>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts | 54 
> +++
>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts | 42 ++
>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts | 42 ++
>  5 files changed, 150 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts

Reviewed-by: Rob Herring 

Re: [PATCH] arm64/debug: Fix registers on sleeping tasks

[Mark Rutland]

On Fri, Mar 02, 2018 at 06:01:31PM +, Will Deacon wrote:
> On Thu, Mar 01, 2018 at 11:38:03AM -0800, Douglas Anderson wrote:
> > This is the equivalent of commit 001bf455d206 ("ARM: 8428/1: kgdb: Fix
> > registers on sleeping tasks") but for arm64.  Nuff said.
> 
> It's a pity that 001bf455d206 doesn't explain *why* past_pt_regs doesn't
> work.

The task_pt_regs are the userspace regs at the highest address on the
kernel stack:

#define task_pt_regs(p) \
((struct pt_regs *)(THREAD_SIZE + task_stack_page(p)) - 1)

... for kernel tasks, that's meaningless, and for user tasks, that won't
correspond to kernel state.

> > diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> > index 2122cd187f19..01285d4dcdc3 100644
> > --- a/arch/arm64/kernel/kgdb.c
> > +++ b/arch/arm64/kernel/kgdb.c
> > @@ -138,14 +138,26 @@ int dbg_set_reg(int regno, void *mem, struct pt_regs 
> > *regs)
> >  void
> >  sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct 
> > *task)
> >  {
> > -   struct pt_regs *thread_regs;
> > +   struct thread_struct *thread = >thread;
> > +   struct cpu_context *cpu_context = >cpu_context;

We can do this in one go:

struct cpu_context *cpu_context = >thread.cpu_context;

... since we don't need the thread variable otherwise.

> >  
> > /* Initialize to zero */
> > memset((char *)gdb_regs, 0, NUMREGBYTES);
> > -   thread_regs = task_pt_regs(task);
> > -   memcpy((void *)gdb_regs, (void *)thread_regs->regs, GP_REG_BYTES);
> > -   /* Special case for PSTATE (check comments in asm/kgdb.h for details) */
> > -   dbg_get_reg(33, gdb_regs + GP_REG_BYTES, thread_regs);
> > +
> > +   gdb_regs[19] = cpu_context->x19;
> > +   gdb_regs[20] = cpu_context->x20;
> > +   gdb_regs[21] = cpu_context->x21;
> > +   gdb_regs[22] = cpu_context->x22;
> > +   gdb_regs[23] = cpu_context->x23;
> > +   gdb_regs[24] = cpu_context->x24;
> > +   gdb_regs[25] = cpu_context->x25;
> > +   gdb_regs[26] = cpu_context->x26;
> > +   gdb_regs[27] = cpu_context->x27;
> > +   gdb_regs[28] = cpu_context->x28;
> > +   gdb_regs[29] = cpu_context->fp;
> > +
> > +   gdb_regs[31] = cpu_context->sp;
> > +   gdb_regs[32] = cpu_context->pc;

Are the other reg fields initialised elsewhere?

We might want to zero them here.

Thanks,
Mark.

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

[Daniel Kurtz]

On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko 
wrote:

> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz  wrote:
> > On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <
andy.shevche...@gmail.com>
> > wrote:

> > "earlycon simply does not utilize the information".
> >
> > earlycon parses iotype, mapbase and baud (from options).  However, it is
> > hard-coded to assume that the clock used to generate the UART bitclock
is
> > always "BASE_BAUD * 16" (1843200).  While this may be true for many
UARTs,
> > it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48
MHz
> > clock.  The main 8250_dw driver uses devm_clk_get to get the "baudclk"
and
> > uses its rate to initialize uartclk.  For AMD CZ/ST, this "baudclk" is
> > actually a set up in acpi_apd.c when there is an acpi match for
"AMD0020",
> > with a rate read from the .fixed_clk_rate param of the corresponding
> > apd_device_desc.
> >
> > This patch attempts to add a way to inform earlycon about this clock.
As
> > noted above, the information is actually already in the kernel and used
by
> > 8250_dw - I would happy be to hear recommendations for wiring this data
> > into earlycon that doesn't require adding another command line arg.

> And it should not require that for sure!

> I would look to this later. It's late here. I need to do a bit of
> research for the answer.

> > I see that support was also added recently to earlycon to let it use
ACPI
> > SPCR to choose a console and configure its parameters... but AFAICT,
this
> > path also doesn't allow specifying the uart clock.

> Fix your firmware then. It should set console to 115200 like (almost)
> everyone does.
> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.

The console is 115200 when it is enabled.  However, the firmware does not
always enable it by default.
The problem is that the UART IP block has a fixed 48 MHz input clock, but
earlycon assumes this clock is always 1843200.

I looked a bit further, and I think this patch (or something similar) is
still required to teach generic earlycon how to handle an explicit
port->uartclk (ie, one that is not 1843200).
The extended string can then be explicitly set on the kernel command line
for this kind of hardware.

In addition, we can add another patch with a new quirk detector in
drivers/acpi/spcr.c:acpi_parse_spcr() to handle this hardware.
acpi_parse_spcr() can then use the extended option string to pass in the
appropriate UART clock to setup_eralycon().

This would again allow a user to just use the simple command line parameter
"earlycon" if the device's firmware has a correctly confiured ACPI SPCR
table.

Thanks,
-Dan

Re: [PATCH v2 2/8] arm64: zynqmp: Add support for Xilinx zcu100-revC

[Michal Simek]

On 2.3.2018 17:40, Rob Herring wrote:
> On Fri, Feb 23, 2018 at 03:40:24PM +0100, Michal Simek wrote:
>> This board has 2GB of memory, i2c, sd, wifi sdio, spis, uarts, display
>> port and usbs.
>> Board is using fixed clocks because clock driver hasn't been merged yet.
> 
> Please get rid of the separate clocks dts file when it is merged.

Will do.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

[Christoph Hellwig]

On Thu, Mar 01, 2018 at 11:53:16PM +, Stephen  Bates wrote:
> > There's a meaningful difference between writing to an NVMe CMB vs PMR
> 
> When the PMR spec becomes public we can discuss how best to integrate it into 
> the P2P framework (if at all) ;-).

http://nvmexpress.org/wp-content/uploads/NVM-Express-1.3-Ratified-TPs.zip

[PATCH v2] block: Add default switch case to blk_pm_allow_request() to kill warning

[Geert Uytterhoeven]

With gcc 4.9.0:

block/blk-core.c: In function 'blk_pm_allow_request':
block/blk-core.c:2653:2: warning: enumeration value 'RPM_ACTIVE' not 
handled in switch [-Wswitch]
  switch (rq->q->rpm_status) {
  ^

Convert the return statement below the switch() block into a default
case to fix this.

Fixes: e4f36b249b4d4e75 ("block: fix peeking requests during PM")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Christoph Hellwig 
---
v2:
  - Add Reviewed-by,
  - Update line number.
---
 block/blk-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 2d1a7bbe063437bf..81d2928ce4e9d370 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2656,9 +2656,9 @@ static bool blk_pm_allow_request(struct request *rq)
return rq->rq_flags & RQF_PM;
case RPM_SUSPENDED:
return false;
+   default:
+   return true;
}
-
-   return true;
 }
 #else
 static bool blk_pm_allow_request(struct request *rq)
-- 
2.7.4

Re: [PATCH v1 02/19] dt-bindings: cpufreq: mediatek: use - instead of _ in examples

[Rob Herring]

On Fri, Feb 23, 2018 at 06:16:22PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> It should be good that no use "_" is in examples. Consequently,
> those nodes in certain files which have an inappropriate name containing
> "_" are all being replaced with "-".
> 
> Signed-off-by: Sean Wang 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: linux...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH v1 04/19] dt-bindings: arm: mediatek: add support for more mt7623 reference boards

[Rob Herring]

On Fri, Feb 23, 2018 at 06:16:24PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Update binding document for more mt7623[A,N] reference boards being
> supported.
> 
> Signed-off-by: Sean Wang 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/arm/mediatek.txt | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Rob Herring 

[PATCH] perf record: Fix crash in pipe mode

[Jiri Olsa]

Currently we can crash perf record when running in pipe mode, like:

  $ perf record ls | perf report
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  perf: Segmentation fault
  Error:
  The - file has no samples!

The callstack of the crash is:

0x00515242 in perf_event__synthesize_event_update_name
  3513ev = event_update_event__new(len + 1, 
PERF_EVENT_UPDATE__NAME, evsel->id[0]);
  (gdb) bt
  #0  0x00515242 in perf_event__synthesize_event_update_name
  #1  0x005158a4 in perf_event__synthesize_extra_attr
  #2  0x00443347 in record__synthesize
  #3  0x004438e3 in __cmd_record
  #4  0x0044514e in cmd_record
  #5  0x004cbc95 in run_builtin
  #6  0x004cbf02 in handle_internal_command
  #7  0x004cc054 in run_argv
  #8  0x004cc422 in main

The reason of the crash is that the evsel does not have ids array
allocated and the pipe's synthesize code tries to access it.

We don't force evsel ids allocation when we have single event,
because it's not needed. However we need it when we are in pipe
mode even for single event as a key for evsel update event.

Fixing this by forcing evsel ids allocation event for single
event, when we are in pipe mode.

Link: http://lkml.kernel.org/n/tip-xbh5ca1azdcdqyep653vb...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-record.c | 9 +
 tools/perf/perf.h   | 1 +
 tools/perf/util/record.c| 8 ++--
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index a60f398cbc24..eeef1143bae3 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -881,6 +881,15 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
}
}
 
+   /*
+* If we have just single event and are sending data
+* through pipe, we need to force the ids allocation,
+* because we synthesize event name through the pipe
+* and need the id for that.
+*/
+   if (data->is_pipe && rec->evlist->nr_entries == 1)
+   rec->opts.sample_id = true;
+
if (record__open(rec) != 0) {
err = -1;
goto out_child;
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 007e0dfd5ce3..8fec1abd0f1f 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -62,6 +62,7 @@ struct record_opts {
bool overwrite;
bool ignore_missing_thread;
bool strict_freq;
+   bool sample_id;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index 3878c503f464..867f5937ebb7 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c
@@ -138,6 +138,7 @@ void perf_evlist__config(struct perf_evlist *evlist, struct 
record_opts *opts,
struct perf_evsel *evsel;
bool use_sample_identifier = false;
bool use_comm_exec;
+   bool sample_id = opts->sample_id;
 
/*
 * Set the evsel leader links before we configure attributes,
@@ -164,8 +165,7 @@ void perf_evlist__config(struct perf_evlist *evlist, struct 
record_opts *opts,
 * match the id.
 */
use_sample_identifier = perf_can_sample_identifier();
-   evlist__for_each_entry(evlist, evsel)
-   perf_evsel__set_sample_id(evsel, use_sample_identifier);
+   sample_id = true;
} else if (evlist->nr_entries > 1) {
struct perf_evsel *first = perf_evlist__first(evlist);
 
@@ -175,6 +175,10 @@ void perf_evlist__config(struct perf_evlist *evlist, 
struct record_opts *opts,
use_sample_identifier = perf_can_sample_identifier();
break;
}
+   sample_id = true;
+   }
+
+   if (sample_id) {
evlist__for_each_entry(evlist, evsel)
perf_evsel__set_sample_id(evsel, use_sample_identifier);
}
-- 
2.13.6

[RFC 0/3] arch/x86/kvm: Introduce PLE(pause loop exit) logic in SVM

[Babu Moger]

Started working on bringing the PLE(pause loop exit) logic from VMX
to SVM. We noticed some improvements in certain cases where numerious
pause is generated.

Please take a look. If you have any suggestions to make things better,
let me know.

Babu Moger (3):
  arch/x86/kvm: SVM: Introduce pause filter threshold
  arch/x86/kvm: VMX: Bring the common code to header file
  arch/x86/kvm: SVM: Introduce pause loop exit logic in SVM

 arch/x86/include/asm/svm.h |   3 +-
 arch/x86/kvm/svm.c | 116 -
 arch/x86/kvm/vmx.c |  53 -
 arch/x86/kvm/x86.h |  35 ++
 4 files changed, 162 insertions(+), 45 deletions(-)

-- 
1.8.3.1

[RFC 2/3] arch/x86/kvm: VMX: Bring the common code to header file

[Babu Moger]

This patch is brings some of the code from vmx to x86.h. We can
share this code between vmx and svm. Modified couple of functions
to make it common. No functional change.

Signed-off-by: Babu Moger 
---
 arch/x86/kvm/vmx.c | 53 ++---
 arch/x86/kvm/x86.h | 34 ++
 2 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c829d89..6b9fa7e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -156,25 +156,19 @@
  * Time is measured based on a counter that runs at the same rate as the TSC,
  * refer SDM volume 3b section 21.6.13 & 22.1.3.
  */
-#define KVM_VMX_DEFAULT_PLE_GAP   128
-#define KVM_VMX_DEFAULT_PLE_WINDOW4096
-#define KVM_VMX_DEFAULT_PLE_WINDOW_GROW   2
-#define KVM_VMX_DEFAULT_PLE_WINDOW_SHRINK 0
-#define KVM_VMX_DEFAULT_PLE_WINDOW_MAX\
-   INT_MAX / KVM_VMX_DEFAULT_PLE_WINDOW_GROW
-
-static int ple_gap = KVM_VMX_DEFAULT_PLE_GAP;
+
+static int ple_gap = KVM_DEFAULT_PLE_GAP;
 module_param(ple_gap, int, S_IRUGO);
 
-static int ple_window = KVM_VMX_DEFAULT_PLE_WINDOW;
+static int ple_window = KVM_DEFAULT_PLE_WINDOW;
 module_param(ple_window, int, S_IRUGO);
 
 /* Default doubles per-vcpu window every exit. */
-static int ple_window_grow = KVM_VMX_DEFAULT_PLE_WINDOW_GROW;
+static int ple_window_grow = KVM_DEFAULT_PLE_WINDOW_GROW;
 module_param(ple_window_grow, int, S_IRUGO);
 
 /* Default resets per-vcpu window every exit to ple_window. */
-static int ple_window_shrink = KVM_VMX_DEFAULT_PLE_WINDOW_SHRINK;
+static int ple_window_shrink = KVM_DEFAULT_PLE_WINDOW_SHRINK;
 module_param(ple_window_shrink, int, S_IRUGO);
 
 /* Default is to compute the maximum so we can never overflow. */
@@ -6640,40 +6634,13 @@ static int handle_invalid_guest_state(struct kvm_vcpu 
*vcpu)
return ret;
 }
 
-static int __grow_ple_window(int val)
-{
-   if (ple_window_grow < 1)
-   return ple_window;
-
-   val = min(val, ple_window_actual_max);
-
-   if (ple_window_grow < ple_window)
-   val *= ple_window_grow;
-   else
-   val += ple_window_grow;
-
-   return val;
-}
-
-static int __shrink_ple_window(int val, int modifier, int minimum)
-{
-   if (modifier < 1)
-   return ple_window;
-
-   if (modifier < ple_window)
-   val /= modifier;
-   else
-   val -= modifier;
-
-   return max(val, minimum);
-}
-
 static void grow_ple_window(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
int old = vmx->ple_window;
 
-   vmx->ple_window = __grow_ple_window(old);
+   vmx->ple_window = __grow_ple_window(old, ple_window, ple_window_grow,
+   ple_window_actual_max);
 
if (vmx->ple_window != old)
vmx->ple_window_dirty = true;
@@ -6686,7 +6653,7 @@ static void shrink_ple_window(struct kvm_vcpu *vcpu)
struct vcpu_vmx *vmx = to_vmx(vcpu);
int old = vmx->ple_window;
 
-   vmx->ple_window = __shrink_ple_window(old,
+   vmx->ple_window = __shrink_ple_window(old, ple_window,
  ple_window_shrink, ple_window);
 
if (vmx->ple_window != old)
@@ -6706,8 +6673,8 @@ static void shrink_ple_window(struct kvm_vcpu *vcpu)
 static void update_ple_window_actual_max(void)
 {
ple_window_actual_max =
-   __shrink_ple_window(max(ple_window_max, ple_window),
-   ple_window_grow, INT_MIN);
+   __shrink_ple_window(max(ple_window_max, ple_window),
+   ple_window, ple_window_grow, INT_MIN);
 }
 
 /*
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index d0b95b7..d1fb7bb 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -9,7 +9,41 @@
 #include "kvm_cache_regs.h"
 
 #define MSR_IA32_CR_PAT_DEFAULT  0x0007040600070406ULL
+#define KVM_DEFAULT_PLE_GAP   128
+#define KVM_DEFAULT_PLE_WINDOW4096
+#define KVM_DEFAULT_PLE_WINDOW_GROW   2
+#define KVM_DEFAULT_PLE_WINDOW_SHRINK 0
+#define KVM_VMX_DEFAULT_PLE_WINDOW_MAX\
+   (INT_MAX / KVM_DEFAULT_PLE_WINDOW_GROW)
+
+static inline int __grow_ple_window(int val, int base, int modifier, int max)
+{
+   if (modifier < 1)
+   return base;
+
+   val = min(val, max);
+
+   if (modifier < base)
+   val *= modifier;
+   else
+   val += modifier;
+
+   return val;
+}
 
+static inline int __shrink_ple_window(int val, int base, int modifier,
+ int minimum)
+{
+   if (modifier < 1)
+   return base;
+
+   if (modifier < base)
+   val /= modifier;
+   else
+   val -= modifier;
+
+   return max(val, minimum);
+}
 static inline void kvm_clear_exception_queue(struct kvm_vcpu 

Re: [PATCH v2 10/10] nvmet: Optionally use PCI P2P memory

[Jason Gunthorpe]

On Thu, Mar 01, 2018 at 11:57:43PM +, Stephen  Bates wrote:
> > We don't want to lump these all together without knowing which region 
> > you're allocating from, right?
> 
> In all seriousness I do agree with you on these Keith in the long
> term. We would consider adding property flags for the memory as it
> is added to the p2p core and then the allocator could evolve to
> intelligently dish it out. Attributes like endurance, latency and
> special write commit requirements could all become attributes in
> time. Perhaps one more reason for a central entity for p2p memory
> allocation so this code does not end up having to go into many
> different drivers?

I fear we will find that every kind of P2P memory has special
allocator requirements and dumping it all into one giant pool is not
going to be helpful.

This allocator is already seems not useful for the P2P target memory
on a Mellanox NIC due to the way it has a special allocation flow
(windowing) and special usage requirements..

Nor can it be usefull for the doorbell memory in the NIC.

Both of these are existing use cases for P2P with out of tree patches..

The allocator seems to only be able to solve the CMB problem, and I
think due to that it is better to put this allocator in the NVMe
driver and not the core code.. At least until we find a 2nd user that
needs the same allocation scheme...

Jason

Re: [PATCH v2 00/11] perf events patches for improved ARM64 support

[John Garry]

Can you check the modifications to the ARM64 JSONs you originally submitted in the 
patchset please?>
If they are not checked, I'll have to see if the maintainers will accept 
without your review. If not, I'll have to drop them.


I am seeing issue(log below) with this patchset on our platfrom.
i have tried using your v2 branch [1]

root@borg-1>perf_acme>> ./perf --version
perf version 4.16.rc1.g087f7ca
root@borg-1>perf_acme>> ./perf stat -e bus_access_rd sleep 1

 Performance counter stats for 'sleep 1':

23,099  bus_access_rd

   1.000708516 seconds time elapsed

root@borg-1>perf_acme>> cd -
/ganapat/perf/linux-hisi/tools/perf
root@borg-1>perf>> ./perf --version
perf version 4.16.rc1.gcb5a74
root@borg-1>perf>> ./perf stat -e bus_access_rd sleep 1

 Performance counter stats for 'sleep 1':

 0  bus_access_rd

   1.000709162 seconds time elapsed

root@borg-1>perf>>


[1] https://github.com/hisilicon/linux-hisi.git


Hi Ganapatrao,

Thanks for the notification. Let me check this.

Regards,
John





Hi John,

I will take a look at the patches this weekend and give feedback beginning of 
next week. -Will



Thanks,
John


Acked-by: Jiri Olsa 

thanks,
jirka

.


thanks
Ganapat








___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


.

Re: [PATCH 2/3] rpmsg: core: make rpmsg bus DMA capable

[Srinivas Kandagatla]

Thanks for your time,

On 02/03/18 16:14, Robin Murphy wrote:

On 02/03/18 14:55, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 

Many of the rpmsg clients like audio drivers need to allocate
dma memory. Make this bus DMA capable so that the child devices
can use dma apis.


AFAICS after 15 minutes in the docs and code, the rpmsg "bus" is a 
virtual one based around shared-memory mailbox communication, so I don't 
really see how DMA exists in that context - I think maybe that 
abstraction needs looking at.


However, from grepping through the DTs it seems at first glance like the 
non-trivial things under the "qcom,smd" bus mostly map to actual 
platform devices via the "qcom,smd-edge" property - if those platform 
devices are the physical DMA masters, they should be the ones used for 
DMA API operations.


Currently there are very limited rpmsg devices in the mainline that use 
dma. Only one I can think of is wcnss WIFI driver which models up itself 
into another layer of platform device. Not sure if the DMA was the 
reason to do that.


However am working on audio drivers [1] which I modeled up as children 
of the rpmsg bus, so the problem started. There is an IOMMU in between 
APPs and DSP which provides audio services.
There are also other projects like FastRPC which have used similar 
driver model which ended up with same issues.


It all depends on how you model your driver. Audio case we have a rpmsg 
channel which exposes audio functionality. so If we want to use the 
iommu/dma operations we have to add another layer of platform device.
Which also means that rpmsg channel notifications have to be passed to 
these platform devices in some way.


Am not 100% sure if this correct way to fix the issue.




Signed-off-by: Srinivas Kandagatla 
---
  drivers/rpmsg/rpmsg_core.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index e84c71f8d6ab..540a3f3567b8 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -472,6 +472,7 @@ struct bus_type rpmsg_bus = {
  .uevent= rpmsg_uevent,
  .probe= rpmsg_dev_probe,
  .remove= rpmsg_dev_remove,
+.force_dma= true,


Regardless of the above, would you really need to use this brute force 
hack instead of just fixing the DTs? I'm struggling to find which 
drivers might currently be relying on this :/


This is one of the two issues. dma-ranges might work in this case, but 
we still have iommu case.




Robin.


  };
  EXPORT_SYMBOL(rpmsg_bus);



thanks,
srini
[1]: https://lkml.org/lkml/2018/2/13/719

Re: [PATCH 2/2] drivers: soc: xilinx: Add ZynqMP power domain driver

[kbuild test robot]

Hi Jolly,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.16-rc3 next-20180302]
[cannot apply to xlnx/master mediatek/for-next]
[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/Jolly-Shah/drivers-soc-xilinx-Add-support-for-ZynqMP-power-domain-driver/20180302-213151
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> drivers/soc/xilinx/zynqmp/pm_domains.c:19:10: fatal error: 
>> linux/firmware/xilinx/zynqmp/firmware.h: No such file or directory
#include 
 ^
   compilation terminated.

vim +19 drivers/soc/xilinx/zynqmp/pm_domains.c

  > 19  #include 
20  

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


.config.gz
Description: application/gzip

[PATCH v3 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

[Lina Iyer]

Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated
TCS for active mode request, but drivers may still want to make active
requests from these RSCs. In such cases re-purpose the wake TCS to send
active state requests.

The requirement for this is that the driver is aware that the wake TCS
is being repurposed to send active request, hence the sleep and wake
TCSes be invalidated before the active request is sent.

Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/rpmh-rsc.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index e9f5a1f387fd..d9cfa7aaf49c 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -220,6 +220,7 @@ static struct tcs_group *get_tcs_for_msg(struct rsc_drv 
*drv,
struct tcs_request *msg)
 {
int type;
+   struct tcs_group *tcs;
 
switch (msg->state) {
case RPMH_ACTIVE_ONLY_STATE:
@@ -235,7 +236,22 @@ static struct tcs_group *get_tcs_for_msg(struct rsc_drv 
*drv,
return ERR_PTR(-EINVAL);
}
 
-   return get_tcs_of_type(drv, type);
+   /*
+* If we are making an active request on a RSC that does not have a
+* dedicated TCS for active state use, then re-purpose a wake TCS to
+* send active votes.
+* NOTE: The driver must be aware that this RSC does not have a
+* dedicated AMC, and therefore would invalidate the sleep and wake
+* TCSes before making an active state request.
+*/
+   tcs = get_tcs_of_type(drv, type);
+   if (msg->state == RPMH_ACTIVE_ONLY_STATE && IS_ERR(tcs)) {
+   tcs = get_tcs_of_type(drv, WAKE_TCS);
+   if (!IS_ERR(tcs))
+   rpmh_rsc_invalidate(drv);
+   }
+
+   return tcs;
 }
 
 static void send_tcs_response(struct tcs_response *resp)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 08/10] drivers: qcom: rpmh: allow requests to be sent asynchronously

[Lina Iyer]

Platform drivers that want to send a request but do not want to block
until the RPMH request completes have now a new API -
rpmh_write_async().

The API allocates memory and send the requests and returns the control
back to the platform driver. The tx_done callback from the controller is
handled in the context of the controller's thread and frees the
allocated memory. This API allows RPMH requests from atomic contexts as
well.

Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/rpmh.c | 52 +
 include/soc/qcom/rpmh.h |  8 
 2 files changed, 60 insertions(+)

diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index 8a04009075b8..a02d9f685b2b 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -35,6 +35,7 @@
.completion = q,\
.wait_count = c,\
.rc = rc,   \
+   .free = NULL,   \
}
 
 
@@ -61,6 +62,7 @@ struct cache_req {
  * @completion: triggered when request is done
  * @wait_count: count of waiters for this completion
  * @err: err return from the controller
+ * @free: the request object to be freed at tx_done
  */
 struct rpmh_request {
struct tcs_request msg;
@@ -69,6 +71,7 @@ struct rpmh_request {
atomic_t *wait_count;
struct rpmh_client *rc;
int err;
+   struct rpmh_request *free;
 };
 
 /**
@@ -114,6 +117,8 @@ void rpmh_tx_done(struct tcs_request *msg, int r)
   "RPMH TX fail in msg addr 0x%x, err=%d\n",
   rpm_msg->msg.payload[0].addr, r);
 
+   kfree(rpm_msg->free);
+
/* Signal the blocking thread we are done */
if (wc && atomic_dec_and_test(wc) && compl)
complete(compl);
@@ -257,6 +262,53 @@ static int __rpmh_write(struct rpmh_client *rc, enum 
rpmh_state state,
return ret;
 }
 
+static struct rpmh_request *__get_rpmh_msg_async(struct rpmh_client *rc,
+   enum rpmh_state state,
+   struct tcs_cmd *cmd, int n)
+{
+   struct rpmh_request *req;
+
+   if (IS_ERR_OR_NULL(rc) || !cmd || n <= 0 || n > MAX_RPMH_PAYLOAD)
+   return ERR_PTR(-EINVAL);
+
+   req = kcalloc(1, sizeof(*req), GFP_ATOMIC);
+   if (!req)
+   return ERR_PTR(-ENOMEM);
+
+   memcpy(req->cmd, cmd, n * sizeof(*cmd));
+
+   req->msg.state = state;
+   req->msg.payload = req->cmd;
+   req->msg.num_payload = n;
+   req->free = req;
+
+   return req;
+}
+
+/**
+ * rpmh_write_async: Write a set of RPMH commands
+ *
+ * @rc: The RPMh handle got from rpmh_get_dev_channel
+ * @state: Active/sleep set
+ * @cmd: The payload data
+ * @n: The number of elements in payload
+ *
+ * Write a set of RPMH commands, the order of commands is maintained
+ * and will be sent as a single shot.
+ */
+int rpmh_write_async(struct rpmh_client *rc, enum rpmh_state state,
+   struct tcs_cmd *cmd, int n)
+{
+   struct rpmh_request *rpm_msg;
+
+   rpm_msg = __get_rpmh_msg_async(rc, state, cmd, n);
+   if (IS_ERR(rpm_msg))
+   return PTR_ERR(rpm_msg);
+
+   return __rpmh_write(rc, state, rpm_msg);
+}
+EXPORT_SYMBOL(rpmh_write_async);
+
 /**
  * rpmh_write: Write a set of RPMH commands and block until response
  *
diff --git a/include/soc/qcom/rpmh.h b/include/soc/qcom/rpmh.h
index a3f1246ce49a..172a649f1a1c 100644
--- a/include/soc/qcom/rpmh.h
+++ b/include/soc/qcom/rpmh.h
@@ -15,6 +15,9 @@ struct rpmh_client;
 int rpmh_write(struct rpmh_client *rc, enum rpmh_state state,
  struct tcs_cmd *cmd, int n);
 
+int rpmh_write_async(struct rpmh_client *rc, enum rpmh_state state,
+   struct tcs_cmd *cmd, int n);
+
 struct rpmh_client *rpmh_get_client(struct platform_device *pdev);
 
 int rpmh_flush(struct rpmh_client *rc);
@@ -32,6 +35,11 @@ static inline int rpmh_write(struct rpmh_client *rc, enum 
rpmh_state state,
 static inline struct rpmh_client *rpmh_get_client(struct platform_device *pdev)
 { return ERR_PTR(-ENODEV); }
 
+static inline int rpmh_write_async(struct rpmh_client *rc,
+ enum rpmh_state state,
+ struct tcs_cmd *cmd, int n)
+{ return -ENODEV; }
+
 static inline int rpmh_flush(struct rpmh_client *rc)
 { return -ENODEV; }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

[Lina Iyer]

Active state requests are sent immediately to the mailbox controller,
while sleep and wake state requests are cached in this driver to avoid
taxing the mailbox controller repeatedly. The cached values will be sent
to the controller when the rpmh_flush() is called.

Generally, flushing is a system PM activity and may be called from the
system PM drivers when the system is entering suspend or deeper sleep
modes during cpuidle.

Also allow invalidating the cached requests, so they may be re-populated
again.

Signed-off-by: Lina Iyer 
---

Changes in v3:
- Remove locking for flush function
- Improve comments
---
 drivers/soc/qcom/rpmh.c | 208 +++-
 include/soc/qcom/rpmh.h |  10 +++
 2 files changed, 217 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index d95ea3fa8b67..8a04009075b8 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -6,11 +6,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -35,6 +37,22 @@
.rc = rc,   \
}
 
+
+/**
+ * cache_req : the request object for caching
+ *
+ * @addr: the address of the resource
+ * @sleep_val: the sleep vote
+ * @wake_val: the wake vote
+ * @list: linked list obj
+ */
+struct cache_req {
+   u32 addr;
+   u32 sleep_val;
+   u32 wake_val;
+   struct list_head list;
+};
+
 /**
  * rpmh_request: the message to be sent to rpmh-rsc
  *
@@ -57,9 +75,15 @@ struct rpmh_request {
  * rpmh_ctrlr: our representation of the controller
  *
  * @drv: the controller instance
+ * @cache: the list of cached requests
+ * @lock: synchronize access to the controller data
+ * @dirty: was the cache updated since flush
  */
 struct rpmh_ctrlr {
struct rsc_drv *drv;
+   struct list_head cache;
+   spinlock_t lock;
+   bool dirty;
 };
 
 /**
@@ -123,17 +147,91 @@ static int wait_for_tx_done(struct rpmh_client *rc,
return (ret > 0) ? 0 : -ETIMEDOUT;
 }
 
+static struct cache_req *__find_req(struct rpmh_client *rc, u32 addr)
+{
+   struct cache_req *p, *req = NULL;
+
+   list_for_each_entry(p, >ctrlr->cache, list) {
+   if (p->addr == addr) {
+   req = p;
+   break;
+   }
+   }
+
+   return req;
+}
+
+static struct cache_req *cache_rpm_request(struct rpmh_client *rc,
+ enum rpmh_state state,
+ struct tcs_cmd *cmd)
+{
+   struct cache_req *req;
+   struct rpmh_ctrlr *rpm = rc->ctrlr;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   req = __find_req(rc, cmd->addr);
+   if (req)
+   goto existing;
+
+   req = kzalloc(sizeof(*req), GFP_ATOMIC);
+   if (!req) {
+   req = ERR_PTR(-ENOMEM);
+   goto unlock;
+   }
+
+   req->addr = cmd->addr;
+   req->sleep_val = req->wake_val = UINT_MAX;
+   INIT_LIST_HEAD(>list);
+   list_add_tail(>list, >cache);
+
+existing:
+   switch (state) {
+   case RPMH_ACTIVE_ONLY_STATE:
+   if (req->sleep_val != UINT_MAX)
+   req->wake_val = cmd->data;
+   break;
+   case RPMH_WAKE_ONLY_STATE:
+   req->wake_val = cmd->data;
+   break;
+   case RPMH_SLEEP_STATE:
+   req->sleep_val = cmd->data;
+   break;
+   default:
+   break;
+   };
+
+   rpm->dirty = true;
+unlock:
+   spin_unlock_irqrestore(>lock, flags);
+
+   return req;
+}
+
 /**
- * __rpmh_write: send the RPMH request
+ * __rpmh_write: Cache and send the RPMH request
  *
  * @rc: The RPMH client
  * @state: Active/Sleep request type
  * @rpm_msg: The data that needs to be sent (payload).
+ *
+ * Cache the RPMH request and send if the state is ACTIVE_ONLY.
+ * SLEEP/WAKE_ONLY requests are not sent to the controller at
+ * this time. Use rpmh_flush() to send them to the controller.
  */
 static int __rpmh_write(struct rpmh_client *rc, enum rpmh_state state,
   struct rpmh_request *rpm_msg)
 {
int ret = -EFAULT;
+   struct cache_req *req;
+   int i;
+
+   /* Cache the request in our store and link the payload */
+   for (i = 0; i < rpm_msg->msg.num_payload; i++) {
+   req = cache_rpm_request(rc, state, _msg->msg.payload[i]);
+   if (IS_ERR(req))
+   return PTR_ERR(req);
+   }
 
rpm_msg->msg.state = state;
 
@@ -150,6 +248,10 @@ static int __rpmh_write(struct rpmh_client *rc, enum 
rpmh_state state,
"Error in RPMH request addr=0x%x, data=0x%x\n",
rpm_msg->msg.payload[0].addr,

[PATCH v3 09/10] drivers: qcom: rpmh: add support for batch RPMH request

[Lina Iyer]

Platform drivers need make a lot of resource state requests at the same
time, say, at the start or end of an usecase. It can be quite
inefficient to send each request separately. Instead they can give the
RPMH library a batch of requests to be sent and wait on the whole
transaction to be complete.

rpmh_write_batch() is a blocking call that can be used to send multiple
RPMH command sets. Each RPMH command set is set asynchronously and the
API blocks until all the command sets are complete and receive their
tx_done callbacks.

Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/rpmh.c | 150 
 include/soc/qcom/rpmh.h |   8 +++
 2 files changed, 158 insertions(+)

diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
index a02d9f685b2b..19e84b031c0d 100644
--- a/drivers/soc/qcom/rpmh.c
+++ b/drivers/soc/qcom/rpmh.c
@@ -22,6 +22,7 @@
 
 #define RPMH_MAX_MBOXES2
 #define RPMH_TIMEOUT   (10 * HZ)
+#define RPMH_MAX_REQ_IN_BATCH  10
 
 #define DEFINE_RPMH_MSG_ONSTACK(rc, s, q, c, name) \
struct rpmh_request name = {\
@@ -81,12 +82,14 @@ struct rpmh_request {
  * @cache: the list of cached requests
  * @lock: synchronize access to the controller data
  * @dirty: was the cache updated since flush
+ * @batch_cache: Cache sleep and wake requests sent as batch
  */
 struct rpmh_ctrlr {
struct rsc_drv *drv;
struct list_head cache;
spinlock_t lock;
bool dirty;
+   struct rpmh_request *batch_cache[2 * RPMH_MAX_REQ_IN_BATCH];
 };
 
 /**
@@ -343,6 +346,146 @@ int rpmh_write(struct rpmh_client *rc, enum rpmh_state 
state,
 }
 EXPORT_SYMBOL(rpmh_write);
 
+static int cache_batch(struct rpmh_client *rc,
+ struct rpmh_request **rpm_msg, int count)
+{
+   struct rpmh_ctrlr *rpm = rc->ctrlr;
+   unsigned long flags;
+   int ret = 0;
+   int index = 0;
+   int i;
+
+   spin_lock_irqsave(>lock, flags);
+   while (rpm->batch_cache[index])
+   index++;
+   if (index + count >=  2 * RPMH_MAX_REQ_IN_BATCH) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   for (i = 0; i < count; i++)
+   rpm->batch_cache[index + i] = rpm_msg[i];
+fail:
+   spin_unlock_irqrestore(>lock, flags);
+
+   return ret;
+}
+
+static int flush_batch(struct rpmh_client *rc)
+{
+   struct rpmh_ctrlr *rpm = rc->ctrlr;
+   struct rpmh_request *rpm_msg;
+   unsigned long flags;
+   int ret = 0;
+   int i;
+
+   /* Send Sleep/Wake requests to the controller, expect no response */
+   spin_lock_irqsave(>lock, flags);
+   for (i = 0; rpm->batch_cache[i]; i++) {
+   rpm_msg = rpm->batch_cache[i];
+   ret = rpmh_rsc_write_ctrl_data(rc->ctrlr->drv, _msg->msg);
+   if (ret)
+   break;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   return ret;
+}
+
+static void invalidate_batch(struct rpmh_client *rc)
+{
+   struct rpmh_ctrlr *rpm = rc->ctrlr;
+   unsigned long flags;
+   int index = 0;
+   int i;
+
+   spin_lock_irqsave(>lock, flags);
+   while (rpm->batch_cache[index])
+   index++;
+   for (i = 0; i < index; i++) {
+   kfree(rpm->batch_cache[i]->free);
+   rpm->batch_cache[i] = NULL;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+/**
+ * rpmh_write_batch: Write multiple sets of RPMH commands and wait for the
+ * batch to finish.
+ *
+ * @rc: The RPMh handle got from rpmh_get_dev_channel
+ * @state: Active/sleep set
+ * @cmd: The payload data
+ * @n: The array of count of elements in each batch, 0 terminated.
+ *
+ * Write a request to the mailbox controller without caching. If the request
+ * state is ACTIVE, then the requests are treated as completion request
+ * and sent to the controller immediately. The function waits until all the
+ * commands are complete. If the request was to SLEEP or WAKE_ONLY, then the
+ * request is sent as fire-n-forget and no ack is expected.
+ *
+ * May sleep. Do not call from atomic contexts for ACTIVE_ONLY requests.
+ */
+int rpmh_write_batch(struct rpmh_client *rc, enum rpmh_state state,
+   struct tcs_cmd *cmd, int *n)
+{
+   struct rpmh_request *rpm_msg[RPMH_MAX_REQ_IN_BATCH] = { NULL };
+   DECLARE_COMPLETION_ONSTACK(compl);
+   atomic_t wait_count = ATOMIC_INIT(0); /* overwritten */
+   int count = 0;
+   int ret, i, j;
+
+   if (IS_ERR_OR_NULL(rc) || !cmd || !n)
+   return -EINVAL;
+
+   while (n[count++] > 0)
+   ;
+   count--;
+   if (!count || count > RPMH_MAX_REQ_IN_BATCH)
+   return -EINVAL;
+
+   /* Create async request batches */
+   for (i = 0; i < count; i++) {
+   rpm_msg[i] = __get_rpmh_msg_async(rc, state, cmd, n[i]);
+   

[PATCH v3 04/10] drivers: qcom: rpmh: add RPMH helper functions

[Lina Iyer]

Sending RPMH requests and waiting for response from the controller
through a callback is common functionality across all platform drivers.
To simplify drivers, add a library functions to create RPMH client and
send resource state requests.

rpmh_write() is a synchronous blocking call that can be used to send
active state requests.

Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/Makefile|   4 +-
 drivers/soc/qcom/rpmh-internal.h |   2 +
 drivers/soc/qcom/rpmh-rsc.c  |   7 ++
 drivers/soc/qcom/rpmh.c  | 257 +++
 include/soc/qcom/rpmh.h  |  34 ++
 5 files changed, 303 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/qcom/rpmh.c
 create mode 100644 include/soc/qcom/rpmh.h

diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index bb013d56b5a1..5c9c6c442ea9 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -13,4 +13,6 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
 obj-$(CONFIG_QCOM_SMP2P)   += smp2p.o
 obj-$(CONFIG_QCOM_SMSM)+= smsm.o
 obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
-obj-$(CONFIG_QCOM_RPMH)+=  rpmh-rsc.o
+obj-$(CONFIG_QCOM_RPMH)+= qcom_rpmh.o
+qcom_rpmh-y+= rpmh-rsc.o
+qcom_rpmh-y+= rpmh.o
diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h
index 12faec77c4f3..1442a64ac4c5 100644
--- a/drivers/soc/qcom/rpmh-internal.h
+++ b/drivers/soc/qcom/rpmh-internal.h
@@ -84,4 +84,6 @@ struct rsc_drv {
 
 int rpmh_rsc_send_data(struct rsc_drv *drv, struct tcs_request *msg);
 
+void rpmh_tx_done(struct tcs_request *msg, int r);
+
 #endif /* __RPM_INTERNAL_H__ */
diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 4322e23a2ba6..b5b39b86f904 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -263,6 +263,8 @@ static void tcs_notify_tx_done(unsigned long data)
struct rsc_drv *drv = (struct rsc_drv *)data;
struct tcs_response *resp;
unsigned long flags;
+   struct tcs_request *msg;
+   int err;
 
for (;;) {
spin_lock_irqsave(>drv_lock, flags);
@@ -275,7 +277,10 @@ static void tcs_notify_tx_done(unsigned long data)
list_del(>list);
spin_unlock_irqrestore(>drv_lock, flags);
trace_rpmh_notify_tx_done(drv, resp);
+   msg = resp->msg;
+   err = resp->err;
free_response(resp);
+   rpmh_tx_done(msg, err);
}
 }
 
@@ -575,6 +580,8 @@ static int rpmh_rsc_probe(struct platform_device *pdev)
write_tcs_reg(drv, RSC_DRV_IRQ_ENABLE, 0, 0,
 drv->tcs[ACTIVE_TCS].tcs_mask);
 
+   dev_set_drvdata(>dev, drv);
+
return of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
 }
 
diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c
new file mode 100644
index ..d95ea3fa8b67
--- /dev/null
+++ b/drivers/soc/qcom/rpmh.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rpmh-internal.h"
+
+#define RPMH_MAX_MBOXES2
+#define RPMH_TIMEOUT   (10 * HZ)
+
+#define DEFINE_RPMH_MSG_ONSTACK(rc, s, q, c, name) \
+   struct rpmh_request name = {\
+   .msg = {\
+   .state = s, \
+   .payload = name.cmd,\
+   .num_payload = 0,   \
+   .is_complete = true,\
+   },  \
+   .cmd = { { 0 } },   \
+   .completion = q,\
+   .wait_count = c,\
+   .rc = rc,   \
+   }
+
+/**
+ * rpmh_request: the message to be sent to rpmh-rsc
+ *
+ * @msg: the request
+ * @cmd: the payload that will be part of the @msg
+ * @completion: triggered when request is done
+ * @wait_count: count of waiters for this completion
+ * @err: err return from the controller
+ */
+struct rpmh_request {
+   struct tcs_request msg;
+   struct tcs_cmd cmd[MAX_RPMH_PAYLOAD];
+   struct completion *completion;
+   atomic_t *wait_count;
+   struct rpmh_client *rc;
+   int err;
+};
+
+/**
+ * rpmh_ctrlr: our representation of the controller
+ *
+ * @drv: the controller instance
+ */
+struct rpmh_ctrlr {
+   struct rsc_drv *drv;
+};
+
+/**
+ * rpmh_client: the client object
+ *
+ * @dev: the platform device that is the owner
+ * @ctrlr: the controller associated with this client.
+ */
+struct rpmh_client {
+   

[PATCH] Input: trackpoint: document sysfs interface

[Aishwarya Pant]

Descriptions have been collected from git commit logs, code commits and
the TrackPoint System Version 4.0 Engineering Specification.

Signed-off-by: Aishwarya Pant 
---
 .../ABI/testing/sysfs-devices-platform-trackpoint  | 115 +
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-trackpoint

diff --git a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint 
b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
new file mode 100644
index ..df11901a6b3d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
@@ -0,0 +1,115 @@
+What:  /sys/devices/platform/i8042/.../sensitivity
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Trackpoint sensitivity.
+
+What:  /sys/devices/platform/i8042/.../intertia
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Negative inertia factor. High values cause the cursor to
+   snap backward when the trackpoint is released.
+
+What:  /sys/devices/platform/i8042/.../reach
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Backup range for z-axis press.
+
+What:  /sys/devices/platform/i8042/.../draghys
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) The drag hysteresis controls how hard it is to drag with
+   z-axis pressed.
+
+What:  /sys/devices/platform/i8042/.../mindrag
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Minimum amount of force needed to trigger dragging.
+
+What:  /sys/devices/platform/i8042/.../speed
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Speed of the trackpoint cursor.
+
+What:  /sys/devices/platform/i8042/.../thresh
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Minimum value for z-axis force required to trigger a press
+   or release, relative to the running average.
+
+What:  /sys/devices/platform/i8042/.../upthresh
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) The offset from the running average required to generate a
+   select (click) on z-axis on release.
+
+What:  /sys/devices/platform/i8042/.../ztime
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) This attribute determines how sharp a press has to be in
+   order to be recognized.
+
+What:  /sys/devices/platform/i8042/.../jenks
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Minimum curvature in degrees required to generate a double
+   click without a release.
+
+What:  /sys/devices/platform/i8042/.../skipback
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) When the skipback bit is set, backup cursor movement during
+   releases from drags will be suppressed. The default value for
+   this bit is 0.
+
+What:  /sys/devices/platform/i8042/.../ext_dev
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Disable (0) or enable (1) external pointing device.
+
+What:  /sys/devices/platform/i8042/.../press_to_select
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Writing a value of 1 to this file will enable the Press to
+   Select functions like tapping the control stick to simulate a
+   left click, and writing 0 will disable it.
+
+What:  /sys/devices/platform/i8042/.../drift_time
+Date:  Dec, 2014
+KernelVersion: 3.19
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) This parameter controls the period of time to test for a
+   ‘hands off’ condition (i.e. when no force is applied) before a
+   drift (noise) calibration occurs.
+
+   IBM Trackpoints have a feature to compensate for drift by
+   recalibrating themselves periodically. By default, if for 0.5
+   seconds there is no change in position, it's used as the new
+   zero. This duration is too low. Often, the calibration happens
+   when the 

Re: [PATCH] X86/KVM: Update the exit_qualification access bits while walking an address

[Paolo Bonzini]

On 28/02/2018 19:06, KarimAllah Ahmed wrote:
> ... to avoid having a stale value when handling an EPT misconfig for MMIO
> regions.
> 
> MMIO regions that are not passed-through to the guest are handled through
> EPT misconfigs. The first time a certain MMIO page is touched it causes an
> EPT violation, then KVM marks the EPT entry to cause an EPT misconfig
> instead. Any subsequent accesses to the entry will generate an EPT
> misconfig.
> 
> Things gets slightly complicated with nested guest handling for MMIO
> regions that are not passed through from L0 (i.e. emulated by L0
> user-space).
> 
> An EPT violation for one of these MMIO regions from L2, exits to L0
> hypervisor. L0 would then look at the EPT12 mapping for L1 hypervisor and
> realize it is not present (or not sufficient to serve the request). Then L0
> injects an EPT violation to L1. L1 would then update its EPT mappings. The
> EXIT_QUALIFICATION value for L1 would come from exit_qualification variable
> in "struct vcpu". The problem is that this variable is only updated on EPT
> violation and not on EPT misconfig. So if an EPT violation because of a
> read happened first, then an EPT misconfig because of a write happened
> afterwards. The L0 hypervisor will still contain exit_qualification value
> from the previous read instead of the write and end up injecting an EPT
> violation to the L1 hypervisor with an out of date EXIT_QUALIFICATION.
> 
> The EPT violation that is injected from L0 to L1 needs to have the correct
> EXIT_QUALIFICATION specially for the access bits because the individual
> access bits for MMIO EPTs are updated only on actual access of this
> specific type. So for the example above, the L1 hypervisor will keep
> updating only the read bit in the EPT then resume the L2 guest. The L2
> guest would end up causing another exit where the L0 *again* will inject
> another EPT violation to L1 hypervisor with *again* an out of date
> exit_qualification which indicates a read and not a write. Then this
> ping-pong just keeps happening without making any forward progress.
> 
> The behavior of mapping MMIO regions changed in:
> 
>commit a340b3e229b24 ("kvm: Map PFN-type memory regions as writable (if 
> possible)")
> 
> ... where an EPT violation for a read would also fixup the write bits to
> avoid another EPT violation which by acciddent would fix the bug mentioned
> above.
> 
> This commit fixes this situation and ensures that the access bits for the
> exit_qualifcation is up to date. That ensures that even L1 hypervisor
> running with a KVM version before the commit mentioned above would still
> work.
> 
> ( The description above assumes EPT to be available and used by L1
>   hypervisor + the L1 hypervisor is passing through the MMIO region to the L2
>   guest while this MMIO region is emulated by the L0 user-space ).

This looks okay.  Would it be possible to add a kvm-unit-tests testcase
for this?

Thanks,

Paolo

> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: x...@kernel.org
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed 
> ---
>  arch/x86/kvm/paging_tmpl.h | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
> index 5abae72..6288e9d 100644
> --- a/arch/x86/kvm/paging_tmpl.h
> +++ b/arch/x86/kvm/paging_tmpl.h
> @@ -452,14 +452,21 @@ static int FNAME(walk_addr_generic)(struct guest_walker 
> *walker,
>* done by is_rsvd_bits_set() above.
>*
>* We set up the value of exit_qualification to inject:
> -  * [2:0] - Derive from [2:0] of real exit_qualification at EPT violation
> +  * [2:0] - Derive from the access bits. The exit_qualification might be
> +  * out of date if it is serving an EPT misconfiguration.
>* [5:3] - Calculated by the page walk of the guest EPT page tables
>* [7:8] - Derived from [7:8] of real exit_qualification
>*
>* The other bits are set to 0.
>*/
>   if (!(errcode & PFERR_RSVD_MASK)) {
> - vcpu->arch.exit_qualification &= 0x187;
> + vcpu->arch.exit_qualification &= 0x180;
> + if (write_fault)
> + vcpu->arch.exit_qualification |= 
> EPT_VIOLATION_ACC_WRITE;
> + if (user_fault)
> + vcpu->arch.exit_qualification |= EPT_VIOLATION_ACC_READ;
> + if (fetch_fault)
> + vcpu->arch.exit_qualification |= 
> EPT_VIOLATION_ACC_INSTR;
>   vcpu->arch.exit_qualification |= (pte_access & 0x7) << 3;
>   }
>  #endif
> 

Re: [PATCH 17/18] crypto: talitos - chain in buffered data for ahash on SEC1

[Christophe LEROY]

Le 02/03/2018 à 18:27, Horia Geantă a écrit :

On 10/6/2017 4:05 PM, Christophe Leroy wrote:
[...]

@@ -1778,6 +1814,36 @@ static int common_nonsnoop_hash(struct talitos_edesc 
*edesc,
if (is_sec1 && from_talitos_ptr_len(>ptr[3], true) == 0)
talitos_handle_buggy_hash(ctx, edesc, >ptr[3]);
  
+	if (is_sec1 && req_ctx->nbuf && length) {

+   struct talitos_desc *desc2 = desc + 1;
+   dma_addr_t next_desc;

[...]

+   next_desc = dma_map_single(dev, >hdr1, TALITOS_DESC_SIZE,
+  DMA_BIDIRECTIONAL);
+   desc->next_desc = cpu_to_be32(next_desc);

Where is desc->next_desc initialized for the !is_sec1 case?
Memory allocation is done using kmalloc(), and since desc->next_desc is checked
in some cases also for SEC 2.x+, it should be initialized to 0.


See 
https://elixir.bootlin.com/linux/v4.16-rc3/source/drivers/crypto/talitos.c#L1411


edesc = kmalloc(alloc_len, GFP_DMA | flags);
if (!edesc) {
dev_err(dev, "could not allocate edescriptor\n");
err = ERR_PTR(-ENOMEM);
goto error_sg;
}
memset(>desc, 0, sizeof(edesc->desc));


Christophe

Re: [PATCH 4.9 00/56] 4.9.86-stable review

[Naresh Kamboju]

On 2 March 2018 at 14:20, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.9.86 release.
> There are 56 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Mar  4 08:44:26 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.86-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
dragonboard-410c and qemu-system-x86_64 are added to testing device pool.

Summary


kernel: 4.9.86-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 85afb4e51ccfdb10f2969b24439ae2887fe0fcff
git describe: v4.9.85-57-g85afb4e51ccf
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.85-57-g85afb4e51ccf


No regressions (compared to build v4.9.85)

Boards, architectures and test suites:
-

dragonboard-410c
* boot - pass: 20,
* kselftest - pass: 38, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1002, skip: 148
* ltp-timers-tests - pass: 12, skip: 1

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 40, skip: 24
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 42, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

qemu_x86_64
* boot - pass: 20,
* kselftest - pass: 62, skip: 20
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1004, skip: 146
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 39, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* 

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

[Alex Williamson]

On Thu, 1 Mar 2018 18:49:53 -0800
Alexander Duyck  wrote:

> On Thu, Mar 1, 2018 at 3:58 PM, Alex Williamson
>  wrote:
> > On Thu, 1 Mar 2018 14:42:40 -0800
> > Alexander Duyck  wrote:
> >  
> >> On Thu, Mar 1, 2018 at 12:22 PM, Alex Williamson
> >>  wrote:  
> >> > On Wed, 28 Feb 2018 16:36:38 -0800
> >> > Alexander Duyck  wrote:
> >> >  
> >> >> On Wed, Feb 28, 2018 at 2:59 PM, Alex Williamson
> >> >>  wrote:  
> >> >> > On Wed, 28 Feb 2018 09:49:21 -0800
> >> >> > Alexander Duyck  wrote:
> >> >> >  
> >> >> >> On Tue, Feb 27, 2018 at 2:25 PM, Alexander Duyck
> >> >> >>  wrote:
> >> >> >> So I was thinking about this some more. In the case of vfio-pci 
> >> >> >> things
> >> >> >> are a bit different since you are essentially taking a given device
> >> >> >> and handing it to a VM or userspace and it doesn't guarantee a
> >> >> >> communication between the two.  
> >> >> >
> >> >> > Doesn't guarantee communication or cooperation or even trust.  
> >> >>
> >> >> Right, but at the same time I consider this to be a shoot yourself in
> >> >> the foot type scenario. If you are going to hand off your PF while VFs
> >> >> are active then you are asking for whatever repercussions you end up
> >> >> getting. I've added a warning and a TAINT_USER flag to my code at this
> >> >> point if you load an active PF in vfio, and I have added a function
> >> >> that locks the setting so it cannot be changed once we place a PF in
> >> >> the control of vfio-pci.
> >> >>
> >> >> The way I see it there are two scenarios. One where the PF is just a
> >> >> VF with an extra bit of SR-IOV configuration space floating off of it.
> >> >> The other is where we want to have SR-IOV enabled and have some third
> >> >> party managing the PF.  The first one doesn't really care about the
> >> >> communication and would prefer that whatever owns the driver on the PF
> >> >> just ignore the SR-IOV portion of the configuration space. The second
> >> >> one actually cares and would want some sort of
> >> >> communication/cooperation but for now I don't see that as being the
> >> >> easiest thing to do so it might be best to just let it see a fixed
> >> >> number of VFs it just has to work with that.  
> >> >
> >> > There's no such thing as a read-only sriov capability in the spec,
> >> > which is a problem we ran into a while ago, vfio-pci exposes the
> >> > capability, but protects it as read-only so the user cannot create
> >> > devices on the host.  QEMU passed this through to the guest, but that
> >> > failed as soon as OVMF started supporting sriov as it's unable to size
> >> > the VF BAR resources.  Now QEMU drops the sriov capability from the
> >> > guest capability chain.  So it's not clear how this fixed number of vfs
> >> > plan works.  Are we inventing our own capability for this?  If the pf
> >> > driver is just a userspace driver and not a VM, maybe what we do now is
> >> > sufficient, otherwise there's no standard for exposing fixed vfs.  
> >>
> >> So one thought I had is what if we provide an ioctl command that
> >> allows for setting the number of VFs through VFIO? Basically it
> >> wouldn't be exposed through the sysfs, but would be totally controlled
> >> by the userspace using the sriov_configure_unmanged call to
> >> enable/disable the VFs and ultimately cleaning it up when the device
> >> it is released. I would imagine all the Amazon guys were looking for
> >> is something where they could just have some sort of command that
> >> could reach through and manage their VF count from some daemon. If
> >> they assigned the interface to a guest it would not be able to touch
> >> the SR-IOV capability unless QEMU went and implemented it which likely
> >> isn't happening anytime soon. It would provide the userspace guys a
> >> way to allocate the VF resources, call this ioctl, and then start
> >> managing VFs in the case of a userspace managed entity instead of it
> >> just being a firmware or preallocated type SR-IOV configuration.  
> >
> > Wait a sec, we were considering that a user owned pf sourcing vfs would
> > taint the host kernel and now we want to give the user the ability to
> > enable those vfs and trigger that tainting?  I saw the route through
> > sysfs to enable sriov on a user owned device as a feature because it
> > would require an existing privilege path rather than creating one
> > through vfio.  For example, an unprivileged QEMU could submit a
> > request to a privileged entity to enable sriov through sysfs.  If we
> > wanted to allow the user to enable sriov directly, the user would at
> > least need to run with privileges like CAP_SYS_ADMIN.  
> 
> The issue in all this ends up being how to handle the synchronization
> between userspace and the kernel. That was the only reason why I 

Applied "spi: Fix scatterlist elements size in spi_map_buf" to the spi tree

[Mark Brown]

The patch

   spi: Fix scatterlist elements size in spi_map_buf

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ce99319a182fe766be67f96338386f3ec73e321c Mon Sep 17 00:00:00 2001
From: Maxime Chevallier 
Date: Fri, 2 Mar 2018 15:55:09 +0100
Subject: [PATCH] spi: Fix scatterlist elements size in spi_map_buf

When SPI transfers can be offloaded using DMA, the SPI core need to
build a scatterlist to make sure that the buffer to be transferred is
dma-able.

This patch fixes the scatterlist entry size computation in the case
where the maximum acceptable scatterlist entry supported by the DMA
controller is less than PAGE_SIZE, when the buffer is vmalloced.

For each entry, the actual size is given by the minimum between the
desc_len (which is the max buffer size supported by the DMA controller)
and the remaining buffer length until we cross a page boundary.

Fixes: 65598c13fd66 ("spi: Fix per-page mapping of unaligned vmalloc-ed buffer")
Signed-off-by: Maxime Chevallier 
Signed-off-by: Mark Brown 
Cc: sta...@vger.kernel.org
---
 drivers/spi/spi.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b33a727a0158..4153f959f28c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -779,8 +779,14 @@ static int spi_map_buf(struct spi_controller *ctlr, struct 
device *dev,
for (i = 0; i < sgs; i++) {
 
if (vmalloced_buf || kmap_buf) {
-   min = min_t(size_t,
-   len, desc_len - offset_in_page(buf));
+   /*
+* Next scatterlist entry size is the minimum between
+* the desc_len and the remaining buffer length that
+* fits in a page.
+*/
+   min = min_t(size_t, desc_len,
+   min_t(size_t, len,
+ PAGE_SIZE - offset_in_page(buf)));
if (vmalloced_buf)
vm_page = vmalloc_to_page(buf);
else
-- 
2.16.2

Re: [PATCH v4 3/3] mm/free_pcppages_bulk: prefetch buddy while not holding lock

[Vlastimil Babka]

On 03/02/2018 07:00 PM, Dave Hansen wrote:
> On 03/02/2018 09:55 AM, Vlastimil Babka wrote:
>> It's even stranger to me. Struct page is 64 bytes these days, exactly a
>> a cache line. Unless that changed, Intel CPUs prefetched a "buddy" cache
>> line (that forms an aligned 128 bytes block with the one we touch).
> 
> I believe that was a behavior that was specific to the Pentium 4
> "Netburst" era.  I don't think the 128-byte line behavior exists on
> modern Intel cpus.

I remember it on Core 2 something (Nehalem IIRC). And this page suggests
up to Broadwell, and it can be disabled. And it's an L2 prefetcher indeed.
https://software.intel.com/en-us/articles/disclosure-of-hw-prefetcher-control-on-some-intel-processors

Re: [PATCH 1/2] crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf

[Horia Geantă]

On 2/26/2018 6:40 PM, Christophe Leroy wrote:
> Commit 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping
> outside the requests") introduced a persistent dma mapping of
> req_ctx->hw_context
> Commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash
> on SEC1") introduced a persistent dma mapping of req_ctx->buf
> 
> As there is no destructor for req_ctx (the request context), the
> associated dma handlers where set in ctx (the tfm context). This is
> wrong as several hash operations can run with the same ctx.
> 
> This patch removes this persistent mapping.
> 
> Reported-by: Horia Geanta 
> Fixes: 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping outside the 
> requests")
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on 
> SEC1")
> Signed-off-by: Christophe Leroy 
Tested-by: Horia Geantă 

Please add this to 4.15.y -stable tree.

Thanks,
Horia

Re: [PATCH] MAINTAINERS: take over Kconfig maintainership

[Linus Torvalds]

On Fri, Mar 2, 2018 at 5:04 AM, Masahiro Yamada
 wrote:
> I have recently picked up Kconfig patches to my tree without any
> declaration.  Making it official now.

Ack.

I expect I'll see this in one of your pull requests, so I'm not applying it now.

Linus

Re: [PATCH] dt-bindings: iio: adc: stm32-dfsdm: fix types, add missing pinctrl

[Rob Herring]

On Fri, Feb 23, 2018 at 12:11:00PM +0100, Fabrice Gasnier wrote:
> - Add missing pinctrl description. Support is made optional as dfsdm
>   may use internal sources (e.g. via registers)
> - Fix typo in IIO STM32 DFSDM filter "MANCH_F" description.
> Basically, this should be "falling edge = logic 0", not "1" that applies
> to "MANCH_R".
> BTW, make the description complete by describing both rising/falling
> edges as described in reference manuals.
> 
> Fixes: 6c82f947fc97 ("IIO: add DT bindings for stm32 DFSDM filter")
> 
> Signed-off-by: Fabrice Gasnier 
> ---
>  Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH net-next 3/5] net: mvpp2: use a data size of 10kB for Tx FIFO on port 0

[Thomas Petazzoni]

Hello,

On Fri,  2 Mar 2018 16:40:42 +0100, Antoine Tenart wrote:

> -/* Initialize Tx FIFO's */
> +/* Initialize Tx FIFO's
> + * The CP110's total tx-fifo size is 19kB.
> + * Use large-size 10kB for fast port but 3kB for others.
> + */

Is there a reason to hardcode 10KB for port 0, and 3KB for the other
ports ? Would there be use cases where the user may want different
configurations ?

It's just that it feels very "hardcoded" to enforce specifically those
numbers.

Also, does it make sense to mention the CP110 here ? Is this 19 KB
limitation a limit of the PPv2.2 IP, or of the CP110 ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH Resend 0/5] hwrng: stm32 - Improvement for stm32-rng

[Herbert Xu]

On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote:
> This set of patches add extended functionalities for stm32 rng
> driver.
> Patch #1 includes a reset during probe to avoid any error status
> which can occur during bootup process and keep safe rng integrity.
> 
> Patch #3 adds a new property to manage the clock error detection
> feature which can be disabled on specific target.
> 
> Patch #5 rework the timeout calculation for read value that was
> previously defined based on loop operation and is now based on
> timer.
> 
> Lionel Debieve (5):
>   hwrng: stm32 - add reset during probe
>   dt-bindings: rng: add reset node for stm32
>   hwrng: stm32 - allow disable clock error detection
>   dt-bindings: rng: add clock detection error for stm32
>   hwrng: stm32 - rework read timeout calculation
> 
>  .../devicetree/bindings/rng/st,stm32-rng.txt   |  4 ++
>  drivers/char/hw_random/stm32-rng.c | 44 
> ++
>  2 files changed, 32 insertions(+), 16 deletions(-)

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

Re: [PATCH v2] Documentation/sphinx: Fix Directive import error

[Matthew Wilcox]

On Fri, Mar 02, 2018 at 04:28:31PM +0100, Takashi Iwai wrote:
>  from docutils.parsers.rst import directives
> -from sphinx.util.compat import Directive
> +try:
> +from docutils.parsers.rst import directives, Directive

We also don't need 'directives' on this line as it was imported on the
previous line.

> +except ImportError:
> +from sphinx.util.compat import Directive
>  from sphinx.ext.autodoc import AutodocReporter
>  
>  __version__  = '1.0'

Here's what I tested on Debian:

+++ b/Documentation/sphinx/kerneldoc.py
@@ -37,7 +37,10 @@ import glob
 from docutils import nodes, statemachine
 from docutils.statemachine import ViewList
 from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+try:
+from docutils.parsers.rst import Directive
+except ImportError:
+from sphinx.util.compat import Directive
 from sphinx.ext.autodoc import AutodocReporter
 
 __version__  = '1.0'

Re: [PATCH Resend 0/5] hwrng: stm32 - Improvement for stm32-rng

[Herbert Xu]

On Thu, Feb 22, 2018 at 04:25:46PM +0100, Alexandre Torgue wrote:
> Hi
> 
> On 02/22/2018 03:03 PM, Herbert Xu wrote:
> >On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote:
> >>This set of patches add extended functionalities for stm32 rng
> >>driver.
> >>Patch #1 includes a reset during probe to avoid any error status
> >>which can occur during bootup process and keep safe rng integrity.
> >>
> >>Patch #3 adds a new property to manage the clock error detection
> >>feature which can be disabled on specific target.
> >>
> >>Patch #5 rework the timeout calculation for read value that was
> >>previously defined based on loop operation and is now based on
> >>timer.
> >
> >I should take only patches 1/3/5, right?
> 
> You could take all (dt-bindings + drivers part).

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

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

[Dmitry Osipenko]

On 01.03.2018 23:20, Andreas Dilger wrote:
> 
> On Mar 1, 2018, at 9:04 AM, Theodore Ts'o  wrote:
>> This doesn't seem to make sense; the PC is where we are currently
>> executing, and LR is the "Link Register" where the flow of control
>> will be returning after the current function returns, right?  Well,
>> dx_probe should *not* be returning to __wait_on_bit().  So this just
>> seems weird.
>>
>> Ignoring the LR register, this stack trace looks sane...  I can't see
>> which pointer could be NULL and getting dereferenced, though.  How
>> easily can you reproduce the problem?  Can you either (a) translate
>> the PC into a line number, or better yet, if you can reproduce, add a
>> series of BUG_ON's so we can see what's going on?

Ted, thank you for the suggestion. I don't have a bug-reproducer, it happens
only under some IO load and quite randomly. I've applied the BUG_ON()'s, but it
may take some time to catch the bug again.

>> +BUG_ON(frame);
> 
> I think you mean:
>   BUG_ON(frame == NULL);
> or
>   BUG_ON(!frame);
> 
> 
>>  memset(frame_in, 0, EXT4_HTREE_LEVEL * sizeof(frame_in[0]));
>>  frame->bh = ext4_read_dirblock(dir, 0, INDEX);
>>  if (IS_ERR(frame->bh))
>>  return (struct dx_frame *) frame->bh;
>>
>> +BUG_ON(frame->bh);
>> +BUG_ON(frame->bh->b_data);
> 
> Same here.
> 
>   BUG_ON(frame->bh == NULL);
>   BUG_ON(frame->bh->b_data == NULL);
> 
> This is why I don't like implicit "is NULL" or "is non-zero" usage.  Lustre
> used to require "== NULL" or "!= NULL" to avoid bugs like this, but had to
> abandon that because of upstream code style.

Well spotted, thanks Andreas.

>>  root = (struct dx_root *) frame->bh->b_data;
>>  if (root->info.hash_version != DX_HASH_TEA &&
>>  root->info.hash_version != DX_HASH_HALF_MD4 &&
>>  root->info.hash_version != DX_HASH_LEGACY) {
>>
>> These are "could never" happen scenarios from looking at the code, but
>> that will help explain what is going on.
>>
>> If this is reliably only happening with mq, the only way I could see
>> that if is something is returning an error when it previously wasn't.
>> This isn't a problem we're seeing with any of our testing, though.

Re: [PATCH v3 2/2] timers: Don't search for expired timers while TIMER_SOFTIRQ is scheduled

[Sebastian Andrzej Siewior]

On 2018-03-02 10:29:56 [-0600], Haris Okanovic wrote:
> > Could please point me to the code/patches or something?
> 
> I rebase onto v4.14.20-rt17, running some sanity test before reposting to ml
> (cyclictest & Anna's timertest). Will post V4 sometime today (US Central
> Time) if everything goes well.
> 
> Are you also asking for a 4.9 version? I'm fine leaving it out of 4.9.

Hmmm. Maybe this is a form of miscommunication here :)
So my understanding is that you complain/ask why there is an older
version of the patch still in v4.9-RT:

|It was added back into 4.9 at some point after v4.9.30-rt20. I see an older
|version in v4.9.68-rt60, for example, hence my original email. It was dropped
|sometime thereafter, presumably because it no longer cleanly applies. I don't
|see it in v4.14.20-rt17, for example.

So I ask where you see the old version of your patch in v4.9-RT. Yes it
was added, then removed and it never appeared back in. However, I don't
see anymore in v4.9.68-rt60.

> -- Haris

Sebastian

[PATCH v3 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

[Lina Iyer]

Add controller driver for QCOM SoCs that have hardware based shared
resource management. The hardware IP known as RSC (Resource State
Coordinator) houses multiple Direct Resource Voter (DRV) for different
execution levels. A DRV is a unique voter on the state of a shared
resource. A Trigger Control Set (TCS) is a bunch of slots that can house
multiple resource state requests, that when triggered will issue those
requests through an internal bus to the Resource Power Manager Hardened
(RPMH) blocks. These hardware blocks are capable of adjusting clocks,
voltages etc. The resource state request from a DRV are aggregated along
with state requests from other processors in the SoC and the aggregate
value is applied on the resource.

Some important aspects of the RPMH communication -
- Requests are  with some header information
- Multiple requests (upto 16) may be sent through a TCS, at a time
- Requests in a TCS are sent in sequence
- Requests may be fire-n-forget or completion (response expected)
- Multiple TCS from the same DRV may be triggered simultaneously
- Cannot send a request if another reques for the same addr is in
  progress from the same DRV
- When all the requests from a TCS are complete, an IRQ is raised
- The IRQ handler needs to clear the TCS before it is available for
  reuse
- TCS configuration is specific to a DRV
- Platform drivers may use DRV from different RSCs to make requests

Resource state requests made when CPUs are active are called 'active'
state requests. Requests made when all the CPUs are powered down (idle
state) are called 'sleep' state requests. They are matched by a
corresponding 'wake' state requests which puts the resources back in to
previously requested active state before resuming any CPU. TCSes are
dedicated for each type of requests. Control TCS are used to provide
specific information to the controller.

Signed-off-by: Lina Iyer 
---
 drivers/soc/qcom/Kconfig|  10 +
 drivers/soc/qcom/Makefile   |   1 +
 drivers/soc/qcom/rpmh-internal.h|  87 +
 drivers/soc/qcom/rpmh-rsc.c | 593 
 include/dt-bindings/soc/qcom,rpmh-rsc.h |  14 +
 include/soc/qcom/tcs.h  |  56 +++
 6 files changed, 761 insertions(+)
 create mode 100644 drivers/soc/qcom/rpmh-internal.h
 create mode 100644 drivers/soc/qcom/rpmh-rsc.c
 create mode 100644 include/dt-bindings/soc/qcom,rpmh-rsc.h
 create mode 100644 include/soc/qcom/tcs.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index e050eb83341d..779f0d14748d 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -55,6 +55,16 @@ config QCOM_RMTFS_MEM
 
  Say y here if you intend to boot the modem remoteproc.
 
+config QCOM_RPMH
+   bool "Qualcomm RPM-Hardened (RPMH) Communication"
+   depends on ARCH_QCOM && ARM64 && OF
+   help
+ Support for communication with the hardened-RPM blocks in
+ Qualcomm Technologies Inc (QTI) SoCs. RPMH communication uses an
+ internal bus to transmit state requests for shared resources. A set
+ of hardware components aggregate requests for these resources and
+ help apply the aggregated state on the resource.
+
 config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index dcebf2814e6d..e7d04f0e3616 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
 obj-$(CONFIG_QCOM_SMP2P)   += smp2p.o
 obj-$(CONFIG_QCOM_SMSM)+= smsm.o
 obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
+obj-$(CONFIG_QCOM_RPMH)+=  rpmh-rsc.o
diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h
new file mode 100644
index ..12faec77c4f3
--- /dev/null
+++ b/drivers/soc/qcom/rpmh-internal.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ */
+
+
+#ifndef __RPM_INTERNAL_H__
+#define __RPM_INTERNAL_H__
+
+#include 
+
+#define TCS_TYPE_NR4
+#define MAX_CMDS_PER_TCS   16
+#define MAX_TCS_PER_TYPE   3
+#define MAX_TCS_NR (MAX_TCS_PER_TYPE * TCS_TYPE_NR)
+
+struct rsc_drv;
+
+/**
+ * tcs_response: Response object for a request
+ *
+ * @drv: the controller
+ * @msg: the request for this response
+ * @m: the tcs identifier
+ * @err: error reported in the response
+ * @list: link list object.
+ */
+struct tcs_response {
+   struct rsc_drv *drv;
+   struct tcs_request *msg;
+   u32 m;
+   int err;
+   struct list_head list;
+};
+
+/**
+ * tcs_group: group of Trigger Command Sets for a request state
+ *
+ * @drv: the controller
+ * @type: type of the TCS in this group - active, sleep, wake
+ * @tcs_mask: mask of the TCSes 

[PATCH v3 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

[Lina Iyer]

Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
driver. The hardware block is used for communicating resource state
requests for shared resources.

Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer 
---

Changes in v2:
- Amend text to describe the registers in reg property
- Add reg-names for the registers
- Update examples to use GIC_SPI in interrupts instead of 0
- Rephrase incorrect description

Changes in v3:
- Fix unwanted capitalization
- Remove clients from the examples, this doc does not describe
  them
- Rephrase introductory paragraph
- Remove hardware specifics from DT bindings
---
 .../devicetree/bindings/arm/msm/rpmh-rsc.txt   | 131 +
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt

diff --git a/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt 
b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
new file mode 100644
index ..afd3817cc615
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/rpmh-rsc.txt
@@ -0,0 +1,131 @@
+RPMH RSC:
+
+
+Resource Power Manager Hardened (RPMH) is the mechanism for communicating with
+the hardened resource accelerators on Qualcomm SoCs. Requests to the resources
+can be written to the Trigger Command Set (TCS)  registers and using a (addr,
+val) pair and triggered. Messages in the TCS are then sent in sequence over an
+internal bus.
+
+The hardware block (Direct Resource Voter or DRV) is a part of the h/w entity
+(Resource State Coordinator a.k.a RSC) that can handle a multiple sleep and
+active/wake resource requests. Multiple such DRVs can exist in a SoC and can
+be written to from Linux. The structure of each DRV follows the same template
+with a few variations that are captured by the properties here.
+
+A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
+have powered off to facilitate idle power saving. TCS could be classified as -
+
+   SLEEP,  /* Triggered by F/W */
+   WAKE,   /* Triggered by F/W */
+   ACTIVE, /* Triggered by Linux */
+   CONTROL /* Triggered by F/W */
+
+The order in which they are described in the DT, should match the hardware
+configuration.
+
+Requests can be made for the state of a resource, when the subsystem is active
+or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state
+will be an aggregate of the sleep votes from each of those subsystem. Drivers
+may request a sleep value for their shared resources in addition to the active
+mode requests.
+
+Control requests are instance specific requests that may or may not reach an
+accelerator. Only one platform device in Linux can request a control channel
+on a DRV.
+
+Properties:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Should be "qcom,rpmh-rsc".
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: The first register specifies the base address of the DRV.
+   The second register specifies the start address of the
+   TCS.
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Maps the register specified in the reg property. Must be
+   "drv" and "tcs".
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: The interrupt that trips when a message complete/response
+  is received for this DRV from the accelerators.
+
+- qcom,drv-id:
+   Usage: required
+   Value type: 
+   Definition: the id of the DRV in the RSC block.
+
+- qcom,tcs-config:
+   Usage: required
+   Value type: 
+   Definition: the tuple defining the configuration of TCS.
+   Must have 2 cells which describe each TCS type.
+   .
+   The order of the TCS must match the hardware
+   configuration.
+   - Cell #1 (TCS Type): TCS types to be specified -
+   SLEEP_TCS
+   WAKE_TCS
+   ACTIVE_TCS
+   CONTROL_TCS
+   - Cell #2 (Number of TCS): 
+
+- label:
+   Usage: optional
+   Value type: 
+   Definition: Name for the RSC. The name would be used in trace logs.
+
+Drivers that want to use the RSC to communicate with RPMH must specify their
+bindings as child of the RSC controllers they wish to communicate with.
+
+Example 1:
+
+For a TCS whose RSC base address is is 0x179C and is at a DRV id of 2, the
+register offsets for DRV2 start at 0D00, the register calculations are like
+this -
+First tuple: 0x179C + 0x1 * 2 = 0x179E
+Second tuple: 0x179E + 0xD00 = 0x179E0D00
+
+   apps_rsc: rsc@179e000 {
+   label = "apps_rsc";
+   compatible = "qcom,rpmh-rsc";
+   reg = <0x179e 0x1>, <0x179e0d00 0x3000>;
+   

Re: [PATCH 1/7] genalloc: track beginning of allocations

[kbuild test robot]

Hi Igor,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20180223]
[also build test WARNING on v4.16-rc3]
[cannot apply to linus/master mmotm/master char-misc/char-misc-testing 
v4.16-rc3 v4.16-rc2 v4.16-rc1]
[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/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20180302-232215
config: i386-randconfig-x007-201808 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c: In function 'gen_pool_free':
   lib/genalloc.c:616:10: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
 "Trying to free unallocated memory"
 ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   lib/genalloc.c:615:5: note: in expansion of macro 'WARN'
WARN(true,
^~~~
   lib/genalloc.c:617:23: note: format string is defined here
 " from pool %s", pool);
 ~^
   In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c:624:17: error: implicit declaration of function 'exit_test'; 
did you mean 'exit_sem'? [-Werror=implicit-function-declaration]
   if (unlikely(exit_test(boundary < 0))) {
^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> lib/genalloc.c:624:4: note: in expansion of macro 'if'
   if (unlikely(exit_test(boundary < 0))) {
   ^~
   include/linux/compiler.h:48:24: note: in expansion of macro 
'__branch_check__'
#  define unlikely(x) (__branch_check__(x, 0, __builtin_constant_p(x)))
   ^~~~
>> lib/genalloc.c:624:8: note: in expansion of macro 'unlikely'
   if (unlikely(exit_test(boundary < 0))) {
   ^~~~
   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c:626:16: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
WARN(true, "Corrupted pool %s", pool);
   ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   lib/genalloc.c:626:5: note: in expansion of macro 'WARN'
WARN(true, "Corrupted pool %s", pool);
^~~~
   lib/genalloc.c:634:10: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
 "Size provided differs from size "
 ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   lib/genalloc.c:633:5: note: in expansion of macro 'WARN'
WARN(true,
^~~~
   lib/genalloc.c:635:31: note: format string is defined here
 "measured from pool %s", pool);
 ~^
   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from lib/genalloc.c:99:
   lib/genalloc.c:643:10: warning: format '%s' expects argument of type 'char 
*', but argument 2 has type 'struct gen_pool *' [-Wformat=]
 "Unexpected bitmap collision while"
 ^
   includ

Re: [PATCH v2 3/8] arm64: zynqmp: Add support for Xilinx zcu102

[Rob Herring]

On Fri, Feb 23, 2018 at 03:40:25PM +0100, Michal Simek wrote:
> This patch is adding revA, revB and rev1.0. There are also other
> revisions between which should be backward compatible with previous
> versions. Unfortunately all revs are still in use.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Remove i2c mw u-boot commands
> - Use i2c-mux instead of i2cswitch
> - Use clock generator without numbers.
> - Use dash in node name zcu102 rev1.0
> - Record compatible string to xilinx.txt
> 
>  Documentation/devicetree/bindings/arm/xilinx.txt   |   5 +
>  arch/arm64/boot/dts/xilinx/Makefile|   3 +
>  .../arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts |  36 ++
>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  | 550 
> +
>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts  |  42 ++
>  5 files changed, 636 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts

Reviewed-by: Rob Herring  

but...


> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts 
> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts
> new file mode 100644
> index ..ed3cc684931f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Xilinx ZynqMP ZCU102 RevB
> + *
> + * (C) Copyright 2016 - 2018, Xilinx, Inc.
> + *
> + * Michal Simek 
> + */
> +
> +#include "zynqmp-zcu102-revA.dts"
> +
> +/ {
> + model = "ZynqMP ZCU102 RevB";
> + compatible = "xlnx,zynqmp-zcu102-revB", "xlnx,zynqmp-zcu102", 
> "xlnx,zynqmp";
> +};
> +
> + {
> + phy-handle = <>;
> + phyc: phy@c {
> + reg = <0xc>;
> + ti,rx-internal-delay = <0x8>;
> + ti,tx-internal-delay = <0xa>;
> + ti,fifo-depth = <0x1>;
> + };
> + /* Cleanup from RevA */
> + /delete-node/ phy@21;
> +};
> +
> +/* Different qspi 512Mbit version */

Stray comment

> +
> +/* Fix collision with u61 */
> + {
> + i2cswitch@75 {

Missed this name.

This probably creates a new node rather than going into the existing 
tree. If this compiles, we should fix it to not allow the same 
unit-address twice.

> + i2c@2 {
> + max15303@1b { /* u8 */
> + compatible = "maxim,max15303";
> + reg = <0x1b>;
> + };
> + /delete-node/ max15303@20;
> + };
> + };
> +};
> -- 
> 1.9.1
> 

Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

[Greg KH]

On Fri, Mar 02, 2018 at 05:14:50PM +0800, Alex Shi wrote:
> 
> 
> On 03/01/2018 11:24 PM, Greg KH wrote:
> > On Wed, Feb 28, 2018 at 11:56:22AM +0800, Alex Shi wrote:
> >> Hi All,
> >>
> >> This backport patchset fixed the meltdown issue, it's original branch:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
> >> A few dependency or fixingpatches are also picked up, if they are necessary
> >>  and no functional changes.
> >>
> >> The patchset also on repository:
> >>git://git.linaro.org/kernel/linux-linaro-stable.git lts-4.9-spectrevv2 
> >>
> >> No bug found yet from kernelci.org and lkft testing.
> > 
> > No bugs is good, but does it actually fix the meltdown problem?  What
> > did you test it on?
> 
> Oh, I have no A73/A75 cpu, so I can not reproduce meltdown bug.

Then why should I trust this backport at all?

Please test on the hardware that is affected, otherwise you do not know
if your patches do anything or not.

> > And why are you making this patchset up?  What is wrong with the patches
> > in the android-common tree for this?
> 
> We believe the LTS is the base kernel for android/lsk, so the fixing
> patches should get it first and then merge to other tree.

But you know that android-common is already fine here, the needed
patches are all integrated into there, so no additional work is needed
for android devices.  So what devices do you expect to use this 4.9
backport?

What is "lsk"?

> >> Any comments are appreciated!
> > 
> > You need to start versioning this changeset, as I have no idea if this
> > is the "latest" one or not, right?>
> > Or have you not sent out this patchset before?  How does this interact
> > with the "spectre" patches?  Or am I totally confused here?
> 
> It is the first patchset for meltdown. Yes, I will resent this patchset
> with versioning after the renesas board booting fixed.
> 
> The meltdown and spectre is 2 different bugs, the fixing patchset are
> isolated each other. So I did the backport as 2 different patchset. And
> merging them together is relative simple. I will comming with a merge
> patch next time, after the meltdown patchset ready.(the kernelci didn't
> works well in recent days)

I don't want a merged patchset, but having one dependant on the other is
just fine.

Again, test this on real hardware properly first.

But really, I don't see this need as all ARM devices that I know of that
are stuck on 4.9.y are already using the android-common tree.  Same for
4.4.y.  Do you know of any that are not, and that can not just use
4.14.y instead?

thanks,

greg k-h