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

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 11:24:14 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> 
> between commits:
> 
>   ab78718bda79 ("arm64: dts: rockchip: Enable tsadc module on RK3328 
> eavluation board")
>   1e28037ec88e ("arm64: dts: rockchip: add rk805 node for rk3328-evb")
> 
> from the rockchip tree and commit:
> 
>   4b05bc6157eb ("ARM64: dts: rockchip: Enable gmac2phy for rk3328-evb")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> index 86605ae7b6f5,b9f36dad17e6..
> --- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> @@@ -51,147 -51,24 +51,164 @@@
>   stdout-path = "serial2:150n8";
>   };
>   
>  +dc_12v: dc-12v {
>  +compatible = "regulator-fixed";
>  +regulator-name = "dc_12v";
>  +regulator-always-on;
>  +regulator-boot-on;
>  +regulator-min-microvolt = <1200>;
>  +regulator-max-microvolt = <1200>;
>  +};
>  +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> ++
>  +vcc_sys: vcc-sys {
>  +compatible = "regulator-fixed";
>  +regulator-name = "vcc_sys";
>  +regulator-always-on;
>  +regulator-boot-on;
>  +regulator-min-microvolt = <500>;
>  +regulator-max-microvolt = <500>;
>  +vin-supply = <_12v>;
>  +};
>   };
>   
> +  {
> + phy-supply = <_phy>;
> + clock_in_out = "output";
> + assigned-clocks = < SCLK_MAC2PHY_SRC>;
> + assigned-clock-rate = <5000>;
> + assigned-clocks = < SCLK_MAC2PHY>;
> + assigned-clock-parents = < SCLK_MAC2PHY_SRC>;
> + status = "okay";
> + };
> + 
>  + {
>  +status = "okay";
>  +
>  +rk805: rk805@18 {
>  +compatible = "rockchip,rk805";
>  +reg = <0x18>;
>  +interrupt-parent = <>;
>  +interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
>  +#clock-cells = <1>;
>  +clock-output-names = "xin32k", "rk805-clkout2";
>  +gpio-controller;
>  +#gpio-cells = <2>;
>  +pinctrl-names = "default";
>  +pinctrl-0 = <_int_l>;
>  +rockchip,system-power-controller;
>  +wakeup-source;
>  +
>  +vcc1-supply = <_sys>;
>  +vcc2-supply = <_sys>;
>  +vcc3-supply = <_sys>;
>  +vcc4-supply = <_sys>;
>  +vcc5-supply = <_io>;
>  +vcc6-supply = <_io>;
>  +
>  +regulators {
>  +vdd_logic: DCDC_REG1 {
>  +regulator-name = "vdd_logic";
>  +regulator-min-microvolt = <712500>;
>  +regulator-max-microvolt = <145>;
>  +regulator-always-on;
>  +regulator-boot-on;
>  +regulator-state-mem {
>  +regulator-on-in-suspend;
>  +regulator-suspend-microvolt = <100>;
>  +};
>  +};
>  +
>  +vdd_arm: DCDC_REG2 {
>  +regulator-name = "vdd_arm";
>  +regulator-min-microvolt = <712500>;
>  +regulator-max-microvolt = <145>;
>  +regulator-always-on;
>  +regulator-boot-on;
>  +regulator-state-mem {
>  +regulator-on-in-suspend;
>  +regulator-suspend-microvolt = <95>;
>  +};
>  +};
>  +
>  +vcc_ddr: DCDC_REG3 {
>  +regulator-name = "vcc_ddr";
>  +regulator-always-on;
>  +regulator-boot-on;
>  +regulator-state-mem {
>  +regulator-on-in-suspend;
>  +};
>  +};
>  +
>  +vcc_io: DCDC_REG4 {
>  +

Re: printk: what is going on with additional newlines?

[Sergey Senozhatsky]

Hello,

I'll answer to both Linus and Joe, just to keep it all one place.

On (09/01/17 13:21), Linus Torvalds wrote:
> On Fri, Sep 1, 2017 at 10:32 AM, Joe Perches  wrote:
> >
> > Yes, it's a poor name.  At least keep using a pr_ prefix.
> 
> I'd suggest perhaps just "pr_line()".

ok, pr_line sound good.

> And instead of having those "err/info/cont" variations, the severity
> level should just be set at initialization time.  Not different
> versions of "pr_line()".
> 
> There's no point to having different severity variations, since the
> *only* reason for this would be for buffering. So "pr_cont()" is kind
> of assumed for everything but the first.
> 
> And even if you end up doing multiple lines, if you actually do
> different severities, you damn well shouldn't buffer them together.
> They are clearly different things!

hm... may be.
the main point of prbuf is not the support of cont lines, but the
fact that buffered messages are added to the logbuf atomically,
and thus are printed in consequent lines, not the usual way:

CPU0because
CPU1this
CPU0it's easier
CPU1might
CPU0to read
CPU1be
CPU1inconvenient.
CPU0seq messages.

some people want to be able to make it to look less spaghetti-like:

CPU0because
CPU0it's easier
CPU0to read
CPU0seq messages.
CPU1this
CPU1might
CPU1be
CPU1inconvenient.

and it's not something completely wrong to ask for, I think.
well, who knows.

there is only way to serialize printks against other printks -- take
the logbuf lock. and that's what pr_line/prbuf flush is doing.


now, pr_line/prbuf/pr_buf is, of course, very limited. it should NOT
be used for things that are really important and absolutely must [if
possible] appear in serial logs/on screens/etc. simply because panic
can happen on CPUA before we flush any pending pr_line/prbuf buffers
on other CPUs. and that's exactly the reason why I initially wanted
(and still do) to implement pr_line/prbuf using printk-safe
mechanism - because we flush printk-safe buffers from panic(). so
utilizing printk-safe buffers can make pr_line less fragile. apart
from that printk-safe buffers are always there, so OOM is not a show
stopper anymore. but, like I said in another email, printk-safe buffer
is per-CPU and is also used for actual printk-safe, hence it must be
used with local IRQs disabled when we "borrow" the buffer for pr_line
(disabled preemption is not enough due to possible IRQ printk-safe
print out). this can be a bit annoying.

in it's current form, pr_line/pr_buf is NOT a replacement for pr_cont
or printk(KERN_CONT). because pr_cont has no such thing as "we were
unable to flush the buffer from CPUB because of panic on CPUA". so
pr_cont/printk(KERN_CONT) beats pr_line/pr_buf here. This can be a
major limitation. am I wrong?


another thing,
if we eventually will decide to stick to "use a seq_buf with stack
allocated char buffer to hold a single line only" design, then I'm
not entirely sure I get it why do we want to add a new API at all.
I mean, the new API does not make anything simpler or shorter. we
need to declare the buffer, seq_buf, init seq_buf, append chars to
seq_buf, flush it:

char buf[80];
struct seq_buf cont_line;

pr_line_init(_line, buf, sizeof(buf));
pr_line_printf(_line, "");
pr_line_printf(_line, "");
pr_line_flush(_line);

this asks for  s/pr_line_/seq_buf_/g, no? well, except for the flush()
part. it can be replaced with printk("%s\n", cont_line->buffer).

so it seems that we need to re-think it.

-ss

Re: printk: what is going on with additional newlines?

[Sergey Senozhatsky]

On (09/04/17 13:30), Sergey Senozhatsky wrote:
> On (09/01/17 10:32), Joe Perches wrote:
> [..]
> > > +static inlin __printf(2, 3) __cold
> > 
> > uncompiled
> > 
> > > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...)
> > 
> > inline
> > 
> 
> thanks.
> 
> there is always a missing

d'oh...  s/always/also/

-ss

Re: linux-next: manual merge of the tip tree with the arm64 tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 13:38:02 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/firmware/efi/libstub/arm64-stub.c
> 
> between commit:
> 
>   170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")
> 
> from the arm64 tree and commit:
> 
>   0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
> markers")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/firmware/efi/libstub/arm64-stub.c
> index af6ae95a5e34,f7a6970e9abc..
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@@ -9,10 -9,17 +9,18 @@@
>* published by the Free Software Foundation.
>*
>*/
> + 
> + /*
> +  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
> +  * references to the section markers, override their visibility as 'hidden'
> +  */
> + #pragma GCC visibility push(hidden)
> + #include 
> + #pragma GCC visibility pop
> + 
>   #include 
>   #include 
>  +#include 
> - #include 
>   #include 
>   
>   #include "efistub.h"

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the usb tree with the mips tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in:

  drivers/phy/Makefile

between commit:

  0ab3aa747f26 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU 
module")

from the mips tree and commit:

  cd4ec4b03dc1 ("phy: phy-mt65xx-usb3: add mediatek directory and rename file")

from the usb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/phy/Makefile
index a8b9439a5d8e,06f3c500030d..
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@@ -4,12 -4,12 +4,12 @@@
  
  obj-$(CONFIG_GENERIC_PHY) += phy-core.o
  obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
- obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o
  obj-$(CONFIG_PHY_XGENE)   += phy-xgene.o
  obj-$(CONFIG_PHY_PISTACHIO_USB)   += phy-pistachio-usb.o
 -
  obj-$(CONFIG_ARCH_SUNXI)  += allwinner/
  obj-$(CONFIG_ARCH_MESON)  += amlogic/
 +obj-$(CONFIG_LANTIQ)  += lantiq/
+ obj-$(CONFIG_ARCH_MEDIATEK)   += mediatek/
  obj-$(CONFIG_ARCH_RENESAS)+= renesas/
  obj-$(CONFIG_ARCH_ROCKCHIP)   += rockchip/
  obj-$(CONFIG_ARCH_TEGRA)  += tegra/

Re: Applied "regulator: pbias: Select voltage table based on max-voltage" to the regulator tree

[Kishon Vijay Abraham I]

Hi Mark,

On Friday 01 September 2017 09:53 PM, Mark Brown wrote:
> On Fri, Sep 01, 2017 at 03:18:03PM +0200, Ulf Hansson wrote:
>> On 31 August 2017 at 15:50, Mark Brown  wrote:
>>> On Thu, Aug 31, 2017 at 05:37:34PM +0530, Kishon Vijay Abraham I wrote:
> 
 This patch should be merged along with the 1st patch of the series "mmc: 
 host:
 omap_hsmmc: Remove setting PBIAS voltage". Or else it'll break MMC with
 omap_hsmmc driver.
> 
> Hang on, how can this break anything?  If it breaks things shouldn't
> there be bugfixes for incorrect constraints somewhere?

omap_hsmmc sets the pbias voltage to 3V. But here we program the volt table to
support either 1.8V or 3.3V (Initially the volt table was programmed to support
3V because of a bug in TRM). So set_voltage of pbias voltage in omap_hsmmc will
fail.

Thanks
Kishon

Re: linux-next: manual merge of the v4l-dvb tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 10:55:34 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the v4l-dvb tree got a conflict in:
> 
>   arch/arm/configs/imx_v6_v7_defconfig
> 
> between commit:
> 
>   b834bc1c52b8 ("ARM: imx_v6_v7_defconfig: Enable staging video4linux 
> drivers")
> 
> from the arm-soc tree and commit:
> 
>   b9e1486e0e4b ("media: rc-core: do not depend on MEDIA_SUPPORT")
> 
> from the v4l-dvb tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm/configs/imx_v6_v7_defconfig
> index 3a48ad809731,1736813bdea7..
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@@ -230,9 -226,7 +230,9 @@@ CONFIG_REGULATOR_MC13892=
>   CONFIG_REGULATOR_PFUZE100=y
>   CONFIG_MEDIA_SUPPORT=y
>   CONFIG_MEDIA_CAMERA_SUPPORT=y
> - CONFIG_MEDIA_RC_SUPPORT=y
> + CONFIG_RC_CORE=y
>  +CONFIG_MEDIA_CONTROLLER=y
>  +CONFIG_VIDEO_V4L2_SUBDEV_API=y
>   CONFIG_RC_DEVICES=y
>   CONFIG_IR_GPIO_CIR=y
>   CONFIG_MEDIA_USB_SUPPORT=y

Just a reminder that this conflict still exists.

-- 
Cheers,
Stephen Rothwell

[PATCH] binder: fix "cast to pointer from integer of different size" warning

[Jisheng Zhang]

The binder driver now could cause warnings as below on 32bit platforms
if ANDROID_BINDER_IPC_32BIT is unselected:

drivers/android/binder.c:1550:15: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]

This patch fix all of them.

Signed-off-by: Jisheng Zhang 
---
 drivers/android/binder.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index f7665c31feca..2812586bfae5 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1547,7 +1547,8 @@ static void binder_transaction_buffer_release(struct 
binder_proc *proc,
   debug_id, (u64)fda->num_fds);
continue;
}
-   fd_array = (u32 *)(parent_buffer + fda->parent_offset);
+   fd_array = (u32 *)(parent_buffer +
+  (uintptr_t)fda->parent_offset);
for (fd_index = 0; fd_index < fda->num_fds; fd_index++)
task_close_fd(proc, fd_array[fd_index]);
} break;
@@ -1751,7 +1752,7 @@ static int binder_translate_fd_array(struct 
binder_fd_array_object *fda,
 * back to the kernel address space to access it
 */
parent_buffer = parent->buffer - target_proc->user_buffer_offset;
-   fd_array = (u32 *)(parent_buffer + fda->parent_offset);
+   fd_array = (u32 *)(parent_buffer + (uintptr_t)fda->parent_offset);
if (!IS_ALIGNED((unsigned long)fd_array, sizeof(u32))) {
binder_user_error("%d:%d parent offset not aligned 
correctly.\n",
  proc->pid, thread->pid);
@@ -1786,7 +1787,7 @@ static int binder_fixup_parent(struct binder_transaction 
*t,
   binder_size_t last_fixup_min_off)
 {
struct binder_buffer_object *parent;
-   u8 *parent_buffer;
+   uintptr_t parent_buffer;
struct binder_buffer *b = t->buffer;
struct binder_proc *proc = thread->proc;
struct binder_proc *target_proc = t->to_proc;
@@ -1817,9 +1818,9 @@ static int binder_fixup_parent(struct binder_transaction 
*t,
  proc->pid, thread->pid);
return -EINVAL;
}
-   parent_buffer = (u8 *)(parent->buffer -
-  target_proc->user_buffer_offset);
-   *(binder_uintptr_t *)(parent_buffer + bp->parent_offset) = bp->buffer;
+   parent_buffer = parent->buffer - target_proc->user_buffer_offset;
+   *(binder_uintptr_t *)(parent_buffer +
+ (uintptr_t)bp->parent_offset) = bp->buffer;
 
return 0;
 }
-- 
2.14.1

Re: linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Aug 2017 13:50:57 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/amd_iommu.c
>   drivers/iommu/amd_iommu_init.c
>   drivers/iommu/amd_iommu_proto.h
>   drivers/iommu/amd_iommu_types.h
> 
> between commits:
> 
>   4c232a708be1 ("iommu/amd: Detect pre enabled translation")
>   9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
>   07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
>   daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
> 
> from the iommu tree and commit:
> 
>   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory 
> encryption")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iommu/amd_iommu.c
> index 31bce367866c,4ad7e5e31943..
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
>   return -EBUSY;
>   
>   if (count > 1) {
> - __pte = PAGE_SIZE_PTE(phys_addr, page_size);
> + __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
>  -__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
>  +__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   } else
> - __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
>  -__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
> ++__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   
>   if (prot & IOMMU_PROT_IR)
>   __pte |= IOMMU_PTE_IR;
> diff --cc drivers/iommu/amd_iommu_init.c
> index ff8887ac,2292a6cece76..
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@@ -29,6 -29,8 +29,7 @@@
>   #include 
>   #include 
>   #include 
>  -#include 
> + #include 
>   #include 
>   #include 
>   #include 
> diff --cc drivers/iommu/amd_iommu_proto.h
> index 90e62e9b01c5,3f12fb2338ea..
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
>   return !!(iommu->features & f);
>   }
>   
> + static inline u64 iommu_virt_to_phys(void *vaddr)
> + {
> + return (u64)__sme_set(virt_to_phys(vaddr));
> + }
> + 
> + static inline void *iommu_phys_to_virt(unsigned long paddr)
> + {
> + return phys_to_virt(__sme_clr(paddr));
> + }
> + 
>  +extern bool translation_pre_enabled(struct amd_iommu *iommu);
>  +extern struct iommu_dev_data *get_dev_data(struct device *dev);
>   #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
> diff --cc drivers/iommu/amd_iommu_types.h
> index 5f775fef341c,8591f43c467c..
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@@ -361,8 -343,8 +361,8 @@@
>   #define GCR3_VALID  0x01ULL
>   
>   #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
>  -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
>  +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
> - #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
> + #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
>   #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
>   
>   #define IOMMU_PROT_MASK 0x03

Just a reminder that these conflicts still exist.

-- 
Cheers,
Stephen Rothwell

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

[Christoph Hellwig]

Thanks Stephen, I'll fix it.

Re: printk: what is going on with additional newlines?

[Joe Perches]

On Mon, 2017-09-04 at 14:22 +0900, Sergey Senozhatsky wrote:
> there is only way to serialize printks against other printks -- take
> the logbuf lock.

If that's really necessary, instead make that
logbuf_lock a public interface and keep the rest
of the code simple.

I think it's more important to get printk to work
reliably than keep expanding the number of lines
possible to buffer.

[PATCH] ALSA: hda: Fix regression of hdmi eld control created based on invalid pcm

[Wang YanQing]

Commit fb087eaaef72 ("ALSA: hda - hdmi eld control created based on pcm")
forget to filter out invalid pcm numbers, if there is only one invalid pcm
number, then this issue causes we create eld control for invalid pcm silently,
but when there are more than one invalid pcm numbers, then this issue bring
probe error looks like below dmesg:
"
kernel: [1.647283] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
0xc2967540)
kernel: [1.651192] snd_hda_intel :00:03.0: Too many HDMI devices
kernel: [1.651195] snd_hda_intel :00:03.0: Consider building the kernel 
with CONFIG_SND_DYNAMIC_MINORS=y
kernel: [1.651197] snd_hda_intel :00:03.0: Too many HDMI devices
kernel: [1.651199] snd_hda_intel :00:03.0: Consider building the kernel 
with CONFIG_SND_DYNAMIC_MINORS=y
kernel: [1.651201] snd_hda_intel :00:03.0: Too many HDMI devices
kernel: [1.651203] snd_hda_intel :00:03.0: Consider building the kernel 
with CONFIG_SND_DYNAMIC_MINORS=y
kernel: [1.651676] snd_hda_intel :00:03.0: control 3:0:0:ELD:0 is 
already present
kernel: [1.651787] snd_hda_codec_hdmi: probe of hdaudioC0D0 failed with 
error -16
"

This patch add invalid pcm number filter before calling hdmi_create_eld_ctl.

Fixes: fb087eaaef72 ("ALSA: hda - hdmi eld control created based on pcm")
Signed-off-by: Wang YanQing 
---
 sound/pci/hda/hda_codec.c  |  4 +++-
 sound/pci/hda/hda_codec.h  |  1 +
 sound/pci/hda/patch_hdmi.c | 14 --
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 821aad3..3db26c4 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3213,8 +3213,10 @@ int snd_hda_codec_build_pcms(struct hda_codec *codec)
continue; /* no substreams assigned */
 
dev = get_empty_pcm_device(bus, cpcm->pcm_type);
-   if (dev < 0)
+   if (dev < 0) {
+   cpcm->device = SNDRV_PCM_INVALID_DEVICE;
continue; /* no fatal error */
+   }
cpcm->device = dev;
err =  snd_hda_attach_pcm_stream(bus, codec, cpcm);
if (err < 0) {
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 60ce1cf..681c360 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -164,6 +164,7 @@ enum {
HDA_PCM_NTYPES
 };
 
+#define SNDRV_PCM_INVALID_DEVICE   (-1)
 /* for PCM creation */
 struct hda_pcm {
char *name;
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 53f9311..2b64fab 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2126,7 +2126,7 @@ static int generic_hdmi_build_jack(struct hda_codec 
*codec, int pcm_idx)
 static int generic_hdmi_build_controls(struct hda_codec *codec)
 {
struct hdmi_spec *spec = codec->spec;
-   int err;
+   int dev, err;
int pin_idx, pcm_idx;
 
 
@@ -2154,11 +2154,13 @@ static int generic_hdmi_build_controls(struct hda_codec 
*codec)
return err;
snd_hda_spdif_ctls_unassign(codec, pcm_idx);
 
-   /* add control for ELD Bytes */
-   err = hdmi_create_eld_ctl(codec, pcm_idx,
-   get_pcm_rec(spec, pcm_idx)->device);
-   if (err < 0)
-   return err;
+   dev = get_pcm_rec(spec, pcm_idx)->device;
+   if (dev != SNDRV_PCM_INVALID_DEVICE) {
+   /* add control for ELD Bytes */
+   err = hdmi_create_eld_ctl(codec, pcm_idx, dev);
+   if (err < 0)
+   return err;
+   }
}
 
for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
-- 
1.8.5.6.2.g3d8a54e.dirty

[PATCH 2/2] [media] meye: Adjust two function calls together with a variable assignment

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 3 Sep 2017 15:41:53 +0200

The script "checkpatch.pl" pointed information out like the following.

ERROR: do not use assignment in if condition

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/media/pci/meye/meye.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index db36040770a6..9b69a07c1d5b 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -1642,14 +1642,15 @@ static int meye_probe(struct pci_dev *pcidev, const 
struct pci_device_id *ent)
meye.vdev = meye_template;
meye.vdev.v4l2_dev = _dev;
 
-   ret = -EIO;
-   if ((ret = sony_pic_camera_command(SONY_PIC_COMMAND_SETCAMERA, 1))) {
+   ret = sony_pic_camera_command(SONY_PIC_COMMAND_SETCAMERA, 1);
+   if (ret) {
v4l2_err(v4l2_dev, "meye: unable to power on the camera\n");
v4l2_err(v4l2_dev, "meye: did you enable the camera in sonypi 
using the module options ?\n");
goto outsonypienable;
}
 
-   if ((ret = pci_enable_device(meye.mchip_dev))) {
+   ret = pci_enable_device(meye.mchip_dev);
+   if (ret) {
v4l2_err(v4l2_dev, "meye: pci_enable_device failed\n");
goto outenabledev;
}
-- 
2.14.1

[PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory

[Chao Fan]

KASLR should choose the memory region of immovable node to extract kernel.
So get ACPI SRAT table and store the memory region of movable node which
kaslr shold avoid.

Signed-off-by: Chao Fan 
---
v2: Add the support for bios
---
 arch/x86/boot/compressed/kaslr.c | 346 +++
 arch/x86/boot/compressed/misc.h  |  42 +
 2 files changed, 388 insertions(+)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 17818ba6906f..8f2b42dc3685 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -45,6 +45,12 @@
 #define STATIC
 #include 
 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 extern unsigned long get_cmd_line_ptr(void);
 
 /* Simplified build-specific string for starting entropy. */
@@ -94,6 +100,18 @@ static bool memmap_too_large;
 /* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
 unsigned long long mem_limit = ULLONG_MAX;
 
+/* Store the max numbers of acpi tables */
+#define ACPI_MAX_TABLES128
+
+/* Store the movable memory */
+static struct {
+   u64 start;
+   u64 end;
+} movable_mem[MAX_NUMNODES*2];
+
+/* Store the num of movable mem affinity */
+static int num_movable_ma;
+
 
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
@@ -257,6 +275,296 @@ static int handle_mem_memmap(void)
return 0;
 }
 
+static bool efi_find_rsdp_addr(acpi_physical_address *rsdp_addr)
+{
+   efi_system_table_t *systab;
+   bool find_rsdp = false;
+   int size, total_size;
+   bool acpi_20 = false;
+   bool efi_64 = false;
+   void *config_tables;
+   struct efi_info *e;
+   char *sig;
+   int i;
+
+#ifndef CONFIG_EFI
+   return false;
+#endif
+
+   e = _params->efi_info;
+   sig = (char *)>efi_loader_signature;
+
+   if (!strncmp(sig, EFI64_LOADER_SIGNATURE, 4))
+   efi_64 = true;
+   else if (!strncmp(sig, EFI32_LOADER_SIGNATURE, 4))
+   efi_64 = false;
+   else {
+   debug_putstr("Wrong efi loader signature.\n");
+   return false;
+   }
+
+   // Get systab from boot params
+#ifdef CONFIG_X86_32
+   if (e->efi_systab_hi || e->efi_memmap_hi) {
+   debug_putstr("Table located above 4GB, disabling EFI.\n");
+   return false;
+   }
+   systab = (efi_system_table_t *)e->efi_systab;
+#else
+   systab = (efi_system_table_t *)(e->efi_systab |
+   ((__u64)e->efi_systab_hi<<32));
+#endif
+
+   // Get efi tables from systab
+   size = efi_64 ? sizeof(efi_config_table_64_t) :
+   sizeof(efi_config_table_32_t);
+   total_size = systab->nr_tables * size;
+
+   for (i = 0; i < systab->nr_tables; i++) {
+   efi_guid_t guid;
+   unsigned long table;
+
+   config_tables = (void *)(systab->tables + size * i);
+   if (efi_64) {
+   efi_config_table_64_t *tmp_table;
+
+   tmp_table = (efi_config_table_64_t *)config_tables;
+   guid = tmp_table->guid;
+   table = tmp_table->table;
+#ifndef CONFIG_64BIT
+   if (table >> 32) {
+   debug_putstr
+   ("Table located above 4G, disabling EFI.\n");
+   return false;
+   }
+#endif
+   } else {
+   efi_config_table_32_t *tmp_table;
+
+   tmp_table = (efi_config_table_32_t *)config_tables;
+   guid = tmp_table->guid;
+   table = tmp_table->table;
+   }
+
+   // Get rsdp from efi tables
+   if (!(efi_guidcmp(guid, ACPI_TABLE_GUID)) && !acpi_20) {
+   *rsdp_addr = (acpi_physical_address)table;
+   acpi_20 = false;
+   find_rsdp = true;
+   } else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID))) {
+   *rsdp_addr = (acpi_physical_address)table;
+   acpi_20 = true;
+   return true;
+   }
+   }
+   return find_rsdp;
+}
+
+static u8 checksum(u8 *buffer, u32 length)
+{
+   u8 sum = 0;
+   u8 *end = buffer + length;
+
+   while (buffer < end)
+   sum = (u8)(sum + *(buffer++));
+
+   return sum;
+}
+
+static u8 *scan_memory_for_rsdp(u8 *start_address, u32 length)
+{
+   struct acpi_table_rsdp *rsdp;
+   u8 *end_address;
+   u8 *mem_rover;
+
+   end_address = start_address + length;
+
+   for (mem_rover = start_address; mem_rover < end_address;
+mem_rover += ACPI_RSDP_SCAN_STEP) {
+   rsdp = ACPI_CAST_PTR(struct acpi_table_rsdp, mem_rover);
+   if (!ACPI_VALIDATE_RSDP_SIG(rsdp->signature))
+  

Re: [PATCH] ALSA: hda: Fix regression of hdmi eld control created based on invalid pcm

[Takashi Iwai]

On Sun, 03 Sep 2017 15:18:49 +0200,
Wang YanQing wrote:
> 
> Commit fb087eaaef72 ("ALSA: hda - hdmi eld control created based on pcm")
> forget to filter out invalid pcm numbers, if there is only one invalid pcm
> number, then this issue causes we create eld control for invalid pcm silently,
> but when there are more than one invalid pcm numbers, then this issue bring
> probe error looks like below dmesg:
> "
> kernel: [1.647283] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
> 0xc2967540)
> kernel: [1.651192] snd_hda_intel :00:03.0: Too many HDMI devices
> kernel: [1.651195] snd_hda_intel :00:03.0: Consider building the 
> kernel with CONFIG_SND_DYNAMIC_MINORS=y
> kernel: [1.651197] snd_hda_intel :00:03.0: Too many HDMI devices
> kernel: [1.651199] snd_hda_intel :00:03.0: Consider building the 
> kernel with CONFIG_SND_DYNAMIC_MINORS=y
> kernel: [1.651201] snd_hda_intel :00:03.0: Too many HDMI devices
> kernel: [1.651203] snd_hda_intel :00:03.0: Consider building the 
> kernel with CONFIG_SND_DYNAMIC_MINORS=y
> kernel: [1.651676] snd_hda_intel :00:03.0: control 3:0:0:ELD:0 is 
> already present
> kernel: [1.651787] snd_hda_codec_hdmi: probe of hdaudioC0D0 failed with 
> error -16
> "
> 
> This patch add invalid pcm number filter before calling hdmi_create_eld_ctl.
> 
> Fixes: fb087eaaef72 ("ALSA: hda - hdmi eld control created based on pcm")
> Signed-off-by: Wang YanQing 

Applied, thanks.


Takashi

[PATCH] dt-binding: phy: don't confuse with Ethernet phy properties

[Baruch Siach]

The generic PHY 'phys' property sometime appears in the same node with
the Ethernet PHY 'phy' or 'phy-handle' properties. Add a warning in
phy-bindings.txt to reduce confusion.

Signed-off-by: Baruch Siach 
---
 Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
index 1293c321754c..a403b81d0679 100644
--- a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -34,7 +34,9 @@ PHY user node
 =
 
 Required Properties:
-phys : the phandle for the PHY device (used by the PHY subsystem)
+phys : the phandle for the PHY device (used by the PHY subsystem; not to be
+   confused with the Ethernet specific 'phy' and 'phy-handle' properties,
+   see Documentation/devicetree/bindings/net/ethernet.txt for these)
 phy-names : the names of the PHY corresponding to the PHYs present in the
*phys* phandle
 
-- 
2.14.1

Re: [PATCH] ALSA: hda: Fix forget to free resource in error handling code path in hda_codec_driver_probe

[Takashi Iwai]

On Sun, 03 Sep 2017 16:11:22 +0200,
Wang YanQing wrote:
> 
> When hda_codec_driver_probe meet error and return failure, we need
> to free resource with patch_ops.free, or we will get resource leak.

No, the codec driver is responsible to free resources in its error
path.


thanks,

Takashi

[PATCH 2/3] ARM: dts: sun7i: Use defines for clock and reset indices

[Priit Laes]

We can now use defines for clock/reset indices defined in the
devicetree binding include files.

Signed-off-by: Priit Laes 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 146 
 1 file changed, 74 insertions(+), 72 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index a5ca5a8..39d0727 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -47,6 +47,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -64,10 +66,10 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
-   clocks = < 56>, < 60>,
-< 62>, < 144>,
-< 155>, < 140>,
-< 164>;
+   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI0>,
+< CLK_AHB_DE_BE0>, < CLK_DE_BE0>,
+< CLK_TCON0_CH1>, < CLK_DRAM_DE_BE0>,
+< CLK_HDMI>;
status = "disabled";
};
 
@@ -75,9 +77,9 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
-   clocks = < 56>, < 62>,
-< 144>, < 149>,
-< 140>;
+   clocks = < CLK_AHB_LCD0>, < CLK_AHB_DE_BE0>,
+< CLK_DE_BE0>, < CLK_TCON0_CH0>,
+< CLK_DRAM_DE_BE0>;
status = "disabled";
};
 
@@ -85,10 +87,10 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-tve0";
-   clocks = < 54>, < 56>,
-< 62>,
-< 144>, < 155>,
-< 135>, < 140>;
+   clocks = < CLK_AHB_TVE0>, < CLK_AHB_LCD0>,
+< CLK_AHB_DE_BE0>,
+< CLK_DE_BE0>, < CLK_TCON0_CH1>,
+< CLK_DRAM_TVE0>, < CLK_DRAM_DE_BE0>;
status = "disabled";
};
};
@@ -101,7 +103,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
-   clocks = < 20>;
+   clocks = < CLK_CPU>;
clock-latency = <244144>; /* 8 32k periods */
operating-points = <
/* kHzuV */
@@ -280,7 +282,7 @@
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
interrupts = ;
-   clocks = < 32>;
+   clocks = < CLK_AHB_DMA>;
#dma-cells = <2>;
};
 
