LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere
From: Michael Ellerman @ 2019-04-04  6:08 UTC (permalink / raw)
  To: Jens Axboe, Will Deacon
  Cc: Rich Felker, linux-ia64, linux-sh, Heiko Carstens, linux-mips,
	James E . J . Bottomley, Max Filippov, Paul Mackerras, sparclinux,
	linux-s390, Helge Deller, Russell King, Geert Uytterhoeven,
	Catalin Marinas, James Hogan, Firoz Khan, Matt Turner, Fenghua Yu,
	Arnd Bergmann, linux-m68k, Ivan Kokshaysky, linux-arm-kernel,
	Richard Henderson, Michal Simek, Tony Luck, linux-parisc,
	linux-kernel, Ralf Baechle, Paul Burton, linux-alpha,
	Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S . Miller
In-Reply-To: <9d673dfd-0051-3676-653e-6376430d73dd@kernel.dk>

Jens Axboe <axboe@kernel.dk> writes:
> On 4/3/19 5:11 AM, Will Deacon wrote:
>> On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
>>>> index b18abb0c3dae..00f5a63c8d9a 100644
>>>> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
>>>> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
>>>> @@ -505,3 +505,7 @@
>>>>  421	32	rt_sigtimedwait_time64		sys_rt_sigtimedwait		compat_sys_rt_sigtimedwait_time64
>>>>  422	32	futex_time64			sys_futex			sys_futex
>>>>  423	32	sched_rr_get_interval_time64	sys_sched_rr_get_interval	sys_sched_rr_get_interval
>>>> +424	common	pidfd_send_signal		sys_pidfd_send_signal
>>>> +425	common	io_uring_setup			sys_io_uring_setup
>>>> +426	common	io_uring_enter			sys_io_uring_enter
>>>> +427	common	io_uring_register		sys_io_uring_register
>>>
>>> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
>>>
>>> Lightly tested.
>>>
>>> The pidfd_test selftest passes.
>> 
>> That reports pass for me too, although it fails to unshare the pid ns, which I
>> assume is benign.

If you run it as root it should work?

>>> Ran the io_uring example from fio, which prints lots of:
>> 
>> How did you invoke that? I had a play with the tests in:
>
> It's t/io_uring from the fio repo:
>
> git://git.kernel.dk/fio
>
> and you just run it ala:
>
> # make t/io_uring
> # t/io_uring /dev/some_device

Yeah that's all I did.

>> will@autoplooker:~/liburing/test$ ./io_uring_register 
>> RELIMIT_MEMLOCK: 67108864 (67108864)
>> [   35.477875] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
>> [   35.478969] Mem abort info:
>> [   35.479296]   ESR = 0x96000004
>> [   35.479785]   Exception class = DABT (current EL), IL = 32 bits
>> [   35.480528]   SET = 0, FnV = 0
>> [   35.480980]   EA = 0, S1PTW = 0
>> [   35.481345] Data abort info:
>> [   35.481680]   ISV = 0, ISS = 0x00000004
>> [   35.482267]   CM = 0, WnR = 0
>> [   35.482618] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
>> [   35.483486] [0000000000000070] pgd=0000000000000000
>> [   35.484041] Internal error: Oops: 96000004 [#1] PREEMPT SMP
>> [   35.484788] Modules linked in:
>> [   35.485311] CPU: 113 PID: 3973 Comm: io_uring_regist Not tainted 5.1.0-rc3-00012-g40b114779944 #1
>> [   35.486712] Hardware name: linux,dummy-virt (DT)
>> [   35.487450] pstate: 20400005 (nzCv daif +PAN -UAO)
>> [   35.488228] pc : link_pwq+0x10/0x60
>> [   35.488794] lr : apply_wqattrs_commit+0xe0/0x118
>> [   35.489550] sp : ffff000017e2bbc0
>
> Huh, this looks odd, it's crashing inside the wq setup.

Looks like you found a bug :)

cheers

^ permalink raw reply

* RE: [PATCH V2] ASoC: fsl_esai: Support synchronous mode
From: S.j. Wang @ 2019-04-04  6:29 UTC (permalink / raw)
  To: Nicolin Chen
  Cc: alsa-devel@alsa-project.org, timur@kernel.org,
	Xiubo.Lee@gmail.com, festevam@gmail.com, broonie@kernel.org,
	linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190403185716.GA5130@Asurada-Nvidia.nvidia.com>

Hi

> 
> This looks better :)
> 
> On Wed, Apr 03, 2019 at 10:07:40AM +0000, S.j. Wang wrote:
> > @@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct
> > snd_soc_dai *dai, int clk_id,  {
> >  	struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
> >  	struct clk *clksrc = esai_priv->extalclk;
> > -	bool tx = clk_id <= ESAI_HCKT_EXTAL;
> > +	bool tx = (clk_id <= ESAI_HCKT_EXTAL || esai_priv->synchronous);
> >  	bool in = dir == SND_SOC_CLOCK_IN;
> >  	u32 ratio, ecr = 0;
> >  	unsigned long clk_rate;
> > @@ -253,7 +253,7 @@ static int fsl_esai_set_dai_sysclk(struct
> snd_soc_dai *dai, int clk_id,
> >  		ecr |= ESAI_ECR_ETI;
> >  		/* fall through */
> 
> Btw, I am also wondering if the fall through here is a bug....
> Because I don't recall that there is a specific reason to fall through here.
> Can you please help confirm? Perhaps we need to submit a separate fix as
> well by replacing it with a "break;".
Yes, I think there is issue here, will submit another patch for it.
> 
> >  	case ESAI_HCKR_EXTAL:
> > -		ecr |= ESAI_ECR_ERI;
> > +		ecr |= esai_priv->synchronous ? ESAI_ECR_ETI :
> ESAI_ECR_ERI;
> >  		break;
> >  	default:
> >  		return -EINVAL;
> 
> > @@ -537,10 +537,18 @@ static int fsl_esai_hw_params(struct
> > snd_pcm_substream *substream,
> >
> >  	bclk = params_rate(params) * slot_width * esai_priv->slots;
> >
> > -	ret = fsl_esai_set_bclk(dai, tx, bclk);
> > +	ret = fsl_esai_set_bclk(dai, esai_priv->synchronous || tx, bclk);
> >  	if (ret)
> >  		return ret;
> >
> > +	mask = ESAI_xCR_xSWS_MASK;
> > +	val = ESAI_xCR_xSWS(slot_width, width);
> > +
> > +	regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask,
> val);
> > +	/* Recording in synchronous mode needs to set TCR also */
> > +	if (!tx && esai_priv->synchronous)
> > +		regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> mask, val);
> > +
> >  	/* Use Normal mode to support monaural audio */
> >  	regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> >  			   ESAI_xCR_xMOD_MASK,
> params_channels(params) > 1 ?
> > @@ -556,10 +564,9 @@ static int fsl_esai_hw_params(struct
> > snd_pcm_substream *substream,
> >
> >  	regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask,
> val);
> >
> > -	mask = ESAI_xCR_xSWS_MASK | (tx ? ESAI_xCR_PADC : 0);
> > -	val = ESAI_xCR_xSWS(slot_width, width) | (tx ? ESAI_xCR_PADC : 0);
> > -
> > -	regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask,
> val);
> > +	if (tx)
> > +		regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > +					ESAI_xCR_PADC, ESAI_xCR_PADC);
> 
> Mind aligning the indentation here like the one below?
> 		regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> 				   ESAI_xCR_PADC, ESAI_xCR_PADC);

Ok. Will send v3.
> 
> Once you fix the indentation, add this:
> 
> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> 
> Thanks

^ permalink raw reply

* Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args
From: Thomas Gleixner @ 2019-04-04  7:52 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: linux-ia64, Gustavo A. R. Silva, Peter Zijlstra, Palmer Dabbelt,
	Dominik Brodowski, Oleg Nesterov, H. Peter Anvin, sparclinux,
	linux-riscv, Ingo Molnar, linux-arch, linux-s390, linux-c6x-dev,
	linux-sh, linux-hexagon, x86, Ingo Molnar, linux-snps-arc,
	Dave Martin, uclinux-h8-devel, linux-xtensa, Kees Cook,
	Roland McGrath, linux-um, linux-mips, openrisc, Borislav Petkov,
	Andy Lutomirski, Dmitry V. Levin, linux-arm-kernel, linux-parisc,
	linuxppc-dev, linux-kernel, Andy Lutomirski, Eric W. Biederman,
	nios2-dev, Andrew Morton, Linus Torvalds
