On Thursday 14 January 2016 05:26:58 Vineet Gupta wrote:
> > +/*
> > + * We don't have to worry about legacy ISA devices, so nothing to do here
> > + */
> > +resource_size_t pcibios_align_resource(void *data, const struct resource
> > *res,
> > + resource_size_t size, r
On Thursday 14 January 2016 10:51:32 Vineet Gupta wrote:
> >>
> >> A somewhat nicer method would be to have callback pointers in struct
> >> pci_host_bridge, and call those when they are non-NULL so we can
> >> remove the global pcibios_* functions from the API. That would also
> >> bring us a big
On Monday 01 February 2016 18:07:45 Joao Pinto wrote:
> This patch adds a new driver that will be the reference platform driver
> for all PCI RC IP Protoyping Kits based on ARC SDP.
> This patch is composed by:
>
> -MAINTAINERS file was updated to include the new driver
> -Documentation/devicetree
On Tuesday 02 February 2016 17:14:49 Bjorn Helgaas wrote:
> On Tue, Feb 02, 2016 at 09:25:25PM +0100, Arnd Bergmann wrote:
> > On Monday 01 February 2016 18:07:45 Joao Pinto wrote:
> > > +static void synopsys_pcie_establish_link(struct pcie_port *pp)
> > > +
On Wednesday 03 February 2016 12:38:44 Bjorn Helgaas wrote:
> On Wed, Feb 03, 2016 at 06:12:00PM +, Joao Pinto wrote:
>
> > - replace "snps,pcie-synopsys" for "snps,pcie-synopsys-ipk"?
>
> This is a question for Arnd.
>
> > - rename the driver to pcie-synopsys-ipk?
>
> It doesn't seem neces
On Thursday 04 February 2016 11:10:55 Joao Pinto wrote:
> > The "synopsys" can go away, it's already in the vendor field of the
> > string. "ipk" is still a bit unspecific, I was hoping to see a specific
> > chip and/or version of the PCIe part. Something like
> >
> > compatible = "snps,ipk2
On Thursday 04 February 2016 14:09:26 Joao Pinto wrote:
> Hi Bjorn and Arnd,
>
> Removing the irq_handler causes the irq request to fail because in
> request_threaded_irq() both handler and thread_fn are NULL.
>
> What's the typical procedure for this?
>
Don't call request_irq? ;-)
Arn
On Friday 05 February 2016 10:44:29 Joao Pinto wrote:
> Hi,
>
> On 2/4/2016 11:43 PM, Bjorn Helgaas wrote:
> >> What do you think?
> >
> > I don't think the "dw" part is relevant (none of the other
> > DesignWare-based drivers includes it in the driver or file name).
> >
> > How do people typica
On Friday 05 February 2016 14:51:39 Joao Pinto wrote:
>
> It is a driver that is useful for PCIe RC prototyping and to be a reference
> platform driver for DesignWare PCIe RC, I don't know if merging some of the
> driver's code into pcie-designware is really necessary depends on the
> usefulness
On Friday 05 February 2016 17:32:48 Bjorn Helgaas wrote:
> On Fri, Feb 05, 2016 at 03:39:05PM +0100, Arnd Bergmann wrote:
> > On Friday 05 February 2016 10:44:29 Joao Pinto wrote:
> > I think in this case, we should do this completely differently:
> >
> > How about pu
On Thursday 10 March 2016, Vineet Gupta wrote:
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
>
> Th
On Thursday 10 March 2016, Lada Trimasova wrote:
> Driver is 8250, kernel is built for BE arc, nsim option in model
> "nsim_isa_big_endian = 1".
>
> With current "readl" and "writel" implementation for ARC we read word from
> memory without any endianess manipulation. So in case of little endian
On Friday 18 March 2016 15:50:11 Vineet Gupta wrote:
> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be
> healthy in small doses At least it keeps the door open for future discussion
> with gcc guys !
FWIW, testing on ARM with gcc-6.0 -O3, I also get tons of maybe-uninit
On Friday 18 March 2016 14:16:23 Vineet Gupta wrote:
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index fed12f39d8ce..aeb101e8e674 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -48,9 +48,14 @@ endif
> upto_gcc44:= $(call cc-ifversion, -le, 0404, y)
> atleast_gcc44
On Friday 18 March 2016 16:13:28 Vineet Gupta wrote:
> On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote:
> > On Friday 18 March 2016 15:50:11 Vineet Gupta wrote:
> >> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be
> >> healthy in small d
On Friday 18 March 2016 18:31:53 Vineet Gupta wrote:
>
> > On a related note, I have submitted a patch that turns
> > CONFIG_CC_OPTIMIZE_FOR_SIZE
> > into a choice statement, so we actually get the -Wmaybe-uninitialized
> > warnings
> > in an allyesconfig or allmodconfig build. It would be trivi
On Monday 02 May 2016 05:13:46 Vineet Gupta wrote:
> On Saturday 30 April 2016 02:59 AM, James Hogan wrote:
> > The newer renameat2 syscall provides all the functionality provided by
> > the renameat syscall and adds flags, so future architectures won't need
> > to include renameat.
> >
> > Therefo
waps on ioread32be() on Big Endian systems.
>
> So provide our versions of big endian IO accessors to ensure io barrier
> calls while also keeping them optimal
>
> Suggested-by: Arnd Bergmann
> Cc: sta...@vger.kernel.org [4.2+]
> Signed-off-by: Vineet Gupta
Yes, that look
7;t need to see it without
COMPILE_TEST elsewhere, and we can avoid the warnings by only
building on 32-bit architectures even with CONFIG_COMPILE_TEST.
Signed-off-by: Arnd Bergmann
---
drivers/irqchip/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/Kconfig b/drivers/
On Friday 13 May 2016 14:05:41 Vineet Gupta wrote:
> On Friday 13 May 2016 01:54 PM, Marc Zyngier wrote:
> > On 12/05/16 22:03, Arnd Bergmann wrote:
> ...
> >>
> >> config EZNPS_GIC
> >> bool "NPS400 Global Interrupt Manager (GIM)"
&g
On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> +CC Arnd, Michal
>
> Hi Geert, Arnd
>
> Need some guidance here.
>
> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> >> 48 error regressions:
> >> > + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad
> >> >
sy to trigger, and I will send them for inclusion
in v4.10.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann
---
Makefile | 10 ++
arch/arc/Makefile | 4 +++-
scripts/Makefile.ubsan
On Thursday, October 27, 2016 11:11:18 AM CEST Thomas Petazzoni wrote:
> On Thu, 27 Oct 2016 09:07:55 +, Alexey Brodkin wrote:
>
> > > axs101 is using a 770 core, while the toolchain is built for the HS38
> > > core. I'm somewhat surprised that a single ARC toolchain cannot produce
> > > code
On Thursday, October 27, 2016 10:21:16 AM CEST Vineet Gupta wrote:
>
> On 10/27/2016 02:39 AM, Alexey Brodkin wrote:
> >
> > And these are functions required by U-Boot (most probably the same is
> > applied to kernel):
> > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX
>
> This
On Friday, October 28, 2016 2:03:21 PM CEST Vineet Gupta wrote:
>
> I'm trying to use about to be released ARC gcc 6.x with current kernels and
> see a
> flood of warnings due to these legit fixes - i.e.g arc gcc 6.2 complains when
> it
> sees -zx formats.
>
> CC mm/percpu.o
> ../mm/percpu
On Friday, October 28, 2016 2:44:13 PM CEST Vineet Gupta wrote:
>
> Indeed if I hack include/linux/types.h
>
> -typedef __kernel_size_tsize_t;
> +typedef unsigned long size_t;
>
> then the warning goes away, so gcc is indeed assuming size_t to be unsigned
> long
> and n
On Friday, October 28, 2016 2:58:33 PM CEST Vineet Gupta wrote:
> On 10/28/2016 02:52 PM, Vineet Gupta wrote:
> > On 10/28/2016 02:44 PM, Vineet Gupta wrote:
> >> This is configuration specific, and something caused your compiler to
> >>> be built assuming that size_t is unsigned long, while the ke
On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
>
> Therefore
On Sunday, October 30, 2016 12:45:41 AM CEST Yury Norov wrote:
> On Sat, Oct 29, 2016 at 11:02:40PM +0200, Arnd Bergmann wrote:
> > On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> > > The newer prlimit64 syscall provides all the functionality provided by
>
so that no
> in-tree architectures are affected.
>
Acked-by: Arnd Bergmann
Can you include this patch in your ilp32 series?
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
ed in
this function [-Werror=maybe-uninitialized]
This changes it to propagate the regulator_disable() result instead.
Fixes: ac61b6001a63 ("pcmcia: soc_common: add support for Vcc and Vpp
regulators")
Signed-off-by: Arnd Bergmann
---
drivers/pcmcia/soc_common.c | 2 +-
1 file chang
unction [-Wmaybe-uninitialized]
This adds a bogus initialization to the function to sanitize
the debug output. I would have preferred a solution without
the initialization, but I only got the report from the
kbuild bot after turning on the warning again, and didn't
manage to reproduce it my
less some configuration option
turns it off because of false-positives.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann
---
Makefile | 10 ++
arch/arc/Makefile | 4 +++-
peats, which the patch indeed fixes.]
Signed-off-by: Sean Young
Tested-by: Sean Young
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
drivers/media/usb/dvb-usb/dib0700_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dib0700_c
le' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This prints the correct one instead, as we did before the patch.
Fixes: 00bb820755ed ("[media] rc: Hauppauge z8f0811 can decode RC6")
Signed-off-by: Arnd Bergmann
---
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
1 f
py with the result.
As the minimum, I'd hope to see the first patch get in soon,
but the individual bugfixes are hopefully now all appropriate
as well. If you see any regressions with the final patch, just
leave that one out and let me know what problems remain.
Arnd
Arnd Bergmann
R_ERR pair
results in a nonzero return value here. Using PTR_ERR_OR_ZERO()
instead makes this clear to the compiler.
Fixes: e09c978aae5b ("NFSv4.1: Fix Oopsable condition in server callback races")
Signed-off-by: Arnd Bergmann
---
First submitted on Aug 31, but ended up not getting
are caught by the 0day builder
in the future as soon as this patch is merged.
Signed-off-by: Arnd Bergmann
---
Please check if there are any remaining warnings with this
patch before applying.
The one known issue right now is commit 32cb7d27e65d ("iio:
maxim_thermocouple: detect invalid st
atchwork.kernel.org/patch/9212825/
Acked-by: Haggai Eran
Signed-off-by: Arnd Bergmann
---
This is marked v2 as the rest of the series but is actually version
three of the patch as I had to do some other changes already.
v3: remove accidental leftover change of the original patch
drivers/i
the
function.
Acked-by: Ley Foon Tan
Signed-off-by: Arnd Bergmann
---
arch/nios2/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index d9563dd..746bf5c 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -32
uld be harmless enough to get the patch into v4.9 so we can turn
on this warning again by default without producing useless output.
A follow-up patch for v4.10 rearranges the code to make the warning
go away.
Signed-off-by: Arnd Bergmann
---
arch/x86/crypto/aesni-intel_glue.c | 4 ++--
1
n BIOS versions, and avoids
the warning.
Signed-off-by: Arnd Bergmann
Reviewed-by: Jiri Kosina
Reviewed-by: Luis R. Rodriguez
---
arch/x86/kernel/apm_32.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index c7364bd..51287
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 b
On Friday, November 18, 2016 10:12:36 PM CET Eugeniy Paltsev wrote:
> +- multi-block: Multi block transfers supported by hardware per AHB master.
> + 0 (default): not supported, 1: supported.
Please clarify that this is an array with one cell per master.
My first thought was "why is this not a bo
On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
>
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> index a53cdb8f068c..c48fee3d7b3b 100644
> --- a/arch/arm/include/asm/types.h
> +++ b/arch/arm/include/asm/types.h
> @@ -1,40 +1,6 @@
> #ifndef _ASM_TYPE
On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> Here is the v2 of this series. The first 5 patches are just cleanup: some
> exported headers were still under a non-uapi directory.
Since this is meant as a cleanup, I commented on this to point out a cleaner
way to do the same.
On Friday, January 6, 2017 10:43:55 AM CET Nicolas Dichtel wrote:
> diff --git a/arch/nios2/include/uapi/asm/setup.h
> b/arch/nios2/include/uapi/asm/setup.h
> new file mode 100644
> index ..8d8285997ba8
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/setup.h
> @@ -0,0 +1,6 @@
> +#
as an alias now for 4.13?
I think that that would make it easier to merge new drivers. Otherwise this
looks good to me,
Acked-by: Arnd Bergmann
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
wrote:
> On Mon, May 29, 2017 at 10:41:52AM +0200, Arnd Bergmann wrote:
>> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
>> wrote:
>> > The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare
>> &
On Mon, May 29, 2017 at 12:55 PM, Daniel Lezcano
wrote:
> On Mon, May 29, 2017 at 11:57:25AM +0200, Arnd Bergmann wrote:
>> On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
>> wrote:
>> Things that could go wrong include:
>>
>> - A platform maintainer wants to
On Thu, Jun 8, 2017 at 6:08 PM, Krzysztof Kozlowski wrote:
> Hi,
>
> While cleaning Samsung ARM defconfigs with savedefconfig, I encountered
> similar obsolete entries in other files.
>
> Except the ARM, no dependencies.
> For ARM, the rest of patches depend on the first change (otherwise
> it mig
On Sat, Jun 10, 2017 at 6:43 PM, Krzysztof Kozlowski wrote:
> On Fri, Jun 09, 2017 at 09:59:48PM +0200, Arnd Bergmann wrote:
>> On Thu, Jun 8, 2017 at 6:08 PM, Krzysztof Kozlowski wrote:
>> > Hi,
>> >
>> > While cleaning Samsung ARM defconfigs with saved
ch enables the relevant stat system calls in the
> generic system call list (if used). It also conditionally defines the
> syscalls in fs/stat.c and struct stat / struct stat64 in
> asm-generic/stat.h.
>
> Signed-off-by: James Hogan
> Cc: David Howells
> Cc: Alexander Viro
&g
On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov wrote:
> On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
>> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
>> > On Mon, Jun 19, 2017 at 11:42 PM, James Hogan
>> > wrote:
>> > > O
On Tue, Jun 20, 2017 at 4:54 PM, Yury Norov wrote:
> On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote:
>> On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov
>> wrote:
>> > On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
>> >> On Mon, Ju
h should normally
dump the stack and kill the current process, like some of the other
architectures already do.
I tried adding barrier_before_unreachable() to panic() and fortify_panic()
as well, but that had very little effect, so I'm not submitting that
patch.
Link: https://gcc.gnu.org/bugzilla/
On Tue, Dec 19, 2017 at 5:57 PM, Vineet Gupta
wrote:
> On 12/19/2017 03:41 AM, Arnd Bergmann wrote:
>> In case of ARC and CRIS, it turns out that the BUG() implementation
>> actually does return (or at least the compiler thinks it does), resulting
>> in lots of warning
On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta
wrote:
> On 12/19/2017 12:13 PM, Arnd Bergmann wrote:
>>
>>
>>> I suppose BUG() implies "dead end" like semantics - which ARC was lacking
>>> before ?
>>
>> Correct. Using __builtin_tra
On Wed, Dec 20, 2017 at 7:52 PM, Vineet Gupta
wrote:
> On 12/20/2017 01:01 AM, Arnd Bergmann wrote:
>>
>> On Tue, Dec 19, 2017 at 11:38 PM, Vineet Gupta
>> wrote:
>>>
>>> On 12/19/2017 12:13 PM, Arnd Bergmann wrote:
>>>>
>>>>
>&
as suggested by Arnd.
>
> Signed-off-by: Vineet Gupta
Acked-by: Arnd Bergmann
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
chitecture specific exports and only
leaves the export next to the __weak symbol.
Fixes: mmotm ("kernel/exit.c: export abort() to modules")
Signed-off-by: Arnd Bergmann
---
Andrew, can you apply this to -mm on top of the other patch?
---
arch/arc/kernel/traps.c | 1 -
arch/arm/kern
The missing 'volatile' keyword on the iounmap argument leads to lots of
harmless warnings in an allmodconfig build:
sound/pci/echoaudio/echoaudio.c:1879:10: warning: passing argument 1 of
'iounmap' discards 'volatile' qualifier f
pointer target type [-Wdiscarded-qu
On Fri, Mar 9, 2018 at 3:02 PM, Andrey Konovalov wrote:
> To allow arm64 syscalls accept tagged pointers from userspace, we must
> untag them when they are passed to the kernel. Since untagging is done in
> generic parts of the kernel (like the mm subsystem), the untagged_addr
> macro should be de
On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
> Hi Arnd,
>
> On Tue, Dec 19, 2017 at 12:39:33PM +0100, Arnd Bergmann wrote:
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index 5d595cfdb2c4..66cfdad68f7e 100644
>> --- a/include/li
On Wed, Apr 11, 2018 at 11:54 AM, James Hogan wrote:
> On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote:
>> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
>> > Before I forward port those patches to add .insn for MIPS, is that sort
>> > of app
On Wed, Nov 21, 2018 at 8:42 PM Vineet Gupta wrote:
>
> +CC lkml, Arnd : subject matter expert
>
> On 11/21/18 10:06 AM, Vitor Soares wrote:
> > I use the follow function to get data from a RX Fifo.
> >
> >
> > static void dw_i3c_master_read_rx_fifo(struct dw_i3c_master *master,
> >
On Wed, Nov 21, 2018 at 9:15 PM Vineet Gupta wrote:
>
> On 11/21/18 12:12 PM, Arnd Bergmann wrote:
> > On Wed, Nov 21, 2018 at 8:42 PM Vineet Gupta
> > wrote:
> >> +CC lkml, Arnd : subject matter expert
> >>
> >> On 11/21/18 10:06 AM, Vitor Soares
On Thu, Nov 29, 2018 at 5:14 PM Jose Abreu wrote:
> --->8--
> static noinline void test_readsl(char *buf, int len)
> {
> readsl(0xdeadbeef, buf, len);
> }
> --->8---
>
> And the disassembly:
> --->8---
> 0e88 :
> e88:breq.dr1,0,eac <0xeac>/* if (count) */
> e8c:and r
On Fri, Nov 30, 2018 at 9:57 AM Jose Abreu wrote:
> On 29-11-2018 21:20, Arnd Bergmann wrote:
> > On Thu, Nov 29, 2018 at 5:14 PM Jose Abreu wrote:
> >> See how the if condition added in this version is checked in
> >> and then it takes two different loops.
> >
On Thu, Dec 20, 2018 at 12:19 PM Adhemerval Zanella
wrote:
> On 19/12/2018 20:23, Vineet Gupta wrote:
> > On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
> >> One possibility is to define an arch-specific __sigset_t.h with a custom
> >> _SIGSET_NWORDS value and add an optimization on Linux sigactio
On Mon, Apr 29, 2019 at 7:17 PM Vineet Gupta wrote:
>
> On 4/22/19 8:31 AM, Arnaldo Carvalho de Melo wrote:
> >> A quick fix for ARC will be to create our own version but I presume all
> >> existing
> >> arches using generic syscall abi are affected. Thoughts ? In lack of ideas
> >> I'll
> >> se
ernelci.org/build/id/5d1cae3f59b514300340c132/logs/
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/arc/kernel/unwind.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 182ce67dfe10..c2663fce7f6c 100644
-
n Wed, Jul 3, 2019 at 6:13 PM Vineet Gupta wrote:
>
> On 7/3/19 6:39 AM, Arnd Bergmann wrote:
> > As kernelci.org reports,
>
> Curious, how are you getting these reports ? I want to see as well.
I'm subscribed to the mailing list at
https://lists.linaro.org/mailman/listin
On Wed, Jul 3, 2019 at 6:13 PM Vineet Gupta wrote:
> On 7/3/19 6:39 AM, Arnd Bergmann wrote:
> > Fixes: bc79c9a72165 ("ARC: dw2 unwind: Reinstante unwinding out of modules")
> > Link: https://kernelci.org/build/id/5d1cae3f59b514300340c132/logs/
> > Cc: sta...@vg
On Tue, Oct 29, 2019 at 7:49 AM Christoph Hellwig wrote:
>
> Whatever reason there is for the existence of ioremap_uc, and the fact
> that it returns NULL by default on architectures with an MMU applies
> equally to nommu architectures, so don't provide different defaults.
Makes sense.
> In prac
ons and rely on asm-generic/io.h instead. For this to work
> the backup ioremap_* defintions needs to be changed to purely cpp
> macros instea of inlines to cover for architectures like openrisc
> that only define ioremap after including .
>
> Signed-off-by: Christoph Hellwi
; although that can be overridden by asm/io.h.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Mon, Nov 11, 2019 at 11:15 AM Christoph Hellwig wrote:
>
> On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote:
> > Maybe we could move the definition into the atyfb driver itself?
> >
> > As I understand it, the difference between ioremap()/ioremap_noca
affects sparc32 nds32 as all others do provide their own version.
>
> Also update the kerneldoc comments in asm-generic/io.h to explain the
> situation around the default ioremap* implementations correctly.
>
> Signed-off-by: Christoph Hellwi
On Wed, Nov 6, 2019 at 7:16 PM Geert Uytterhoeven wrote:
>
> Hi Palmer,
>
> On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt wrote:
> > It looks like the difference in prototype between the architectures is
> > between
> >
> > void __iomem *ioremap(resource_size_t, size_t)
> > void __iomem
On Tue, Oct 29, 2019 at 7:48 AM Christoph Hellwig wrote:
>
> No users of ioremap_cached are left, remove it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
linux-snps-arc mailing list
linux-snps-arc@lists.infrad
rms of ioremap as no portable driver could rely on the behavior
> anyway.
>
> However x86 implements ioremap_uc in a similar way as the ia64
> version of ioremap_nocache, in that it ignores the firmware tables.
> Switch ia64 to override ioremap_uc instead.
>
> Signed-off-by: Christop
On Mon, Nov 11, 2019 at 11:29 AM Christoph Hellwig wrote:
>
> On Mon, Nov 11, 2019 at 11:27:27AM +0100, Arnd Bergmann wrote:
> > Ok, fair enough. Let's just go with your version for now, if only to not
> > hold your series up more. I'd still suggest we change atyfb to
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the
> address so they can be
On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven
> > wrote:
> > I'll add to this one also changes to ioreadX_rep() and add another
> > patch for volatile for reads and writes. I guess
On Wed, Jan 8, 2020 at 10:15 AM Krzysztof Kozlowski wrote:
> > The __force-cast that removes the __iomem here also means that
> > the 'volatile' keyword could be dropped from the argument list,
> > as it has no real effect any more, but then there are a few drivers
> > that mark their iomem point
e memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Krzysztof Kozlowski
> Reviewed-by: Geert Uytterhoeven
Thanks for getting this done!
R
On Tue, Jan 14, 2020 at 9:08 PM Vineet Gupta wrote:
> diff --git a/arch/arc/include/asm/word-at-a-time.h
> b/arch/arc/include/asm/word-at-a-time.h
> new file mode 100644
> index ..00e92be70987
> --- /dev/null
> +++ b/arch/arc/include/asm/word-at-a-time.h
> @@ -0,0 +1,49 @@
> +/* SPDX
On Tue, Jan 14, 2020 at 9:08 PM Vineet Gupta wrote:
>
> There are 2 generic varaints of strncpy_from_user() / strnlen_user()
> (1). inline version in asm-generic/uaccess.h
> (2). optimized word-at-a-time version in lib/*
>
> This patch disables #1 if #2 selected. This allows arches to continue
>
On Tue, Jan 14, 2020 at 10:33 PM Linus Torvalds
wrote:
>
> On Tue, Jan 14, 2020 at 12:09 PM Vineet Gupta
> wrote:
> >
> > There are 2 generic varaints of strncpy_from_user() / strnlen_user()
> > (1). inline version in asm-generic/uaccess.h
>
> I think we should get rid of this entirely. It's jus
On Wed, Jan 15, 2020 at 3:12 PM Al Viro wrote:
>
> On Wed, Jan 15, 2020 at 10:08:31AM +0100, Arnd Bergmann wrote:
>
> > > I would suggest that anybody who uses asm-generic/uaccess.h needs to
> > > simply use the generic library version.
> >
> > Or possibly j
On Thu, Jan 16, 2020 at 12:02 AM Vineet Gupta
wrote:
> On 1/14/20 12:57 PM, Arnd Bergmann wrote:
> > On Tue, Jan 14, 2020 at 9:08 PM Vineet Gupta
> > wrote:
> >> There are 2 generic varaints of strncpy_from_user() / strnlen_user()
> >> (1). inline version
On Wed, Feb 12, 2020 at 2:42 AM Vineet Gupta wrote:
> On 2/11/20 4:14 PM, Alistair Francis wrote:
> > On Tue, Feb 11, 2020 at 4:14 PM Vineet Gupta wrote:
>
> >>> +/* Same for ino_t and ino64_t. */
> >>> +# define __INO_T_MATCHES_INO64_T 1
>
> I'm surprised that ARC port doesn't define this in gl
On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers wrote:
>
> On Thu, 20 Feb 2020, Vineet Gupta wrote:
>
> > The first 4 will need more work as sym aliasing like
> > strong_alias (__xstat64, __xstat)
> >
> > will be needed in those ARM files (which in turn use i386).
>
> The situation for Arm is f
On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski wrote:
> > On 2/14/20 2:39 PM, Alistair Francis wrote:
> > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > An the reason this all works on RISCV is that your kernel doesn't
> > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> >
> > Would it be possible to take a snapshot of your glibc tree
>
> The description of the status of Y2038 supporting glibc on ARM 32 can
> be found here [1].
>
> The most recent patche
On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > wrote:
> > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > > Are there any glibc issues that prevent it from working
> > > > correctly,
> > >
> > > I think that the glibc wr
On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
>
> I do see two approaches here:
>
> 1. In glibc:
>
> When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> wrappers; for example __clock_settime64 is used instead of
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
I tried packaging this into a .deb package for use with rebootstrap, but
ran into a couple of test failures from glibc itself, when testing the i386
version while running o
1 - 100 of 370 matches
Mail list logo