@@ -288,7 +290,7 @@
compatible = "allwinner,sun4i-a10-nand";
reg = <0x01c03000 0x1000>;
interrupts = ;
-   clocks = < 39>, < 96>;
+   clocks = < CLK_AHB_NAND>, < CLK_NAND>;
clock-names = "ahb", "mod";
dmas = < SUN4I_DMA_DEDICATED 3>;
dma-names = "rxtx";
@@ -301,7 +303,7 @@
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c05000 0x1000>;
interrupts = ;
-   clocks = < 44>, < 112>;
+   clocks = < CLK_AHB_SPI0>, < CLK_SPI0>;
clock-names = "ahb", "mod";
dmas = < SUN4I_DMA_DEDICATED 27>,
   < SUN4I_DMA_DEDICATED 26>;
@@ -316,7 +318,7 @@
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c06000 0x1000>;
interrupts = ;
-   clocks = < 45>, < 113>;
+   clocks = < CLK_AHB_SPI1>, < CLK_SPI1>;
clock-names = "ahb", "mod";
dmas = < SUN4I_DMA_DEDICATED 9>,
   < SUN4I_DMA_DEDICATED 8>;
@@ -331,7 +333,7 @@
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
interrupts = ;
-   clocks = < 42>;
+   clocks = < CLK_AHB_EMAC>;
allwinner,sram = <_sram 1>;

[PATCH 1/3] ARM: dts: sun4i: Use defines for clock and reset indices

[Priit Laes]

We can now use defines for clock/reset indices defined in the
dt-bindings includes.

Signed-off-by: Priit Laes 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 121 
 1 file changed, 61 insertions(+), 60 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index fc23c41..c5efd53 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -44,8 +44,9 @@
 #include "skeleton.dtsi"
 
 #include 
-
 #include 
+#include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -63,9 +64,9 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
-   clocks = < 56>, < 60>,
-< 62>, < 144>,
-< 155>, < 140>;
+   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI0>,
+< CLK_AHB_DE_BE0>, < CLK_DE_BE0>,
+< CLK_TCON0_CH1>, < CLK_DRAM_DE_BE0>;
status = "disabled";
};
 
@@ -73,11 +74,11 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_fe0-de_be0-lcd0-hdmi";
-   clocks = < 56>, < 60>,
-< 62>, < 64>,
-< 144>, < 146>,
-< 155>, < 164>,
-< 139>, < 140>;
+   clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI0>,
+< CLK_AHB_DE_BE0>, < CLK_AHB_DE_FE0>,
+< CLK_DE_BE0>, < CLK_AHB_DE_FE0>,
+< CLK_TCON0_CH1>, < CLK_HDMI>,
+< CLK_DRAM_DE_FE0>, < CLK_DRAM_DE_BE0>;
status = "disabled";
};
 
@@ -85,10 +86,10 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_fe0-de_be0-lcd0";
-   clocks = < 56>, < 62>,
-< 64>, < 144>,
-< 146>, < 149>,
-< 139>, < 140>;
+   clocks = < CLK_AHB_LCD0>, < CLK_AHB_DE_BE0>,
+< CLK_AHB_DE_FE0>, < CLK_DE_BE0>,
+< CLK_AHB_DE_FE0>, < CLK_TCON0_CH0>,
+< CLK_DRAM_DE_FE0>, < CLK_DRAM_DE_BE0>;
status = "disabled";
};
 
@@ -96,11 +97,11 @@
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
-   clocks = < 54>, < 56>,
-< 62>, < 64>,
-< 144>, < 146>,
-< 155>, < 135>,
-< 139>, < 140>;
+   clocks = < CLK_AHB_TVE0>, < CLK_AHB_LCD0>,
+< CLK_AHB_DE_BE0>, < CLK_AHB_DE_FE0>,
+< CLK_DE_BE0>, < CLK_AHB_DE_FE0>,
+< CLK_TCON0_CH1>, < CLK_DRAM_TVE0>,
+< CLK_DRAM_DE_FE0>, < CLK_DRAM_DE_BE0>;
status = "disabled";
};
};
@@ -112,7 +113,7 @@
device_type = "cpu";
compatible = "arm,cortex-a8";
reg = <0x0>;
-   clocks = < 20>;
+   clocks = < CLK_CPU>;
clock-latency = <244144>; /* 8 32k periods */
operating-points = <
/* kHzuV */
@@ -229,7 +230,7 @@
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
interrupts = <27>;
-   clocks = < 32>;
+   clocks = < CLK_AHB_DMA>;
#dma-cells = <2>;
};
 
@@ -237,7 +238,7 @@
compatible = "allwinner,sun4i-a10-nand";
reg = <0x01c03000 0x1000>;
interrupts = <37>;
-   clocks = < 39>, < 96>;
+   clocks = < CLK_AHB_NAND>, < CLK_NAND>;
clock-names = "ahb", "mod";
dmas = < SUN4I_DMA_DEDICATED 3>;
dma-names = "rxtx";
@@ -250,7 +251,7 @@
compatible = "allwinner,sun4i-a10-spi";
reg 

[PATCH 0/3] ARM: dts: sunxi: Use defines for ccu clock indices

[Priit Laes]

This is a follow-up commit for sun{4,7}i ccu conversion. Now that
all the relevant pieces have been merged we can use dt-binding headers
again.

Also included is additional patch to add i2s0 block to sun4i dtsi header.

Priit Laes (3):
  ARM: dts: sun4i: Use defines for clock and reset indices
  ARM: dts: sun7i: Use defines for clock and reset indices
  ARM: dts: sun4i: Add i2s0 block to dtsi

 arch/arm/boot/dts/sun4i-a10.dtsi | 134 -
 arch/arm/boot/dts/sun7i-a20.dtsi | 146 
 2 files changed, 148 insertions(+), 132 deletions(-)

base-commit: d11067fd67a0549b0e7b330dbcbdc28f90ba5712
-- 
git-series 0.9.1

[PATCH 0/2] [media] Motion Eye: Adjustments for meye_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 3 Sep 2017 15:54:45 +0200

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete three error messages for a failed memory allocation
  Adjust two function calls together with a variable assignment

 drivers/media/pci/meye/meye.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

-- 
2.14.1

[PATCH 1/2] [media] meye: Delete three error messages for a failed memory allocation in meye_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sun, 3 Sep 2017 15:30:04 +0200

Omit extra messages for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/pci/meye/meye.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index 9c4a024745de..db36040770a6 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -1626,23 +1626,18 @@ static int meye_probe(struct pci_dev *pcidev, const 
struct pci_device_id *ent)
meye.mchip_dev = pcidev;
 
meye.grab_temp = vmalloc(MCHIP_NB_PAGES_MJPEG * PAGE_SIZE);
-   if (!meye.grab_temp) {
-   v4l2_err(v4l2_dev, "grab buffer allocation failed\n");
+   if (!meye.grab_temp)
goto outvmalloc;
-   }
 
spin_lock_init(_lock);
if (kfifo_alloc(, sizeof(int) * MEYE_MAX_BUFNBRS,
-   GFP_KERNEL)) {
-   v4l2_err(v4l2_dev, "fifo allocation failed\n");
+   GFP_KERNEL))
goto outkfifoalloc1;
-   }
+
spin_lock_init(_lock);
if (kfifo_alloc(, sizeof(int) * MEYE_MAX_BUFNBRS,
-   GFP_KERNEL)) {
-   v4l2_err(v4l2_dev, "fifo allocation failed\n");
+   GFP_KERNEL))
goto outkfifoalloc2;
-   }
 
meye.vdev = meye_template;
meye.vdev.v4l2_dev = _dev;
-- 
2.14.1

[PATCH] ALSA: hda: Fix forget to free resource in error handling code path in hda_codec_driver_probe

[Wang YanQing]

When hda_codec_driver_probe meet error and return failure, we need
to free resource with patch_ops.free, or we will get resource leak.

Signed-off-by: Wang YanQing 
---
 sound/pci/hda/hda_bind.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index 6efadbf..f1b1b7e 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -123,6 +123,8 @@ static int hda_codec_driver_probe(struct device *dev)
module_put(owner);
 
  error:
+   if (codec->patch_ops.free)
+   codec->patch_ops.free(codec);
snd_hda_codec_cleanup_for_unbind(codec);
return err;
 }
-- 
1.8.5.6.2.g3d8a54e.dirty

Re: [PATCH] ALSA: hda: Fix assign invalid fixed slots pcm numbers to HDA_PCM_TYPE_HDMI in get_empty_pcm_device

[Takashi Iwai]

On Sun, 03 Sep 2017 15:52:31 +0200,
Wang YanQing wrote:
> 
> The length of pcm_dev_bits in hda_bus is SNDRV_PCM_DEVICES,
> and the definiton of SNDRV_PCM_DEVICES is:
> "
>  #if defined(CONFIG_SND_DYNAMIC_MINORS)
>  #define SNDRV_PCM_DEVICES   (SNDRV_OS_MINORS-2)
>  #else
>  #define SNDRV_PCM_DEVICES   8
>  #endif
> "
> 
> So the max valid fixed slots pcm number is 7, and the first
> non-fixed slot is 8.

It's only when CONFIG_SND_DYNAMIC_MINORS=n, and that's already covered
in the code in get_empty_pcm_device().

#ifndef CONFIG_SND_DYNAMIC_MINORS
if (audio_idx[type][i] >= 8)
  break;
#endif

For CONFIG_SND_DYNAMIC_MINORS=y, there is no such restriction, thus
the non-fixed slot begins from 10 as in the current code.


thanks,

Takashi

> 
> Signed-off-by: Wang YanQing 
> ---
>  sound/pci/hda/hda_codec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> index 3db26c4..df6b57e 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -3118,7 +3118,7 @@ static int get_empty_pcm_device(struct hda_bus *bus, 
> unsigned int type)
>   static int audio_idx[HDA_PCM_NTYPES][5] = {
>   [HDA_PCM_TYPE_AUDIO] = { 0, 2, 4, 5, -1 },
>   [HDA_PCM_TYPE_SPDIF] = { 1, -1 },
> - [HDA_PCM_TYPE_HDMI]  = { 3, 7, 8, 9, -1 },
> + [HDA_PCM_TYPE_HDMI]  = { 3, 7, -1 },
>   [HDA_PCM_TYPE_MODEM] = { 6, -1 },
>   };
>   int i;
> @@ -3139,7 +3139,7 @@ static int get_empty_pcm_device(struct hda_bus *bus, 
> unsigned int type)
>  
>  #ifdef CONFIG_SND_DYNAMIC_MINORS
>   /* non-fixed slots starting from 10 */
> - for (i = 10; i < 32; i++) {
> + for (i = 8; i < 32; i++) {
>   if (!test_and_set_bit(i, bus->pcm_dev_bits))
>   return i;
>   }
> -- 
> 1.8.5.6.2.g3d8a54e.dirty
> 

[PATCH v2 7/8] staging: ccree: replace noop macro with inline

[Gilad Ben-Yossef]

Replace noop macro with a noop inline function

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 06a3c48..81ba827 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -187,8 +187,8 @@ struct async_gen_req_ctx {
 #ifdef DX_DUMP_BYTES
 void dump_byte_array(const char *name, const u8 *the_array, unsigned long 
size);
 #else
-#define dump_byte_array(name, array, size) do {\
-} while (0);
+static inline void dump_byte_array(const char *name, const u8 *the_array,
+  unsigned long size) {};
 #endif
 
 int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe);
-- 
2.1.4

[PATCH v2 8/8] staging: ccree: remove BUG macro usage

[Gilad Ben-Yossef]

Replace BUG() macro usage that crash the kernel with alternatives
that signal error and/or try to recover.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c  | 14 ++
 drivers/staging/ccree/ssi_cipher.c  |  1 -
 drivers/staging/ccree/ssi_pm.c  |  3 ++-
 drivers/staging/ccree/ssi_request_mgr.c | 22 --
 4 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 6393609..d744820 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -81,11 +81,6 @@ static unsigned int ssi_buffer_mgr_get_sgl_nents(
unsigned int nents = 0;
 
while (nbytes != 0) {
-   if (sg_is_chain(sg_list)) {
-   SSI_LOG_ERR("Unexpected chained entry "
-  "in sg (entry =0x%X)\n", nents);
-   BUG();
-   }
if (sg_list->length != 0) {
nents++;
/* get the number of bytes in the last entry */
@@ -854,7 +849,8 @@ static inline int ssi_buffer_mgr_aead_chain_assoc(
//if have reached the end of the sgl, then this is 
unexpected
if (!current_sg) {
SSI_LOG_ERR("reached end of sg list. 
unexpected\n");
-   BUG();
+   rc = -EINVAL;
+   goto chain_assoc_exit;
}
sg_index += current_sg->length;
mapped_nents++;
@@ -1154,7 +1150,8 @@ static inline int ssi_buffer_mgr_aead_chain_data(
//if have reached the end of the sgl, then this is unexpected
if (!areq_ctx->src_sgl) {
SSI_LOG_ERR("reached end of sg list. unexpected\n");
-   BUG();
+   return -EINVAL;
+   goto chain_data_exit;
}
sg_index += areq_ctx->src_sgl->length;
src_mapped_nents--;
@@ -1198,7 +1195,8 @@ static inline int ssi_buffer_mgr_aead_chain_data(
//if have reached the end of the sgl, then this is unexpected
if (!areq_ctx->dst_sgl) {
SSI_LOG_ERR("reached end of sg list. unexpected\n");
-   BUG();
+   rc = -EINVAL;
+   goto chain_data_exit;
}
sg_index += areq_ctx->dst_sgl->length;
dst_mapped_nents--;
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 4311746..68c9fc0 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -541,7 +541,6 @@ ssi_blkcipher_create_setup_desc(
break;
default:
SSI_LOG_ERR("Unsupported cipher mode (%d)\n", cipher_mode);
-   BUG();
}
 }
 
diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index 31325e6..a50671a 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -109,7 +109,8 @@ int ssi_power_mgr_runtime_put_suspend(struct device *dev)
rc = pm_runtime_put_autosuspend(dev);
} else {
/* Something wrong happens*/
-   BUG();
+   SSI_LOG_ERR("request to suspend already suspended queue");
+   rc = -EBUSY;
}
return rc;
 }
diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index e5c2f92..97c2359 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -369,11 +369,16 @@ int send_request(
enqueue_seq(cc_base, _mgr_h->compl_desc, (is_dout ? 0 : 1));
 
if (unlikely(req_mgr_h->q_free_slots < total_seq_len)) {
-   /*This means that there was a problem with the resume*/
-   BUG();
+   /* This situation should never occur. Maybe indicating problem
+* with resuming power. Set the free slot count to 0 and hope
+* for the best.
+*/
+   SSI_LOG_ERR("HW free slot count mismatch.");
+   req_mgr_h->q_free_slots = 0;
+   } else {
+   /* Update the free slots in HW queue */
+   req_mgr_h->q_free_slots -= total_seq_len;
}
-   /* Update the free slots in HW queue */
-   req_mgr_h->q_free_slots -= total_seq_len;
 
spin_unlock_bh(_mgr_h->hw_lock);
 
@@ -460,8 +465,13 @@ static void proc_completions(struct ssi_drvdata *drvdata)
 
/* Dequeue request */
if (unlikely(request_mgr_handle->req_queue_head == 
request_mgr_handle->req_queue_tail)) {
-   

[PATCH v2 6/8] staging: ccree: move over to BIT macro for bit defines

[Gilad Ben-Yossef]

Use BIT macro for bit definitions where needed.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_cipher.h | 10 +-
 drivers/staging/ccree/ssi_driver.c |  3 ++-
 drivers/staging/ccree/ssi_driver.h |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.h 
b/drivers/staging/ccree/ssi_cipher.h
index 296b375..c9a83df 100644
--- a/drivers/staging/ccree/ssi_cipher.h
+++ b/drivers/staging/ccree/ssi_cipher.h
@@ -27,11 +27,11 @@
 #include "ssi_buffer_mgr.h"
 
 /* Crypto cipher flags */
-#define CC_CRYPTO_CIPHER_KEY_KFDE0(1 << 0)
-#define CC_CRYPTO_CIPHER_KEY_KFDE1(1 << 1)
-#define CC_CRYPTO_CIPHER_KEY_KFDE2(1 << 2)
-#define CC_CRYPTO_CIPHER_KEY_KFDE3(1 << 3)
-#define CC_CRYPTO_CIPHER_DU_SIZE_512B (1 << 4)
+#define CC_CRYPTO_CIPHER_KEY_KFDE0 BIT(0)
+#define CC_CRYPTO_CIPHER_KEY_KFDE1 BIT(1)
+#define CC_CRYPTO_CIPHER_KEY_KFDE2 BIT(2)
+#define CC_CRYPTO_CIPHER_KEY_KFDE3 BIT(3)
+#define CC_CRYPTO_CIPHER_DU_SIZE_512B  BIT(4)
 
 #define CC_CRYPTO_CIPHER_KEY_KFDE_MASK (CC_CRYPTO_CIPHER_KEY_KFDE0 | 
CC_CRYPTO_CIPHER_KEY_KFDE1 | CC_CRYPTO_CIPHER_KEY_KFDE2 | 
CC_CRYPTO_CIPHER_KEY_KFDE3)
 
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 8f1d7af..6d16220 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -185,7 +185,8 @@ int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe)
CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_ICR), val);
 
/* Unmask relevant interrupt cause */
-   val = (~(SSI_COMP_IRQ_MASK | SSI_AXI_ERR_IRQ_MASK | SSI_GPR0_IRQ_MASK));
+   val = (unsigned int)(~(SSI_COMP_IRQ_MASK | SSI_AXI_ERR_IRQ_MASK |
+  SSI_GPR0_IRQ_MASK));
CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IMR), val);
 
 #ifdef DX_HOST_IRQ_TIMER_INIT_VAL_REG_OFFSET
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 9b6476d..06a3c48 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -68,12 +68,12 @@
 #define SSI_AXI_IRQ_MASK ((1 << DX_AXIM_CFG_BRESPMASK_BIT_SHIFT) | (1 << 
DX_AXIM_CFG_RRESPMASK_BIT_SHIFT) |\
(1 << DX_AXIM_CFG_INFLTMASK_BIT_SHIFT) | (1 << 
DX_AXIM_CFG_COMPMASK_BIT_SHIFT))
 
-#define SSI_AXI_ERR_IRQ_MASK (1 << DX_HOST_IRR_AXI_ERR_INT_BIT_SHIFT)
+#define SSI_AXI_ERR_IRQ_MASK BIT(DX_HOST_IRR_AXI_ERR_INT_BIT_SHIFT)
 
-#define SSI_COMP_IRQ_MASK (1 << DX_HOST_IRR_AXIM_COMP_INT_BIT_SHIFT)
+#define SSI_COMP_IRQ_MASK BIT(DX_HOST_IRR_AXIM_COMP_INT_BIT_SHIFT)
 
 /* TEE FIPS status interrupt */
-#define SSI_GPR0_IRQ_MASK (1 << DX_HOST_IRR_GPR0_BIT_SHIFT)
+#define SSI_GPR0_IRQ_MASK BIT(DX_HOST_IRR_GPR0_BIT_SHIFT)
 
 #define SSI_CRA_PRIO 3000
 
-- 
2.1.4

[PATCH v2 3/8] staging: ccree: Use platform_get_irq and devm_request_irq

[Gilad Ben-Yossef]

From: Suniel Mahesh 

It is recommended to use managed function devm_request_irq(),
which simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace platform_get_resource(), request_irq() and corresponding
error handling with platform_get_irq() and devm_request_irq().
(b) remove struct resource pointer(res_irq) in struct ssi_drvdata as
it seems redundant.
(c) change type of member irq in struct ssi_drvdata from unsigned int
to int, as return type of platform_get_irq is int and can be used in
error handling.
(d) remove irq_registered variable from driver probe as it seems
redundant.
(e) free_irq is not required any more, devm_request_irq() free's it
on driver detach.
(f) adjust log messages accordingly and remove any blank lines.

Signed-off-by: Suniel Mahesh 
Acked-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 30 +-
 drivers/staging/ccree/ssi_driver.h |  3 +--
 2 files changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index cbe9a03..3e7193d 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -222,7 +222,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 {
struct resource *req_mem_cc_regs = NULL;
void __iomem *cc_base = NULL;
-   bool irq_registered = false;
struct ssi_drvdata *new_drvdata;
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
@@ -262,26 +261,22 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
  _mem_cc_regs->start, new_drvdata->cc_base);