In-Reply-To: <20190401134421.278590567@goodmis.org>

On Mon, 1 Apr 2019, Steven Rostedt wrote:

> From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
> 
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard case of passing in 0 and 6 for
> the starting index and the number of system calls to get. When looking at
> all the users of this function, I discovered that all instances pass in only
> 0 and 6 for these arguments. Instead of having this function handle
> different cases that are never used, simply rewrite it to return the first 6
> arguments of a system call.
> 
> This should help out the performance of tracing system calls by ptrace,
> ftrace and perf.
> 
> Link: http://lkml.kernel.org/r/20161107213233.754809394@goodmis.org

For x86:

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

^ permalink raw reply

* Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args
From: Thomas Gleixner @ 2019-04-04  7:53 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: linux-ia64, Gustavo A. R. Silva, Peter Zijlstra, Palmer Dabbelt,
	Dominik Brodowski, Oleg Nesterov, H. Peter Anvin, sparclinux,
	linux-riscv, Ingo Molnar, linux-arch, linux-s390, linux-c6x-dev,
	linux-sh, linux-hexagon, x86, Ingo Molnar, linux-snps-arc,
	Dave Martin, uclinux-h8-devel, linux-xtensa, Kees Cook,
	Roland McGrath, linux-um, linux-mips, openrisc, Borislav Petkov,
	Andy Lutomirski, Dmitry V. Levin, linux-arm-kernel, linux-parisc,
	linuxppc-dev, linux-kernel, Andy Lutomirski, Eric W. Biederman,
	nios2-dev, Andrew Morton, Linus Torvalds
In-Reply-To: <20190401134421.442323029@goodmis.org>

On Mon, 1 Apr 2019, Steven Rostedt wrote:

> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> 
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of syscall_set_arguments(). But we are told that
> there will be soon. But for now, at least make it consistent with
> syscall_get_arguments().
> 
> Link: http://lkml.kernel.org/r/20190327222014.GA32540@altlinux.org

For x86:

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

^ permalink raw reply

* VLC doesn't play videos anymore since the PowerPC fixes 5.1-3
From: Christian Zigotzky @ 2019-04-04  8:44 UTC (permalink / raw)
  To: Christophe Leroy, linuxppc-dev, Michael Ellerman
In-Reply-To: <5726a634-25ca-d267-17fd-af88436edf1f@c-s.fr>

On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
>
>
> Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
>> On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
>>> Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
>>>> Please test VLC with the RC3 of kernel 5.1.
>>>>
>>>> The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. 
>>>> Another user has already confirmed that [1]. This isn’t an April 
>>>> Fool‘s. ;-)
>>>
>>> Could you bisect to identify the guilty commit ?
>>>
>>> Thanks
>>> Christophe
>>>
>>>>
>>>> Thanks
>>>>
>>>> [1] 
>>>> http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4256&start=20#p47561 
>>>>
>>>>
>>>
>> Hello Christophe,
>>
>> I have found the problematic patch. The following patch from the 
>> PowerPC fixes 5.1-3 is responsible for the VLC issue.
>
> That change is part of the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2&id=b5b4453e7912f056da1ca7572574cada32ecb60c 
>
>
> Just changing back the type of wtom_clock_sec to 32 bits without 
> changing back the loading instruction is likely to give unexpected 
> results on PPC64.
>
> Are you using 32 bits or 64 bits powerpc ?
>
> Christophe
64-bit kernel + 32-bit userland for example:

- ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
- Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
- MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 64-bit kernel

-- Christian
>
>
>>
>> diff --git a/arch/powerpc/include/asm/vdso_datapage.h 
>> b/arch/powerpc/include/asm/vdso_datapage.h
>> index 1afe90ade595..bbc06bd72b1f 100644
>> --- a/arch/powerpc/include/asm/vdso_datapage.h
>> +++ b/arch/powerpc/include/asm/vdso_datapage.h
>> @@ -82,10 +82,10 @@ struct vdso_data {
>>      __u32 icache_block_size;      /* L1 i-cache block size */
>>      __u32 dcache_log_block_size;      /* L1 d-cache log block size */
>>      __u32 icache_log_block_size;      /* L1 i-cache log block size */
>> -   __s32 wtom_clock_sec;         /* Wall to monotonic clock */
>> -   __s32 wtom_clock_nsec;
>> -   struct timespec stamp_xtime;   /* xtime as at tb_orig_stamp */
>> -   __u32 stamp_sec_fraction;   /* fractional seconds of stamp_xtime */
>> +   __u32 stamp_sec_fraction;      /* fractional seconds of 
>> stamp_xtime */
>> +   __s32 wtom_clock_nsec;         /* Wall to monotonic clock nsec */
>> +   __s64 wtom_clock_sec;         /* Wall to monotonic clock sec */
>> +   struct timespec stamp_xtime;      /* xtime as at tb_orig_stamp */
>>         __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>         __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>   };
>>
>> -----
>>
>> Link: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/include/asm/vdso_datapage.h?h=v5.1-rc2&id=a5ed1e96cafde5ba48638f486bfca0685dc6ddc9 
>>
>>
>> I created a patch for solving the VLC issue today.
>>
>> vdso_datapage_vlc.patch:
>>
>> diff -rupN a/arch/powerpc/include/asm/vdso_datapage.h 
>> b/arch/powerpc/include/asm/vdso_datapage.h
>> --- a/arch/powerpc/include/asm/vdso_datapage.h  2019-04-03 
>> 22:56:44.560645936 +0200
>> +++ b/arch/powerpc/include/asm/vdso_datapage.h  2019-04-04 
>> 02:20:09.479361827 +0200
>> @@ -82,10 +82,10 @@ struct vdso_data {
>>          __u32 icache_block_size;                /* L1 i-cache block 
>> size     */
>>          __u32 dcache_log_block_size;            /* L1 d-cache log 
>> block size */
>>          __u32 icache_log_block_size;            /* L1 i-cache log 
>> block size */
>> -       __u32 stamp_sec_fraction;               /* fractional seconds 
>> of stamp_xtime */
>> -       __s32 wtom_clock_nsec;                  /* Wall to monotonic 
>> clock nsec */
>> -       __s64 wtom_clock_sec;                   /* Wall to monotonic 
>> clock sec */
>> -       struct timespec stamp_xtime;            /* xtime as at 
>> tb_orig_stamp */
>> +       __s32 wtom_clock_sec;                   /* Wall to monotonic 
>> clock */
>> +       __s32 wtom_clock_nsec;
>> +       struct timespec stamp_xtime;    /* xtime as at tb_orig_stamp */
>> +       __u32 stamp_sec_fraction;       /* fractional seconds of 
>> stamp_xtime */
>>          __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>          __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>   };
>>
>> -----
>>
>> Cheers,
>> Christian
>


^ permalink raw reply

* [PATCH 4.9 44/91] SoC: imx-sgtl5000: add missing put_device()
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Sascha Hauer, Takashi Iwai, Liam Girdwood,
	stable, Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
	Pengutronix Kernel Team, Wen Yang, Shawn Guo, Fabio Estevam,
	linux-arm-kernel
In-Reply-To: <20190404084535.450029272@linuxfoundation.org>

4.9-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index b99e0b5e00e9..8e525f7ac08d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
 		ret = -EPROBE_DEFER;
 		goto fail;
 	}
+	put_device(&ssi_pdev->dev);
 	codec_dev = of_find_i2c_device_by_node(codec_np);
 	if (!codec_dev) {
 		dev_err(&pdev->dev, "failed to find codec platform device\n");
-- 
2.19.1




^ permalink raw reply related

* [PATCH 4.9 66/91] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Takashi Iwai, Liam Girdwood, stable,
	Jaroslav Kysela, Nicolin Chen, Mark Brown, Wen Yang,
	Fabio Estevam
In-Reply-To: <20190404084535.450029272@linuxfoundation.org>

4.9-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index dffd549a0e2a..705d2524ec31 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
 	of_node_put(asrc_np);
 	of_node_put(codec_np);
+	put_device(&cpu_pdev->dev);
 fail:
 	of_node_put(cpu_np);
 
-- 
2.19.1




^ permalink raw reply related

* [PATCH 4.14 058/121] SoC: imx-sgtl5000: add missing put_device()
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Sascha Hauer, Takashi Iwai, Liam Girdwood,
	stable, Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
	Pengutronix Kernel Team, Wen Yang, Shawn Guo, Fabio Estevam,
	linux-arm-kernel
In-Reply-To: <20190404084545.245659903@linuxfoundation.org>

4.14-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index b99e0b5e00e9..8e525f7ac08d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
 		ret = -EPROBE_DEFER;
 		goto fail;
 	}
