Re: ARC stable backport request for 4.4 and 4.2
On Wed, Jul 13, 2016 at 01:44:31PM -0700, Vineet Gupta wrote:
> Hi,
>
> Could you please backport the following upstream commits for v4.4 and v4.2
>
> 4d0cb15fccd1db9 ("ARCv2: Check for LL-SC livelock only if LLSC is enabled")
> b31ac42697bef4a ("ARCv2: LLSC: software backoff is NOT needed starting
> HS2.1c")
Applied to 4.4-stable, thanks.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC stable backport request
On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote: > Hi, > > Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler mnemonic". > Newer binutils don't like ASL instruction and fail to build kernels prior to > v4.4 > which added this fix. Didn't apply to 3.14-stable :( ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC stable backport request
On Tue, Aug 02, 2016 at 09:45:56AM +0200, Jiri Slaby wrote: > On 08/02/2016, 09:00 AM, Greg KH wrote: > > On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote: > >> Hi, > >> > >> Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler > >> mnemonic". > >> Newer binutils don't like ASL instruction and fail to build kernels prior > >> to v4.4 > >> which added this fix. > > > > Didn't apply to 3.14-stable :( > > I have a backport in 3.12. There was a conflict in comments. Could you > try that? > > commit fa5d506592a759b7848a59d1d5a025af8c9a7a6c > Author: Vineet Gupta > Date: Thu Nov 5 09:13:31 2015 +0530 > > ARC: use ASL assembler mnemonic > > commit a6416f57ce57fb390b6ee30b12c01c29032a26af upstream. > > ARCompact and ARCv2 only have ASL, while binutils used to support LSL as > a alias mnemonic. > > Newer binutils (upstream) don't want to do that so replace it. > > Signed-off-by: Vineet Gupta > Signed-off-by: Jiri Slaby Ah, that worked, thanks, now applied. greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC stable backport request
On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote: > Hi, > > Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler mnemonic". > Newer binutils don't like ASL instruction and fail to build kernels prior to > v4.4 > which added this fix. Fails to apply to 3.14-stable :( ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC stable backport request
On Mon, Aug 22, 2016 at 10:36:20AM -0700, Vineet Gupta wrote:
> Hi Stable Team,
>
> Could you please backport upstream 20d780374c81c ("ARC: build: Better way to
> detect ISA compatible toolchain")
>
> This is needed to let kernel building with newer gcc 6.x based tools.
Applied to 4.4-stable, thanks.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized
On Sat, Nov 12, 2016 at 01:27:12PM +, Jonathan Cameron wrote:
> On 11/11/16 19:49, Arnd Bergmann wrote:
> > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote:
> >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote:
> >>>
> >>> Please merge these directly if you are happy with the result.
> >>
> >> I will take this.
> >
> > Thanks a lot!
> >
> >> I do see two warnings, but they both seem to be valid and recent,
> >> though, so I have no issues with the spurious cases.
> >
> > Ok, both of them should have my fixes coming your way already.
> >
> >> Warning #1:
> >>
> >> sound/soc/qcom/lpass-platform.c: In function
> >> ‘lpass_platform_pcmops_open’:
> >> sound/soc/qcom/lpass-platform.c:83:29: warning: ‘dma_ch’ may be used
> >> uninitialized in this function [-Wmaybe-uninitialized]
> >> drvdata->substream[dma_ch] = substream;
> >> ~~~^~~
> >>
> >> and 'dma_ch' usage there really is crazy and wrong. Broken by
> >> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
> >
> > Right, the patches crossed here, the bugfix patch that introduced
> > this came into linux-next over the kernel summit, and the fix I
> > sent on Tuesday made it into Mark Brown's tree on Wednesday but not
> > before you pulled alsa tree. It should be fixed the next time you
> > pull from the alsa tree, the commit is
> >
> > 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number")
> >
> >> Warning #2 is not a real bug, but it's reasonable that gcc doesn't
> >> know that storage_bytes (chip->read_size) has to be 2/4. Again,
> >> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple:
> >> Align 16 bit big endian value of raw reads"), so you didn't see it.
> >
> > This is the one I mentioned in the commit message as one that
> > is fixed in linux-next and that should make it in soon.
> >
> >> drivers/iio/temperature/maxim_thermocouple.c: In function
> >> ‘maxim_thermocouple_read_raw’:
> >> drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ‘ret’
> >> may be used uninitialized in this function [-Wmaybe-uninitialized]
> >> if (ret)
> >>^
> >> drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ‘ret’ was
> >> declared here
> >> int ret;
> >> ^~~
> >>
> >> and I guess that code can just initialize 'ret' to '-EINVAL' or
> >> something to just make the theoretical "somehow we had a wrong
> >> chip->read_size" case error out cleanly.
> >
> > Right, that was my conclusion too. I sent the bugfix on Oct 25
> > for linux-next but it didn't make it in until this Monday, after
> > you pulled the patch that introduced it on Oct 29.
> >
> > The commit in staging-testing is
> > 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in
> > read()")
> >
> > Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b'
> > branch, so I suspect you were not planning to send this before the
> > merge window. Could you make sure this ends up in v4.9 so we get
> > a clean build when -Wmaybe-uninitialized gets enabled again?
> I'll queue this up and send a pull to Greg tomorrow.
>
> Was highly doubtful that a false warning suppression (be it an
> understandable one) was worth sending mid cycle, hence it was
> taking the slow route.
I can just cherry-pick this, no need to send a separate pull request.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized
On Sun, Nov 13, 2016 at 09:47:41AM +0100, Greg KH wrote:
> On Sat, Nov 12, 2016 at 01:27:12PM +, Jonathan Cameron wrote:
> > On 11/11/16 19:49, Arnd Bergmann wrote:
> > > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote:
> > >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote:
> > >>>
> > >>> Please merge these directly if you are happy with the result.
> > >>
> > >> I will take this.
> > >
> > > Thanks a lot!
> > >
> > >> I do see two warnings, but they both seem to be valid and recent,
> > >> though, so I have no issues with the spurious cases.
> > >
> > > Ok, both of them should have my fixes coming your way already.
> > >
> > >> Warning #1:
> > >>
> > >> sound/soc/qcom/lpass-platform.c: In function
> > >> ‘lpass_platform_pcmops_open’:
> > >> sound/soc/qcom/lpass-platform.c:83:29: warning: ‘dma_ch’ may be used
> > >> uninitialized in this function [-Wmaybe-uninitialized]
> > >> drvdata->substream[dma_ch] = substream;
> > >> ~~~^~~
> > >>
> > >> and 'dma_ch' usage there really is crazy and wrong. Broken by
> > >> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
> > >
> > > Right, the patches crossed here, the bugfix patch that introduced
> > > this came into linux-next over the kernel summit, and the fix I
> > > sent on Tuesday made it into Mark Brown's tree on Wednesday but not
> > > before you pulled alsa tree. It should be fixed the next time you
> > > pull from the alsa tree, the commit is
> > >
> > > 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number")
> > >
> > >> Warning #2 is not a real bug, but it's reasonable that gcc doesn't
> > >> know that storage_bytes (chip->read_size) has to be 2/4. Again,
> > >> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple:
> > >> Align 16 bit big endian value of raw reads"), so you didn't see it.
> > >
> > > This is the one I mentioned in the commit message as one that
> > > is fixed in linux-next and that should make it in soon.
> > >
> > >> drivers/iio/temperature/maxim_thermocouple.c: In function
> > >> ‘maxim_thermocouple_read_raw’:
> > >> drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ‘ret’
> > >> may be used uninitialized in this function [-Wmaybe-uninitialized]
> > >> if (ret)
> > >>^
> > >> drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ‘ret’ was
> > >> declared here
> > >> int ret;
> > >> ^~~
> > >>
> > >> and I guess that code can just initialize 'ret' to '-EINVAL' or
> > >> something to just make the theoretical "somehow we had a wrong
> > >> chip->read_size" case error out cleanly.
> > >
> > > Right, that was my conclusion too. I sent the bugfix on Oct 25
> > > for linux-next but it didn't make it in until this Monday, after
> > > you pulled the patch that introduced it on Oct 29.
> > >
> > > The commit in staging-testing is
> > > 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in
> > > read()")
> > >
> > > Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b'
> > > branch, so I suspect you were not planning to send this before the
> > > merge window. Could you make sure this ends up in v4.9 so we get
> > > a clean build when -Wmaybe-uninitialized gets enabled again?
> > I'll queue this up and send a pull to Greg tomorrow.
> >
> > Was highly doubtful that a false warning suppression (be it an
> > understandable one) was worth sending mid cycle, hence it was
> > taking the slow route.
>
> I can just cherry-pick this, no need to send a separate pull request.
Now done and sent to Linus, so all should be good here.
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: 4.2+ stable inclusion request: ARCv2: save r30 on kernel entry as gcc uses it for code-gen
On Fri, Apr 28, 2017 at 11:57:36AM -0700, Vineet Gupta wrote:
> Hi,
>
> Can we please backport upstream ecd43afdbe72017aefe48080631eb625e177ef4d
> ("ARCv2:
> save r30 on kernel entry as gcc uses it for code-gen") to 4.2 to 4.9 kernels.
>
> While the issue cites gcc, it is general deficiency of kernel as userspace
> programs can modify r30 register in hand/inline assembly and those will not be
> preserved without this change.
Queued up for 4.9 and 4.4 stable trees, thanks.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC PATCH 1/5] serial: arc: Remove __init marking from early write
On Tue, Jul 18, 2017 at 12:29:59PM +0800, Jeffy Chen wrote: > The earlycon would be alive outside the init code in these cases: > 1/ we have keep_bootcon in cmdline. > 2/ we don't have a real console to switch to. > > So remove the __init marking to avoid invalid memory access. > > Signed-off-by: Jeffy Chen > --- > I can't apply "RFC" patches. If you have tested and found this series to be correct, can you resend it without that on the patch? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Add patch "arch: define weak abort()" to 4.14-stable tree
On Mon, Feb 05, 2018 at 03:25:58PM +, Evgeniy Didin wrote: > Patch subject:"arch: define weak abort()" > Commit ID:7c2c11b208be > Reason: While building mpi.ko module with lastest stable Linux > v4.14.17 an error occured: > >ERROR: "abort" [lib/mpi/mpi.ko] undefined! > Kernel version: 4.14.x What kernel config is causing this build error? I don't see it here, nor have I seen it reported in any other built test. And what kernel version did this break on? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Add patch "kernel/exit.c: export abort() to modules" to 4.14-stable tree
On Mon, Feb 05, 2018 at 03:30:19PM +, Evgeniy Didin wrote: > Patch subject:"kernel/exit.c: export abort() to modules" > Commit ID:dc8635b78cd8 > Reason: While building mpi.ko module with lastest stable Linux > v4.14.17 an error occured: > >ERROR: "abort" [lib/mpi/mpi.ko] undefined! > Kernel version: 4.14.x Same questions as before, what config is causing this, and when did it break? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Add patch "kernel/exit.c: export abort() to modules" to 4.14-stable tree
On Mon, Feb 05, 2018 at 03:30:19PM +, Evgeniy Didin wrote: > Patch subject:"kernel/exit.c: export abort() to modules" > Commit ID:dc8635b78cd8 > Reason: While building mpi.ko module with lastest stable Linux > v4.14.17 an error occured: > >ERROR: "abort" [lib/mpi/mpi.ko] undefined! > Kernel version: 4.14.x The patch does not apply to the 4.14.y kernel tree :( Can you please provide a working backport? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Add patch "kernel/exit.c: export abort() to modules" to 4.14-stable tree
On Thu, Feb 08, 2018 at 06:04:12PM +0100, Greg KH wrote: > On Mon, Feb 05, 2018 at 03:30:19PM +, Evgeniy Didin wrote: > > Patch subject: "kernel/exit.c: export abort() to modules" > > Commit ID: dc8635b78cd8 > > Reason: While building mpi.ko module with lastest stable Linux > > v4.14.17 an error occured: > > >ERROR: "abort" [lib/mpi/mpi.ko] undefined! > > Kernel version: 4.14.x > > The patch does not apply to the 4.14.y kernel tree :( > > Can you please provide a working backport? Ah, the other patch needs to go first, please always tell me what order to apply patches in. Otherwise I will get it wrong (as this just proved to be the case...) thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] devres: Really align data field to unsigned long long
On Sun, Jul 08, 2018 at 08:56:21PM +0300, Alexey Brodkin wrote: > Depending on ABI "long long" type of a particular 32-bit CPU > might be aligned by either word (32-bits) or double word (64-bits). > Make sure "data" is really 64-bit aligned for any 32-bit CPU. > > At least for 32-bit ARC cores ABI requires "long long" types > to be aligned by normal 32-bit word. This makes "data" field aligned to > 12 bytes. Which is still OK as long as we use 32-bit data only. > > But once we want to use native atomic64_t type (i.e. when we use special > instructions LLOCKD/SCONDD for accessing 64-bit data) we easily hit > misaligned access exception. > > That's because even on CPUs capable of non-aligned data access LL/SC > instructions require strict alignment. > > Signed-off-by: Alexey Brodkin > Cc: Thomas Gleixner > Cc: sta...@vger.kernel.org > --- > > Changes v1 -> v2: > > * Reworded commit message > * Inserted comment right in source [Thomas] > > drivers/base/devres.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) Always use scripts/get_maintainer.pl to properly cc: the needed developer/maintainer. As it is, this patch is going to get dropped on the floor, sorry... greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] devres: Really align data field to unsigned long long
On Sun, Jul 08, 2018 at 09:45:31PM +0300, Алексей Бродкин wrote: > Hi Greg, > > вс, 8 июл. 2018 г. в 21:40, Greg KH : > > > > On Sun, Jul 08, 2018 at 08:56:21PM +0300, Alexey Brodkin wrote: > > > Depending on ABI "long long" type of a particular 32-bit CPU > > > might be aligned by either word (32-bits) or double word (64-bits). > > > Make sure "data" is really 64-bit aligned for any 32-bit CPU. > > > > > > At least for 32-bit ARC cores ABI requires "long long" types > > > to be aligned by normal 32-bit word. This makes "data" field aligned to > > > 12 bytes. Which is still OK as long as we use 32-bit data only. > > > > > > But once we want to use native atomic64_t type (i.e. when we use special > > > instructions LLOCKD/SCONDD for accessing 64-bit data) we easily hit > > > misaligned access exception. > > > > > > That's because even on CPUs capable of non-aligned data access LL/SC > > > instructions require strict alignment. > > > > > > Signed-off-by: Alexey Brodkin > > > Cc: Thomas Gleixner > > > Cc: sta...@vger.kernel.org > > > --- > > > > > > Changes v1 -> v2: > > > > > > * Reworded commit message > > > * Inserted comment right in source [Thomas] > > > > > > drivers/base/devres.c | 8 ++-- > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > Always use scripts/get_maintainer.pl to properly cc: the needed > > developer/maintainer. As it is, this patch is going to get dropped on > > the floor, sorry... > > Right I was way too relaxed dealing with very generic stuff which might get > not that much of attention as more narrow topics or subsystems. But anyways > get_maintainer.pl says you're the guy so do I need to do anything extra still > or > it's OK for this time? Please resend it properly, it is not in my patch queue anywhere... greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RESEND PATCH v2] devres: Really align data field to unsigned long long
On Mon, Jul 09, 2018 at 07:44:44AM +0300, Alexey Brodkin wrote:
> Depending on ABI "long long" type of a particular 32-bit CPU
> might be aligned by either word (32-bits) or double word (64-bits).
> Make sure "data" is really 64-bit aligned for any 32-bit CPU.
>
> At least for 32-bit ARC cores ABI requires "long long" types
> to be aligned by normal 32-bit word. This makes "data" field aligned to
> 12 bytes. Which is still OK as long as we use 32-bit data only.
>
> But once we want to use native atomic64_t type (i.e. when we use special
> instructions LLOCKD/SCONDD for accessing 64-bit data) we easily hit
> misaligned access exception.
So is this something you hit today? If not, why is this needed for
stable kernels?
> That's because even on CPUs capable of non-aligned data access LL/SC
> instructions require strict alignment.
Are you going to hit this code with all types of structures? What
happens when you do have an unaligned access?
>
> Signed-off-by: Alexey Brodkin
> Cc: Greg Kroah-Hartman
You didn't cc: this address :(
> Cc: Thomas Gleixner
> Cc: sta...@vger.kernel.org
> ---
>
> Changes v1 -> v2:
>
> * Reworded commit message
> * Inserted comment right in source [Thomas]
>
> drivers/base/devres.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index f98a097e73f2..466fa59c866a 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -24,8 +24,12 @@ struct devres_node {
>
> struct devres {
> struct devres_node node;
> - /* -- 3 pointers */
> - unsigned long long data[]; /* guarantee ull alignment */
> + /*
> + * Depending on ABI "long long" type of a particular 32-bit CPU
> + * might be aligned by either word (32-bits) or double word (64-bits).
> + * Make sure "data" is really 64-bit aligned for any 32-bit CPU.
> + */
> + unsigned long long data[] __aligned(sizeof(unsigned long
> long));
> };
Does this change the padding today for any other arches? If so, does
the increased memory usage cause any noticable issues?
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 5/5] Lib: sort.h: replace int size with size_t size in the swap function
On Sat, Mar 30, 2019 at 08:15:49PM +, George Spelvin wrote: > On Sat, 30 Mar 2019 at 19:38:26 +0100 greh k-h wrote; > > On Sat, Mar 30, 2019 at 07:43:53PM +0300, Andrey Abramov wrote: > >> Replace int type with size_t type of the size argument > >> in the swap function, also affect all its dependencies. > > > > This says _what_ the patch does, but it gives no clue as to _why_ you > > are doing this. Neither did your 0/5 patch :( > > > > Why make this change? Nothing afterward depends on it from what I can > > tell, so why is it needed? > > It's just a minor cleanup, making things less surprising for future > programmers. As I wrote in a comment in my patches, using a signed type > for an object size is definitely a wart; ever since C89 it's expected > you'd use size_t for the purpose. You did not say that in this commit log :) > The connection is that it's a natural consequence of doing a pass over > every call site. > > You're right it could be dropped from the series harmlessly, but it > comes from the same work. But it's all of *three* call sites in the kernel > which are affected. Surely that's not an unreasonable amount of churn > to clean up a wart? If you think it is a wart, wonderful, yes, let's fix it up. But again, a changelog comment should explain _why_ a commit is needed, not _what_ it does, as we can see from the diff itself exactly what the commit does. thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] DRM: ARC: PGU: interlaced mode not supported
On Wed, Mar 11, 2020 at 04:13:10PM +0300, Eugeniy Paltsev wrote: > Filter out interlaced modes as they are not supported by ARC PGU > hardware. > > Signed-off-by: Eugeniy Paltsev > --- > drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c > b/drivers/gpu/drm/arc/arcpgu_crtc.c > index 8ae1e1f97a73..c854066d4c75 100644 > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c > @@ -67,6 +67,9 @@ static enum drm_mode_status arc_pgu_crtc_mode_valid(struct > drm_crtc *crtc, > long rate, clk_rate = mode->clock * 1000; > long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */ > > + if (mode->flags & DRM_MODE_FLAG_INTERLACE) > + return MODE_NO_INTERLACE; > + > rate = clk_round_rate(arcpgu->clk, clk_rate); > if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0)) > return MODE_OK; > -- > 2.21.1 > This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [question] De-registration does not remove port
On Wed, Jun 23, 2021 at 11:42:36AM +0530, Saubhik Mukherjee wrote: > In drivers/tty/serial/arc_uart.c, arc_serial_remove always returns 0, > instead of calling uart_remove_one_port to remove uart port from serial > core. The comment says "This will be never be called". In my understanding, > a port added using uart_add_one_port should be removed during > de-registration. > > Is there a reason for this behavior? Did you test the code to see if that function will ever be called? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [question] De-registration does not remove port
On Thu, Jun 24, 2021 at 06:33:01PM +0530, Saubhik Mukherjee wrote: > On 6/23/21 12:44 PM, Greg KH wrote: > > On Wed, Jun 23, 2021 at 11:42:36AM +0530, Saubhik Mukherjee wrote: > > > In drivers/tty/serial/arc_uart.c, arc_serial_remove always returns 0, > > > instead of calling uart_remove_one_port to remove uart port from serial > > > core. The comment says "This will be never be called". In my > > > understanding, > > > a port added using uart_add_one_port should be removed during > > > de-registration. > > > > > > Is there a reason for this behavior? > > > > Did you test the code to see if that function will ever be called? > > I would like to reformulate the question: Suppose arc_serial_remove is never > called. Then I would like to know how the driver de-registration is > organized since the UART port is never removed? I would like to reiterate my original question, have you tested this? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> pgd = a27bd01c
> [] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil
> raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : []lr : []psr: 6013
> sp : e376bbe0 ip : fp : c1e2921c
> r10: 0002 r9 : c1dda730 r8 :
> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
>support more than 32 bits, even though supersections in theory allow
>up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
>XPA supports up to 60 bits in theory, but 40 bits are more than
>anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
>addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
>addressing. There is no highmem support on RISC-V, so anything
>above 2GB is unused, but it might be useful to eventually support
>CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Acked-by: Thomas Bogendoerfer
> Reviewed-by: Stefan Agner
> Tested-by: Stefan Agner
> Acked-by: Mike Rapoport
> Link:
> https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.ste...@agner.ch/
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Sasha Levin
> [florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
> Signed-off-by: Florian Fainelli
All now queued up, thanks.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/14] nds32: fix access_ok() checks in get/put_user
On Tue, Feb 15, 2022 at 10:18:15AM +0100, Arnd Bergmann wrote:
> On Mon, Feb 14, 2022 at 6:01 PM Christoph Hellwig wrote:
> >
> > On Mon, Feb 14, 2022 at 05:34:41PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The get_user()/put_user() functions are meant to check for
> > > access_ok(), while the __get_user()/__put_user() functions
> > > don't.
> > >
> > > This broke in 4.19 for nds32, when it gained an extraneous
> > > check in __get_user(), but lost the check it needs in
> > > __put_user().
> >
> > Can we follow the lead of MIPS (which this was originally copied
> > from I think) and kill the pointless __get/put_user_check wrapper
> > that just obsfucate the code?
>
> I had another look, but I think that would be a bigger change than
> I want to have in a fix for stable backports, as nds32 also uses
> the _check versions in __{get,put}_user_error.
Don't worry about stable backports first, get it correct and merged and
then worry about them if you really have to.
If someone cares about nds32 for stable kernels, they can do the
backport work :)
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