cc_base = new_drvdata->cc_base;
/* Then IRQ */
-   new_drvdata->res_irq = platform_get_resource(plat_dev, IORESOURCE_IRQ, 
0);
-   if (unlikely(!new_drvdata->res_irq)) {
+   new_drvdata->irq = platform_get_irq(plat_dev, 0);
+   if (new_drvdata->irq < 0) {
SSI_LOG_ERR("Failed getting IRQ resource\n");
-   rc = -ENODEV;
+   rc = new_drvdata->irq;
goto init_cc_res_err;
}
-   rc = request_irq(new_drvdata->res_irq->start, cc_isr,
-IRQF_SHARED, "arm_cc7x", new_drvdata);
-   if (unlikely(rc != 0)) {
-   SSI_LOG_ERR("Could not register to interrupt %llu\n",
-   (unsigned long long)new_drvdata->res_irq->start);
+   rc = devm_request_irq(_dev->dev, new_drvdata->irq, cc_isr,
+ IRQF_SHARED, "arm_cc7x", new_drvdata);
+   if (rc) {
+   SSI_LOG_ERR("Could not register to interrupt %d\n",
+   new_drvdata->irq);
goto init_cc_res_err;
}
init_completion(_drvdata->icache_setup_completion);
 
-   irq_registered = true;
-   SSI_LOG_DEBUG("Registered to IRQ (%s) %llu\n",
- new_drvdata->res_irq->name,
- (unsigned long long)new_drvdata->res_irq->start);
-
+   SSI_LOG_DEBUG("Registered to IRQ: %d\n", new_drvdata->irq);
new_drvdata->plat_dev = plat_dev;
 
rc = cc_clk_on(new_drvdata);
@@ -410,10 +405,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 #ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
 #endif
-   if (irq_registered) {
-   free_irq(new_drvdata->res_irq->start, new_drvdata);
-   new_drvdata->res_irq = NULL;
-   }
dev_set_drvdata(_dev->dev, NULL);
}
return rc;
@@ -443,11 +434,8 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
 #ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
 #endif
-
fini_cc_regs(drvdata);
cc_clk_off(drvdata);
-   free_irq(drvdata->res_irq->start, drvdata);
-   drvdata->res_irq = NULL;
dev_set_drvdata(_dev->dev, NULL);
 }
 
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 518c0bf..88ef370 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -128,9 +128,8 @@ struct ssi_crypto_req {
  * @fw_ver:SeP loaded firmware version
  */
 struct ssi_drvdata {
-   struct resource *res_irq;
void __iomem *cc_base;
-   unsigned int irq;
+   int irq;
u32 irq_mask;
u32 fw_ver;
/* Calibration time of start/stop
-- 
2.1.4

[PATCH 0/8] staging: ccree: more cleanup work for 4.14

[Gilad Ben-Yossef]

More cleanup work from Sunil and myself.

I've previously sent some of these as part of a larger patch set.
I've decided to split the patch set to smaller chunks to make it
more manageable.

This patch set applies on top of commit 28eb51f7468a
("staging:rtl8188eu:core Fix remove unneccessary else block").

Changes from v1:
- Fix kbuild reported error of "label at end of compound statement"

Gilad Ben-Yossef (5):
  staging: ccree: simplify resource release on error
  staging: ccree: remove unused completion
  staging: ccree: move over to BIT macro for bit defines
  staging: ccree: replace noop macro with inline
  staging: ccree: remove BUG macro usage

Suniel Mahesh (3):
  staging: ccree: Replace kzalloc with devm_kzalloc
  staging: ccree: Convert to devm_ioremap_resource for map, unmap
  staging: ccree: Use platform_get_irq and devm_request_irq

 drivers/staging/ccree/ssi_aead.c|   3 +-
 drivers/staging/ccree/ssi_buffer_mgr.c  |  14 +--
 drivers/staging/ccree/ssi_cipher.c  |   4 +-
 drivers/staging/ccree/ssi_cipher.h  |  10 +-
 drivers/staging/ccree/ssi_driver.c  | 196 +---
 drivers/staging/ccree/ssi_driver.h  |  15 +--
 drivers/staging/ccree/ssi_hash.c|   3 +-
 drivers/staging/ccree/ssi_pm.c  |   3 +-
 drivers/staging/ccree/ssi_request_mgr.c |  22 +++-
 9 files changed, 118 insertions(+), 152 deletions(-)

-- 
2.1.4

[PATCH v2 4/8] staging: ccree: simplify resource release on error

[Gilad Ben-Yossef]

The resource release on probe/init error was being handled
in an awkward manner and possibly leaking memory on certain
(unlikely) error path.

Fix it by simplifying the error resource release and making
it easier to track.

Reported-by: Dan Carpenter 
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c   |   3 +-
 drivers/staging/ccree/ssi_cipher.c |   3 +-
 drivers/staging/ccree/ssi_driver.c | 102 -
 drivers/staging/ccree/ssi_hash.c   |   3 +-
 4 files changed, 59 insertions(+), 52 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 5abe6b2..8191ec4 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -2720,6 +2720,7 @@ int ssi_aead_alloc(struct ssi_drvdata *drvdata)
goto fail0;
}
 
+   INIT_LIST_HEAD(_handle->aead_list);
drvdata->aead_handle = aead_handle;
 
aead_handle->sram_workspace_addr = ssi_sram_mgr_alloc(
@@ -2730,8 +2731,6 @@ int ssi_aead_alloc(struct ssi_drvdata *drvdata)
goto fail1;
}
 
-   INIT_LIST_HEAD(_handle->aead_list);
-
/* Linux crypto */
for (alg = 0; alg < ARRAY_SIZE(aead_algs); alg++) {
t_alg = ssi_aead_create_alg(_algs[alg]);
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 8d31a93..4311746 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -1315,9 +1315,8 @@ int ssi_ablkcipher_alloc(struct ssi_drvdata *drvdata)
if (!ablkcipher_handle)
return -ENOMEM;
 
-   drvdata->blkcipher_handle = ablkcipher_handle;
-
INIT_LIST_HEAD(_handle->blkcipher_alg_list);
+   drvdata->blkcipher_handle = ablkcipher_handle;
 
/* Linux crypto */
SSI_LOG_DEBUG("Number of algorithms = %zu\n", 
ARRAY_SIZE(blkcipher_algs));
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 3e7193d..dc22f13 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -233,16 +233,14 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
if (!new_drvdata) {
SSI_LOG_ERR("Failed to allocate drvdata");
rc = -ENOMEM;
-   goto init_cc_res_err;
+   goto post_drvdata_err;
}
+   dev_set_drvdata(_dev->dev, new_drvdata);
+   new_drvdata->plat_dev = plat_dev;
 
new_drvdata->clk = of_clk_get(np, 0);
new_drvdata->coherent = of_dma_is_coherent(np);
 
-   /*Initialize inflight counter used in dx_ablkcipher_secure_complete 
used for count of BYSPASS blocks operations*/
-   new_drvdata->inflight_counter = 0;
-
-   dev_set_drvdata(_dev->dev, new_drvdata);
/* Get device resources */
/* First CC registers space */
req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
@@ -250,38 +248,42 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
new_drvdata->cc_base = devm_ioremap_resource(_dev->dev,
 req_mem_cc_regs);
if (IS_ERR(new_drvdata->cc_base)) {
+   SSI_LOG_ERR("Failed to ioremap registers");
rc = PTR_ERR(new_drvdata->cc_base);
-   goto init_cc_res_err;
+   goto post_drvdata_err;
}
+
SSI_LOG_DEBUG("Got MEM resource (%s): start=%pad end=%pad\n",
  req_mem_cc_regs->name,
  req_mem_cc_regs->start,
  req_mem_cc_regs->end);
SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n",
  _mem_cc_regs->start, new_drvdata->cc_base);
+
cc_base = new_drvdata->cc_base;
+
/* Then IRQ */
new_drvdata->irq = platform_get_irq(plat_dev, 0);
if (new_drvdata->irq < 0) {
SSI_LOG_ERR("Failed getting IRQ resource\n");
rc = new_drvdata->irq;
-   goto init_cc_res_err;
+   goto post_drvdata_err;
}
+
rc = devm_request_irq(_dev->dev, new_drvdata->irq, cc_isr,
  IRQF_SHARED, "arm_cc7x", new_drvdata);
if (rc) {
SSI_LOG_ERR("Could not register to interrupt %d\n",
new_drvdata->irq);
-   goto init_cc_res_err;
+   goto post_drvdata_err;
}
-   init_completion(_drvdata->icache_setup_completion);
-
SSI_LOG_DEBUG("Registered to IRQ: %d\n", new_drvdata->irq);
-   new_drvdata->plat_dev = plat_dev;
+
+   init_completion(_drvdata->icache_setup_completion);
 
rc = cc_clk_on(new_drvdata);
if (rc)
-   goto init_cc_res_err;
+   goto post_drvdata_err;
 
if (!new_drvdata->plat_dev->dev.dma_mask)

[PATCH v2 2/8] staging: ccree: Convert to devm_ioremap_resource for map, unmap

[Gilad Ben-Yossef]

From: Suniel Mahesh 

It is recommended to use managed function devm_ioremap_resource(),
which simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace request_mem_region(), ioremap() and corresponding error
handling with devm_ioremap_resource().
(b) remove struct resource pointer(res_mem) in struct ssi_drvdata as it
seems redundant, use struct resource pointer which is defined locally and
adjust return value of platform_get_resource() accordingly.
(c) release_mem_region() and iounmap() are dropped, since devm_ioremap_
resource() releases and unmaps mem region on driver detach.
(d) adjust log messages accordingly and remove any blank lines.

Signed-off-by: Suniel Mahesh 
[gby: rebase on top of latest coding style fixes changes]
Acked-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 60 ++
 drivers/staging/ccree/ssi_driver.h |  1 -
 2 files changed, 15 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 47e0880..cbe9a03 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -246,35 +246,21 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
dev_set_drvdata(_dev->dev, new_drvdata);
/* Get device resources */
/* First CC registers space */
-   new_drvdata->res_mem = platform_get_resource(plat_dev, IORESOURCE_MEM, 
0);
-   if (unlikely(!new_drvdata->res_mem)) {
-   SSI_LOG_ERR("Failed getting IO memory resource\n");
-   rc = -ENODEV;
-   goto init_cc_res_err;
-   }
-   SSI_LOG_DEBUG("Got MEM resource (%s): start=%pad end=%pad\n",
- new_drvdata->res_mem->name,
- new_drvdata->res_mem->start,
- new_drvdata->res_mem->end);
+   req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
/* Map registers space */
-   req_mem_cc_regs = request_mem_region(new_drvdata->res_mem->start, 
resource_size(new_drvdata->res_mem), "arm_cc7x_regs");
-   if (unlikely(!req_mem_cc_regs)) {
-   SSI_LOG_ERR("Couldn't allocate registers memory region at "
-"0x%08X\n", (unsigned 
int)new_drvdata->res_mem->start);
-   rc = -EBUSY;
-   goto init_cc_res_err;
-   }
-   cc_base = ioremap(new_drvdata->res_mem->start, 
resource_size(new_drvdata->res_mem));
-   if (unlikely(!cc_base)) {
-   SSI_LOG_ERR("ioremap[CC](0x%08X,0x%08X) failed\n",
-   (unsigned int)new_drvdata->res_mem->start,
-   (unsigned int)resource_size(new_drvdata->res_mem));
-   rc = -ENOMEM;
+   new_drvdata->cc_base = devm_ioremap_resource(_dev->dev,
+req_mem_cc_regs);
+   if (IS_ERR(new_drvdata->cc_base)) {
+   rc = PTR_ERR(new_drvdata->cc_base);
goto init_cc_res_err;
}
-   SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n", 
_drvdata->res_mem->start, cc_base);
-   new_drvdata->cc_base = cc_base;
-
+   SSI_LOG_DEBUG("Got MEM resource (%s): start=%pad end=%pad\n",
+ req_mem_cc_regs->name,
+ req_mem_cc_regs->start,
+ req_mem_cc_regs->end);
+   SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n",
+ _mem_cc_regs->start, new_drvdata->cc_base);
+   cc_base = new_drvdata->cc_base;
/* Then IRQ */
new_drvdata->res_irq = platform_get_resource(plat_dev, IORESOURCE_IRQ, 
0);
if (unlikely(!new_drvdata->res_irq)) {
@@ -424,17 +410,9 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 #ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
 #endif
-
-   if (req_mem_cc_regs) {
-   if (irq_registered) {
-   free_irq(new_drvdata->res_irq->start, 
new_drvdata);
-   new_drvdata->res_irq = NULL;
-   iounmap(cc_base);
-   new_drvdata->cc_base = NULL;
-   }
-   release_mem_region(new_drvdata->res_mem->start,
-  resource_size(new_drvdata->res_mem));
-   new_drvdata->res_mem = NULL;
+   if (irq_registered) {
+   free_irq(new_drvdata->res_irq->start, new_drvdata);
+   new_drvdata->res_irq = NULL;
}
dev_set_drvdata(_dev->dev, NULL);
}
@@ -470,14 +448,6 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
cc_clk_off(drvdata);
free_irq(drvdata->res_irq->start, drvdata);
drvdata->res_irq = NULL;
-
-   if 

[PATCH v2 5/8] staging: ccree: remove unused completion

[Gilad Ben-Yossef]

icache_setup_completion is no longer used. Remove it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 2 --
 drivers/staging/ccree/ssi_driver.h | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index dc22f13..8f1d7af 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -279,8 +279,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
}
SSI_LOG_DEBUG("Registered to IRQ: %d\n", new_drvdata->irq);
 
-   init_completion(_drvdata->icache_setup_completion);
-
rc = cc_clk_on(new_drvdata);
if (rc)
goto post_drvdata_err;
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 88ef370..9b6476d 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -138,7 +138,6 @@ struct ssi_drvdata {
u32 monitor_null_cycles;
struct platform_device *plat_dev;
ssi_sram_addr_t mlli_sram_addr;
-   struct completion icache_setup_completion;
void *buff_mgr_handle;
void *hash_handle;
void *aead_handle;
-- 
2.1.4

[PATCH v2 1/8] staging: ccree: Replace kzalloc with devm_kzalloc

[Gilad Ben-Yossef]

From: Suniel Mahesh 

It is recommended to use managed function devm_kzalloc, which
simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace kzalloc with devm_kzalloc.
(b) drop kfree(), because memory allocated with devm_kzalloc() is
automatically freed on driver detach, otherwise it leads to a double
free.
(c) remove unnecessary blank lines.

Signed-off-by: Suniel Mahesh 
[gby: rebase on top of latest coding style fixes changes]
Acked-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 9c6f120..47e0880 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -223,14 +223,15 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
struct resource *req_mem_cc_regs = NULL;
void __iomem *cc_base = NULL;
bool irq_registered = false;
-   struct ssi_drvdata *new_drvdata = kzalloc(sizeof(*new_drvdata),
- GFP_KERNEL);
+   struct ssi_drvdata *new_drvdata;
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
u32 signature_val;
int rc = 0;
 
-   if (unlikely(!new_drvdata)) {
+   new_drvdata = devm_kzalloc(_dev->dev, sizeof(*new_drvdata),
+  GFP_KERNEL);
+   if (!new_drvdata) {
SSI_LOG_ERR("Failed to allocate drvdata");
rc = -ENOMEM;
goto init_cc_res_err;
@@ -435,10 +436,8 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
   resource_size(new_drvdata->res_mem));
new_drvdata->res_mem = NULL;
}
-   kfree(new_drvdata);
dev_set_drvdata(_dev->dev, NULL);
}
-
return rc;
 }
 
@@ -479,8 +478,6 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
drvdata->cc_base = NULL;
drvdata->res_mem = NULL;
}
-
-   kfree(drvdata);
dev_set_drvdata(_dev->dev, NULL);
 }
 
-- 
2.1.4

Re: [PATCH 4.9 01/12] p54: memset(0) whole array

[Joe Perches]

On Sun, 2017-09-03 at 14:32 +0200, Christian Lamparter wrote:
> On Saturday, September 2, 2017 8:51:01 AM CEST Joe Perches wrote:
> > On Thu, 2017-08-31 at 09:40 -0700, Joe Perches wrote:
> > > On Thu, 2017-08-31 at 17:44 +0200, Greg Kroah-Hartman wrote:
> > > > 4.9-stable review patch.  If anyone has any objections, please let me 
> > > > know.
[]
> > > > +++ b/drivers/net/wireless/intersil/p54/fwio.c
> > > > @@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u1
> > > >  
> > > > entry += sizeof(__le16);
> > > > chan->pa_points_per_curve = 8;
> > > > -   memset(chan->curve_data, 0, 
> > > > sizeof(*chan->curve_data));
> > > > +   memset(chan->curve_data, 0, 
> > > > sizeof(chan->curve_data));
> > > > memcpy(chan->curve_data, entry,
> > > >sizeof(struct p54_pa_curve_data_sample) *
> > > >min((u8)8, 
> > > > curve_data->points_per_channel));
> > > > 
> 
> > > Why is this change correct?
> > > 
> > > curve_data is a pointer.
> > > 
> > > This now clears the sizeof a pointer and not
> > > the sizeof struct p54_cal_database
> > 
> > So what happens here?
> > This change seems clearly incorrect.
> > For all stable versions.
>  
> hm?
> 
> Please, just look again at [0]:
[]
> yes: "curve_data" is a pointer.

Thank you.
My mistake, curve_data here is an array of structs.

> This means that chan->curve_data is 64 bytes in total.

I saw only:

drivers/net/wireless/intersil/p54/p54.h:struct p54_cal_database 
*curve_data;

and did not notice

drivers/net/wireless/intersil/p54/lmac.h:   struct p54_pa_curve_data_sample 
curve_data[8];

Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

[Fabio Estevam]

On Sun, Sep 3, 2017 at 11:40 AM, Łukasz Majewski  wrote:

> This is the part of fsl_ssi_set_bclk() function which is called after
> fsl_ssi_set_dai_sysclk() (which sets ssi_private->bitclk_freq = freq;).
>
> Before the aforementioned check we do have:
>
> if (ssi_private->bitclk_freq)
> freq = ssi_private->bitclk_freq;
> else
> freq = params_channels(hw_params) * 32 *
> params_rate(hw_params);
>
>
> Which assigns freq = bitclk_freq (66 MHz)
>
> And then we break on this particular check:
>
> 66MHz * 5 > 66 MHz.
>
>
>
> The culprit IMHO is the  ssi_private->bitclk_freq = freq; in the
> fsl_ssi_set_dai_sysclk(), since we _should_ set SSI's IP block clock
> (ssi_private->clk), not the bit clock (BCLK).
>
>
> This patch just quits early if it detects change, which don't need to be
> done.

Thanks for the clarification.

Reviewed-by: Fabio Estevam 

Re: [alsa-devel] [PATCH v6 01/12] ALSA: ac97: split out the generic ac97 registers

[Takashi Iwai]

On Sat, 02 Sep 2017 21:54:03 +0200,
Robert Jarzmik wrote:
> 
> Split out from the ac97_codec.h the ac97 generic registers, which can be
> used by a codec, typically a generic ac97 codec, and by the ac97 bus, to
> scan an ac97 AC-Link.
> 
> This split encompasses all the AC97 standard registers, but not the
> codec specific ones.
> 
> In order to have a clean split between former ac97 bus implementation
> and the new coming one in sound/ac97, it is safer to not include any
> former ac97 includes, excepting in sound/ac97/compat.c.
> 
> Amongst the thing to isolate :
>  - don't have the struct snd_ac97 in sound/ac97/* (except compat.c) to not
>be "fooled" by a definition which would come with ac97_codec.h by
>"chance".
>  - don't have to have snd_a97_*() functions, as they rely on struct
>snd_ac97.
>   - don't want the struct snd_ac97_bus_ops, there is a new one
> 
> Signed-off-by: Robert Jarzmik 

Reviewed-by: Takashi Iwai 


thanks,

Takashi

Re: [PATCH 7/10] net/mlx4_core: Use ARRAY_SIZE macro

[Tariq Toukan]

On 03/09/2017 3:19 PM, Thomas Meyer wrote:

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---



Reviewed-by: Tariq Toukan 

Thanks Thomas!

[PATCH][thermal-next] thermal: brcmstb: remove two redundant integer range checks

[Colin King]

From: Colin Ian King 

The comparisons for integer low on low > INT_MAX and also
integer high > INT_MAX are never going to be true since an
int type cannot be greater than INT_MAX.  Remove these redundant
checks.

Detected by: CoverityScan CID#1455245, 1455248 ("Operands don't affect
  result (CONSTANT_EXPRESSION_RESULT)")

Signed-off-by: Colin Ian King 
---
 drivers/thermal/broadcom/brcmstb_thermal.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
index 87b8e7a86ee3..bcb3945feea6 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -278,8 +278,6 @@ static int brcmstb_set_trips(void *data, int low, int high)
dev_dbg(priv->dev, "set trips %d <--> %d\n", low, high);
 
if (low) {
-   if (low > INT_MAX)
-   low = INT_MAX;
avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_LOW, low);
avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 1);
} else {
@@ -287,8 +285,6 @@ static int brcmstb_set_trips(void *data, int low, int high)
}
 