+	put_device(&ssi_pdev->dev);
 	codec_dev = of_find_i2c_device_by_node(codec_np);
 	if (!codec_dev) {
 		dev_err(&pdev->dev, "failed to find codec platform device\n");
-- 
2.19.1




^ permalink raw reply related

* [PATCH 4.14 085/121] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Takashi Iwai, Liam Girdwood, stable,
	Jaroslav Kysela, Nicolin Chen, Mark Brown, Wen Yang,
	Fabio Estevam
In-Reply-To: <20190404084545.245659903@linuxfoundation.org>

4.14-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 2db4d0c80d33..393100edd5fd 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
 	of_node_put(asrc_np);
 	of_node_put(codec_np);
+	put_device(&cpu_pdev->dev);
 fail:
 	of_node_put(cpu_np);
 
-- 
2.19.1




^ permalink raw reply related

* [PATCH 4.19 083/187] SoC: imx-sgtl5000: add missing put_device()
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Sascha Hauer, Takashi Iwai, Liam Girdwood,
	stable, Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
	Pengutronix Kernel Team, Wen Yang, Shawn Guo, Fabio Estevam,
	linux-arm-kernel
In-Reply-To: <20190404084603.119654039@linuxfoundation.org>

4.19-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index c29200cf755a..9b9a7ec52905 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -108,6 +108,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
 		ret = -EPROBE_DEFER;
 		goto fail;
 	}
+	put_device(&ssi_pdev->dev);
 	codec_dev = of_find_i2c_device_by_node(codec_np);
 	if (!codec_dev) {
 		dev_err(&pdev->dev, "failed to find codec platform device\n");
-- 
2.19.1




^ permalink raw reply related

* [PATCH 4.19 131/187] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Takashi Iwai, Liam Girdwood, stable,
	Jaroslav Kysela, Nicolin Chen, Mark Brown, Wen Yang,
	Fabio Estevam
In-Reply-To: <20190404084603.119654039@linuxfoundation.org>

4.19-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 44433b20435c..600d9be9706e 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
 	of_node_put(asrc_np);
 	of_node_put(codec_np);
+	put_device(&cpu_pdev->dev);
 fail:
 	of_node_put(cpu_np);
 
-- 
2.19.1




^ permalink raw reply related

* Re: VLC doesn't play videos anymore since the PowerPC fixes 5.1-3
From: Christophe Leroy @ 2019-04-04  9:07 UTC (permalink / raw)
  To: Christian Zigotzky, linuxppc-dev, Michael Ellerman
In-Reply-To: <99ff68a4-3aef-47ad-99f8-433b181afe3f@xenosoft.de>



On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
> On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
>>
>>
>> Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
>>> On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
>>>> Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
>>>>> Please test VLC with the RC3 of kernel 5.1.
>>>>>
>>>>> The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. 
>>>>> Another user has already confirmed that [1]. This isn’t an April 
>>>>> Fool‘s. ;-)
>>>>
>>>> Could you bisect to identify the guilty commit ?
>>>>
>>>> Thanks
>>>> Christophe
>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> [1] 
>>>>> http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4256&start=20#p47561 
>>>>>
>>>>>
>>>>
>>> Hello Christophe,
>>>
>>> I have found the problematic patch. The following patch from the 
>>> PowerPC fixes 5.1-3 is responsible for the VLC issue.
>>
>> That change is part of the following commit:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2&id=b5b4453e7912f056da1ca7572574cada32ecb60c 
>>
>>
>> Just changing back the type of wtom_clock_sec to 32 bits without 
>> changing back the loading instruction is likely to give unexpected 
>> results on PPC64.
>>
>> Are you using 32 bits or 64 bits powerpc ?
>>
>> Christophe
> 64-bit kernel + 32-bit userland for example:
> 
> - ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
> - Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
> - MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 64-bit 
> kernel

Ok, thanks. Can you please try below change:

diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
b/arch/powerpc/kernel/vdso32/gettimeofday.S
index 1e0bc5955a40..afd516b572f8 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -98,7 +98,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
  	 * can be used, r7 contains NSEC_PER_SEC.
  	 */

-	lwz	r5,WTOM_CLOCK_SEC(r9)
+	lwz	r5,(WTOM_CLOCK_SEC+LOPART)(r9)
  	lwz	r6,WTOM_CLOCK_NSEC(r9)

  	/* We now have our offset in r5,r6. We create a fake dependency


Christophe

> 
> -- Christian
>>
>>
>>>
>>> diff --git a/arch/powerpc/include/asm/vdso_datapage.h 
>>> b/arch/powerpc/include/asm/vdso_datapage.h
>>> index 1afe90ade595..bbc06bd72b1f 100644
>>> --- a/arch/powerpc/include/asm/vdso_datapage.h
>>> +++ b/arch/powerpc/include/asm/vdso_datapage.h
>>> @@ -82,10 +82,10 @@ struct vdso_data {
>>>      __u32 icache_block_size;      /* L1 i-cache block size */
>>>      __u32 dcache_log_block_size;      /* L1 d-cache log block size */
>>>      __u32 icache_log_block_size;      /* L1 i-cache log block size */
>>> -   __s32 wtom_clock_sec;         /* Wall to monotonic clock */
>>> -   __s32 wtom_clock_nsec;
>>> -   struct timespec stamp_xtime;   /* xtime as at tb_orig_stamp */
>>> -   __u32 stamp_sec_fraction;   /* fractional seconds of stamp_xtime */
>>> +   __u32 stamp_sec_fraction;      /* fractional seconds of 
>>> stamp_xtime */
>>> +   __s32 wtom_clock_nsec;         /* Wall to monotonic clock nsec */
>>> +   __s64 wtom_clock_sec;         /* Wall to monotonic clock sec */
>>> +   struct timespec stamp_xtime;      /* xtime as at tb_orig_stamp */
>>>         __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>>         __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>>   };
>>>
>>> -----
>>>
>>> Link: 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/include/asm/vdso_datapage.h?h=v5.1-rc2&id=a5ed1e96cafde5ba48638f486bfca0685dc6ddc9 
>>>
>>>
>>> I created a patch for solving the VLC issue today.
>>>
>>> vdso_datapage_vlc.patch:
>>>
>>> diff -rupN a/arch/powerpc/include/asm/vdso_datapage.h 
>>> b/arch/powerpc/include/asm/vdso_datapage.h
>>> --- a/arch/powerpc/include/asm/vdso_datapage.h  2019-04-03 
>>> 22:56:44.560645936 +0200
>>> +++ b/arch/powerpc/include/asm/vdso_datapage.h  2019-04-04 
>>> 02:20:09.479361827 +0200
>>> @@ -82,10 +82,10 @@ struct vdso_data {
>>>          __u32 icache_block_size;                /* L1 i-cache block 
>>> size     */
>>>          __u32 dcache_log_block_size;            /* L1 d-cache log 
>>> block size */
>>>          __u32 icache_log_block_size;            /* L1 i-cache log 
>>> block size */
>>> -       __u32 stamp_sec_fraction;               /* fractional seconds 
>>> of stamp_xtime */
>>> -       __s32 wtom_clock_nsec;                  /* Wall to monotonic 
>>> clock nsec */
>>> -       __s64 wtom_clock_sec;                   /* Wall to monotonic 
>>> clock sec */
>>> -       struct timespec stamp_xtime;            /* xtime as at 
>>> tb_orig_stamp */
>>> +       __s32 wtom_clock_sec;                   /* Wall to monotonic 
>>> clock */
>>> +       __s32 wtom_clock_nsec;
>>> +       struct timespec stamp_xtime;    /* xtime as at tb_orig_stamp */
>>> +       __u32 stamp_sec_fraction;       /* fractional seconds of 
>>> stamp_xtime */
>>>          __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>>          __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
>>>   };
>>>
>>> -----
>>>
>>> Cheers,
>>> Christian
>>

^ permalink raw reply related

* [PATCH 5.0 057/246] mm/resource: Return real error codes from walk failures
From: Greg Kroah-Hartman @ 2019-04-04  8:45 UTC (permalink / raw)
  To: linux-kernel
  Cc: Michal Hocko, Takashi Iwai, Dave Hansen, Keith Busch, linux-mm,
	Paul Mackerras, Yaowei Bai, Ross Zwisler, Sasha Levin, Dave Jiang,
	linux-nvdimm, Vishal Verma, Huang Ying, Borislav Petkov,
	Tom Lendacky, Jerome Glisse, Bjorn Helgaas, Dan Williams,
	Greg Kroah-Hartman, stable, Andrew Morton, Fengguang Wu,
	linuxppc-dev
In-Reply-To: <20190404084619.236418459@linuxfoundation.org>

5.0-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 5cd401ace914dc68556c6d2fcae0c349444d5f86 ]

walk_system_ram_range() can return an error code either becuase
*it* failed, or because the 'func' that it calls returned an
error.  The memory hotplug does the following:

	ret = walk_system_ram_range(..., func);
        if (ret)
		return ret;

and 'ret' makes it out to userspace, eventually.  The problem
s, walk_system_ram_range() failues that result from *it* failing
(as opposed to 'func') return -1.  That leads to a very odd
-EPERM (-1) return code out to userspace.

Make walk_system_ram_range() return -EINVAL for internal
failures to keep userspace less confused.

This return code is compatible with all the callers that I
audited.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ross Zwisler <zwisler@kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: linux-nvdimm@lists.01.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Huang Ying <ying.huang@intel.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Keith Busch <keith.busch@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 kernel/resource.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 915c02e8e5dd..ca7ed5158cff 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -382,7 +382,7 @@ static int __walk_iomem_res_desc(resource_size_t start, resource_size_t end,
 				 int (*func)(struct resource *, void *))
 {
 	struct resource res;
-	int ret = -1;
+	int ret = -EINVAL;
 
 	while (start < end &&
 	       !find_next_iomem_res(start, end, flags, desc, first_lvl, &res)) {
@@ -462,7 +462,7 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 	unsigned long flags;
 	struct resource res;
 	unsigned long pfn, end_pfn;
-	int ret = -1;
+	int ret = -EINVAL;
 
 	start = (u64) start_pfn << PAGE_SHIFT;
 	end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
-- 
2.19.1




^ permalink raw reply related

* [PATCH 5.0 111/246] SoC: imx-sgtl5000: add missing put_device()
From: Greg Kroah-Hartman @ 2019-04-04  8:46 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Sascha Hauer, Takashi Iwai, Liam Girdwood,
	stable, Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
	Pengutronix Kernel Team, Wen Yang, Shawn Guo, Fabio Estevam,
	linux-arm-kernel
In-Reply-To: <20190404084619.236418459@linuxfoundation.org>

5.0-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index c29200cf755a..9b9a7ec52905 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -108,6 +108,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
 		ret = -EPROBE_DEFER;
 		goto fail;
 	}
+	put_device(&ssi_pdev->dev);
 	codec_dev = of_find_i2c_device_by_node(codec_np);
 	if (!codec_dev) {
 		dev_err(&pdev->dev, "failed to find codec platform device\n");
-- 
2.19.1




^ permalink raw reply related

* [PATCH 5.0 173/246] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
From: Greg Kroah-Hartman @ 2019-04-04  8:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
	Greg Kroah-Hartman, Takashi Iwai, Liam Girdwood, stable,
	Jaroslav Kysela, Nicolin Chen, Mark Brown, Wen Yang,
	Fabio Estevam
In-Reply-To: <20190404084619.236418459@linuxfoundation.org>

5.0-stable review patch.  If anyone has any objections, please let me know.

------------------

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 81f2fe2c6d23..60f87a0d99f4 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
 	of_node_put(asrc_np);
 	of_node_put(codec_np);
+	put_device(&cpu_pdev->dev);
 fail:
 	of_node_put(cpu_np);
 
-- 
2.19.1




^ permalink raw reply related

* [PATCH V3] ASoC: fsl_esai: Support synchronous mode
From: S.j. Wang @ 2019-04-04  9:40 UTC (permalink / raw)
  To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
	festevam@gmail.com, broonie@kernel.org,
	alsa-devel@alsa-project.org
  Cc: linuxppc-dev@lists.ozlabs.org

In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
Changes in v3
- fix the indentation

 sound/soc/fsl/fsl_esai.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 3623aa9a6f2e..c7410bbfd2af 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
 {
 	struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
 	struct clk *clksrc = esai_priv->extalclk;
-	bool tx = clk_id <= ESAI_HCKT_EXTAL;
+	bool tx = (clk_id <= ESAI_HCKT_EXTAL || esai_priv->synchronous);
 	bool in = dir == SND_SOC_CLOCK_IN;
 	u32 ratio, ecr = 0;
 	unsigned long clk_rate;
@@ -253,7 +253,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
 		ecr |= ESAI_ECR_ETI;
 		/* fall through */
 	case ESAI_HCKR_EXTAL:
-		ecr |= ESAI_ECR_ERI;
+		ecr |= esai_priv->synchronous ? ESAI_ECR_ETI : ESAI_ECR_ERI;
 		break;
 	default:
 		return -EINVAL;
@@ -537,10 +537,18 @@ static int fsl_esai_hw_params(struct snd_pcm_substream *substream,
 
 	bclk = params_rate(params) * slot_width * esai_priv->slots;
 
-	ret = fsl_esai_set_bclk(dai, tx, bclk);
+	ret = fsl_esai_set_bclk(dai, esai_priv->synchronous || tx, bclk);
 	if (ret)
 		return ret;
 
+	mask = ESAI_xCR_xSWS_MASK;
+	val = ESAI_xCR_xSWS(slot_width, width);
+
+	regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+	/* Recording in synchronous mode needs to set TCR also */
+	if (!tx && esai_priv->synchronous)
+		regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, val);
+
 	/* Use Normal mode to support monaural audio */
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
 			   ESAI_xCR_xMOD_MASK, params_channels(params) > 1 ?
@@ -556,10 +564,9 @@ static int fsl_esai_hw_params(struct snd_pcm_substream *substream,
 
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask, val);
 
-	mask = ESAI_xCR_xSWS_MASK | (tx ? ESAI_xCR_PADC : 0);
-	val = ESAI_xCR_xSWS(slot_width, width) | (tx ? ESAI_xCR_PADC : 0);
-
-	regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+	if (tx)
+		regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+				ESAI_xCR_PADC, ESAI_xCR_PADC);
 
 	/* Remove ESAI personal reset by configuring ESAI_PCRC and ESAI_PRRC */
 	regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
-- 
1.9.1


^ permalink raw reply related

* Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states
From: Daniel Lezcano @ 2019-04-04 10:21 UTC (permalink / raw)
  To: Abhishek, Rafael J. Wysocki
  Cc: Rafael J. Wysocki, linuxppc-dev, Linux Kernel Mailing List,
	Linux PM
In-Reply-To: <50f62972-dfce-52bf-d26b-32e6d2a367e2@linux.vnet.ibm.com>


Hi Abhishek,

thanks for taking the time to test the different scenario and give us
the numbers.

On 01/04/2019 07:11, Abhishek wrote:
> 
> 
> On 03/22/2019 06:56 PM, Daniel Lezcano wrote:
>> On 22/03/2019 10:45, Rafael J. Wysocki wrote:
>>> On Fri, Mar 22, 2019 at 8:31 AM Abhishek Goel
>>> <huntbag@linux.vnet.ibm.com> wrote:
>>>> Currently, the cpuidle governors (menu /ladder) determine what idle
>>>> state
>>>> an idling CPU should enter into based on heuristics that depend on the
>>>> idle history on that CPU. Given that no predictive heuristic is
>>>> perfect,
>>>> there are cases where the governor predicts a shallow idle state,
>>>> hoping
>>>> that the CPU will be busy soon. However, if no new workload is
>>>> scheduled
>>>> on that CPU in the near future, the CPU will end up in the shallow
>>>> state.
>>>>
>>>> In case of POWER, this is problematic, when the predicted state in the
>>>> aforementioned scenario is a lite stop state, as such lite states will
>>>> inhibit SMT folding, thereby depriving the other threads in the core
>>>> from
>>>> using the core resources.

I can understand an idle state can prevent other threads to use the core
resources. But why a deeper idle state does not prevent this also?


>>>> To address this, such lite states need to be autopromoted. The cpuidle-
>>>> core can queue timer to correspond with the residency value of the next
>>>> available state. Thus leading to auto-promotion to a deeper idle
>>>> state as
>>>> soon as possible.
>>> Isn't the tick stopping avoidance sufficient for that?
>> I was about to ask the same :)
>>
>>
>>
>>
> Thanks for the review.
> I performed experiments for three scenarios to collect some data.
> 
> case 1 :
> Without this patch and without tick retained, i.e. in a upstream kernel,
> It would spend more than even a second to get out of stop0_lite.
> 
> case 2 : With tick retained(as suggested) -
> 
> Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
> it to take 8 sched tick to get out of stop0_lite. Experimentally,
> observation was
> 
> ===================================
> min            max            99percentile
> 4ms            12ms          4ms
> ===================================
> *ms = milliseconds
> 
> It would take atleast one sched tick to get out of stop0_lite.
> 
> case 2 :  With this patch (not stopping tick, but explicitly queuing a
> timer)
> 
> min            max              99.5percentile
> ===============================
> 144us       192us              144us
> ===============================
> *us = microseconds
> 
> In this patch, we queue a timer just before entering into a stop0_lite
> state. The timer fires at (residency of next available state + exit
> latency of next available state * 2).

So for the context, we have a similar issue but from the power
management point of view where a CPU can stay in a shallow state for a
long period, thus consuming a lot of energy.

The window was reduced by preventing stopping the tick when a shallow
state is selected. Unfortunately, if the tick is stopped and we
exit/enter again and we select a shallow state, the situation is the same.

A solution was previously proposed with a timer some years ago, like
this patch does, and merged but there were complains about bad
performance impact, so it has been reverted.

> Let's say if next state(stop0) is available which has residency of 20us, it
> should get out in as low as (20+2*2)*8 [Based on the forumla (residency +
> 2xlatency)*history length] microseconds = 192us. Ideally we would expect 8
> iterations, it was observed to get out in 6-7 iterations.

Can you explain the formula? I don't get the rational. Why using the
exit latency and why multiply it by 2?

Why the timer is not set to the next state's target residency value ?

> Even if let's say stop2 is next available state(stop0 and stop1 both are
> unavailable), it would take (100+2*10)*8 = 960us to get into stop2.
> 
> So, We are able to get out of stop0_lite generally in 150us(with this
> patch) as
> compared to 4ms(with tick retained). As stated earlier, we do not want
> to get
> stuck into stop0_lite as it inhibits SMT folding for other sibling
> threads, depriving
> them of core resources. Current patch is using auto-promotion only for
> stop0_lite,
> as it gives performance benefit(primary reason) along with lowering down
> power
> consumption. We may extend this model for other states in future.
> 
> --Abhishek
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