if (high < ULONG_MAX) {
-   if (high > INT_MAX)
-   high = INT_MAX;
avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_HIGH, high);
avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 1);
} else {
-- 
2.14.1

[PATCH v2] media: net.h: add kernel-doc and use it at Documentation/

[Mauro Carvalho Chehab]

As we did with frontend.h, ca.h and dmx.h, move the struct
definition to net.h.

That should help to keep it updated, as more stuff gets
added there.

Signed-off-by: Mauro Carvalho Chehab 
---

v2:
  - Version 1 was broken: it was missing net-types.rst file and if_num was
called "ifnum", causing a warning.

 Documentation/media/uapi/dvb/net-add-if.rst | 34 -
 Documentation/media/uapi/dvb/net-types.rst  |  9 
 Documentation/media/uapi/dvb/net.rst|  1 +
 include/uapi/linux/dvb/net.h| 15 +
 4 files changed, 25 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/media/uapi/dvb/net-types.rst

diff --git a/Documentation/media/uapi/dvb/net-add-if.rst 
b/Documentation/media/uapi/dvb/net-add-if.rst
index 1087efb9baa0..6749b70246c5 100644
--- a/Documentation/media/uapi/dvb/net-add-if.rst
+++ b/Documentation/media/uapi/dvb/net-add-if.rst
@@ -41,40 +41,6 @@ created.
 The struct :c:type:`dvb_net_if`::ifnum field will be
 filled with the number of the created interface.
 
-.. c:type:: dvb_net_if
-
-.. flat-table:: struct dvb_net_if
-:header-rows:  1
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  ID
-
-   -  Description
-
--  .. row 2
-
-   -  pid
-
-   -  Packet ID (PID) of the MPEG-TS that contains data
-
--  .. row 3
-
-   -  ifnum
-
-   -  number of the Digital TV interface.
-
--  .. row 4
-
-   -  feedtype
-
-   -  Encapsulation type of the feed. It can be:
- ``DVB_NET_FEEDTYPE_MPE`` for MPE encoding or
- ``DVB_NET_FEEDTYPE_ULE`` for ULE encoding.
-
-
 Return Value
 
 
diff --git a/Documentation/media/uapi/dvb/net-types.rst 
b/Documentation/media/uapi/dvb/net-types.rst
new file mode 100644
index ..e1177bdcd623
--- /dev/null
+++ b/Documentation/media/uapi/dvb/net-types.rst
@@ -0,0 +1,9 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _dmx_types:
+
+**
+Net Data Types
+**
+
+.. kernel-doc:: include/uapi/linux/dvb/net.h
diff --git a/Documentation/media/uapi/dvb/net.rst 
b/Documentation/media/uapi/dvb/net.rst
index fdb5301a4b1f..e0cd4e402627 100644
--- a/Documentation/media/uapi/dvb/net.rst
+++ b/Documentation/media/uapi/dvb/net.rst
@@ -35,6 +35,7 @@ Digital TV net Function Calls
 .. toctree::
 :maxdepth: 1
 
+net-types
 net-add-if
 net-remove-if
 net-get-if
diff --git a/include/uapi/linux/dvb/net.h b/include/uapi/linux/dvb/net.h
index f451e7eb0b0b..89d805f9a5a6 100644
--- a/include/uapi/linux/dvb/net.h
+++ b/include/uapi/linux/dvb/net.h
@@ -26,6 +26,21 @@
 
 #include 
 
+/**
+ * struct dvb_net_if - describes a DVB network interface
+ *
+ * @pid: Packet ID (PID) of the MPEG-TS that contains data
+ * @if_num: number of the Digital TV interface.
+ * @feedtype: Encapsulation type of the feed.
+ *
+ * A MPEG-TS stream may contain packet IDs with IP packages on it.
+ * This struct describes it, and the type of encoding.
+ *
+ * @feedtype can be:
+ *
+ * - %DVB_NET_FEEDTYPE_MPE for MPE encoding
+ * - %DVB_NET_FEEDTYPE_ULE for ULE encoding.
+ */
 struct dvb_net_if {
__u16 pid;
__u16 if_num;
-- 
2.13.5

[PATCH] mmc: dw_mmc: make const arrays mszs static

[Colin King]

From: Colin Ian King 

Don't populate the const arrays mszs on the stack, instead make them
static. Makes the object code smaller by over 310 bytes:

Before:
   textdata bss dec hex filename
  475278528 320   56375dc37 drivers/mmc/host/dw_mmc.o

After:
   textdata bss dec hex filename
  470558688 320   56063daff drivers/mmc/host/dw_mmc.o

Signed-off-by: Colin Ian King 
---
 drivers/mmc/host/dw_mmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 860313bd952a..45289c5e0295 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -796,7 +796,7 @@ static int dw_mci_edmac_start_dma(struct dw_mci *host,
struct dma_slave_config cfg;
struct dma_async_tx_descriptor *desc = NULL;
struct scatterlist *sgl = host->data->sg;
-   const u32 mszs[] = {1, 4, 8, 16, 32, 64, 128, 256};
+   static const u32 mszs[] = {1, 4, 8, 16, 32, 64, 128, 256};
u32 sg_elems = host->data->sg_len;
u32 fifoth_val;
u32 fifo_offset = host->fifo_reg - host->regs;
@@ -1003,7 +1003,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
 static void dw_mci_adjust_fifoth(struct dw_mci *host, struct mmc_data *data)
 {
unsigned int blksz = data->blksz;
-   const u32 mszs[] = {1, 4, 8, 16, 32, 64, 128, 256};
+   static const u32 mszs[] = {1, 4, 8, 16, 32, 64, 128, 256};
u32 fifo_width = 1 << host->data_shift;
u32 blksz_depth = blksz / fifo_width, fifoth_val;
u32 msize = 0, rx_wmark = 1, tx_wmark, tx_wmark_invers;
-- 
2.14.1

[PATCH 3/3] ARM: dts: sun4i: Add i2s0 block to dtsi

[Priit Laes]

sun4i-a10.dtsi was missing i2s0 block. Add it.

Signed-off-by: Priit Laes 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index c5efd53..9899ecd 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -670,6 +670,19 @@
status = "disabled";
};
 
+   i2s0: i2s@01c22400 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun4i-a10-i2s";
+   reg = <0x01c22400 0x400>;
+   interrupts = <16>;
+   clocks = < CLK_APB0_I2S0>, < CLK_I2S0>;
+   clock-names = "apb", "mod";
+   dmas = < SUN4I_DMA_NORMAL 3>,
+  < SUN4I_DMA_NORMAL 3>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x100>;
-- 
git-series 0.9.1

[PATCH] ALSA: hda: Fix assign invalid fixed slots pcm numbers to HDA_PCM_TYPE_HDMI in get_empty_pcm_device

[Wang YanQing]

The length of pcm_dev_bits in hda_bus is SNDRV_PCM_DEVICES,
and the definiton of SNDRV_PCM_DEVICES is:
"
 #if defined(CONFIG_SND_DYNAMIC_MINORS)
 #define SNDRV_PCM_DEVICES   (SNDRV_OS_MINORS-2)
 #else
 #define SNDRV_PCM_DEVICES   8
 #endif
"

So the max valid fixed slots pcm number is 7, and the first
non-fixed slot is 8.

Signed-off-by: Wang YanQing 
---
 sound/pci/hda/hda_codec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 3db26c4..df6b57e 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3118,7 +3118,7 @@ static int get_empty_pcm_device(struct hda_bus *bus, 
unsigned int type)
static int audio_idx[HDA_PCM_NTYPES][5] = {
[HDA_PCM_TYPE_AUDIO] = { 0, 2, 4, 5, -1 },
[HDA_PCM_TYPE_SPDIF] = { 1, -1 },
-   [HDA_PCM_TYPE_HDMI]  = { 3, 7, 8, 9, -1 },
+   [HDA_PCM_TYPE_HDMI]  = { 3, 7, -1 },
[HDA_PCM_TYPE_MODEM] = { 6, -1 },
};
int i;
@@ -3139,7 +3139,7 @@ static int get_empty_pcm_device(struct hda_bus *bus, 
unsigned int type)
 
 #ifdef CONFIG_SND_DYNAMIC_MINORS
/* non-fixed slots starting from 10 */
-   for (i = 10; i < 32; i++) {
+   for (i = 8; i < 32; i++) {
if (!test_and_set_bit(i, bus->pcm_dev_bits))
return i;
}
-- 
1.8.5.6.2.g3d8a54e.dirty

[PATCH] ASoC: fsl_spdif: make const arrays rate static

[Colin King]

From: Colin Ian King 

Don't populate the const arrays rate on the stack, instead make them
static. Makes the object code smaller by 220 bytes:

Before:
   textdata bss dec hex filename
  243859776 128   3428985f1 sound/soc/fsl/fsl_spdif.o

After:
   textdata bss dec hex filename
  240059936 128   340698515 sound/soc/fsl/fsl_spdif.o

Signed-off-by: Colin Ian King 
---
 sound/soc/fsl/fsl_spdif.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 7e6cc4da0088..4f7469c1864c 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -1110,7 +1110,7 @@ static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv 
*spdif_priv,
struct clk *clk, u64 savesub,
enum spdif_txrate index, bool round)
 {
-   const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
+   static const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
bool is_sysclk = clk_is_match(clk, spdif_priv->sysclk);
u64 rate_ideal, rate_actual, sub;
u32 sysclk_dfmin, sysclk_dfmax;
@@ -1169,7 +1169,7 @@ static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv 
*spdif_priv,
 static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv,
enum spdif_txrate index)
 {
-   const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
+   static const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 };
struct platform_device *pdev = spdif_priv->pdev;
struct device *dev = >dev;
u64 savesub = 10, ret;
-- 
2.14.1

Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

[Łukasz Majewski]

Hi Fabio,



[Sorry for the top-posting]


The driver currently has:


/*
* Hardware limitation: The bclk rate must be
* never greater than 1/5 IPG clock rate
*/
if (freq * 5 > clk_get_rate(ssi_private->clk)) {
dev_err(cpu_dai->dev, "bitclk > ipgclk/5\n");
return -EINVAL;
}



Unfortunately not.

This is the part of fsl_ssi_set_bclk() function which is called after 
fsl_ssi_set_dai_sysclk() (which sets ssi_private->bitclk_freq = freq;).


Before the aforementioned check we do have:

if (ssi_private->bitclk_freq)
freq = ssi_private->bitclk_freq;
else
freq = params_channels(hw_params) * 32 *
params_rate(hw_params);


Which assigns freq = bitclk_freq (66 MHz)

And then we break on this particular check:

66MHz * 5 > 66 MHz.



The culprit IMHO is the  ssi_private->bitclk_freq = freq; in the 
fsl_ssi_set_dai_sysclk(), since we _should_ set SSI's IP block clock 
(ssi_private->clk), not the bit clock (BCLK).



This patch just quits early if it detects change, which don't need to be 
done.




Isn't this properly taking care of the clock restriction?


From: Lukasz Majewski 
Sent: Sunday, September 3, 2017 8:05:01 AM
To: Timur Tabi; Nicolin Chen; Xiubo Li; Fabio Estevam; Liam Girdwood; Mark 
Brown; Jaroslav Kysela; Takashi Iwai
Cc: alsa-de...@alsa-project.org; linuxppc-...@lists.ozlabs.org; 
linux-kernel@vger.kernel.org; Lukasz Majewski
Subject: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to 
system freq

The problem is visible in the following setup (on the imx6q):
"simple-audio-card" -> ssi2 -> I2S + I2C -> codec

The function call log (simple-card probe -> CONFIG_SND_SIMPLE_CARD):

asoc_simple_card_init_dai() @ sound/soc/generic/simple-card-utils.c
snd_soc_dai_set_sysclk()
fsl_ssi_set_dai_sysclk() @ sound/soc/fsl/fsl_ssi.c

The last call is changing the bit clock (BCLK) frequency to SSI's IP
block clock (ipg = 66 MHz) [1].
This is wrong, since IMX SSI block requires the I2S BCLK to be less
than 1/5 of [1].

As a result the driver initialization passes without any errors, but the
speaker-test test case breaks.

This commit checks if the fsl_ssi_set_dai_sysclk() frequency passed is
not equal to [1].

Signed-off-by: Lukasz Majewski 
---
  sound/soc/fsl/fsl_ssi.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 173cb84..1186fa9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -809,6 +809,8 @@ static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai 
*cpu_dai,
  int clk_id, unsigned int freq, int dir)
  {
  struct fsl_ssi_private *ssi_private = 
snd_soc_dai_get_drvdata(cpu_dai);
+   if (clk_get_rate(ssi_private->clk) == freq)
+   return 0;

  ssi_private->bitclk_freq = freq;

--
2.1.4





--
Best regards,

Lukasz Majewski

--

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

Re: RFC: Revert move default dialect from CIFS to to SMB3

[Thorsten Leemhuis]

Hi! Just a quick feedback from my side.

After reading Andrew explanation in this thread about the "movement
against SMB1" I kind of think "maybe the proposed revert for 4.13 and
doing it properly in 4.14 would really have been a good fit". But
whatever, doesn't bother me much any more:

Steve French wrote on 01.09.2017 04:42:
> Any thoughts on this patch to add additional warnings for the user -
> logging when using default dialects (or when server returns dialect
> not supported), and noting the default dialect change?
> See 
> https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commit;h=bb86f22eeddbb5879675b55168b8fa8990d74a21

I noticed Linus committed a sightly updated variant earlier today
(https://git.kernel.org/torvalds/c/7e682f766f28 ). I just gave it a
quick try and it worked well. I can still mount smb3 shares. For
cifs/smb1 shares mount.cifs obviously still fails with the confusing
error message. But at least one gets a better explanation in dmesg now.

Many thx for this! Ciao, Thorsten.

P.S.: For the curious reader (and search engines!), this is the
confusing mount message you'll get when trying to access a CIFS/SMB1
only share with Linux master currently:

mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)"

And this is the warning you see in dmesg now when not specifying
"vers=1.0" as option (-o) to mount/mount.cifs:

No dialect specified on mount. Default has changed to a
more secure dialect, SMB3 (vers=3.0), from CIFS (SMB1). To use the less
secure SMB1 dialect to access old servers which do not support SMB3
specify vers=1.0 on mount. For somewhat newer servers such as Windows 7
try vers=2.1.
CIFS VFS: cifs_mount failed w/return code = -112


> On Thu, Aug 31, 2017 at 7:29 PM, Steve French  wrote:
>> Yes - updating the parsing slightly and printks as suggested makes sense
>>
>> Some additional warning messages in the userspace helper (adding Jeff
>> Layton), mount.cifs can also help.
>>
>> I also have an experimental set of patches to allow multi-dialect
>> negotiation with at least three of the acceptable dialects
>> (smb2.1/smb3/smb3.02) which will help, but complicate secure dialect
>> validation ("validate negotiate") but that will have to wait till next
>> release.
>>
>> On Thu, Aug 31, 2017 at 7:12 PM, Linus Torvalds
>>  wrote:
>>> On Thu, Aug 31, 2017 at 2:36 PM, Thorsten Leemhuis  
>>> wrote:
 Lo! To give a bit more background to this (the mail I reply to was the
 first I sent with git send-email and I missed some details): Maybe I'm
 over stretching my abilities/position as regression tracker with this
 RFC for a revert, but I hope it at least triggers a discussion if such a
 revert should be done or not.
>>>
>>> I don't think that a revert is appropriate.
>>>
>>> But perhaps just a single printk() or something if the user does *not*
>>> specify the version explicitly? Just saying something like
>>>
>>>   We used to default to 1.0, we now default to 3.0, if you want old
>>> defaults, use "vers=1.0"
>>>
>>> Oh, looking at that version parsing code, I think we also need to fix
>>> that legacy "ver=1" thing (ver without the 's') which now silently
>>> ignores "ver=1" as being the "default", even though it's not.
>>>
>>> I do *not* believe that "default to version 1" is acceptable.
>>>
>>> Linus

[PATCH] ALSA: hda: Fix resource leak issue in snd_hda_codec_build_controls and snd_hda_codec_parse_pcms

[Wang YanQing]

When patch_ops.init, patch_ops.build_pcms and patch_ops.build_controls
return failure, we need to free resource with patch_ops.free, or we will
get resource leak.

Signed-off-by: Wang YanQing 
---
 sound/pci/hda/hda_codec.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index df6b57e..4e3e613 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2973,8 +2973,11 @@ int snd_hda_codec_build_controls(struct hda_codec *codec)
err = codec->patch_ops.init(codec);
if (!err && codec->patch_ops.build_controls)
err = codec->patch_ops.build_controls(codec);
-   if (err < 0)
+   if (err < 0) {
+   if (codec->patch_ops.free)
+   codec->patch_ops.free(codec);
return err;
+   }
 
/* we create chmaps here instead of build_pcms */
err = add_std_chmaps(codec);
@@ -3170,6 +3173,8 @@ int snd_hda_codec_parse_pcms(struct hda_codec *codec)
if (err < 0) {
codec_err(codec, "cannot build PCMs for #%d (error %d)\n",
  codec->core.addr, err);
+   if (codec->patch_ops.free)
+   codec->patch_ops.free(codec);
return err;
}
 
-- 
1.8.5.6.2.g3d8a54e.dirty

Re: [PATCH 0/10] Use ARRAY_SIZE macro - v4.13-rc7

[Joe Perches]

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

Hey Thomas.

There are some instances that span multiple lines that
the regex above misses.

For instance:

diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
index 3d701c7a4c91..26a825bd7581 100644
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@ -929,8 +929,7 @@ static int mlx5_ib_mr_initiator_pfault_handler(
return -EFAULT;
}
 
-   if (unlikely(opcode >= sizeof(mlx5_ib_odp_opcode_cap) /
-   sizeof(mlx5_ib_odp_opcode_cap[0]) ||
+   if (unlikely(opcode >= ARRAY_SIZE(mlx5_ib_odp_opcode_cap) ||

Here is another perl command regex that fixes a few more:

$ perl -i -e 'local $/; while (<>) { 
s/\bsizeof\s*\(\s*(\w+)\s*\)\s*\/\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)/ARRAY_SIZE(\1)/g;
 print; }' $file

This regex could still miss variants that
have a comment or that don't use parentheses
around the sizeof.

It seems none of those styles exist though.

Re: [PATCH v7 00/19] simplify crypto wait for async op

[Gilad Ben-Yossef]

On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain  wrote:
> HI Gilad,
>
> I think we need an update in ESP also. Now EBUSY return means driver
> has accepted, Packet should not be dropped in
>
> esp_output_tail() function.

Good catch. You are right and the same holds true for ah_output() in ah4.c.

But I do wonder, the code there now treats -EBUSY as a special case
and returns NET_XMIT_DROP
but if an AEAD or AHASH transformation return some other error, like
-ENOMEM or -EINVAL shouldn't
we return NET_XMIT_DROP in that case too?

Any ideas?

Gilad

>
>
> On Thu, Aug 24, 2017 at 7:48 PM, Gilad Ben-Yossef  wrote:
>> Many users of kernel async. crypto services have a pattern of
>> starting an async. crypto op and than using a completion
>> to wait for it to end.
>>
>> This patch set simplifies this common use case in two ways:
>>
>> First, by separating the return codes of the case where a
>> request is queued to a backlog due to the provider being
>> busy (-EBUSY) from the case the request has failed due
>> to the provider being busy and backlogging is not enabled
>> (-EAGAIN).
>>
>> Next, this change is than built on to create a generic API
>> to wait for a async. crypto operation to complete.
>>
>> The end result is a smaller code base and an API that is
>> easier to use and more difficult to get wrong.
>>
>> The patch set was boot tested on x86_64 and arm64 which
>> at the very least tests the crypto users via testmgr and
>> tcrypt but I do note that I do not have access to some
>> of the HW whose drivers are modified nor do I claim I was
>> able to test all of the corner cases.
>>
>> The patch set is based upon linux-next release tagged
>> next-20170824.
>>
>> Changes from v6:
>> - Fix brown paper bag compile error on marvell/cesa
>>   code.
>>
>> Changes from v5:
>> - Remove redundant new line as spotted by Jonathan
>>   Cameron.
>> - Reworded dm-verity change commit message to better
>>   clarify potential issue averted by change as
>>   pointed out by Mikulas Patocka.
>>
>> Changes from v4:
>> - Rebase on top of latest algif changes from Stephan
>>   Mueller.
>> - Fix typo in ccp patch title.
>>
>> Changes from v3:
>> - Instead of changing the return code to indicate
>>   backlog queueing, change the return code to indicate
>>   transient busy state, as suggested by Herbert Xu.
>>
>> Changes from v2:
>> - Patch title changed from "introduce crypto wait for
>>   async op" to better reflect the current state.
>> - Rebase on top of latest linux-next.
>> - Add a new return code of -EIOCBQUEUED for backlog
>>   queueing, as suggested by Herbert Xu.
>> - Transform more users to the new API.
>> - Update the drbg change to account for new init as
>>   indicated by Stephan Muller.
>>
>> Changes from v1:
>> - Address review comments from Eric Biggers.
>> - Separated out bug fixes of existing code and rebase
>>   on top of that patch set.
>> - Rename 'ecr' to 'wait' in fscrypto code.
>> - Split patch introducing the new API from the change
>>   moving over the algif code which it originated from
>>   to the new API.
>> - Inline crypto_wait_req().
>> - Some code indentation fixes.
>>
>> Gilad Ben-Yossef (19):
>>   crypto: change transient busy return code to -EAGAIN
>>   crypto: ccp: use -EAGAIN for transient busy indication
>>   crypto: remove redundant backlog checks on EBUSY
>>   crypto: marvell/cesa: remove redundant backlog checks on EBUSY
>>   crypto: introduce crypto wait for async op
>>   crypto: move algif to generic async completion
>>   crypto: move pub key to generic async completion
>>   crypto: move drbg to generic async completion
>>   crypto: move gcm to generic async completion
>>   crypto: move testmgr to generic async completion
>>   fscrypt: move to generic async completion
>>   dm: move dm-verity to generic async completion
>>   cifs: move to generic async completion
>>   ima: move to generic async completion
>>   crypto: tcrypt: move to generic async completion
>>   crypto: talitos: move to generic async completion
>>   crypto: qce: move to generic async completion
>>   crypto: mediatek: move to generic async completion
>>   crypto: adapt api sample to use async. op wait
>>
>>  Documentation/crypto/api-samples.rst |  52 ++---
>>  crypto/af_alg.c  |  27 -
>>  crypto/ahash.c   |  12 +--
>>  crypto/algapi.c  |   6 +-
>>  crypto/algif_aead.c  |   8 +-
>>  crypto/algif_hash.c  |  50 +
>>  crypto/algif_skcipher.c  |   9 +-
>>  crypto/api.c |  13 +++
>>  crypto/asymmetric_keys/public_key.c  |  28 +
>>  crypto/cryptd.c  |   4 +-
>>  crypto/cts.c |   6 +-
>>  crypto/drbg.c|  36 ++-
>>  crypto/gcm.c |  32 ++
>>  crypto/lrw.c |   8 +-
>>  crypto/rsa-pkcs1pad.c|  16 +--
>>  

hotplug lockdep splat (tip)

[Mike Galbraith]

[  126.626908] Unregister pv shared memory for cpu 1
[  126.631041] 
[  126.631269] ==
[  126.632442] WARNING: possible circular locking dependency detected
[  126.633599] 4.13.0.g06260ca-tip-lockdep #2 Tainted: GE  
[  126.634380] --
[  126.635124] stress-cpu-hotp/3156 is trying to acquire lock:
[  126.635804]  ((complete)>done){+.+.}, at: [] 
takedown_cpu+0x8a/0xf0
[  126.636809] 
[  126.636809] but task is already holding lock:
[  126.637567]  (sparse_irq_lock){+.+.}, at: [] 
irq_lock_sparse+0x17/0x20
[  126.638665] 
[  126.638665] which lock already depends on the new lock.
[  126.638665] 
[  126.639679] 
[  126.639679] the existing dependency chain (in reverse order) is:
[  126.641086] 
[  126.641086] -> #2 (sparse_irq_lock){+.+.}:
[  126.641862]__lock_acquire+0x116a/0x11c0
[  126.642456]lock_acquire+0xbd/0x200
[  126.642975]__mutex_lock+0x70/0x8e0
[  126.643499]mutex_lock_nested+0x1b/0x20
[  126.644118]irq_lock_sparse+0x17/0x20
[  126.644870]irq_affinity_online_cpu+0x18/0xd0
[  126.645941]cpuhp_invoke_callback+0x1f6/0x830
[  126.647000]cpuhp_up_callbacks+0x37/0xb0
[  126.647961]cpuhp_thread_fun+0x14f/0x160
[  126.648672]smpboot_thread_fn+0x11a/0x1e0
[  126.649511]kthread+0x152/0x190
[  126.650347]ret_from_fork+0x2a/0x40
[  126.651239] 
[  126.651239] -> #1 (cpuhp_state){+.+.}:
[  126.651956]cpuhp_thread_fun+0x54/0x160
[  126.652523]smpboot_thread_fn+0x11a/0x1e0
[  126.653233]kthread+0x152/0x190
[  126.654090]ret_from_fork+0x2a/0x40
[  126.656166]0x
[  126.657242] 
[  126.657242] -> #0 ((complete)>done){+.+.}:
[  126.658407]check_prev_add+0x666/0x700
[  126.659570]__lock_acquire+0x116a/0x11c0
[  126.660576]lock_acquire+0xbd/0x200
[  126.663278]wait_for_completion+0x53/0x1a0
[  126.32]takedown_cpu+0x8a/0xf0
[  126.669845]cpuhp_invoke_callback+0x1f6/0x830
[  126.670623]cpuhp_down_callbacks+0x42/0x80
[  126.673508]_cpu_down+0xc6/0x100
[  126.674323]do_cpu_down+0x3e/0x60
[  126.674825]cpu_down+0x10/0x20
[  126.675306]cpu_subsys_offline+0x14/0x20
[  126.675895]device_offline+0x8c/0xb0
[  126.676561]online_store+0x40/0x80
[  126.677081]dev_attr_store+0x18/0x30
[  126.677674]sysfs_kf_write+0x44/0x60
[  126.678338]kernfs_fop_write+0x113/0x1a0
[  126.678922]__vfs_write+0x28/0x150
[  126.679553]vfs_write+0xc7/0x1c0
[  126.680034]SyS_write+0x49/0xa0
[  126.680563]entry_SYSCALL_64_fastpath+0x1f/0xbe
[  126.681459] 
[  126.681459] other info that might help us debug this:
[  126.681459] 
[  126.683271] Chain exists of:
[  126.683271]   (complete)>done --> cpuhp_state --> sparse_irq_lock
[  126.683271] 
[  126.687307]  Possible unsafe locking scenario:
[  126.687307] 
[  126.688244]CPU0CPU1
[  126.689027]
[  126.689591]   lock(sparse_irq_lock);
[  126.690036]lock(cpuhp_state);
[  126.690970]lock(sparse_irq_lock);
[  126.692057]   lock((complete)>done);
[  126.693199] 
[  126.693199]  *** DEADLOCK ***
[  126.693199] 
[  126.694283] 8 locks held by stress-cpu-hotp/3156:
[  126.694772]  #0:  (sb_writers#4){.+.+}, at: [] 
vfs_write+0x196/0x1c0
[  126.696285]  #1:  (>mutex){+.+.}, at: [] 
kernfs_fop_write+0xe3/0x1a0
[  126.697178]  #2:  (s_active#158){.+.+}, at: [] 
kernfs_fop_write+0xeb/0x1a0
[  126.698367]  #3:  (device_hotplug_lock){+.+.}, at: [] 
lock_device_hotplug_sysfs+0x15/0x40
[  126.699632]  #4:  (>mutex){}, at: [] 
device_offline+0x4a/0xb0
[  126.701229]  #5:  (cpu_add_remove_lock){+.+.}, at: [] 
do_cpu_down+0x27/0x60
[  126.703277]  #6:  (cpu_hotplug_lock.rw_sem){}, at: [] 
percpu_down_write+0x26/0x110
[  126.706302]  #7:  (sparse_irq_lock){+.+.}, at: [] 
irq_lock_sparse+0x17/0x20
[  126.708966] 
[  126.708966] stack backtrace:
[  126.709558] CPU: 0 PID: 3156 Comm: stress-cpu-hotp Tainted: GE   
4.13.0.g06260ca-tip-lockdep #2
[  126.710790] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.0.0-prebuilt.qemu-project.org 04/01/2014
[  126.712075] Call Trace:
[  126.712523]  dump_stack+0x85/0xc5
[  126.712904]  print_circular_bug+0x2e9/0x2f7
[  126.713308]  ? copy_trace+0xc0/0xc0
[  126.713636]  check_prev_add+0x666/0x700
[  126.713978]  ? copy_trace+0xc0/0xc0
[  126.714426]  ? copy_trace+0xc0/0xc0
[  126.714847]  __lock_acquire+0x116a/0x11c0
[  126.715452]  lock_acquire+0xbd/0x200
[  126.716073]  ? takedown_cpu+0x8a/0xf0
[  126.716930]  wait_for_completion+0x53/0x1a0
[  126.717805]  ? takedown_cpu+0x8a/0xf0
[  126.718352]  ? stop_machine_cpuslocked+0xee/0x100
[  126.718867]  ? cpuhp_invoke_callback+0x830/0x830
[  126.719489]  

Re: [PATCH][next] IB/core: fix spelling mistake: "aceess" -> "access"

[Leon Romanovsky]

On Fri, Sep 01, 2017 at 09:22:14AM +0100, Colin King wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistake in WARN message
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/core/uverbs_ioctl_merge.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Thanks,
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type

[kbuild test robot]

Hi Daniel,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d0d6ab53c9abd7dd1070f43a0455328874127ba8
commit: dc11bae78529526605c5c45c369c9512fd012093 clocksource/drivers: Add 
timer-of common init routine
date:   3 months ago
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout dc11bae78529526605c5c45c369c9512fd012093
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/clocksource/timer-of.c:25:0:
>> drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete 
>> type
 struct clock_event_device clkevt;
   ^~
   In file included from include/linux/clk.h:16:0,
from drivers/clocksource/timer-of.c:18:
   drivers/clocksource/timer-of.h: In function 'to_timer_of':
   include/linux/kernel.h:854:48: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
 const typeof( ((type *)0)->member ) *__mptr = (ptr); \
   ^
   drivers/clocksource/timer-of.h:44:9: note: in expansion of macro 
'container_of'
 return container_of(clkevt, struct timer_of, clkevt);
^~~~
   drivers/clocksource/timer-of.c: In function 'timer_irq_init':
   drivers/clocksource/timer-of.c:63:8: error: dereferencing pointer to 
incomplete type 'struct clock_event_device'
 clkevt->irq = of_irq->irq;
   ^~
   cc1: some warnings being treated as errors

vim +/clkevt +35 drivers/clocksource/timer-of.h

32  
33  struct timer_of {
34  unsigned int flags;
  > 35  struct clock_event_device clkevt;
36  struct of_timer_base of_base;
37  struct of_timer_irq  of_irq;
38  struct of_timer_clk  of_clk;
39  void *private_data;
40  };
41  

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


.config.gz
Description: application/gzip

Re: [alsa-devel] [PATCH v6 02/12] ALSA: ac97: add an ac97 bus

[Takashi Iwai]

On Sat, 02 Sep 2017 21:54:04 +0200,
Robert Jarzmik wrote:
> 
> AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one
> controller to 0 to 4 AC97 codecs.
> 
> The goal of this new implementation is to implement a device/driver
> model for AC97, with an automatic scan of the bus and automatic
> discovery of AC97 codec devices.
> 
> Signed-off-by: Robert Jarzmik 

Reviewed-by: Takashi Iwai 


thanks,

Takashi

Re: [PATCH][next] net/mlx4_core: fix memory leaks on error exit path

[Tariq Toukan]

On 31/08/2017 7:30 PM, Colin King wrote:

From: Colin Ian King 

The structures hca_param and func_cap are not being kfree'd on an error
exit path causing two memory leaks. Fix this by jumping to the existing
free memory error exit path.

Detected by CoverityScan, CID#1455219, CID#1455224 ("Resource Leak")

Fixes: c73c8b1e47ca ("net/mlx4_core: Dynamically allocate structs at 
mlx4_slave_cap")
Signed-off-by: Colin Ian King 
---
  drivers/net/ethernet/mellanox/mlx4/main.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
b/drivers/net/ethernet/mellanox/mlx4/main.c
index 1c92101b3ec2..d46f3283ec36 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -977,7 +977,8 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
if (dev->caps.num_ports > MLX4_MAX_PORTS) {
mlx4_err(dev, "HCA has %d ports, but we only support %d, 
aborting\n",
 dev->caps.num_ports, MLX4_MAX_PORTS);
-   return -ENODEV;
+   err = -ENODEV;
+   goto free_mem;
}
  
  	mlx4_replace_zero_macs(dev);




Acked-by: Tariq Toukan 

Thanks Colin!

RE: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

[Prakhya, Sai Praneeth]

> >
> > Thanks for this v2.
> > Introducing the 'efi_switch_mm() ' helper instead of manually
> > twiddling with %cr3 seems more cleaner.
> >
> > I have tested this patchset on a x86_64 machine with the following
> > configurations:
> >
> > 1. Primary kernel boot with efi=old_map 2. Primary kernel boot with
> > new efi map
> >
> > While it seems that efi=old_map passes, the new efi map boot fails for
> > me on both the two x86 machine (Dell 3050MT and a SGI - UV300 machine.
> >
> > It seems we are hitting a NULL pointer deference in
> > 'efi_call_phys_prolog' while accessing '_mm'.
> >
> > Please see the log below for details:
> >
> > [0.020006] BUG: unable to handle kernel NULL pointer dereference
> > at   (null)
> > [0.021000] IP: switch_mm_irqs_off+0x44/0x270
> > [0.021000] Call Trace:
> > [0.021000]  switch_mm+0x20/0x30
> > [0.021000]  efi_switch_mm+0x49/0x60
> > [0.021000]  efi_call_phys_prolog+0x56/0x1b3
> > [0.021000]  efi_enter_virtual_mode+0x3a9/0x520
> > [0.021000]  start_kernel+0x424/0x4c8
> > [0.021000]  ? set_init_arg+0x5a/0x5a
> > [0.021000]  ? early_idt_handler_array+0x120/0x120
> > [0.021000]  x86_64_start_reservations+0x29/0x2b
> > [0.021000]  x86_64_start_kernel+0x151/0x174
> > [0.021000]  secondary_startup_64+0x9f/0x9f
> > [0.021000] Code: 2d 82 51 d9 4f 65 c7 05 0f 65 da 4f 01 00 00 00
> > 48 39 f7 0f 84 14 01 00 00 65 48 89 35 f6 64 da 4f 48 8b 86 e8 02 00
> > 00 45 89 ed  4c 0f ab 28 bf 00 00 00 80 48 03 7e 50 48 8b 05 27 b0
> > b9 00
> > [0.021000] RIP: switch_mm_irqs_off+0x44/0x270 RSP: b0e035d0
> > [0.021000] CR2: 
> > [0.021000] ---[ end trace fb94349305e1cb8b ]---
> > [0.021000] Kernel panic - not syncing: Fatal exception
> > [0.021000] ---[ end Kernel panic - not syncing: Fatal exception
> >
> 
> And I forgot to mention that I tried the patchset both with the efi/next and
> linus's trees and saw the same result.
> 
> I would be happy to help in case you need further details of the test 
> environment
> or need help in testing this crash further.
> 
> Regards,
> Bhupesh

Hi Bhupesh,

Thanks for trying the patches and raising the concern.
Could you also please also give a try on qemu? (if reproducible, we will be 
having a common platform to start debugging)
I have tested this patch set on qemu and real machines (different from one's 
you tried) in our lab and didn’t notice this issue.

Regards,
Sai

[PATCH 1/1] RAS/CEC: use the right length of "cec_disable"

[Nicolas Iooss]

parse_cec_param() compares a string with "cec_disable" using only 7
characters of the 11-character-long string. Fix the length.

Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector")
Signed-off-by: Nicolas Iooss 
---
 drivers/ras/cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index d0e5d6ee882c..586c296d1538 100644
--- a/drivers/ras/cec.c
+++ b/drivers/ras/cec.c
@@ -523,7 +523,7 @@ int __init parse_cec_param(char *str)
if (*str == '=')
str++;
 
-   if (!strncmp(str, "cec_disable", 7))
+   if (!strncmp(str, "cec_disable", 11))
ce_arr.disabled = 1;
else
return 0;
-- 
2.14.1

[PATCH 1/2] tracing: irqsoff: Move code under tracer config options

[Joel Fernandes]

In preparation for adding critical sections events such that
they don't depend on enabling of tracers, move tracer specific
code to their config options and common code that would be needed
by a subsequent patch into a common area. This patch is only
code movement patch.

Cc: Steven Rostedt 
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes 
---
 kernel/trace/trace_irqsoff.c | 242 ++-
 1 file changed, 126 insertions(+), 116 deletions(-)

diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 7758bc0617cb..edd52ee8b756 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -16,6 +16,7 @@
 
 #include "trace.h"
 
+#if defined(CONFIG_IRQSOFF_TRACER) || defined(CONFIG_PREEMPT_TRACER)
 static struct trace_array  *irqsoff_trace __read_mostly;
 static int tracer_enabled __read_mostly;
 
@@ -35,27 +36,6 @@ static int save_flags;
 static void stop_irqsoff_tracer(struct trace_array *tr, int graph);
 static int start_irqsoff_tracer(struct trace_array *tr, int graph);
 
-#ifdef CONFIG_PREEMPT_TRACER
-static inline int
-preempt_trace(void)
-{
-   return ((trace_type & TRACER_PREEMPT_OFF) && preempt_count());
-}
-#else
-# define preempt_trace() (0)
-#endif
-
-#ifdef CONFIG_IRQSOFF_TRACER
-static inline int
-irq_trace(void)
-{
-   return ((trace_type & TRACER_IRQS_OFF) &&
-   irqs_disabled());
-}
-#else
-# define irq_trace() (0)
-#endif
-
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 static int irqsoff_display_graph(struct trace_array *tr, int set);
 # define is_graph(tr) ((tr)->trace_flags & TRACE_ITER_DISPLAY_GRAPH)
@@ -431,101 +411,6 @@ stop_critical_timing(unsigned long ip, unsigned long 
parent_ip)
atomic_dec(>disabled);
 }
 
-/* start and stop critical timings used to for stoppage (in idle) */
-void start_critical_timings(void)
-{
-   if (preempt_trace() || irq_trace())
-   start_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL_GPL(start_critical_timings);
-
-void stop_critical_timings(void)
-{
-   if (preempt_trace() || irq_trace())
-   stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL_GPL(stop_critical_timings);
-
-#ifdef CONFIG_IRQSOFF_TRACER
-#ifdef CONFIG_PROVE_LOCKING
-void time_hardirqs_on(unsigned long a0, unsigned long a1)
-{
-   if (!preempt_trace() && irq_trace())
-   stop_critical_timing(a0, a1);
-}
-
-void time_hardirqs_off(unsigned long a0, unsigned long a1)
-{
-   if (!preempt_trace() && irq_trace())
-   start_critical_timing(a0, a1);
-}
-
-#else /* !CONFIG_PROVE_LOCKING */
-
-/*
- * Stubs:
- */
-
-void trace_softirqs_on(unsigned long ip)
-{
-}
-
-void trace_softirqs_off(unsigned long ip)
-{
-}
-
-inline void print_irqtrace_events(struct task_struct *curr)
-{
-}
-
-/*
- * We are only interested in hardirq on/off events:
- */
-void trace_hardirqs_on(void)
-{
-   if (!preempt_trace() && irq_trace())
-   stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL(trace_hardirqs_on);
-
-void trace_hardirqs_off(void)
-{
-   if (!preempt_trace() && irq_trace())
-   start_critical_timing(CALLER_ADDR0, CALLER_ADDR1);
-}
-EXPORT_SYMBOL(trace_hardirqs_off);
-
-__visible void trace_hardirqs_on_caller(unsigned long caller_addr)
-{
-   if (!preempt_trace() && irq_trace())
-   stop_critical_timing(CALLER_ADDR0, caller_addr);
-}
-EXPORT_SYMBOL(trace_hardirqs_on_caller);
-
-__visible void trace_hardirqs_off_caller(unsigned long caller_addr)
-{
-   if (!preempt_trace() && irq_trace())
-   start_critical_timing(CALLER_ADDR0, caller_addr);
-}
-EXPORT_SYMBOL(trace_hardirqs_off_caller);
-
-#endif /* CONFIG_PROVE_LOCKING */
-#endif /*  CONFIG_IRQSOFF_TRACER */
-
-#ifdef CONFIG_PREEMPT_TRACER
-void trace_preempt_on(unsigned long a0, unsigned long a1)
-{
-   if (preempt_trace() && !irq_trace())
-   stop_critical_timing(a0, a1);
-}
-
-void trace_preempt_off(unsigned long a0, unsigned long a1)
-{
-   if (preempt_trace() && !irq_trace())
-   start_critical_timing(a0, a1);
-}
-#endif /* CONFIG_PREEMPT_TRACER */
-
 #ifdef CONFIG_FUNCTION_TRACER
 static bool function_enabled;
 
@@ -781,3 +666,128 @@ __init static int init_irqsoff_tracer(void)
return 0;
 }
 core_initcall(init_irqsoff_tracer);
+
+#else /* CONFIG_IRQSOFF_TRACER || CONFIG_PREEMPT_TRACER */
+
+# define start_critical_timing(x, y) do { } while (0)
+# define stop_critical_timing(x, y) do { } while (0)
+
+#endif
+
+#ifdef CONFIG_PREEMPT_TRACER
+static inline int
+preempt_trace(void)
+{
+   return ((trace_type & TRACER_PREEMPT_OFF) && preempt_count());
+}
+#else
+# define preempt_trace() (0)
+#endif
+
+#ifdef CONFIG_IRQSOFF_TRACER
+static inline int
+irq_trace(void)
+{
+   return ((trace_type & TRACER_IRQS_OFF) &&
+   irqs_disabled());
+}
+#else
+# define 

[PATCH 5/8] staging: ccree: remove unused completion

[Gilad Ben-Yossef]

icache_setup_completion is no longer used. Remove it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 2 --
 drivers/staging/ccree/ssi_driver.h | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index dc22f13..8f1d7af 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -279,8 +279,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
}
SSI_LOG_DEBUG("Registered to IRQ: %d\n", new_drvdata->irq);
 
-   init_completion(_drvdata->icache_setup_completion);
-
rc = cc_clk_on(new_drvdata);
if (rc)
goto post_drvdata_err;
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 88ef370..9b6476d 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -138,7 +138,6 @@ struct ssi_drvdata {
u32 monitor_null_cycles;
struct platform_device *plat_dev;
ssi_sram_addr_t mlli_sram_addr;
-   struct completion icache_setup_completion;
void *buff_mgr_handle;
void *hash_handle;
void *aead_handle;
-- 
2.1.4

[PATCH 8/8] staging: ccree: remove BUG macro usage

[Gilad Ben-Yossef]

Replace BUG() macro usage that crash the kernel with alternatives
that signal error and/or try to recover.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c  | 14 ++
 drivers/staging/ccree/ssi_cipher.c  |  1 -
 drivers/staging/ccree/ssi_pm.c  |  3 ++-
 drivers/staging/ccree/ssi_request_mgr.c | 23 +--
 4 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 6393609..d744820 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -81,11 +81,6 @@ static unsigned int ssi_buffer_mgr_get_sgl_nents(
unsigned int nents = 0;
 
while (nbytes != 0) {
-   if (sg_is_chain(sg_list)) {
-   SSI_LOG_ERR("Unexpected chained entry "
-  "in sg (entry =0x%X)\n", nents);
-   BUG();
-   }
if (sg_list->length != 0) {
nents++;
/* get the number of bytes in the last entry */
@@ -854,7 +849,8 @@ static inline int ssi_buffer_mgr_aead_chain_assoc(
//if have reached the end of the sgl, then this is 
unexpected
if (!current_sg) {
SSI_LOG_ERR("reached end of sg list. 
unexpected\n");
-   BUG();
+   rc = -EINVAL;
+   goto chain_assoc_exit;
}
sg_index += current_sg->length;
mapped_nents++;
@@ -1154,7 +1150,8 @@ static inline int ssi_buffer_mgr_aead_chain_data(
//if have reached the end of the sgl, then this is unexpected
if (!areq_ctx->src_sgl) {
SSI_LOG_ERR("reached end of sg list. unexpected\n");
-   BUG();
+   return -EINVAL;
+   goto chain_data_exit;
}
sg_index += areq_ctx->src_sgl->length;
src_mapped_nents--;
@@ -1198,7 +1195,8 @@ static inline int ssi_buffer_mgr_aead_chain_data(
//if have reached the end of the sgl, then this is unexpected
if (!areq_ctx->dst_sgl) {
SSI_LOG_ERR("reached end of sg list. unexpected\n");
-   BUG();
+   rc = -EINVAL;
+   goto chain_data_exit;
}
sg_index += areq_ctx->dst_sgl->length;
dst_mapped_nents--;
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 4311746..68c9fc0 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -541,7 +541,6 @@ ssi_blkcipher_create_setup_desc(
break;
default:
SSI_LOG_ERR("Unsupported cipher mode (%d)\n", cipher_mode);
-   BUG();
}
 }
 
diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index 31325e6..a50671a 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -109,7 +109,8 @@ int ssi_power_mgr_runtime_put_suspend(struct device *dev)
rc = pm_runtime_put_autosuspend(dev);
} else {
/* Something wrong happens*/
-   BUG();
+   SSI_LOG_ERR("request to suspend already suspended queue");
+   rc = -EBUSY;
}
return rc;
 }
diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index e5c2f92..6914dc6 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -369,11 +369,16 @@ int send_request(
enqueue_seq(cc_base, _mgr_h->compl_desc, (is_dout ? 0 : 1));
 
if (unlikely(req_mgr_h->q_free_slots < total_seq_len)) {
-   /*This means that there was a problem with the resume*/
-   BUG();
+   /* This situation should never occur. Maybe indicating problem
+* with resuming power. Set the free slot count to 0 and hope
+* for the best.
+*/
+   SSI_LOG_ERR("HW free slot count mismatch.");
+   req_mgr_h->q_free_slots = 0;
+   } else {
+   /* Update the free slots in HW queue */
+   req_mgr_h->q_free_slots -= total_seq_len;
}
-   /* Update the free slots in HW queue */
-   req_mgr_h->q_free_slots -= total_seq_len;
 
spin_unlock_bh(_mgr_h->hw_lock);
 
@@ -460,8 +465,13 @@ static void proc_completions(struct ssi_drvdata *drvdata)
 
/* Dequeue request */
if (unlikely(request_mgr_handle->req_queue_head == 
request_mgr_handle->req_queue_tail)) {
-   

[PATCH 2/8] staging: ccree: Convert to devm_ioremap_resource for map, unmap

[Gilad Ben-Yossef]

From: Suniel Mahesh 

It is recommended to use managed function devm_ioremap_resource(),
which simplifies driver cleanup paths and driver code.
This patch does the following:
(a) replace request_mem_region(), ioremap() and corresponding error
handling with devm_ioremap_resource().
(b) remove struct resource pointer(res_mem) in struct ssi_drvdata as it
seems redundant, use struct resource pointer which is defined locally and
adjust return value of platform_get_resource() accordingly.
(c) release_mem_region() and iounmap() are dropped, since devm_ioremap_
resource() releases and unmaps mem region on driver detach.
(d) adjust log messages accordingly and remove any blank lines.

Signed-off-by: Suniel Mahesh 
[gby: rebase on top of latest coding style fixes changes]
Acked-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 60 ++
 drivers/staging/ccree/ssi_driver.h |  1 -
 2 files changed, 15 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 47e0880..cbe9a03 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -246,35 +246,21 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
dev_set_drvdata(_dev->dev, new_drvdata);
/* Get device resources */
/* First CC registers space */
-   new_drvdata->res_mem = platform_get_resource(plat_dev, IORESOURCE_MEM, 
0);
-   if (unlikely(!new_drvdata->res_mem)) {
-   SSI_LOG_ERR("Failed getting IO memory resource\n");
-   rc = -ENODEV;
-   goto init_cc_res_err;
-   }
-   SSI_LOG_DEBUG("Got MEM resource (%s): start=%pad end=%pad\n",
- new_drvdata->res_mem->name,
- new_drvdata->res_mem->start,
- new_drvdata->res_mem->end);
+   req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
/* Map registers space */
-   req_mem_cc_regs = request_mem_region(new_drvdata->res_mem->start, 
resource_size(new_drvdata->res_mem), "arm_cc7x_regs");
-   if (unlikely(!req_mem_cc_regs)) {
-   SSI_LOG_ERR("Couldn't allocate registers memory region at "
-"0x%08X\n", (unsigned 
int)new_drvdata->res_mem->start);
-   rc = -EBUSY;
-   goto init_cc_res_err;
-   }
-   cc_base = ioremap(new_drvdata->res_mem->start, 
resource_size(new_drvdata->res_mem));
-   if (unlikely(!cc_base)) {
-   SSI_LOG_ERR("ioremap[CC](0x%08X,0x%08X) failed\n",
-   (unsigned int)new_drvdata->res_mem->start,
-   (unsigned int)resource_size(new_drvdata->res_mem));
-   rc = -ENOMEM;
+   new_drvdata->cc_base = devm_ioremap_resource(_dev->dev,
+req_mem_cc_regs);
+   if (IS_ERR(new_drvdata->cc_base)) {
+   rc = PTR_ERR(new_drvdata->cc_base);
goto init_cc_res_err;
}
-   SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n", 
_drvdata->res_mem->start, cc_base);
-   new_drvdata->cc_base = cc_base;
-
+   SSI_LOG_DEBUG("Got MEM resource (%s): start=%pad end=%pad\n",
+ req_mem_cc_regs->name,
+ req_mem_cc_regs->start,
+ req_mem_cc_regs->end);
+   SSI_LOG_DEBUG("CC registers mapped from %pa to 0x%p\n",
+ _mem_cc_regs->start, new_drvdata->cc_base);
+   cc_base = new_drvdata->cc_base;
/* Then IRQ */
new_drvdata->res_irq = platform_get_resource(plat_dev, IORESOURCE_IRQ, 
0);
if (unlikely(!new_drvdata->res_irq)) {
@@ -424,17 +410,9 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 #ifdef ENABLE_CC_SYSFS
ssi_sysfs_fini();
 #endif
-
-   if (req_mem_cc_regs) {
-   if (irq_registered) {
-   free_irq(new_drvdata->res_irq->start, 
new_drvdata);
-   new_drvdata->res_irq = NULL;
-   iounmap(cc_base);
-   new_drvdata->cc_base = NULL;
-   }
-   release_mem_region(new_drvdata->res_mem->start,
-  resource_size(new_drvdata->res_mem));
-   new_drvdata->res_mem = NULL;
+   if (irq_registered) {
+   free_irq(new_drvdata->res_irq->start, new_drvdata);
+   new_drvdata->res_irq = NULL;
}
dev_set_drvdata(_dev->dev, NULL);
}
@@ -470,14 +448,6 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
cc_clk_off(drvdata);
free_irq(drvdata->res_irq->start, drvdata);
drvdata->res_irq = NULL;
-
-   if 

[PATCH 0/8] staging: ccree: more cleanup work for 4.14

[Gilad Ben-Yossef]

More cleanup work from Sunil and myself.

I've previously sent some of these as part of a larger patch set.
I've decided to split the patch set to smaller chunks to make it
more manageable.

This patch set applies on top of commit 28eb51f7468a
("staging:rtl8188eu:core Fix remove unneccessary else block").

Gilad Ben-Yossef (5):
  staging: ccree: simplify resource release on error
  staging: ccree: remove unused completion
  staging: ccree: move over to BIT macro for bit defines
  staging: ccree: replace noop macro with inline
  staging: ccree: remove BUG macro usage

Suniel Mahesh (3):
  staging: ccree: Replace kzalloc with devm_kzalloc
  staging: ccree: Convert to devm_ioremap_resource for map, unmap
  staging: ccree: Use platform_get_irq and devm_request_irq

 drivers/staging/ccree/ssi_aead.c|   3 +-
 drivers/staging/ccree/ssi_buffer_mgr.c  |  14 +--
 drivers/staging/ccree/ssi_cipher.c  |   4 +-
 drivers/staging/ccree/ssi_cipher.h  |  10 +-
 drivers/staging/ccree/ssi_driver.c  | 196 +---
 drivers/staging/ccree/ssi_driver.h  |  15 +--
 drivers/staging/ccree/ssi_hash.c|   3 +-
 drivers/staging/ccree/ssi_pm.c  |   3 +-
 drivers/staging/ccree/ssi_request_mgr.c |  23 +++-
 9 files changed, 119 insertions(+), 152 deletions(-)

-- 
2.1.4

[PATCH 6/8] staging: ccree: move over to BIT macro for bit defines

[Gilad Ben-Yossef]

Use BIT macro for bit definitions where needed.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_cipher.h | 10 +-
 drivers/staging/ccree/ssi_driver.c |  3 ++-
 drivers/staging/ccree/ssi_driver.h |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.h 
b/drivers/staging/ccree/ssi_cipher.h
index 296b375..c9a83df 100644
--- a/drivers/staging/ccree/ssi_cipher.h
+++ b/drivers/staging/ccree/ssi_cipher.h
@@ -27,11 +27,11 @@
 #include "ssi_buffer_mgr.h"
 
 /* Crypto cipher flags */
-#define CC_CRYPTO_CIPHER_KEY_KFDE0(1 << 0)
-#define CC_CRYPTO_CIPHER_KEY_KFDE1(1 << 1)
-#define CC_CRYPTO_CIPHER_KEY_KFDE2(1 << 2)
-#define CC_CRYPTO_CIPHER_KEY_KFDE3(1 << 3)
-#define CC_CRYPTO_CIPHER_DU_SIZE_512B (1 << 4)
+#define CC_CRYPTO_CIPHER_KEY_KFDE0 BIT(0)
+#define CC_CRYPTO_CIPHER_KEY_KFDE1 BIT(1)
+#define CC_CRYPTO_CIPHER_KEY_KFDE2 BIT(2)
+#define CC_CRYPTO_CIPHER_KEY_KFDE3 BIT(3)
+#define CC_CRYPTO_CIPHER_DU_SIZE_512B  BIT(4)
 
 #define CC_CRYPTO_CIPHER_KEY_KFDE_MASK (CC_CRYPTO_CIPHER_KEY_KFDE0 | 
CC_CRYPTO_CIPHER_KEY_KFDE1 | CC_CRYPTO_CIPHER_KEY_KFDE2 | 
CC_CRYPTO_CIPHER_KEY_KFDE3)
 
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 8f1d7af..6d16220 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -185,7 +185,8 @@ int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe)
CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_ICR), val);
 
/* Unmask relevant interrupt cause */
-   val = (~(SSI_COMP_IRQ_MASK | SSI_AXI_ERR_IRQ_MASK | SSI_GPR0_IRQ_MASK));
+   val = (unsigned int)(~(SSI_COMP_IRQ_MASK | SSI_AXI_ERR_IRQ_MASK |
+  SSI_GPR0_IRQ_MASK));
CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IMR), val);
 
 #ifdef DX_HOST_IRQ_TIMER_INIT_VAL_REG_OFFSET
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 9b6476d..06a3c48 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -68,12 +68,12 @@
 #define SSI_AXI_IRQ_MASK ((1 << DX_AXIM_CFG_BRESPMASK_BIT_SHIFT) | (1 << 
DX_AXIM_CFG_RRESPMASK_BIT_SHIFT) |\
(1 << DX_AXIM_CFG_INFLTMASK_BIT_SHIFT) | (1 << 
DX_AXIM_CFG_COMPMASK_BIT_SHIFT))
 
-#define SSI_AXI_ERR_IRQ_MASK (1 << DX_HOST_IRR_AXI_ERR_INT_BIT_SHIFT)
+#define SSI_AXI_ERR_IRQ_MASK BIT(DX_HOST_IRR_AXI_ERR_INT_BIT_SHIFT)
 
-#define SSI_COMP_IRQ_MASK (1 << DX_HOST_IRR_AXIM_COMP_INT_BIT_SHIFT)
+#define SSI_COMP_IRQ_MASK BIT(DX_HOST_IRR_AXIM_COMP_INT_BIT_SHIFT)
 
 /* TEE FIPS status interrupt */
-#define SSI_GPR0_IRQ_MASK (1 << DX_HOST_IRR_GPR0_BIT_SHIFT)
+#define SSI_GPR0_IRQ_MASK BIT(DX_HOST_IRR_GPR0_BIT_SHIFT)
 
 #define SSI_CRA_PRIO 3000
 
-- 
2.1.4

[GIT pull] x86 fixes for 4.13

[Thomas Gleixner]

Linus,

please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus

This update contains:

 - Expand the space for uncompressing as the LZ4 worst case does not fit
   into the currently reserved space.

 - Validate boot parameters more strictly to prevent out of bound access in
   the decompressor/boot code.

 - Fix off by one errors in get_segment_base().

Thanks,

tglx

-->
Dan Carpenter (1):
  x86/ldt: Fix off by one in get_segment_base()

Jan H. Schönherr (2):
  x86/boot: Provide more slack space during decompression
  x86/boot: Prevent faulty bootparams.screeninfo from causing harm


 arch/x86/boot/compressed/misc.c | 3 +--
 arch/x86/boot/header.S  | 8 +++-
 arch/x86/events/core.c  | 7 ++-
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index a0838ab929f2..c14217cd0155 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -116,8 +116,7 @@ void __putstr(const char *s)
}
}
 
-   if (boot_params->screen_info.orig_video_mode == 0 &&
-   lines == 0 && cols == 0)
+   if (lines == 0 || cols == 0)
return;
 
x = boot_params->screen_info.orig_x;
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2ed8f0c25def..1bb08ecffd24 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -520,8 +520,14 @@ pref_address:  .quad LOAD_PHYSICAL_ADDR
# preferred load addr
 # the description in lib/decompressor_xxx.c for specific information.
 #
 # extra_bytes = (uncompressed_size >> 12) + 65536 + 128
+#
+# LZ4 is even worse: data that cannot be further compressed grows by 0.4%,
+# or one byte per 256 bytes. OTOH, we can safely get rid of the +128 as
+# the size-dependent part now grows so fast.
+#
+# extra_bytes = (uncompressed_size >> 8) + 65536
 
-#define ZO_z_extra_bytes   ((ZO_z_output_len >> 12) + 65536 + 128)
+#define ZO_z_extra_bytes   ((ZO_z_output_len >> 8) + 65536)
 #if ZO_z_output_len > ZO_z_input_len
 # define ZO_z_extract_offset   (ZO_z_output_len + ZO_z_extra_bytes - \
 ZO_z_input_len)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index af12e294caed..939050169d12 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2335,12 +2335,9 @@ static unsigned long get_segment_base(unsigned int 
segment)
 #ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
 
-   if (idx > LDT_ENTRIES)
-   return 0;
-
/* IRQs are off, so this synchronizes with smp_store_release */
ldt = lockless_dereference(current->active_mm->context.ldt);
-   if (!ldt || idx > ldt->nr_entries)
+   if (!ldt || idx >= ldt->nr_entries)
return 0;
 
desc = >entries[idx];
@@ -2348,7 +2345,7 @@ static unsigned long get_segment_base(unsigned int 
segment)
return 0;
 #endif
} else {
-   if (idx > GDT_ENTRIES)
+   if (idx >= GDT_ENTRIES)
return 0;
 
desc = raw_cpu_ptr(gdt_page.gdt) + idx;

Re: [PATCH] iio staging: tsl2x7x: clean up limit checks

[Jonathan Cameron]

On Mon, 21 Aug 2017 13:11:03 +0300
Dan Carpenter  wrote:

> The second part of this patch is probably the most interesting.  We
> use "TSL2X7X_MAX_LUX_TABLE_SIZE * 3" as the limit instead of just
> "TSL2X7X_MAX_LUX_TABLE_SIZE".  It creates a static checker warning that
> we are going of of bounds, but in real life we always hit the break
> statement on the last element so it's fine.
> 
> The situation is that we normally have arrays with 3 elements of struct
> tsl2x7x_lux which has 3 unsigned integers.  If we load the table with
> sysfs then we're allow to have 9 elements instead.
> 
> So the size of the default table in bytes is sizeof(int) times 3 struct
> members times 3 elements.  The original code wrote it as sizeof(int)
> times the number of elements in the bigger table (9).  It happens that
> 9 is the same thing as 3 * 3 but expressing it that way is misleading.
> 
> For the second part of the patch, the original code just had an extra
> "multiply by three" and now that is removed.  The last element in the
> array is always zeroed memory whether this uses the default tables or it
> gets loaded with sysfs so we always hit the break statement anyway.
> 
> Signed-off-by: Dan Carpenter 

Looks sensible to me.

Cc'd Brian who has been working extensively on this driver recently as I'd
like his input.

Jonathan
> 
> diff --git a/drivers/staging/iio/light/tsl2x7x.h 
> b/drivers/staging/iio/light/tsl2x7x.h
> index ecae92211216..1beb8d2eb848 100644
> --- a/drivers/staging/iio/light/tsl2x7x.h
> +++ b/drivers/staging/iio/light/tsl2x7x.h
> @@ -23,10 +23,6 @@
>  #define __TSL2X7X_H
>  #include 
>  
> -/* Max number of segments allowable in LUX table */
> -#define TSL2X7X_MAX_LUX_TABLE_SIZE   9
> -#define MAX_DEFAULT_TABLE_BYTES (sizeof(int) * TSL2X7X_MAX_LUX_TABLE_SIZE)
> -
>  struct iio_dev;
>  
>  struct tsl2x7x_lux {
> @@ -35,6 +31,11 @@ struct tsl2x7x_lux {
>   unsigned int ch1;
>  };
>  
> +/* Max number of segments allowable in LUX table */
> +#define TSL2X7X_MAX_LUX_TABLE_SIZE   9
> +/* The default tables are all 3 elements */
> +#define MAX_DEFAULT_TABLE_BYTES (sizeof(struct tsl2x7x_lux) * 3)
> +
>  /**
>   * struct tsl2x7x_default_settings - power on defaults unless
>   *   overridden by platform data.
> diff --git a/drivers/staging/iio/light/tsl2x7x.c 
> b/drivers/staging/iio/light/tsl2x7x.c
> index 786e93f16ce9..2db1715ff659 100644
> --- a/drivers/staging/iio/light/tsl2x7x.c
> +++ b/drivers/staging/iio/light/tsl2x7x.c
> @@ -1113,7 +1113,7 @@ static ssize_t in_illuminance0_lux_table_show(struct 
> device *dev,
>   int i = 0;
>   int offset = 0;
>  
> - while (i < (TSL2X7X_MAX_LUX_TABLE_SIZE * 3)) {
> + while (i < TSL2X7X_MAX_LUX_TABLE_SIZE) {
>   offset += snprintf(buf + offset, PAGE_SIZE, "%u,%u,%u,",
>   chip->tsl2x7x_device_lux[i].ratio,
>   chip->tsl2x7x_device_lux[i].ch0,

Re: [PATCH] iio: multiplexer: add NULL check on devm_kzalloc() and devm_kmemdup() return values

[Jonathan Cameron]

On Sat, 26 Aug 2017 08:09:43 +0200
Peter Rosin  wrote:

> On 2017-07-09 19:10, Jonathan Cameron wrote:
> > On Fri, 7 Jul 2017 11:26:35 +0200
> > Peter Rosin  wrote:
> >   
> >> On 2017-07-07 06:57, Peter Rosin wrote:  
> >>> On 2017-07-07 06:53, Gustavo A. R. Silva wrote:
>  Check return values from call to devm_kzalloc() and devm_kmemup()
> >>>
> >>> If someone cares enough: s/devm_kmemup/evm_kmemdup/
> >>
> >> Strange, there seems to be some inherent shortage of 'd' characters...
> >>
> >> Cheers,
> >> pea :-)
> >>  
> >>> 
>  in order to prevent a NULL pointer dereference.
> 
>  This issue was detected using Coccinelle and the following semantic 
>  patch:
> 
>  @@
>  expression x;
>  identifier fld;
>  @@
> 
>  * x = devm_kzalloc(...);
> ... when != x == NULL
> x->fld
> 
>  Cc: Peter Rosin 
>  Signed-off-by: Gustavo A. R. Silva 
> >>>
> >>> Either way,
> >>>
> >>> Reviewed-by: Peter Rosin 
> >>>
> >>> Thanks!
> >>>  
> > The relevant patch adding the file in questions hasn't yet worked it's
> > way back to the iio tree so I can't apply this until it does.
> > 
> > That is likely to be a few weeks away yet.  Please give me a poke if
> > I seem to have forgotten it!  
> 
> Hi Jonathan!
> 
> I saw a patch from Christophe JAILLET [1] and it seemed familiar so I
> did a bit of digging. Now, I did go back and check this a couple of
> weeks after you request, but iio-mux.c still wasn't in the iio tree,
> and then I did forgot about it. Sorry. But here's the poke...
> 

Applied.  Thanks - this one had completely dropped off the back of my
patch queue. Oops.

Jonathan

> Cheers,
> Peter
> 
> [1] https://lkml.org/lkml/2017/8/26/3
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/10] drm/amdgpu: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
index 9804318f3488..7ef84d884714 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
@@ -20,6 +20,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
+#include 
+
 #include "amdgpu.h"
 #include "mmhub_v1_0.h"
 
@@ -268,7 +270,7 @@ const struct pctl_data pctl0_data[] = {
 {0x135, 0x12a810},
 {0x149, 0x7a82c}
 };
-#define PCTL0_DATA_LEN (sizeof(pctl0_data)/sizeof(pctl0_data[0]))
+#define PCTL0_DATA_LEN (ARRAY_SIZE(pctl0_data))
 
 #define PCTL0_RENG_EXEC_END_PTR 0x151
 #define PCTL0_STCTRL_REG_SAVE_RANGE0_BASE  0xa640
@@ -297,7 +299,7 @@ const struct pctl_data pctl1_data[] = {
 {0x1be, 0x17a7dd},
 {0x1d7, 0x12a810}
 };
-#define PCTL1_DATA_LEN (sizeof(pctl1_data)/sizeof(pctl1_data[0]))
+#define PCTL1_DATA_LEN (ARRAY_SIZE(pctl1_data))
 
 #define PCTL1_RENG_EXEC_END_PTR 0x1ea
 #define PCTL1_STCTRL_REG_SAVE_RANGE0_BASE  0xa000

[PATCH 0/10] Use ARRAY_SIZE macro - v4.13-rc7

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.

Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Run against version v4.13-rc7

Let me know when you as a maintainer are not interested in these kind of 
patches.
I can exclude you by path; e.g. all findings in "drivers/scsi" will never
be reported again by this semi-automatic program runs.

[PATCH 5/10] [media] lgdt3306a: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
b/drivers/media/dvb-frontends/lgdt3306a.c
index c9b1eb38444e..724e9aac0f11 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -19,6 +19,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include "dvb_math.h"
 #include "lgdt3306a.h"
@@ -2072,7 +2073,7 @@ static const short regtab[] = {
0x30aa, /* MPEGLOCK */
 };
 
-#define numDumpRegs (sizeof(regtab)/sizeof(regtab[0]))
+#define numDumpRegs (ARRAY_SIZE(regtab))
 static u8 regval1[numDumpRegs] = {0, };
 static u8 regval2[numDumpRegs] = {0, };
 

Linux 4.13: Reported regressions as of Sunday, 2017-09-03

[Thorsten Leemhuis]

Hi! Find below my fifth regression report for Linux 4.13. It lists 4
regressions I'm currently aware of. There are no new ones; 2 got fixed
since the last report.

You can also find the report at http://bit.ly/lnxregrep413 where I try
to update it every now and then.

As always: Are you aware of any other regressions? Then please let me
know. For details see http://bit.ly/lnxregtrackid And please tell me if
there is anything in the report that shouldn't be there.

Ciao, Thorsten

P.S.: Thx to all those that CCed me on regression reports or provided
other input, it makes compiling these reports a whole lot easier!

== Current regressions ==

[x86/mm/gup] e585513b76: will-it-scale.per_thread_ops -6.9% regression
Status: Asked on the list, but looks like issue gets ignored by everyone
Note: I'm a bit unsure if adding this issue to this list was a good
idea. Side note: Was reported against linux-next in May already
Reported: 2017-07-10
http://lkml.kernel.org/r/20170710024020.GA26389@yexl-desktop
Cause: https://git.kernel.org/torvalds/c/e585513b76f7

[lkp-robot] [Btrfs] 28785f70ef: xfstests.generic.273.fail
Status: Jeff: "We're not ignoring it. […] collection of bugs that
approximate a correct result, and we're addressing them individually.[…]"
Reported: 2017-07-26 Last known developer activity: 2017-08-10
https://lkml.kernel.org/r/20170726062352.GC4877@yexl-desktop
https://lkml.kernel.org/r/bcd49705-e63a-4439-1620-57cd16f5b...@suse.com
Cause: https://git.kernel.org/torvalds/c/28785f70ef88
Linux-Regression-ID: lr#a7d273

Build regression: cc1: error: '-march=r3000' requires '-mfp32'
Note: is there any way to query 0-day to see if this is still happening?
Reported: 2017-08-13
https://lkml.org/lkml/2017/8/13/38
Cause: https://git.kernel.org/torvalds/c/89a55278dee4

usb:xhci: regression when ATI chipsets detected
Status: Fix in usb-next/usb-testing
Reported: 2017-08-23 Last known developer activity: 2017-08-28
https://lkml.kernel.org/r/1503485760-15146-1-git-send-email-sandeep.si...@amd.com
Cause: https://git.kernel.org/torvalds/c/e788787ef4f9


== Fixed since last report ==

[Dell xps13 9630] Could not be woken up from suspend-to-idle via usb
keyboard
Status: was a tracking bug that got closed by the developer that created it
Reported: 2017-07-24
https://bugzilla.kernel.org/show_bug.cgi?id=196459
Cause: https://git.kernel.org/torvalds/c/33e4f80ee69b
Linux-Regression-ID: lr#bd29ab

CIFS mount error -112 due to "SMB3 by default for security reasons"
Status: Situation not perfect, but improved a lot by
https://git.kernel.org/torvalds/c/7e682f766f28
Note: https://lkml.org/lkml/2017/8/31/843
Reported: 2017-08-06
https://bugzilla.kernel.org/show_bug.cgi?id=196599
Cause: https://git.kernel.org/torvalds/c/eef914a9eb5e /
https://git.kernel.org/torvalds/c/908b852df1d5
Linux-Regression-ID: lr#60efe5

[PATCH 9/10] [SCSI] bfa: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/scsi/bfa/bfa_core.c b/drivers/scsi/bfa/bfa_core.c
index 3e1caec82554..4a03cd9fa63f 100644
--- a/drivers/scsi/bfa/bfa_core.c
+++ b/drivers/scsi/bfa/bfa_core.c
@@ -16,6 +16,7 @@
  * General Public License for more details.
  */
 
+#include 
 #include "bfad_drv.h"
 #include "bfa_modules.h"
 #include "bfi_reg.h"
@@ -1957,7 +1958,7 @@ bfa_get_pciids(struct bfa_pciid_s **pciids, int *npciids)
{BFA_PCI_VENDOR_ID_BROCADE, BFA_PCI_DEVICE_ID_CT_FC},
};
 
-   *npciids = sizeof(__pciids) / sizeof(__pciids[0]);
+   *npciids = ARRAY_SIZE(__pciids);
*pciids = __pciids;
 }
 

Re: [PATCH 4.9 01/12] p54: memset(0) whole array

[Christian Lamparter]

On Saturday, September 2, 2017 8:51:01 AM CEST Joe Perches wrote:
> On Thu, 2017-08-31 at 09:40 -0700, Joe Perches wrote:
> > On Thu, 2017-08-31 at 17:44 +0200, Greg Kroah-Hartman wrote:
> > > 4.9-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Jiri Slaby 
> > > 
> > > commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.
> > > 
> > > gcc 7 complains:
> > > drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
> > > drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used 
> > > with length equal to number of elements without multiplication by element 
> > > size [-Wmemset-elt-size]
> > > 
> > > Fix that by passing the correct size to memset.
> > > 
> > > Signed-off-by: Jiri Slaby 
> > > Cc: Christian Lamparter 
> > > Cc: Kalle Valo 
> > > Acked-by: Christian Lamparter 
> > > Signed-off-by: Kalle Valo 
> > > Signed-off-by: Greg Kroah-Hartman 
> > > 
> > > ---
> > >  drivers/net/wireless/intersil/p54/fwio.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > --- a/drivers/net/wireless/intersil/p54/fwio.c
> > > +++ b/drivers/net/wireless/intersil/p54/fwio.c
> > > @@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u1
> > >  
> > >   entry += sizeof(__le16);
> > >   chan->pa_points_per_curve = 8;
> > > - memset(chan->curve_data, 0, sizeof(*chan->curve_data));
> > > + memset(chan->curve_data, 0, sizeof(chan->curve_data));
> > >   memcpy(chan->curve_data, entry,
> > >  sizeof(struct p54_pa_curve_data_sample) *
> > >  min((u8)8, curve_data->points_per_channel));
> > > 
> > 
> > Why is this change correct?
> > 
> > curve_data is a pointer.
> > 
> > This now clears the sizeof a pointer and not
> > the sizeof struct p54_cal_database
> 
> So what happens here?
> This change seems clearly incorrect.
> For all stable versions.
 
hm?

Please, just look again at [0]:
|   struct p54_scan_body *chan = >normal;
|   struct pda_pa_curve_data *curve_data =
|   (void *) priv->curve_data->data;
|
|   entry += sizeof(__le16);
|   chan->pa_points_per_curve = 8;
|   memset(chan->curve_data, 0, sizeof(chan->curve_data));
|   memcpy(chan->curve_data, entry,
|  sizeof(struct p54_pa_curve_data_sample) *
|  min((u8)8, curve_data->points_per_channel));

yes: "curve_data" is a pointer. But memset and memcpy are using
"chan->curve_data". chan is a pointer to a p54_scan_body struct.
The structure is defined in lmac.h:

|struct p54_pa_curve_data_sample {
|   u8 rf_power;
|   u8 pa_detector;
|   u8 data_barker;
|   u8 data_bpsk;
|   u8 data_qpsk;
|   u8 data_16qam;
|   u8 data_64qam;
|   u8 padding;
|} __packed;
|
|struct p54_scan_body {
|   u8 pa_points_per_curve;
|   u8 val_barker;
|   u8 val_bpsk;
|   u8 val_qpsk;
|   u8 val_16qam;
|   u8 val_64qam;
|   struct p54_pa_curve_data_sample curve_data[8];
|   u8 dup_bpsk;
|   u8 dup_qpsk;
|   u8 dup_16qam;
|   u8 dup_64qam;
|} __packed;

p54_scan_body's curve_data is an array of eight
p54_pa_curve_data_sample, each with eight u8.
This means that chan->curve_data is 64 bytes in total.

If you are not convinced yet, please add:

BUILD_BUG_ON(sizeof(chan->curve_data) != 64);

next to the memset and compile the driver. 
If this was all wrong, this would cause a build error, right?

Regards,
Christian

[0] 

[1] 

[PATCH 4/10] drm/nouveau/bios/init: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index b58ee99f7bfc..440efa333d6c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -21,6 +21,7 @@
  *
  * Authors: Ben Skeggs
  */
+#include 
 #include 
 #include 
 #include 
@@ -2271,7 +2272,7 @@ static struct nvbios_init_opcode {
[0xaa] = { init_reserved },
 };
 
-#define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0]))
+#define init_opcode_nr (ARRAY_SIZE(init_opcode))
 
 int
 nvbios_exec(struct nvbios_init *init)

[PATCH 3/10] drm/i915/gvt: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 3deadcbd5a24..7d8035093a1e 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -30,6 +30,7 @@
  *Bing Niu 
  *
  */
+#include 
 
 #include "i915_drv.h"
 #include "gvt.h"
@@ -115,7 +116,7 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
 */
low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
-   num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]);
+   num_types = ARRAY_SIZE(vgpu_types);
 
gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type),
 GFP_KERNEL);