^ permalink raw reply

* Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states
From: Gautham R Shenoy @ 2019-04-04 10:54 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: ego, Linux PM, Rafael J. Wysocki, Rafael J. Wysocki,
	Linux Kernel Mailing List, Abhishek, linuxppc-dev
In-Reply-To: <9e542011-df6d-9b84-823b-2af6a6ef9e94@linaro.org>

Hello Daniel,

On Thu, Apr 4, 2019 at 3:52 PM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
>
> Hi Abhishek,
>
> thanks for taking the time to test the different scenario and give us
> the numbers.
>
> On 01/04/2019 07:11, Abhishek wrote:
> >

[.. snip..]

>
> >>>> In case of POWER, this is problematic, when the predicted state in the
> >>>> aforementioned scenario is a lite stop state, as such lite states will
> >>>> inhibit SMT folding, thereby depriving the other threads in the core
> >>>> from
> >>>> using the core resources.
>
> I can understand an idle state can prevent other threads to use the core
> resources. But why a deeper idle state does not prevent this also?

On POWER9, we have the following classes of platform idle states
(called stop states)

lite    : These do not lose any context including the user context. In
this state
           GPRs are also preserved (stop0_lite)

shallow : These lose user context,but not the hypervisor context. So
GPRs are lost but
               not SPRs. (stop0, stop1, stop2)

deep: These lose hypervisor context. (stop4, stop5)

In the case of lite stop state, only instruction dispatch on the CPU thread
is paused. The thread does not  give up its registers set in this state for the
use of its busy sibling threads in the core.  Hence, SMT folding does not
happen in this state.

With respect to shallow and deep states, not only is the instruction dispatch
paused, it also gives up its registers set for the other siblings to use
These stop states are beneficial for SMT folding.

Hence, if a CPU thread remains in a lite state for too long,
its siblings in the core would not be able to utilize the full resources
of the core for that duration, thereby inhibiting single
thread performance. This is not the case with non-lite states.

-- 
Thanks and Regards
gautham.

^ permalink raw reply

* Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states
From: Abhishek @ 2019-04-04 11:10 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: ego, Linux PM, Rafael J. Wysocki, Linux Kernel Mailing List,
	linuxppc-dev
In-Reply-To: <9e542011-df6d-9b84-823b-2af6a6ef9e94@linaro.org>



On 04/04/2019 03:51 PM, Daniel Lezcano wrote:
> Hi Abhishek,
>
> thanks for taking the time to test the different scenario and give us
> the numbers.
>
> On 01/04/2019 07:11, Abhishek wrote:
>>
>> On 03/22/2019 06:56 PM, Daniel Lezcano wrote:
>>> On 22/03/2019 10:45, Rafael J. Wysocki wrote:
>>>> On Fri, Mar 22, 2019 at 8:31 AM Abhishek Goel
>>>> <huntbag@linux.vnet.ibm.com> wrote:
>>>>> Currently, the cpuidle governors (menu /ladder) determine what idle
>>>>> state
>>>>> an idling CPU should enter into based on heuristics that depend on the
>>>>> idle history on that CPU. Given that no predictive heuristic is
>>>>> perfect,
>>>>> there are cases where the governor predicts a shallow idle state,
>>>>> hoping
>>>>> that the CPU will be busy soon. However, if no new workload is
>>>>> scheduled
>>>>> on that CPU in the near future, the CPU will end up in the shallow
>>>>> state.
>>>>>
>>>>> In case of POWER, this is problematic, when the predicted state in the
>>>>> aforementioned scenario is a lite stop state, as such lite states will
>>>>> inhibit SMT folding, thereby depriving the other threads in the core
>>>>> from
>>>>> using the core resources.
> I can understand an idle state can prevent other threads to use the core
> resources. But why a deeper idle state does not prevent this also?
>
>
>>>>> To address this, such lite states need to be autopromoted. The cpuidle-
>>>>> core can queue timer to correspond with the residency value of the next
>>>>> available state. Thus leading to auto-promotion to a deeper idle
>>>>> state as
>>>>> soon as possible.
>>>> Isn't the tick stopping avoidance sufficient for that?
>>> I was about to ask the same :)
>>>
>>>
>>>
>>>
>> Thanks for the review.
>> I performed experiments for three scenarios to collect some data.
>>
>> case 1 :
>> Without this patch and without tick retained, i.e. in a upstream kernel,
>> It would spend more than even a second to get out of stop0_lite.
>>
>> case 2 : With tick retained(as suggested) -
>>
>> Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
>> it to take 8 sched tick to get out of stop0_lite. Experimentally,
>> observation was
>>
>> ===================================
>> min            max            99percentile
>> 4ms            12ms          4ms
>> ===================================
>> *ms = milliseconds
>>
>> It would take atleast one sched tick to get out of stop0_lite.
>>
>> case 2 :  With this patch (not stopping tick, but explicitly queuing a
>> timer)
>>
>> min            max              99.5percentile
>> ===============================
>> 144us       192us              144us
>> ===============================
>> *us = microseconds
>>
>> In this patch, we queue a timer just before entering into a stop0_lite
>> state. The timer fires at (residency of next available state + exit
>> latency of next available state * 2).
> So for the context, we have a similar issue but from the power
> management point of view where a CPU can stay in a shallow state for a
> long period, thus consuming a lot of energy.
>
> The window was reduced by preventing stopping the tick when a shallow
> state is selected. Unfortunately, if the tick is stopped and we
> exit/enter again and we select a shallow state, the situation is the same.
>
> A solution was previously proposed with a timer some years ago, like
> this patch does, and merged but there were complains about bad
> performance impact, so it has been reverted.
>
>> Let's say if next state(stop0) is available which has residency of 20us, it
>> should get out in as low as (20+2*2)*8 [Based on the forumla (residency +
>> 2xlatency)*history length] microseconds = 192us. Ideally we would expect 8
>> iterations, it was observed to get out in 6-7 iterations.
> Can you explain the formula? I don't get the rational. Why using the
> exit latency and why multiply it by 2?
>
> Why the timer is not set to the next state's target residency value ?
>
The idea behind multiplying by 2 is, entry latency + exit latency = 2* 
exit latency, i.e.,
using exit latency = entry latency
So in effect, we are using target residency + 2 * exit latency for 
timeout of timer.
Latency is generally <=10% of residency. I have tried to be conservative 
by including latency
factor in computation for timeout. Thus, this formula will give slightly 
greater value compared
to directly using residency of target state.

--Abhishek


^ permalink raw reply

* Re: [PATCH] powerpc/watchdog: Use hrtimers for per-CPU heartbeat
From: Gautham R Shenoy @ 2019-04-04 11:19 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: Ravikumar Bangoria, linuxppc-dev
In-Reply-To: <20190402112521.24888-1-npiggin@gmail.com>

Hello Nicholas,

On Tue, Apr 2, 2019 at 4:57 PM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
> incrementing jiffies. If that CPU has locked up and jiffies is not
> incrementing, the watchdog heartbeat timer for all CPUs stops and
> creates false positives and confusing warnings on local CPUs, and
> also causes the SMP detector to stop, so the root cause is never
> detected.
>
> Fix this by using hrtimer based timers for the watchdog heartbeat,
> like the generic kernel hardlockup detector.
>
> Reported-by: Ravikumar Bangoria <ravi.bangoria@in.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

[..snip..]

> @@ -325,19 +325,21 @@ EXPORT_SYMBOL(arch_touch_nmi_watchdog);
>
>  static void start_watchdog_timer_on(unsigned int cpu)
>  {
> -       struct timer_list *t = per_cpu_ptr(&wd_timer, cpu);
> +       struct hrtimer *hrtimer = this_cpu_ptr(&wd_hrtimer);

This function can be called during the initialization via

watchdog_nmi_start -->
    for_each_online_cpu(cpu)
           start_wd_on_cpu(cpu) -->
                   start_watchdog_timer_on(cpu)

Thus, it is not guarateed that we are always calling
start_watchdog_timer_on() from the CPU where
we want to start the watchdog timer.

Thus, should we be calling this function from start_wd_on_cpu() via an
smp_call_function_single() ?


>
>         per_cpu(wd_timer_tb, cpu) = get_tb();
>
> -       timer_setup(t, wd_timer_fn, TIMER_PINNED);
> -       wd_timer_reset(cpu, t);
> +       hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> +       hrtimer->function = watchdog_timer_fn;
> +       hrtimer_start(hrtimer, ms_to_ktime(wd_timer_period_ms),
> +                     HRTIMER_MODE_REL_PINNED);
>  }
>
>  static void stop_watchdog_timer_on(unsigned int cpu)
>  {
> -       struct timer_list *t = per_cpu_ptr(&wd_timer, cpu);
> +       struct hrtimer *hrtimer = this_cpu_ptr(&wd_hrtimer);
>
> -       del_timer_sync(t);
> +       hrtimer_cancel(hrtimer);
>  }
>
>  static int start_wd_on_cpu(unsigned int cpu)
> --
> 2.20.1
>


-- 
Thanks and Regards
gautham.

^ permalink raw reply

* VLC doesn't play videos anymore since the PowerPC fixes 5.1-3
From: Christian Zigotzky @ 2019-04-04 11:23 UTC (permalink / raw)
  To: Christophe Leroy, linuxppc-dev, Michael Ellerman
In-Reply-To: <84668be2-94ff-19f6-3b12-56ac545b92bd@c-s.fr>

On 04 April 2019 at 11:07AM, Christophe Leroy wrote:
>
>
> On 04/04/2019 08:44 AM, Christian Zigotzky wrote:
>> On 04 April 2019 at 06:00AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :
>>>> On 03 April 2019 at 07:05AM, Christophe Leroy wrote:
>>>>> Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :
>>>>>> Please test VLC with the RC3 of kernel 5.1.
>>>>>>
>>>>>> The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. 
>>>>>> Another user has already confirmed that [1]. This isn’t an April 
>>>>>> Fool‘s. ;-)
>>>>>
>>>>> Could you bisect to identify the guilty commit ?
>>>>>
>>>>> Thanks
>>>>> Christophe
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> [1] 
>>>>>> http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4256&start=20#p47561 
>>>>>>
>>>>>>
>>>>>
>>>> Hello Christophe,
>>>>
>>>> I have found the problematic patch. The following patch from the 
>>>> PowerPC fixes 5.1-3 is responsible for the VLC issue.
>>>
>>> That change is part of the following commit:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2&id=b5b4453e7912f056da1ca7572574cada32ecb60c 
>>>
>>>
>>> Just changing back the type of wtom_clock_sec to 32 bits without 
>>> changing back the loading instruction is likely to give unexpected 
>>> results on PPC64.
>>>
>>> Are you using 32 bits or 64 bits powerpc ?
>>>
>>> Christophe
>> 64-bit kernel + 32-bit userland for example:
>>
>> - ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
>> - Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
>> - MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 64-bit 
>> kernel
>
> Ok, thanks. Can you please try below change:
>
> diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
> b/arch/powerpc/kernel/vdso32/gettimeofday.S
> index 1e0bc5955a40..afd516b572f8 100644
> --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> @@ -98,7 +98,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
>       * can be used, r7 contains NSEC_PER_SEC.
>       */
>
> -    lwz    r5,WTOM_CLOCK_SEC(r9)
> +    lwz    r5,(WTOM_CLOCK_SEC+LOPART)(r9)
>      lwz    r6,WTOM_CLOCK_NSEC(r9)
>
>      /* We now have our offset in r5,r6. We create a fake dependency
>
>
> Christophe
>
Hello Christophe,

Your patch works! VLC plays videos without any problems! Thank you!

Cheers,
Christian

^ permalink raw reply

* [PATCH v2 1/2] powerpc/perf: init pmu from core-book3s
From: Madhavan Srinivasan @ 2019-04-04 11:54 UTC (permalink / raw)
  To: mpe; +Cc: Madhavan Srinivasan, linuxppc-dev

Currenty pmu driver file for each ppc64 generation processor
has a __init call in itself. Refactor the code by moving the
__init call to core-books.c. This also clean's up compat mode
pmu driver registration.

Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
Changelog v1:
- Added "internal.h" file and moved the extern definitions to that file

 arch/powerpc/perf/core-book3s.c | 28 ++++++++++++++++++++++++++++
 arch/powerpc/perf/internal.h    | 16 ++++++++++++++++
 arch/powerpc/perf/power5+-pmu.c |  4 +---
 arch/powerpc/perf/power5-pmu.c  |  4 +---
 arch/powerpc/perf/power6-pmu.c  |  4 +---
 arch/powerpc/perf/power7-pmu.c  |  4 +---
 arch/powerpc/perf/power8-pmu.c  |  3 +--
 arch/powerpc/perf/power9-pmu.c  |  3 +--
 arch/powerpc/perf/ppc970-pmu.c  |  4 +---
 9 files changed, 51 insertions(+), 19 deletions(-)
 create mode 100644 arch/powerpc/perf/internal.h

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index b0723002a396..a96f9420139c 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -22,6 +22,10 @@
 #include <asm/ptrace.h>
 #include <asm/code-patching.h>
 
+#ifdef CONFIG_PPC64
+#include "internal.h"
+#endif
+
 #define BHRB_MAX_ENTRIES	32
 #define BHRB_TARGET		0x0000000000000002
 #define BHRB_PREDICTION		0x0000000000000001
@@ -2294,3 +2298,27 @@ int register_power_pmu(struct power_pmu *pmu)
 			  power_pmu_prepare_cpu, NULL);
 	return 0;
 }
+
+#ifdef CONFIG_PPC64
+static int __init init_ppc64_pmu(void)
+{
+	/* run through all the pmu drivers one at a time */
+	if (!init_power5_pmu())
+		return 0;
+	else if (!init_power5p_pmu())
+		return 0;
+	else if (!init_power6_pmu())
+		return 0;
+	else if (!init_power7_pmu())
+		return 0;
+	else if (!init_power8_pmu())
+		return 0;
+	else if (!init_power9_pmu())
+		return 0;
+	else if (!init_ppc970_pmu())
+		return 0;
+	else
+		return -ENODEV;
+}
+early_initcall(init_ppc64_pmu);
+#endif
diff --git a/arch/powerpc/perf/internal.h b/arch/powerpc/perf/internal.h
new file mode 100644
index 000000000000..e54d524d4283
--- /dev/null
+++ b/arch/powerpc/perf/internal.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright 2019 Madhavan Srinivasan, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+extern int init_ppc970_pmu(void);
+extern int init_power5_pmu(void);
+extern int init_power5p_pmu(void);
+extern int init_power6_pmu(void);
+extern int init_power7_pmu(void);
+extern int init_power8_pmu(void);
+extern int init_power9_pmu(void);
diff --git a/arch/powerpc/perf/power5+-pmu.c b/arch/powerpc/perf/power5+-pmu.c
index 0526dac66007..9aa803504cb2 100644
--- a/arch/powerpc/perf/power5+-pmu.c
+++ b/arch/powerpc/perf/power5+-pmu.c
@@ -677,7 +677,7 @@ static struct power_pmu power5p_pmu = {
 	.cache_events		= &power5p_cache_events,
 };
 