[PATCH 6/10] ixgbe: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index 72d84a065e34..fabb11475fb4 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -21,6 +21,7 @@
  *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
  *
  
**/
+#include 
 #include "ixgbe_x540.h"
 #include "ixgbe_type.h"
 #include "ixgbe_common.h"
@@ -947,7 +948,7 @@ static s32 ixgbe_checksum_ptr_x550(struct ixgbe_hw *hw, u16 
ptr,
u16 length, bufsz, i, start;
u16 *local_buffer;
 
-   bufsz = sizeof(buf) / sizeof(buf[0]);
+   bufsz = ARRAY_SIZE(buf);
 
/* Read a chunk at the pointer location */
if (!buffer) {

Re: [RFC v2 1/6] platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe function

[Andy Shevchenko]

On Sun, Sep 3, 2017 at 4:24 AM,
 wrote:
> From: Kuppuswamy Sathyanarayanan 
>
> This patch cleans up unnecessary free/alloc calls in ipc_plat_probe(),
> ipc_pci_probe() and ipc_plat_get_res() functions by using devm_*
> calls.
>
> This patch also adds proper error handling for failure cases in
> ipc_pci_probe() function.

> ret = pci_enable_device(pdev);
> if (ret)
> -   return ret;
> +   goto release_device;

Instead you should use PCI managed function(s).

-- 
With Best Regards,
Andy Shevchenko

Re: fanotify hangs with AUFS

[J. R. Okajima]

Ariel Zelivansky:
> I just opened bug 196815 on the kernel bugzilla
> (https://bugzilla.kernel.org/show_bug.cgi?id=196815). Let me know if
> there's anything else I can do

It seems that the problem exists in aufs.
I will dive into it.
Mainline people should not worry about it.

Ariel,
Aufs is not in mainline, so I don't think it is appropriate to book the
report into kernel bugzilla. Read aufs README file please.


J. R. Okajima

[PATCH] rpmsg: glink: initialize ret to zero to ensure error status check is correct

[Colin King]

From: Colin Ian King 

The new switch cases for RPM_CMD_RX_DONE, RPM_CMD_RX_DONE_W_REUSE,
RPM_CMD_RX_INTENT_REQ_ACK, RPM_CMD_INTENT and RPM_CMD_RX_INTENT_REQ from
4 recent commits are not setting ret and so a later non-zero check on ret
is testing on a garbage value in ret. Fix this by initializing ret to zero.

Detected by CoverityScan CID#1455249 ("Uninitialized scalar variable")

Fixes: 933b45da5d1d ("rpmsg: glink: Add support for TX intents)
Fixes: dacbb35e930f ("glink: Receive and store the remote intent buffers")
Fixes: 27b9c5b66b23 ("rpmsg: glink: Request for intents when unavailable")
Fixes: 88c6060f5a7f ("rpmsg: glink: Handle remote rx done command")
Signed-off-by: Colin Ian King 
---
 drivers/rpmsg/qcom_glink_native.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/rpmsg/qcom_glink_native.c 
b/drivers/rpmsg/qcom_glink_native.c
index 8bc0d0456a40..5a5e927ea50f 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -957,7 +957,7 @@ static irqreturn_t qcom_glink_native_intr(int irq, void 
*data)
unsigned int param2;
unsigned int avail;
unsigned int cmd;
-   int ret;
+   int ret = 0;
 
for (;;) {
avail = qcom_glink_rx_avail(glink);
@@ -994,8 +994,6 @@ static irqreturn_t qcom_glink_native_intr(int irq, void 
*data)
 
mbox_send_message(glink->mbox_chan, NULL);
mbox_client_txdone(glink->mbox_chan, 0);
-
-   ret = 0;
break;
case RPM_CMD_INTENT:
qcom_glink_handle_intent(glink, param1, param2, avail);
-- 
2.14.1

Re: [PATCH][next] net/mlx4_core: fix incorrect size allocation for dev->caps.spec_qps

[Tariq Toukan]

On 31/08/2017 8:07 PM, Colin King wrote:

From: Colin Ian King 

The current allocation for dev->caps.spec_qps is for the size of the
pointer and not the size of the actual  mlx4_spec_qps structure.  Fix
this by using the correct size.   Also splint allocation over a few
lines to make it cppcheck clean on overly wide lines.

Detected by CoverityScan, CID#1455222 ("Wrong sizeof argument")

Fixes: c73c8b1e47ca ("net/mlx4_core: Dynamically allocate structs at 
mlx4_slave_cap")
Signed-off-by: Colin Ian King 
---
  drivers/net/ethernet/mellanox/mlx4/qp.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/qp.c 
b/drivers/net/ethernet/mellanox/mlx4/qp.c
index b16fc441609e..728a2fb1f5c0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/qp.c
+++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
@@ -845,8 +845,9 @@ int mlx4_init_qp_table(struct mlx4_dev *dev)
  
  		/* In mfunc, calculate proxy and tunnel qp offsets for the PF here,

 * since the PF does not call mlx4_slave_caps */
-   dev->caps.spec_qps = kcalloc(dev->caps.num_ports, 
sizeof(dev->caps.spec_qps), GFP_KERNEL);
-
+   dev->caps.spec_qps = kcalloc(dev->caps.num_ports,
+sizeof(*dev->caps.spec_qps),
+GFP_KERNEL);
if (!dev->caps.spec_qps) {
err = -ENOMEM;
goto err_mem;



Acked-by: Tariq Toukan 

Thanks!

Re: Converting struct timer_list callback argument to struct timer_list *

[Christoph Hellwig]

On Fri, Sep 01, 2017 at 09:24:22AM -0700, Kees Cook wrote:
> #define list_entry(ptr, type, member) container_of(ptr, type, member)
> #define rb_entry(ptr, type, member) container_of(ptr, type, member)
> 
> The use of a "timer_entry()" at the start of callbacks repeats the
> struct name, which I find irritating (and it usually results in split
> lines). For example:
> 
> #define timer_entry(ptr, type, member) container_of(ptr, type, member)
> 
> -static void snd_card_asihpi_timer_function(unsigned long data)
> +static void snd_card_asihpi_timer_function(struct timer_list *t)
>  {
> -   struct snd_card_asihpi_pcm *dpcm = (struct snd_card_asihpi_pcm *)data;
> +   struct snd_card_asihpi_pcm *dpcm =
> +timer_entry(t, struct
> snd_card_asihpi_pcm, timer);
> 
> I prefer to tie this directly to the variable, so how about renaming
> TIMER_CONTAINER to timer_of():

The TIMER_CONTAINER semantics are more useful indeed, and I which
we'd have a general purpose variant of that.  But I was complaining
about the name anyway.  timer_of sounds ok, but timer_entry still sounds
a bit more descriptive.  As for the split lines:  you'll generally
get a lot of these, even TIMER_CONTAINER has a quite a few.  I generally
prefer to move everything right of the = to the next line as that
becomes a lot more redable.

[PATCH 1/1] dax: initialize variable pfn before using it

[Nicolas Iooss]

Function dax_pmd_insert_mapping() contains the following code:

pfn_t pfn;
if (bdev_dax_pgoff(bdev, sector, size, ) != 0)
goto fallback;
/* ... */
fallback:
  trace_dax_pmd_insert_mapping_fallback(inode, vmf, length, pfn, ret);

When the condition in the if statement fails, the function calls
trace_dax_pmd_insert_mapping_fallback() with an uninitialized pfn value.

This issue has been found while building the kernel with clang. The
compiler reported:

fs/dax.c:1280:6: error: variable 'pfn' is used uninitialized
whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (bdev_dax_pgoff(bdev, sector, size, ) != 0)
^~~
fs/dax.c:1310:60: note: uninitialized use occurs here
  trace_dax_pmd_insert_mapping_fallback(inode, vmf, length, pfn, ret);
 ^~~

Signed-off-by: Nicolas Iooss 
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index ab925dc6647a..20e6d76d6fff 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1283,7 +1283,7 @@ static int dax_pmd_insert_mapping(struct vm_fault *vmf, 
struct iomap *iomap,
void *ret = NULL, *kaddr;
long length = 0;
pgoff_t pgoff;
-   pfn_t pfn;
+   pfn_t pfn = {};
int id;
 
if (bdev_dax_pgoff(bdev, sector, size, ) != 0)
-- 
2.14.1

[PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header

[Nicolas Iooss]

Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until
shared_info is initialized") moved xen_init_time_ops() from __init to
__ref without updating xen-ops.h accordingly. Fix this.

Fixes: d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until
shared_info is initialized")
Signed-off-by: Nicolas Iooss 
---
 arch/x86/xen/xen-ops.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 0d5004477db6..b2a5d48a2c2a 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -69,7 +69,7 @@ void xen_setup_runstate_info(int cpu);
 void xen_teardown_timer(int cpu);
 u64 xen_clocksource_read(void);
 void xen_setup_cpu_clockevents(void);
-void __init xen_init_time_ops(void);
+void __ref xen_init_time_ops(void);
 void __init xen_hvm_init_time_ops(void);
 
 irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
-- 
2.14.1

[PATCH 0/2] tracing: Add critical section event support

[Joel Fernandes]

These patches add critical section event tracing support.

Changes since RFC [1] are:
- Make critical events independent of the preempt/irqsoff tracer.
- Store pointers instead of symbol names to do less in the fast path.
- Other changes based on Steven's comments.

Here's an example of how Android's systrace will be using it to show critical
sections as a gantt chart: http://imgur.com/download/TZplEVp

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

Joel Fernandes (2):
  tracing: irqsoff: Move code under tracer config options
  tracing: Add support for critical section events

 include/linux/ftrace.h  |   2 +-
 include/linux/irqflags.h|   3 +-
 include/trace/events/critical.h |  45 ++
 kernel/trace/Kconfig|   5 +
 kernel/trace/Makefile   |   1 +
 kernel/trace/trace_irqsoff.c| 331 ++--
 6 files changed, 269 insertions(+), 118 deletions(-)
 create mode 100644 include/trace/events/critical.h

Cc: Steven Rostedt 
Cc: kernel-t...@android.com
-- 
2.14.1.581.gf28d330327-goog

[PATCH 2/2] tracing: Add support for critical section events

[Joel Fernandes]

Critical section trace events can be used for tracing the start and
end of a critical section which can be used by a trace viewer like
systrace to graphically view the start and end of a critical section and
correlate them with latencies and scheduling issues.

Reason for starting critical section:
Either preemption or interrupts were turned off.
Reason for ending critical section:
Both preemption and interrupts are now turned back on.

Cc: Steven Rostedt 
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes 
---
 include/linux/ftrace.h  |  2 +-
 include/linux/irqflags.h|  3 +-
 include/trace/events/critical.h | 45 +++
 kernel/trace/Kconfig|  5 +++
 kernel/trace/Makefile   |  1 +
 kernel/trace/trace_irqsoff.c| 97 +++--
 6 files changed, 147 insertions(+), 6 deletions(-)
 create mode 100644 include/trace/events/critical.h

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 6383115e9d2c..6020c473a198 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -742,7 +742,7 @@ static inline unsigned long get_lock_parent_ip(void)
   static inline void time_hardirqs_off(unsigned long a0, unsigned long a1) { }
 #endif
 
-#ifdef CONFIG_PREEMPT_TRACER
+#if defined(CONFIG_PREEMPT_TRACER) || defined(CONFIG_CRITICAL_SECTION_EVENTS)
   extern void trace_preempt_on(unsigned long a0, unsigned long a1);
   extern void trace_preempt_off(unsigned long a0, unsigned long a1);
 #else
diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
index 9bc050bc81b2..79c372fe9dcb 100644
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -61,7 +61,8 @@ do {  \
 #endif
 
 #if defined(CONFIG_IRQSOFF_TRACER) || \
-   defined(CONFIG_PREEMPT_TRACER)
+   defined(CONFIG_PREEMPT_TRACER) || \
+   defined(CONFIG_CRITICAL_SECTION_EVENTS)
  extern void stop_critical_timings(void);
  extern void start_critical_timings(void);
 #else
diff --git a/include/trace/events/critical.h b/include/trace/events/critical.h
new file mode 100644
index ..bd07a6a50252
--- /dev/null
+++ b/include/trace/events/critical.h
@@ -0,0 +1,45 @@
+#ifdef CONFIG_CRITICAL_SECTION_EVENTS
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM critical
+
+#if !defined(_TRACE_CRITICAL_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CRITICAL_H
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_EVENT_CLASS(critical_template,
+
+   TP_PROTO(unsigned long ip, unsigned long parent_ip),
+
+   TP_ARGS(ip, parent_ip),
+
+   TP_STRUCT__entry(
+   __field(u32, caller_offs)
+   __field(u32, parent_offs)
+   ),
+
+   TP_fast_assign(
+   __entry->caller_offs = (u32)(ip - (unsigned long)_stext);
+   __entry->parent_offs = (u32)(parent_ip - (unsigned long)_stext);
+   ),
+
+   TP_printk("caller=%pF parent=%pF\n",
+ (void *)((unsigned long)(_stext) + __entry->caller_offs),
+ (void *)((unsigned long)(_stext) + __entry->parent_offs))
+);
+
+DEFINE_EVENT(critical_template, critical_start,
+TP_PROTO(unsigned long ip, unsigned long parent_ip),
+TP_ARGS(ip, parent_ip));
+
+DEFINE_EVENT(critical_template, critical_stop,
+TP_PROTO(unsigned long ip, unsigned long parent_ip),
+TP_ARGS(ip, parent_ip));
+#endif /* _TRACE_CRITICAL_H */
+
+/* This part must be outside protection */
+#include 
+#endif
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 434c840e2d82..c08b23fcae6d 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -209,6 +209,11 @@ config PREEMPT_TRACER
  enabled. This option and the irqs-off timing option can be
  used together or separately.)
 
+config CRITICAL_SECTION_EVENTS
+   bool "Trace critical sections as trace events"
+   select TRACE_IRQFLAGS
+   default n
+
 config SCHED_TRACER
bool "Scheduling Latency Tracer"
select GENERIC_TRACER
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 90f2701d92a7..265135e35b79 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_CONTEXT_SWITCH_TRACER) += trace_sched_switch.o
 obj-$(CONFIG_FUNCTION_TRACER) += trace_functions.o
 obj-$(CONFIG_IRQSOFF_TRACER) += trace_irqsoff.o
 obj-$(CONFIG_PREEMPT_TRACER) += trace_irqsoff.o
+obj-$(CONFIG_CRITICAL_SECTION_EVENTS) += trace_irqsoff.o
 obj-$(CONFIG_SCHED_TRACER) += trace_sched_wakeup.o
 obj-$(CONFIG_HWLAT_TRACER) += trace_hwlat.o
 obj-$(CONFIG_NOP_TRACER) += trace_nop.o
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index edd52ee8b756..7f59f41fbdc0 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -13,9 +13,69 @@
 #include 
 #include 
 #include 
+#define CREATE_TRACE_POINTS
+#include 
 
 #include "trace.h"
 
+#ifdef 

[GIT pull] timer fix for 4.13

[Thomas Gleixner]

Linus,

please pull the latest timers-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
timers-urgent-for-linus

A single fix for a thinko in the raw timekeeper update which causes clock
MONOTONIC_RAW to run with erratically increased frequency.

Thanks,

tglx

-->
John Stultz (1):
  time: Fix ktime_get_raw() incorrect base accumulation


 kernel/time/timekeeping.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index cedafa008de5..7e7e61c00d61 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -637,9 +637,7 @@ static inline void tk_update_ktime_data(struct timekeeper 
*tk)
tk->ktime_sec = seconds;
 
/* Update the monotonic raw base */
-   seconds = tk->raw_sec;
-   nsec = (u32)(tk->tkr_raw.xtime_nsec >> tk->tkr_raw.shift);
-   tk->tkr_raw.base = ns_to_ktime(seconds * NSEC_PER_SEC + nsec);
+   tk->tkr_raw.base = ns_to_ktime(tk->raw_sec * NSEC_PER_SEC);
 }
 
 /* must hold timekeeper_lock */

[PATCH 1/1] drm/amd/powerplay: initialize a variable before using it

[Nicolas Iooss]

Function vega10_apply_state_adjust_rules() only initializes
stable_pstate_sclk_dpm_percentage when
data->registry_data.stable_pstate_sclk_dpm_percentage is not between 1
and 100. The variable is then used to compute stable_pstate_sclk, which
therefore uses an uninitialized value.

Fix this by initializing stable_pstate_sclk_dpm_percentage to
data->registry_data.stable_pstate_sclk_dpm_percentage.

This issue has been found while building the kernel with clang. The
compiler reported a -Wsometimes-uninitialized warning.

Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 197174e562d2..c8d28f78cd47 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3043,6 +3043,8 @@ static int vega10_apply_state_adjust_rules(struct 
pp_hwmgr *hwmgr,
 
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_StablePState)) {
+   stable_pstate_sclk_dpm_percentage =
+   data->registry_data.stable_pstate_sclk_dpm_percentage;
PP_ASSERT_WITH_CODE(
data->registry_data.stable_pstate_sclk_dpm_percentage 
>= 1 &&
data->registry_data.stable_pstate_sclk_dpm_percentage 
<= 100,
-- 
2.14.1

[PATCH 7/10] net/mlx4_core: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c 
b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 041c0ed65929..8eca12927be0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "fw.h"
 #include "icm.h"
@@ -2450,14 +2451,14 @@ int mlx4_config_dev_retrieval(struct mlx4_dev *dev,
csum_mask = (config_dev.rx_checksum_val >> 
CONFIG_DEV_RX_CSUM_MODE_PORT1_BIT_OFFSET) &
CONFIG_DEV_RX_CSUM_MODE_MASK;
 
-   if (csum_mask >= 
sizeof(config_dev_csum_flags)/sizeof(config_dev_csum_flags[0]))
+   if (csum_mask >= ARRAY_SIZE(config_dev_csum_flags))
return -EINVAL;
params->rx_csum_flags_port_1 = config_dev_csum_flags[csum_mask];
 
csum_mask = (config_dev.rx_checksum_val >> 
CONFIG_DEV_RX_CSUM_MODE_PORT2_BIT_OFFSET) &
CONFIG_DEV_RX_CSUM_MODE_MASK;
 
-   if (csum_mask >= 
sizeof(config_dev_csum_flags)/sizeof(config_dev_csum_flags[0]))
+   if (csum_mask >= ARRAY_SIZE(config_dev_csum_flags))
return -EINVAL;
params->rx_csum_flags_port_2 = config_dev_csum_flags[csum_mask];
 
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
b/drivers/net/ethernet/mellanox/mlx4/main.c
index 5fe5cdc51357..fe18650c9342 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -34,6 +34,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3658,7 +3659,7 @@ static int __mlx4_init_one(struct pci_dev *pdev, int 
pci_dev_data,
 * per port, we must limit the number of VFs to 63 (since their are
 * 128 MACs)
 */
-   for (i = 0; i < sizeof(nvfs)/sizeof(nvfs[0]) && i < num_vfs_argc;
+   for (i = 0; i < ARRAY_SIZE(nvfs) && i < num_vfs_argc;
 total_vfs += nvfs[param_map[num_vfs_argc - 1][i]], i++) {
nvfs[param_map[num_vfs_argc - 1][i]] = num_vfs[i];
if (nvfs[i] < 0) {
@@ -3667,7 +3668,7 @@ static int __mlx4_init_one(struct pci_dev *pdev, int 
pci_dev_data,
goto err_disable_pdev;
}
}
-   for (i = 0; i < sizeof(prb_vf)/sizeof(prb_vf[0]) && i < probe_vfs_argc;
+   for (i = 0; i < ARRAY_SIZE(prb_vf) && i < probe_vfs_argc;
 i++) {
prb_vf[param_map[probe_vfs_argc - 1][i]] = probe_vf[i];
if (prb_vf[i] < 0 || prb_vf[i] > nvfs[i]) {
@@ -3746,11 +3747,11 @@ static int __mlx4_init_one(struct pci_dev *pdev, int 
pci_dev_data,
if (total_vfs) {
unsigned vfs_offset = 0;
 
-   for (i = 0; i < sizeof(nvfs)/sizeof(nvfs[0]) &&
+   for (i = 0; i < ARRAY_SIZE(nvfs) &&
 vfs_offset + nvfs[i] < extended_func_num(pdev);
 vfs_offset += nvfs[i], i++)
;
-   if (i == sizeof(nvfs)/sizeof(nvfs[0])) {
+   if (i == ARRAY_SIZE(nvfs)) {
err = -ENODEV;
goto err_release_regions;
}

[PATCH 10/10] staging/atomisp: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/ifmtr/src/ifmtr.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/ifmtr/src/ifmtr.c
index a7c6bba7e094..11d3995ba0db 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/ifmtr/src/ifmtr.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/ifmtr/src/ifmtr.c
@@ -29,6 +29,7 @@ more details.
 #endif
 
 #include "system_global.h"
+#include 
 
 #ifdef USE_INPUT_SYSTEM_VERSION_2
 
@@ -487,7 +488,7 @@ static void ifmtr_set_if_blocking_mode(
 {
int i;
bool block[] = { false, false, false, false };
-   assert(N_INPUT_FORMATTER_ID <= (sizeof(block) / sizeof(block[0])));
+   assert(N_INPUT_FORMATTER_ID <= (ARRAY_SIZE(block)));
 
 #if !defined(IS_ISP_2400_SYSTEM)
 #error "ifmtr_set_if_blocking_mode: ISP_SYSTEM must be one of 
{IS_ISP_2400_SYSTEM}"

[PATCH 8/10] ath9k: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c 
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 3dbfd86ebe36..c2e210c0a770 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include "hw.h"
 #include "ar9003_phy.h"
 #include "ar9003_eeprom.h"
@@ -2946,14 +2947,12 @@ static const struct ar9300_eeprom 
*ar9300_eep_templates[] = {
 
 static const struct ar9300_eeprom *ar9003_eeprom_struct_find_by_id(int id)
 {
-#define N_LOOP (sizeof(ar9300_eep_templates) / sizeof(ar9300_eep_templates[0]))
int it;
 
-   for (it = 0; it < N_LOOP; it++)
+   for (it = 0; it < ARRAY_SIZE(ar9300_eep_templates); it++)
if (ar9300_eep_templates[it]->templateVersion == id)
return ar9300_eep_templates[it];
return NULL;
-#undef N_LOOP
 }
 
 static int ath9k_hw_ar9300_check_eeprom(struct ath_hw *ah)

[PATCH] ASoC: samsung: i2s: Fix error handling path in i2s_set_sysclk()

[Christophe JAILLET]

If 'clk_prepare_enable()' fails, we must 'put' the corresponding clock.
Othewise, there is a resource leak.

Fixes: f5c97c7b0438 ("ASoC: samsung: i2s: Handle return value of 
clk_prepare_enable.")
Signed-off-by: Christophe JAILLET 
---
I'm not 100% confident in this patch.
It is mostly inspired by surrounding error handling. (L533 and L550)
---
 sound/soc/samsung/i2s.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 10a4da06c0a1..d7e7f4244d38 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -552,8 +552,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
}
 
ret = clk_prepare_enable(i2s->op_clk);
-   if (ret)
+   if (ret) {
+   clk_put(i2s->op_clk);
+   i2s->op_clk = NULL;
goto err;
+   }
i2s->rclk_srcrate = clk_get_rate(i2s->op_clk);
 
/* Over-ride the other's */
-- 
2.11.0

[PATCH v4 3/3] platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties

[Hans de Goede]

The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id
rather then just "fusb302" and needs us to set a number of device-
properties, adjust the intel_cht_int33fe driver accordingly.

One of the properties set is max-snk-mv which makes the fusb302 driver
negotiate up to 12V charging voltage, which is a bad idea on boards
which are not setup to handle this, so this commit also adds 2 extra
sanity checks to make sure that the expected Whiskey Cove PMIC +
TI bq24292i charger combo, which can handle 12V, is present.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Set board_info.dev_name
-Adjust for changes in other patches in this patch-set
---
 drivers/platform/x86/Kconfig |  6 -
 drivers/platform/x86/intel_cht_int33fe.c | 44 +++-
 2 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 80b87954f6dd..c5554577681a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -793,7 +793,7 @@ config ACPI_CMPC
 
 config INTEL_CHT_INT33FE
tristate "Intel Cherry Trail ACPI INT33FE Driver"
-   depends on X86 && ACPI && I2C
+   depends on X86 && ACPI && I2C && REGULATOR
---help---
  This driver add support for the INT33FE ACPI device found on
  some Intel Cherry Trail devices.
@@ -804,6 +804,10 @@ config INTEL_CHT_INT33FE
  This driver instantiates i2c-clients for these, so that standard
  i2c drivers for these chips can bind to the them.
 
+ If you enable this driver it is advised to also select
+ CONFIG_CHARGER_BQ24190=m, CONFIG_BATTERY_MAX17042=m and
+ CONFIG_TYPEC_FUSB302=m (currently in drivers/staging).
+
 config INTEL_INT0002_VGPIO
tristate "Intel ACPI INT0002 Virtual GPIO driver"
depends on GPIOLIB && ACPI
diff --git a/drivers/platform/x86/intel_cht_int33fe.c 
b/drivers/platform/x86/intel_cht_int33fe.c
index a9cbc4b8ca63..b2925d996613 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define EXPECTED_PTYPE 4
@@ -77,12 +78,21 @@ static const struct property_entry max17047_props[] = {
{ }
 };
 
+static const struct property_entry fusb302_props[] = {
+   PROPERTY_ENTRY_STRING("fcs,extcon-name", "cht_wcove_pwrsrc"),
+   PROPERTY_ENTRY_U32("fcs,max-sink-microvolt", 1200),
+   PROPERTY_ENTRY_U32("fcs,max-sink-microamp",   300),
+   PROPERTY_ENTRY_U32("fcs,max-sink-microwatt", 3600),
+   { }
+};
+
 static int cht_int33fe_probe(struct i2c_client *client)
 {
struct device *dev = >dev;
struct i2c_board_info board_info;
struct cht_int33fe_data *data;
struct i2c_client *max17047;
+   struct regulator *regulator;
unsigned long long ptyp;
acpi_status status;
int ret, fusb302_irq;
@@ -100,6 +110,34 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (ptyp != EXPECTED_PTYPE)
return -ENODEV;
 
+   /* Check presence of INT34D3 (hardware-rev 3) expected for ptype == 4 */
+   if (!acpi_dev_present("INT34D3", "1", 3)) {
+   dev_err(dev, "Error PTYPE == %d, but no INT34D3 device\n",
+   EXPECTED_PTYPE);
+   return -ENODEV;
+   }
+
+   /*
+* We expect the WC PMIC to be paired with a TI bq24292i charger-IC.
+* We check for the bq24292i vbus regulator here, this has 2 purposes:
+* 1) The bq24292i allows charging with up to 12V, setting the fusb302's
+*max-snk voltage to 12V with another charger-IC is not good.
+* 2) For the fusb302 driver to get the bq24292i vbus regulator, the
+*regulator-map, which is part of the bq24292i regulator_init_data,
+*must be registered before the fusb302 is instantiated, otherwise
+*it will end up with a dummy-regulator.
+* Note "cht_wc_usb_typec_vbus" comes from the regulator_init_data
+* which is defined in i2c-cht-wc.c from where the bq24292i i2c-client
+* gets instantiated. We use regulator_get_optional here so that we
+* don't end up getting a dummy-regulator ourselves.
+*/
+   regulator = regulator_get_optional(dev, "cht_wc_usb_typec_vbus");
+   if (IS_ERR(regulator)) {
+   ret = PTR_ERR(regulator);
+   return (ret == -ENODEV) ? -EPROBE_DEFER : ret;
+   }
+   regulator_put(regulator);
+
/* The FUSB302 uses the irq at index 1 and is the only irq user */
fusb302_irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 1);
if (fusb302_irq < 0) {
@@ -126,6 +164,7 @@ static int cht_int33fe_probe(struct i2c_client *client)
} else {
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, 

[PATCH v4 2/3] i2c-cht-wc: Add device-properties for fusb302 integration

[Hans de Goede]

Add device-properties to make the bq24292i charger connected to
the bus get its input-current-limit from the fusb302 Type-C port
controller which is used on boards with the cht-wc PMIC,
as well as regulator_init_data for the 5V boost converter on
the bq24292i.

Since this means we now hook-up the bq24292i to the fusb302 Type-C port
controller add a check for the ACPI device which instantiates the fusb302.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Set board_info.dev_name
-Define and pass regulator_init_data for the bq24292i
-Add a check for the ACPI device which instantiates the fusb302
Changes in v4:
-Drop the ti,input-current-limit-from-supplier property on the bq24292i
 this is the default now
---
 drivers/i2c/busses/Kconfig  |  5 
 drivers/i2c/busses/i2c-cht-wc.c | 51 +++--
 2 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 79c33817e412..272ef10fb629 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -197,6 +197,11 @@ config I2C_CHT_WC
  SMBus controller found in the Intel Cherry Trail Whiskey Cove PMIC
  found on some Intel Cherry Trail systems.
 
+ Note this controller is hooked up to a TI bq24292i charger-IC,
+ combined with a FUSB302 Type-C port-controller as such it is advised
+ to also select CONFIG_CHARGER_BQ24190=m and CONFIG_TYPEC_FUSB302=m
+ (the fusb302 driver currently is in drivers/staging).
+
 config I2C_NFORCE2
tristate "Nvidia nForce2, nForce3 and nForce4"
depends on PCI
diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
index 21312eed09e4..82e331db8d98 100644
--- a/drivers/i2c/busses/i2c-cht-wc.c
+++ b/drivers/i2c/busses/i2c-cht-wc.c
@@ -16,6 +16,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define CHT_WC_I2C_CTRL0x5e24
@@ -232,13 +234,35 @@ static const struct irq_chip cht_wc_i2c_irq_chip = {
.name   = "cht_wc_ext_chrg_irq_chip",
 };
 
+static const char * const bq24190_suppliers[] = { "fusb302-typec-source" };
+
 static const struct property_entry bq24190_props[] = {
-   PROPERTY_ENTRY_STRING("extcon-name", "cht_wcove_pwrsrc"),
+   PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq24190_suppliers),
PROPERTY_ENTRY_BOOL("omit-battery-class"),
PROPERTY_ENTRY_BOOL("disable-reset"),
{ }
 };
 
+static struct regulator_consumer_supply fusb302_consumer = {
+   .supply = "vbus",
+   /* Must match fusb302 dev_name in intel_cht_int33fe.c */
+   .dev_name = "i2c-fusb302",
+};
+
+static const struct regulator_init_data bq24190_vbus_init_data = {
+   .constraints = {
+   /* The name is used in intel_cht_int33fe.c do not change. */
+   .name = "cht_wc_usb_typec_vbus",
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+   .consumer_supplies = _consumer,
+   .num_consumer_supplies = 1,
+};
+
+static struct bq24190_platform_data bq24190_pdata = {
+   .regulator_init_data = _vbus_init_data,
+};
+
 static int cht_wc_i2c_adap_i2c_probe(struct platform_device *pdev)
 {
struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
@@ -246,7 +270,9 @@ static int cht_wc_i2c_adap_i2c_probe(struct platform_device 
*pdev)
struct i2c_board_info board_info = {
.type = "bq24190",
.addr = 0x6b,
+   .dev_name = "bq24190",
.properties = bq24190_props,
+   .platform_data = _pdata,
};
int ret, reg, irq;
 
@@ -314,11 +340,21 @@ static int cht_wc_i2c_adap_i2c_probe(struct 
platform_device *pdev)
if (ret)
goto remove_irq_domain;
 
-   board_info.irq = adap->client_irq;
-   adap->client = i2c_new_device(>adapter, _info);
-   if (!adap->client) {
-   ret = -ENOMEM;
-   goto del_adapter;
+   /*
+* Normally the Whiskey Cove PMIC is paired with a TI bq24292i charger,
+* connected to this i2c bus, and a max17047 fuel-gauge and a fusb302
+* USB Type-C controller connected to another i2c bus. In this setup
+* the max17047 and fusb302 devices are enumerated through an INT33FE
+* ACPI device. If this device is present register an i2c-client for
+* the TI bq24292i charger.
+*/
+   if (acpi_dev_present("INT33FE", NULL, -1)) {
+   board_info.irq = adap->client_irq;
+   adap->client = i2c_new_device(>adapter, _info);
+   if (!adap->client) {
+   ret = -ENOMEM;
+   goto del_adapter;
+   }
}
 
platform_set_drvdata(pdev, adap);
@@ -335,7 +371,8 @@ static int 

[PATCH v4 0/3] i2c: Hookup typec power-negotation to the PMIC and charger

[Hans de Goede]

Hi Wolfram,

Almost all patches from my patch series for hooking up typec
power-negotation to the PMIC and charger drivers have been
queued for merging into 4.14, leaving only the 3 patches of
the v4 of this series.

The first 2 patches are i2c patches, if you could review and
merge these (preferably for 4.14, but 4.15 is fine too) that would
be great.

Darren, Andy, the single platform/x86 patch in here should only
be merged after the 2 i2c patches are in place, otherwise users
of the board(s) in question will end up not having any battery
monitoring. Also note that this patch applies on top of the
"[PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some 
devices"
patch I send out yesterday.

Regards,

Hans

[PATCH v4 1/3] i2c: Allow overriding dev_name through board_info

[Hans de Goede]

For devices not instantiated through ACPI the i2c-client's device-name
gets set to - by default, e.g. "0-0022" this means that
the device-name is dependent on the order in which the i2c-busses are
enumerated.

In some cases having a predictable constant device-name is desirable,
for example on non device-tree platforms the link between a regulator
and its consumers is specified by the platform code by setting
regulator_init_data.consumers. This array identifies the regulator's
consumers by dev_name and supply(-name). Which requires a constant
dev_name.

This commit adds a dev_name field to i2c_board_info allowing
platform code to set a contstant dev_name so that the device can
be identified by its dev_name in other platform code.

Signed-off-by: Hans de Goede 
---
 drivers/i2c/i2c-core-base.c | 10 --
 include/linux/i2c.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 45fafcc88b93..5cdf3b947c23 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -672,10 +672,16 @@ static void i2c_adapter_unlock_bus(struct i2c_adapter 
*adapter,
 }
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
-struct i2c_client *client)
+struct i2c_client *client,
+struct i2c_board_info const *info)
 {
struct acpi_device *adev = ACPI_COMPANION(>dev);
 
+   if (info && info->dev_name) {
+   dev_set_name(>dev, "i2c-%s", info->dev_name);
+   return;
+   }
+
if (adev) {
dev_set_name(>dev, "i2c-%s", acpi_dev_name(adev));
return;
@@ -772,7 +778,7 @@ i2c_new_device(struct i2c_adapter *adap, struct 
i2c_board_info const *info)
client->dev.of_node = info->of_node;
client->dev.fwnode = info->fwnode;
 
-   i2c_dev_set_name(adap, client);
+   i2c_dev_set_name(adap, client, info);
 
if (info->properties) {
status = device_add_properties(>dev, info->properties);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 701ad26fa6b4..d3655cfe9a3e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -310,6 +310,7 @@ static inline bool i2c_detect_slave_mode(struct device 
*dev) { return false; }
  * @type: chip type, to initialize i2c_client.name
  * @flags: to initialize i2c_client.flags
  * @addr: stored in i2c_client.addr
+ * @dev_name: Overrides the default - dev_name if set
  * @platform_data: stored in i2c_client.dev.platform_data
  * @archdata: copied into i2c_client.dev.archdata
  * @of_node: pointer to OpenFirmware device node
@@ -334,6 +335,7 @@ struct i2c_board_info {
chartype[I2C_NAME_SIZE];
unsigned short  flags;
unsigned short  addr;
+   const char  *dev_name;
void*platform_data;
struct dev_archdata *archdata;
struct device_node *of_node;
-- 
2.13.4

Re: [PATCH] iio: imu: inv_mpu6050: fix missing break in switch

[Jonathan Cameron]

On Wed, 23 Aug 2017 08:41:43 +0200 (CEST)
Peter Meerwald-Stadler  wrote:

> > Add missing break statement to prevent the code for case
> > IIO_CHAN_INFO_CALIBBIAS falling through to the default case.
> > 
> > Also, add a break to the default case for the switch within
> > case IIO_CHAN_INFO_CALIBBIAS.  
> 
> fix seems to be cosmetic only...
> 
> > Addresses-Coverity-ID: 1357377
> > Signed-off-by: Gustavo A. R. Silva 
Indeed only cosmetic, but if it makes static analysis more productive
by removing a trivial case, it is worth having.

Applied to the togreg branch of iio.git - will be pushed out as testing
just as soon as I catch up with my backlog.

Jonathan

> > ---
> > This issue was reported by Coverity and it was tested by compilation only.
> > Please, verify if this is an actual bug.
> > 
> >  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c 
> > b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > index 44830bc..6d2268a 100644
> > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > @@ -542,7 +542,9 @@ static int inv_mpu6050_write_raw(struct iio_dev 
> > *indio_dev,
> > break;
> > default:
> > result = -EINVAL;
> > +   break;
> > }
> > +   break;
> > default:
> > result = -EINVAL;
> > break;
> >   
> 

Re: [PATCH] ALSA: hda: Fix resource leak issue in snd_hda_codec_build_controls and snd_hda_codec_parse_pcms

[Takashi Iwai]

On Sun, 03 Sep 2017 18:10:53 +0200,
Wang YanQing wrote:
> 
> On Sun, Sep 03, 2017 at 11:27:31PM +0800, Wang YanQing wrote:
> > When patch_ops.init, patch_ops.build_pcms and patch_ops.build_controls
> > return failure, we need to free resource with patch_ops.free, or we will
> > get resource leak.
> > 
> > Signed-off-by: Wang YanQing 
> > ---
> >  sound/pci/hda/hda_codec.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> > index df6b57e..4e3e613 100644
> > --- a/sound/pci/hda/hda_codec.c
> > +++ b/sound/pci/hda/hda_codec.c
> > @@ -2973,8 +2973,11 @@ int snd_hda_codec_build_controls(struct hda_codec 
> > *codec)
> > err = codec->patch_ops.init(codec);
> > if (!err && codec->patch_ops.build_controls)
> > err = codec->patch_ops.build_controls(codec);
> > -   if (err < 0)
> > +   if (err < 0) {
> > +   if (codec->patch_ops.free)
> > +   codec->patch_ops.free(codec);
> > return err;
> > +   }
> >  
> > /* we create chmaps here instead of build_pcms */
> > err = add_std_chmaps(codec);
> > @@ -3170,6 +3173,8 @@ int snd_hda_codec_parse_pcms(struct hda_codec *codec)
> > if (err < 0) {
> > codec_err(codec, "cannot build PCMs for #%d (error %d)\n",
> >   codec->core.addr, err);
> > +   if (codec->patch_ops.free)
> > +   codec->patch_ops.free(codec);
> > return err;
> > }
> >  
> > -- 
> > 1.8.5.6.2.g3d8a54e.dirty
> 
> I don't know whether this new patch is ok for you, but I think that
> we could allocate resources in patch_ops.init, patch_ops.build_pcms
> and patch_ops.build_controls separately, so I think it isn't flexible
> and elegant to free all resources in all the error path cases in them
> separately, so maybe it is better to use patch_ops.free as the unique
> point to release all resource.

In that case, it'll be easier to do that in hda_bind.c as your first
patch, but skip the free for patch() call; i.e. something like below.
The point is that the codec probe function does already care about the
free at its error path, while others don't do generically.

Or, for safety, we may put an internal flag to indicate that the codec
free got already called, and check it at before calling
patch_ops.free, too.


thanks,

Takashi

---
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index 6efadbfb3fe3..d361bb77ca00 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -100,7 +100,7 @@ static int hda_codec_driver_probe(struct device *dev)
if (patch) {
err = patch(codec);
if (err < 0)
-   goto error_module;
+   goto error_module_put;
}
 
err = snd_hda_codec_build_pcms(codec);
@@ -120,6 +120,9 @@ static int hda_codec_driver_probe(struct device *dev)
return 0;
 
  error_module:
+   if (codec->patch_ops.free)
+   codec->patch_ops.free(codec);
+ error_module_put:
module_put(owner);
 
  error:

Re: Linux 4.13: Reported regressions as of Sunday, 2017-09-03

[Linus Torvalds]

On Sun, Sep 3, 2017 at 2:36 AM, Thorsten Leemhuis
 wrote:
>
> [x86/mm/gup] e585513b76: will-it-scale.per_thread_ops -6.9% regression
> Status: Asked on the list, but looks like issue gets ignored by everyone
> Note: I'm a bit unsure if adding this issue to this list was a good
> idea. Side note: Was reported against linux-next in May already
> Reported: 2017-07-10
> http://lkml.kernel.org/r/20170710024020.GA26389@yexl-desktop
> Cause: https://git.kernel.org/torvalds/c/e585513b76f7

Sadly, while I love the concept of performance tracking, the
"will-it-scale" reports haven't really been reliable enough to really
be useful. There is a _ton_ of noise in the numbers, and the
test-cases don't seem to be stable enough to really track sanely.

I wish it was otherwise, because we also got a report of "57.3%
improvement of will-it-scale.per_process_ops" this release.

So I find the kernel test robot performance tracking very interesting
in theory, but as things stand now I think it's just that:
"interesting". Not quite ready for action.

 Linus

Re: [PATCH 0/3] iio: Introduce the generic counter interface

[Jonathan Cameron]

On Mon, 28 Aug 2017 10:16:33 -0400
William Breathitt Gray  wrote:

> On Sun, Aug 20, 2017 at 01:00:16PM +0100, Jonathan Cameron wrote:
> >On Mon, 31 Jul 2017 12:02:45 -0400
> >William Breathitt Gray  wrote:
> >  
> >> Summary
> >> ===  
> >
> >I'd like to see some of this brought out as proper documentation files
> >in future sets.  In particular the sysfs interface needs full docs.  
> 
> I'll write up some proper documentation for the interface and
> implementation for version 2 of this patchset; it should help elucidate
> some of the concepts here a bit better.
> 
> >> 
> >> Counter devices are prevalent within a diverse spectrum of industries.
> >> The ubiquitous presence of these devices necessitates a common interface
> >> and standard of interaction and exposure. This patchset attempts to
> >> resolve the issue of duplicate code found among existing counter device
> >> drivers by introducing a generic counter interface for consumption. The
> >> generic counter interface enables drivers to support and expose a common
> >> set of components and functionality present in counter devices.
> >> 
> >> Theory
> >> ==
> >> 
> >> Counter devices can vary greatly in design, but regardless of whether
> >> some devices are quadrature encoder counters or pedometers, all counter
> >> devices consist of a core set of components. This core set of
> >> components, shared by all counter devices, is what forms the essence of
> >> the generic counter interface.
> >> 
> >> There are three core components to a counter:
> >> 
> >> VALUE
> >> -
> >> A Value represents the count data for a set of Signals. A Value
> >> has a count function mode (e.g. "increment" or "quadrature x4")
> >> which respresents the update behavior for the count data. A
> >> Value also has a set of one or more associated Signals.
> >> 
> >> SIGNAL
> >> --
> >> A Signal represents a count input line. A Signal may be
> >>associated to one or more Values.
> >> 
> >> TRIGGER
> >>---
> >> A Trigger represents a Value's count function trigger condition
> >> mode (e.g. "rising edge" or "double pulse") for an associated
> >> Signal.If a Signal is associated with a Value, a respective
> >> Triggerinstance for that association exists -- albeit perhaps
> >> with a trigger condition mode of "none."
> >> 
> >> A counter is defined as a set of input signals associated to count data
> >> that are generated by the evaluation of the state of the associated
> >> input signals as defined by the respective count functions. Within the
> >> context of the generic counter interface, a counter consists of Values
> >> each associated to a set of Signals, whose respective Trigger instances
> >> represent the count function update conditions for the associated
> >> Values.
> >> 
> >> Implementation
> >> ==
> >> 
> >> The IIO generic counter interface piggybacks off of the IIO core. This
> >> is primarily used to leverage the existing sysfs setup: the IIO_COUNT
> >> channel attributes represent the "counter value," while the IIO_SIGNAL
> >> channel attributes represent the "counter signal;" auxilary IIO_COUNT
> >> attributes represent the "counter signal" connections and their
> >> respective state change configurations which trigger an associated
> >> "counter function" evaluation.
> >> 
> >> The iio_counter_ops structure serves as a container for driver callbacks
> >> to communicate with the device; function callbacks are provided to read
> >> and write various "counter signals" and "counter values," and set and
> >> get the "trigger mode" and "function mode" for various "counter signals"
> >> and "counter values" respectively.
> >> 
> >> To support a counter device, a driver must first allocate the available
> >> "counter signals" via iio_counter_signal structures. These "counter
> >> signals" should be stored as an array and set to the init_signals member
> >> of an allocated iio_counter structure before the counter is registered.
> >> 
> >> "Counter values" may be allocated via iio_counter_value structures, and
> >> respective "counter signal" associations made via iio_counter_trigger
> >> structures. Initial associated iio_counter_trigger structures may be
> >> stored as an array and set to the the init_triggers member of the
> >> respective iio_counter_value structure. These iio_counter_value
> >> structures may be set to the init_values member of an allocated
> >> iio_counter structure before the counter is registered if so desired.
> >> 
> >> A counter device is registered to the system by passing the respective
> >> initialized iio_counter structure to the iio_counter_register function;
> >> similarly, the iio_counter_unregister function unregisters the
> >> respective counter.
> >> 
> >> Userspace Interface
> >> ===
> >> 
> >> Several 

Re: [PATCH 3/3] iio: 104-quad-8: Add IIO generic counter interface support

[Jonathan Cameron]

On Mon, 28 Aug 2017 12:23:45 -0400
William Breathitt Gray  wrote:

> On Sun, Aug 20, 2017 at 01:11:18PM +0100, Jonathan Cameron wrote:
> >On Mon, 31 Jul 2017 12:03:46 -0400
> >William Breathitt Gray  wrote:
> >  
> >> This patch adds support for the IIO generic counter interface to the
> >> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not
> >> be affected by this patch; all changes are intended as supplemental
> >> additions as perceived by the user.
> >> 
> >> IIO Counter Signals are defined for all quadrature input pairs
> >> (A and B), as well as index input lines. However, IIO Counter Triggers
> >> are not created for the index input Signals. IIO Counter Values are
> >> created for the eight quadrature channel counts, and their respective
> >> Signals are associated via IIO Counter Triggers.
> >> 
> >> The new generic counter interface sysfs attributes expose the same
> >> functionality and data available via the existing 104-QUAD-8 device
> >> interface. Four IIO Counter Value function modes are available,
> >> correlating to the four possible quadrature mode configurations:
> >> "non-quadrature," "quadrature x1," "quadrature x2," and "quadrature x4."
> >> 
> >> A quad8_remove function is defined to call iio_counter_unregister. This
> >> function can be eliminated once a devm_iio_counter_register function is
> >> defined.
> >> 
> >> Signed-off-by: William Breathitt Gray   
> >
> >A good example.
> >
> >I think it does make it clear that we need to be very careful on how much of
> >the interface is defined by freeform strings.  Even if we export other means
> >of establishing the associations to userspace, the moment there are strings
> >available giving them names, software will start to use those.
> >
> >May be fine but we need to be very careful.  
> 
> I would like to limit the amount of strings as well; the availability of
> freeform strings has an unfortunate tendency to create situations where
> different drivers form separate conventions for duplicate functionality.

Absolutely.

> 
> The reason freeform strings are available for the generic counter
> interface is to provide the flexibility to support more complex classes
> of counters. More specific counter class interfaces such as the future
> quadrature counter interface will likely expose predefined constants
> rather than allow drivers to create their own strings. In general
> though, I believe your warning is a good word of caution and I'll keep
> an eye on reducing the amount of freeform strings we allow.

OK. That could work fine - we enforce the usage by review rather than
code.
> 
> In truth, while this is a good example of how a driver would utilize the
> generic counter interface with real hardware, it's not a perfect case
> for quadrature counters in general. As you noticed, the dynamic aspects
> of the generic counter interface are not needed by the 104-QUAD-8. The
> future quadrature counter interface would be more fitting for the
> 104-QUAD-8.
> 
> In addition, I may provide a dummy software counter driver in version 2
> of this patchset to showcase and exemplify the functionality of the
> generic counter interface more directly and aptly.

That could be very useful.  An alternative would be to look at a simple
device (if we can find one) and implement a userspace fake for it
(similar to what Guenter has done with lots of hwmon devices).

That way we can play with a real driver against fake hardware and get
the best of all possible worlds.  I've been meaning to look at doing this
for various IIO drivers for a while (most complete for i2c devices I think).

As you might imagine I don't actually have that many parts (and most of them
aren't connected to boards at any given time) so any form of emulation can be
very helpful.

I'll see if I can dig up any interesting devices beyond the ones we
already know are integrated in various SoCs.

I think we really need say 2+ devices to justify decisions in the
core code. I did the original IIO version against 3ish devices but
that was more varied (and that wasn't nearly enough with hindsight!)

Jonathan

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

[Thomas Gleixner]

On Fri, 1 Sep 2017, Chen Yu wrote:

> This is the major logic to spread the vectors on different CPUs.
> The main idea is to choose the 'idlest' CPU which has assigned
> the least number of vectors as the candidate/hint for the vector
> allocation domain, in the hope that the vector allocation domain
> could leverage this hint to generate corresponding cpumask.
> 
> One of the requirements to do this vector spreading work comes from the
> following hibernation problem found on a 16 cores server:
> 
> CPU 31 disable failed: CPU has 62 vectors assigned and there
> are only 0 available.
> 
> 2 issues were found after investigation:
> 
> 1. The network driver has declared many vector resources via
>pci_enable_msix_range(), say, this driver might likely want
>to reserve 6 per logical CPU, then there would be 192 of them.
> 2. Besides, most of the vectors reserved by this driver are assigned
>on CPU0 due to the current code strategy, so there would be
>insufficient slots left on CPU0 to receive any migrated IRQs
>during CPU offine.
> 
> In theory after the commit c5cb83bb337c ("genirq/cpuhotplug: Handle
> managed IRQs on CPU hotplug") the issue 1 has been solved with the
> managed interrupt mechanism for multi queue devices, which no longer
> migrate these interrupts. It simply shuts them down and restarts
> them when the CPU comes back online.
> 
> However, according to the implementation of this network driver,
> the commit mentioned above does not fully fix the issue 1.
> Here's the framework of the network driver:
> 
> step 1. Reserved enough irq vectors and corresponding IRQs.
> step 2. If the network is activated, invoke request_irq() to
> register the handler.
> step 3. Invoke set_affinity() to spread the IRQs onto different
> CPUs, thus to spread the vectors too.
>
> The problem is, if the network cable is not connected, step 2
> and 3 will not get invoked, thus the IRQ vectors will not spread
> on different CPUs and will still be allocated on CPU0. As a result
> the CPUs will still get the offline failure.

So the proper solution for this network driver is to switch to managed
interrupts instead of trying to work around it in some other place. It's
using the wrong mechanism - end of story.

Why are you insisting on implementing a band aid for this particular driver
instead of fixing the underlying problem of that driver which requires to
have 32 queues and interrupts open even if only a single CPU is online?

> Previously there were some discussion in the thread [1] about the
> vector spread, and here are the suggestion from Thomas:
> 
> Q1:
> Rewrite that allocation code from scratch, use per cpu bitmaps,
> so we can do fast search over masks and keep track of
> the vectors which are used/free per cpu.
> A1:
> per cpu bitmap was onced considered but this might not be
> as fast as the solution proposed here. That is, if we introduce the
> per cpu bitmap, we need to count the number of vectors assigned on
> each CPUs by cpumask_weight() and sort them in order to get the
> CPUs who have the least number of vectors assigned. By contrast,
> if we introduce the bitmaps for each vector number, we can get the
> 'idle' CPU at the cost of nearly O(1).

The weight accounting with the cpumasks is an orthogonal issue to the per
cpu vector bitmaps.

Once you selected a CPU the current code still loops in circles instead of
just searching a bitmap.

And if the required affinity mask needs more than one CPU then this is
still not giving you the right answer. You assign perhaps a vector to the
least busy CPU, but the other CPUs which happen to be in the mask are going
to be randomly selected.

I'm not against making the vector allocation better, but certainly not by
adding yet more duct tape to something which is well known as one of the
dumbest search algorithms on the planet with a worst case of

   nvectors * nr_online_cpus * nr_online_cpus_in_affinity_mask

and your mechanism nests another loop of potentially NR_VECTORS into
that. Which is pointless as the actual assignable vector space is
smaller. While x86 has 256 vectors the assignable vector space is way
smaller and non continous:

Vectors   0- 31 are reserved for CPU traps and exceptions
Vectors 239-255 are reserved by the kernel for IPIs, local timer etc.
Vector   32 can be reserved by the kernel for the reboot interrupt
Vector   96 can be reserved by the kernel for INT80

So the actually usable array size is between 205 and 207.

Aside of that the code is incorrect vs. the percpu accounting. Remove the
limit in the update function and see what happens. While the limit is
necessary in general, it should at least warn and yell whenever the
accounting goes out of bounds. And if that happens, then the whole thing is
completely useless simply because the numbers are just wrong.

> One scenario of this patch can be illustrated below:
> 
> a) After initialization, 

[PATCH RFC v3 3/4] samples/bpf: Fix pt_regs issues when cross-compiling

[Joel Fernandes]

BPF samples fail to build when cross-compiling for ARM64 because of incorrect
pt_regs param selection. This is because clang defines __x86_64__ and
bpf_headers thinks we're building for x86. Since clang is building for the BPF
target, it shouldn't make assumptions about what target the BPF program is
going to run on. To fix this, lets pass ARCH so the header knows which target
the BPF program is being compiled for and can use the correct pt_regs code.

CC: Alexei Starovoitov 
CC: Daniel Borkmann 
Cc: David Miller 
Signed-off-by: Joel Fernandes 
---
 samples/bpf/Makefile  |  2 +-
 tools/testing/selftests/bpf/bpf_helpers.h | 56 +++
 2 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 13f74b67ca44..ebc2ad69b62c 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -230,7 +230,7 @@ $(obj)/%.o: $(src)/%.c
$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
-I$(srctree)/tools/testing/selftests/bpf/ \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value 
-Wno-pointer-sign \
-   -Wno-compare-distinct-pointer-types \
+   -D__TARGET_ARCH_$(ARCH) -Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
diff --git a/tools/testing/selftests/bpf/bpf_helpers.h 
b/tools/testing/selftests/bpf/bpf_helpers.h
index 36fb9161b34a..4875395b0b52 100644
--- a/tools/testing/selftests/bpf/bpf_helpers.h
+++ b/tools/testing/selftests/bpf/bpf_helpers.h
@@ -109,7 +109,47 @@ static int (*bpf_skb_under_cgroup)(void *ctx, void *map, 
int index) =
 static int (*bpf_skb_change_head)(void *, int len, int flags) =
(void *) BPF_FUNC_skb_change_head;
 
+/* Scan the ARCH passed in from ARCH env variable (see Makefile) */
+#if defined(__TARGET_ARCH_x86)
+   #define bpf_target_x86
+   #define bpf_target_defined
+#elif defined(__TARGET_ARCH_s930x)
+   #define bpf_target_s930x
+   #define bpf_target_defined
+#elif defined(__TARGET_ARCH_arm64)
+   #define bpf_target_arm64
+   #define bpf_target_defined
+#elif defined(__TARGET_ARCH_mips)
+   #define bpf_target_mips
+   #define bpf_target_defined
+#elif defined(__TARGET_ARCH_powerpc)
+   #define bpf_target_powerpc
+   #define bpf_target_defined
+#elif defined(__TARGET_ARCH_sparc)
+   #define bpf_target_sparc
+   #define bpf_target_defined
+#else
+   #undef bpf_target_defined
+#endif
+
+/* Fall back to what the compiler says */
+#ifndef bpf_target_defined
 #if defined(__x86_64__)
+   #define bpf_target_x86
+#elif defined(__s390x__)
+   #define bpf_target_s930x
+#elif defined(__aarch64__)
+   #define bpf_target_arm64
+#elif defined(__mips__)
+   #define bpf_target_mips
+#elif defined(__powerpc__)
+   #define bpf_target_powerpc
+#elif defined(__sparc__)
+   #define bpf_target_sparc
+#endif
+#endif
+
+#if defined(bpf_target_x86)
 
 #define PT_REGS_PARM1(x) ((x)->di)
 #define PT_REGS_PARM2(x) ((x)->si)
@@ -122,7 +162,7 @@ static int (*bpf_skb_change_head)(void *, int len, int 
flags) =
 #define PT_REGS_SP(x) ((x)->sp)
 #define PT_REGS_IP(x) ((x)->ip)
 
-#elif defined(__s390x__)
+#elif defined(bpf_target_s390x)
 
 #define PT_REGS_PARM1(x) ((x)->gprs[2])
 #define PT_REGS_PARM2(x) ((x)->gprs[3])
@@ -135,7 +175,7 @@ static int (*bpf_skb_change_head)(void *, int len, int 
flags) =
 #define PT_REGS_SP(x) ((x)->gprs[15])
 #define PT_REGS_IP(x) ((x)->psw.addr)
 
-#elif defined(__aarch64__)
+#elif defined(bpf_target_arm64)
 
 #define PT_REGS_PARM1(x) ((x)->regs[0])
 #define PT_REGS_PARM2(x) ((x)->regs[1])
@@ -148,7 +188,7 @@ static int (*bpf_skb_change_head)(void *, int len, int 
flags) =
 #define PT_REGS_SP(x) ((x)->sp)
 #define PT_REGS_IP(x) ((x)->pc)
 
-#elif defined(__mips__)
+#elif defined(bpf_target_mips)
 
 #define PT_REGS_PARM1(x) ((x)->regs[4])
 #define PT_REGS_PARM2(x) ((x)->regs[5])
@@ -161,7 +201,7 @@ static int (*bpf_skb_change_head)(void *, int len, int 
flags) =
 #define PT_REGS_SP(x) ((x)->regs[29])
 #define PT_REGS_IP(x) ((x)->cp0_epc)
 
-#elif defined(__powerpc__)
+#elif defined(bpf_target_powerpc)
 
 #define PT_REGS_PARM1(x) ((x)->gpr[3])
 #define PT_REGS_PARM2(x) ((x)->gpr[4])
@@ -172,7 +212,7 @@ static int (*bpf_skb_change_head)(void *, int len, int 
flags) =
 #define PT_REGS_SP(x) ((x)->sp)
 #define PT_REGS_IP(x) ((x)->nip)
 
-#elif defined(__sparc__)
+#elif defined(bpf_target_sparc)
 
 #define PT_REGS_PARM1(x) ((x)->u_regs[UREG_I0])
 #define PT_REGS_PARM2(x) ((x)->u_regs[UREG_I1])
@@ -182,6 +222,8 @@ static int (*bpf_skb_change_head)(void *, int len, int 
flags) =
 #define PT_REGS_RET(x) ((x)->u_regs[UREG_I7])
 #define PT_REGS_RC(x) ((x)->u_regs[UREG_I0])
 #define PT_REGS_SP(x) 

Re: [PATCH 3/3] iio: 104-quad-8: Add IIO generic counter interface support

[Jonathan Cameron]

On Sun, 3 Sep 2017 18:50:01 +0100
Jonathan Cameron  wrote:

> On Mon, 28 Aug 2017 12:23:45 -0400
> William Breathitt Gray  wrote:
> 
> > On Sun, Aug 20, 2017 at 01:11:18PM +0100, Jonathan Cameron wrote:  
> > >On Mon, 31 Jul 2017 12:03:46 -0400
> > >William Breathitt Gray  wrote:
> > >
> > >> This patch adds support for the IIO generic counter interface to the
> > >> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not
> > >> be affected by this patch; all changes are intended as supplemental
> > >> additions as perceived by the user.
> > >> 
> > >> IIO Counter Signals are defined for all quadrature input pairs
> > >> (A and B), as well as index input lines. However, IIO Counter Triggers
> > >> are not created for the index input Signals. IIO Counter Values are
> > >> created for the eight quadrature channel counts, and their respective
> > >> Signals are associated via IIO Counter Triggers.
> > >> 
> > >> The new generic counter interface sysfs attributes expose the same
> > >> functionality and data available via the existing 104-QUAD-8 device
> > >> interface. Four IIO Counter Value function modes are available,
> > >> correlating to the four possible quadrature mode configurations:
> > >> "non-quadrature," "quadrature x1," "quadrature x2," and "quadrature x4."
> > >> 
> > >> A quad8_remove function is defined to call iio_counter_unregister. This
> > >> function can be eliminated once a devm_iio_counter_register function is
> > >> defined.
> > >> 
> > >> Signed-off-by: William Breathitt Gray 
> > >
> > >A good example.
> > >
> > >I think it does make it clear that we need to be very careful on how much 
> > >of
> > >the interface is defined by freeform strings.  Even if we export other 
> > >means
> > >of establishing the associations to userspace, the moment there are strings
> > >available giving them names, software will start to use those.
> > >
> > >May be fine but we need to be very careful.
> > 
> > I would like to limit the amount of strings as well; the availability of
> > freeform strings has an unfortunate tendency to create situations where
> > different drivers form separate conventions for duplicate functionality.  
> 
> Absolutely.
> 
> > 
> > The reason freeform strings are available for the generic counter
> > interface is to provide the flexibility to support more complex classes
> > of counters. More specific counter class interfaces such as the future
> > quadrature counter interface will likely expose predefined constants
> > rather than allow drivers to create their own strings. In general
> > though, I believe your warning is a good word of caution and I'll keep
> > an eye on reducing the amount of freeform strings we allow.  
> 
> OK. That could work fine - we enforce the usage by review rather than
> code.
> > 
> > In truth, while this is a good example of how a driver would utilize the
> > generic counter interface with real hardware, it's not a perfect case
> > for quadrature counters in general. As you noticed, the dynamic aspects
> > of the generic counter interface are not needed by the 104-QUAD-8. The
> > future quadrature counter interface would be more fitting for the
> > 104-QUAD-8.
> > 
> > In addition, I may provide a dummy software counter driver in version 2
> > of this patchset to showcase and exemplify the functionality of the
> > generic counter interface more directly and aptly.  
> 
> That could be very useful.  An alternative would be to look at a simple
> device (if we can find one) and implement a userspace fake for it
> (similar to what Guenter has done with lots of hwmon devices).
> 
> That way we can play with a real driver against fake hardware and get
> the best of all possible worlds.  I've been meaning to look at doing this
> for various IIO drivers for a while (most complete for i2c devices I think).
> 
> As you might imagine I don't actually have that many parts (and most of them
> aren't connected to boards at any given time) so any form of emulation can be
> very helpful.
> 
> I'll see if I can dig up any interesting devices beyond the ones we
> already know are integrated in various SoCs.

A quick search turned up a few parts that might do the job as additional
test parts.

lsi ls7366r - spi encoder to count chip. 
www.lsisci.com  - lots of parts made by them...

The broadcom (now - been various people) hctl-2032 - parallel output
but otherwise, does basic counting index etc.

https://www.tindie.com/products/Renbotics/tinyqed/
looks quite cute... Just does it using at little micro to do the hard work.
(long dead as a product by the look of it though..) Easy to emulate perhaps
but none of the links work..

Another thought would be to do a quick fpga version of whatever we
fancy playing with and use that.  I can think of a few people to
ask if this would be useful (could do it myself, but low on time
for the next few months at