-static int __init init_power5p_pmu(void)
+int init_power5p_pmu(void)
 {
 	if (!cur_cpu_spec->oprofile_cpu_type ||
 	    (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5+")
@@ -686,5 +686,3 @@ static int __init init_power5p_pmu(void)
 
 	return register_power_pmu(&power5p_pmu);
 }
-
-early_initcall(init_power5p_pmu);
diff --git a/arch/powerpc/perf/power5-pmu.c b/arch/powerpc/perf/power5-pmu.c
index 4dc99f9f7962..30cb13d081a9 100644
--- a/arch/powerpc/perf/power5-pmu.c
+++ b/arch/powerpc/perf/power5-pmu.c
@@ -618,7 +618,7 @@ static struct power_pmu power5_pmu = {
 	.flags			= PPMU_HAS_SSLOT,
 };
 
-static int __init init_power5_pmu(void)
+int init_power5_pmu(void)
 {
 	if (!cur_cpu_spec->oprofile_cpu_type ||
 	    strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5"))
@@ -626,5 +626,3 @@ static int __init init_power5_pmu(void)
 
 	return register_power_pmu(&power5_pmu);
 }
-
-early_initcall(init_power5_pmu);
diff --git a/arch/powerpc/perf/power6-pmu.c b/arch/powerpc/perf/power6-pmu.c
index 9c9d646b68a1..80ec48632cfe 100644
--- a/arch/powerpc/perf/power6-pmu.c
+++ b/arch/powerpc/perf/power6-pmu.c
@@ -540,7 +540,7 @@ static struct power_pmu power6_pmu = {
 	.cache_events		= &power6_cache_events,
 };
 
-static int __init init_power6_pmu(void)
+int init_power6_pmu(void)
 {
 	if (!cur_cpu_spec->oprofile_cpu_type ||
 	    strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power6"))
@@ -548,5 +548,3 @@ static int __init init_power6_pmu(void)
 
 	return register_power_pmu(&power6_pmu);
 }
-
-early_initcall(init_power6_pmu);
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 6dbae9884ec4..bb6efd5d2530 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -445,7 +445,7 @@ static struct power_pmu power7_pmu = {
 	.cache_events		= &power7_cache_events,
 };
 
-static int __init init_power7_pmu(void)
+int init_power7_pmu(void)
 {
 	if (!cur_cpu_spec->oprofile_cpu_type ||
 	    strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power7"))
@@ -456,5 +456,3 @@ static int __init init_power7_pmu(void)
 
 	return register_power_pmu(&power7_pmu);
 }
-
-early_initcall(init_power7_pmu);
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index d12a2db26353..bcc3409a06de 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -379,7 +379,7 @@ static struct power_pmu power8_pmu = {
 	.bhrb_nr		= 32,
 };
 
-static int __init init_power8_pmu(void)
+int init_power8_pmu(void)
 {
 	int rc;
 
@@ -399,4 +399,3 @@ static int __init init_power8_pmu(void)
 
 	return 0;
 }
-early_initcall(init_power8_pmu);
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 030544e35959..3a31ac6f4805 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -437,7 +437,7 @@ static struct power_pmu power9_pmu = {
 	.bhrb_nr		= 32,
 };
 
-static int __init init_power9_pmu(void)
+int init_power9_pmu(void)
 {
 	int rc = 0;
 	unsigned int pvr = mfspr(SPRN_PVR);
@@ -467,4 +467,3 @@ static int __init init_power9_pmu(void)
 
 	return 0;
 }
-early_initcall(init_power9_pmu);
diff --git a/arch/powerpc/perf/ppc970-pmu.c b/arch/powerpc/perf/ppc970-pmu.c
index 8b6a8a36fa38..1d3370914022 100644
--- a/arch/powerpc/perf/ppc970-pmu.c
+++ b/arch/powerpc/perf/ppc970-pmu.c
@@ -490,7 +490,7 @@ static struct power_pmu ppc970_pmu = {
 	.flags			= PPMU_NO_SIPR | PPMU_NO_CONT_SAMPLING,
 };
 
-static int __init init_ppc970_pmu(void)
+int init_ppc970_pmu(void)
 {
 	if (!cur_cpu_spec->oprofile_cpu_type ||
 	    (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/970")
@@ -499,5 +499,3 @@ static int __init init_ppc970_pmu(void)
 
 	return register_power_pmu(&ppc970_pmu);
 }
-
-early_initcall(init_ppc970_pmu);
-- 
2.7.4


^ permalink raw reply related

* [PATCH 2/2] powerpc/perf: Add generic compat mode pmu driver
From: Madhavan Srinivasan @ 2019-04-04 11:54 UTC (permalink / raw)
  To: mpe; +Cc: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <1554378890-31851-1-git-send-email-maddy@linux.vnet.ibm.com>

Most of the power processor generation performance monitoring
unit (PMU) driver code is bundled in the kernel and one of those
is enabled/registered based on the oprofile_cpu_type check at
the boot.

But things get little tricky incase of "compat" mode boot.
IBM POWER System Server based processors has a compactibility
mode feature, which simpily put is, Nth generation processor
(lets say POWER8) will act and appear in a mode consistent
with an earlier generation (N-1) processor (that is POWER7).
And in this "compat" mode boot, kernel modify the
"oprofile_cpu_type" to be Nth generation (POWER8). If Nth
generation pmu driver is bundled (POWER8), it gets registered.

Key dependency here is to have distro support for latest
processor performance monitoring support. Patch here adds
a generic "compat-mode" performance monitoring driver to
be register in absence of powernv platform specific pmu driver.

Driver supports only "cycles" and "instruction" events.
"0x0001e" used as event code for "cycles" and "0x00002"
used as event code for "instruction" events. New file
called "generic-compat-pmu.c" is created to contain the driver
specific code. And base raw event code format modeled
on PPMU_ARCH_207S.

Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
 arch/powerpc/perf/Makefile             |   3 +-
 arch/powerpc/perf/core-book3s.c        |   2 +-
 arch/powerpc/perf/generic-compat-pmu.c | 241 +++++++++++++++++++++++++++++++++
 arch/powerpc/perf/internal.h           |   1 +
 4 files changed, 245 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/perf/generic-compat-pmu.c

diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index ab26df5bacb9..c155dcbb8691 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -5,7 +5,8 @@ obj-$(CONFIG_PERF_EVENTS)	+= callchain.o perf_regs.o
 obj-$(CONFIG_PPC_PERF_CTRS)	+= core-book3s.o bhrb.o
 obj64-$(CONFIG_PPC_PERF_CTRS)	+= ppc970-pmu.o power5-pmu.o \
 				   power5+-pmu.o power6-pmu.o power7-pmu.o \
-				   isa207-common.o power8-pmu.o power9-pmu.o
+				   isa207-common.o power8-pmu.o power9-pmu.o \
+				   generic-compat-pmu.o
 obj32-$(CONFIG_PPC_PERF_CTRS)	+= mpc7450-pmu.o
 
 obj-$(CONFIG_PPC_POWERNV)	+= imc-pmu.o
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index a96f9420139c..a66fb9c01c9e 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2318,7 +2318,7 @@ static int __init init_ppc64_pmu(void)
 	else if (!init_ppc970_pmu())
 		return 0;
 	else
-		return -ENODEV;
+		return init_generic_compat_pmu();
 }
 early_initcall(init_ppc64_pmu);
 #endif
diff --git a/arch/powerpc/perf/generic-compat-pmu.c b/arch/powerpc/perf/generic-compat-pmu.c
new file mode 100644
index 000000000000..5981ef742648
--- /dev/null
+++ b/arch/powerpc/perf/generic-compat-pmu.c
@@ -0,0 +1,241 @@
+/*
+ * Performance counter support.
+ *
+ * Copyright 2019 Madhavan Srinivasan, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or later version.
+ */
+
+#define pr_fmt(fmt)	"generic-compat-pmu: " fmt
+
+#include "isa207-common.h"
+
+/*
+ * Raw event encoding:
+ *
+ *        60        56        52        48        44        40        36        32
+ * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - |
+ *
+ *        28        24        20        16        12         8         4         0
+ * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - |
+ *                                 [ pmc ]   [unit ]   [ ]   m   [    pmcxsel    ]
+ *                                                     |     |
+ *                                                     |     *- mark
+ *                                                     |
+ *                                                     |
+ *                                                     *- combine
+ *
+ * Below uses IBM bit numbering.
+ *
+ * MMCR1[x:y] = unit    (PMCxUNIT)
+ * MMCR1[24]   = pmc1combine[0]
+ * MMCR1[25]   = pmc1combine[1]
+ * MMCR1[26]   = pmc2combine[0]
+ * MMCR1[27]   = pmc2combine[1]
+ * MMCR1[28]   = pmc3combine[0]
+ * MMCR1[29]   = pmc3combine[1]
+ * MMCR1[30]   = pmc4combine[0]
+ * MMCR1[31]   = pmc4combine[1]
+ *
+ */
+
+/*
+ * Some power9 event codes.
+ */
+#define EVENT(_name, _code)	_name = _code,
+
+enum {
+EVENT(PM_CYC,					0x0001e)
+EVENT(PM_INST_CMPL,				0x00002)
+};
+
+#undef EVENT
+
+GENERIC_EVENT_ATTR(cpu-cycles,			PM_CYC);
+GENERIC_EVENT_ATTR(instructions,		PM_INST_CMPL);
+
+static struct attribute *generic_compat_events_attr[] = {
+	GENERIC_EVENT_PTR(PM_CYC),
+	GENERIC_EVENT_PTR(PM_INST_CMPL),
+	NULL
+};
+
+static struct attribute_group generic_compat_pmu_events_group = {
+	.name = "events",
+	.attrs = generic_compat_events_attr,
+};
+
+PMU_FORMAT_ATTR(event,		"config:0-19");
+PMU_FORMAT_ATTR(pmcxsel,	"config:0-7");
+PMU_FORMAT_ATTR(mark,		"config:8");
+PMU_FORMAT_ATTR(combine,	"config:10-11");
+PMU_FORMAT_ATTR(unit,		"config:12-15");
+PMU_FORMAT_ATTR(pmc,		"config:16-19");
+
+static struct attribute *generic_compat_pmu_format_attr[] = {
+	&format_attr_event.attr,
+	&format_attr_pmcxsel.attr,
+	&format_attr_mark.attr,
+	&format_attr_combine.attr,
+	&format_attr_unit.attr,
+	&format_attr_pmc.attr,
+	NULL,
+};
+
+static struct attribute_group generic_compat_pmu_format_group = {
+	.name = "format",
+	.attrs = generic_compat_pmu_format_attr,
+};
+
+static const struct attribute_group *generic_compat_pmu_attr_groups[] = {
+	&generic_compat_pmu_format_group,
+	&generic_compat_pmu_events_group,
+	NULL,
+};
+
+static int compat_generic_events[] = {
+	[PERF_COUNT_HW_CPU_CYCLES] =			PM_CYC,
+	[PERF_COUNT_HW_INSTRUCTIONS] =			PM_INST_CMPL,
+};
+
+#define C(x)	PERF_COUNT_HW_CACHE_##x
+
+/*
+ * Table of generalized cache-related events.
+ * 0 means not supported, -1 means nonsensical, other values
+ * are event codes.
+ */
+static int generic_compat_cache_events[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
+	[ C(L1D) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+	},
+	[ C(L1I) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+	},
+	[ C(LL) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+	},
+	[ C(DTLB) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+	},
+	[ C(ITLB) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+	},
+	[ C(BPU) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = 0,
+			[ C(RESULT_MISS)   ] = 0,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+	},
+	[ C(NODE) ] = {
+		[ C(OP_READ) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+		[ C(OP_WRITE) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+		[ C(OP_PREFETCH) ] = {
+			[ C(RESULT_ACCESS) ] = -1,
+			[ C(RESULT_MISS)   ] = -1,
+		},
+	},
+};
+
+#undef C
+
+static struct power_pmu generic_compat_pmu = {
+	.name			= "GENERIC_COMPAT",
+	.n_counter		= MAX_PMU_COUNTERS,
+	.add_fields		= ISA207_ADD_FIELDS,
+	.test_adder		= ISA207_TEST_ADDER,
+	.compute_mmcr		= isa207_compute_mmcr,
+	.get_constraint		= isa207_get_constraint,
+	.disable_pmc		= isa207_disable_pmc,
+	.flags			= PPMU_HAS_SIER | PPMU_ARCH_207S,
+	.n_generic		= ARRAY_SIZE(compat_generic_events),
+	.generic_events		= compat_generic_events,
+	.cache_events		= &generic_compat_cache_events,
+	.attr_groups		= generic_compat_pmu_attr_groups,
+};
+
+int init_generic_compat_pmu(void)
+{
+	int rc = 0;
+
+	rc = register_power_pmu(&generic_compat_pmu);
+	if (rc)
+		return rc;
+
+	/* Tell userspace that EBB is supported */
+	cur_cpu_spec->cpu_user_features2 |= PPC_FEATURE2_EBB;
+
+	return 0;
+}
diff --git a/arch/powerpc/perf/internal.h b/arch/powerpc/perf/internal.h
index e54d524d4283..185a40d1adff 100644
--- a/arch/powerpc/perf/internal.h
+++ b/arch/powerpc/perf/internal.h
@@ -14,3 +14,4 @@ extern int init_power6_pmu(void);
 extern int init_power7_pmu(void);
 extern int init_power8_pmu(void);
 extern int init_power9_pmu(void);
+extern int init_generic_compat_pmu(void);
-- 
2.7.4


^ permalink raw reply related

* Re: [PATCH] ASoC: imx-pcm: Switch to SPDX identifier
From: Fabio Estevam @ 2019-04-04 12:09 UTC (permalink / raw)
  To: Andra Danciu
  Cc: Daniel Baluta, Linux-ALSA, linux-kernel, timur, Xiubo Li,
	linuxppc-dev, Sascha Hauer, Takashi Iwai, Liam Girdwood,
	Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
	Sascha Hauer, Shawn Guo,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190404120703.30054-1-andradanciu1997@gmail.com>

On Thu, Apr 4, 2019 at 9:07 AM Andra Danciu <andradanciu1997@gmail.com> wrote:
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Andra Danciu <andradanciu1997@gmail.com>
> ---
>  sound/soc/fsl/imx-pcm.h | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
> index 133c4470acad..3ce2f437e645 100644
> --- a/sound/soc/fsl/imx-pcm.h
> +++ b/sound/soc/fsl/imx-pcm.h
> @@ -1,13 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

This is not correct...

>  /*
>   * Copyright 2009 Sascha Hauer <s.hauer@pengutronix.de>
>   *
>   * This code is based on code copyrighted by Freescale,
>   * Liam Girdwood, Javier Martin and probably others.
> - *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.

as it does not match with the original license text.

You should use:

/* SPDX-License-Identifier: GPL-2.0+ */

^ permalink raw reply

* Re: [PATCH v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds
From: Joel Stanley @ 2019-04-04 12:17 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20190329095318.GJ3969@gate.crashing.org>

On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > -     NOTES :kernel :notes
> > +     NOTES
>
> I think this still need to be
>
>         NOTES :kernel
>
> or the linker will complain.  Did you try to build ppc64_defconfig?

Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
leaving in/removing the :kernel annotation in a bunch of places and as
long as I had it in the first spot, the kernel linked.

Shall I respin with this added?

> (And I do not know if there are any tools that expect the notes in a phdr,
> or even specifically the second phdr).
>
>
> Segher

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox