From: Billy Tsai
[ Upstream commit 886f82ce9f1f4559c139fdb2d79d158999ca38cd ]
The GPIO controller is a GPIO controller followed by some SGPIO
controllers, which are a different type of device with their own binding
and drivers.
Make the gpio node cover the only conventional GPIO controller.
Fi
On 25/09/2020 09:37, Martin Blumenstingl wrote:
> Hi Artem,
>
> On Fri, Sep 25, 2020 at 5:31 AM Artem Lapkin wrote:
>>
>> no need force setup memory size!
>> VIM3 boards have 2Gb and 4Gb variants
>> memory size will be automatically defined
>>
>> mai
Hi Artem,
On Fri, Sep 25, 2020 at 5:31 AM Artem Lapkin wrote:
>
> no need force setup memory size!
> VIM3 boards have 2Gb and 4Gb variants
> memory size will be automatically defined
>
> mainline uboot works properly in any case
> but old vendor uboot works not properly for
no need force setup memory size!
VIM3 boards have 2Gb and 4Gb variants
memory size will be automatically defined
mainline uboot works properly in any case
but old vendor uboot works not properly for 4Gb variants
Signed-off-by: Artem Lapkin
---
arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
On Wed, Sep 09, 2020 at 09:55:20AM -0700, Roman Gushchin wrote:
> On Wed, Sep 09, 2020 at 10:55:34AM -0400, Johannes Weiner wrote:
> > On Thu, Sep 03, 2020 at 04:00:55PM -0700, Roman Gushchin wrote:
> > > In the memcg case count_shadow_nodes() sums the number of pages in lru
> > > lists and the amo
On Wed, Sep 09, 2020 at 10:55:34AM -0400, Johannes Weiner wrote:
> On Thu, Sep 03, 2020 at 04:00:55PM -0700, Roman Gushchin wrote:
> > In the memcg case count_shadow_nodes() sums the number of pages in lru
> > lists and the amount of slab memory (reclaimable and non-reclaimable)
> > as a baseline f
On Thu, Sep 03, 2020 at 04:00:55PM -0700, Roman Gushchin wrote:
> In the memcg case count_shadow_nodes() sums the number of pages in lru
> lists and the amount of slab memory (reclaimable and non-reclaimable)
> as a baseline for the allowed number of shadow entries.
>
> It seems to be a good analo
On Thu, Sep 03, 2020 at 09:10:59PM -0700, Andrew Morton wrote:
> On Thu, 3 Sep 2020 16:00:55 -0700 Roman Gushchin wrote:
>
> > In the memcg case count_shadow_nodes() sums the number of pages in lru
> > lists and the amount of slab memory (reclaimable and non-reclaimable)
> > as a baseline for the
On Thu, 3 Sep 2020 16:00:55 -0700 Roman Gushchin wrote:
> In the memcg case count_shadow_nodes() sums the number of pages in lru
> lists and the amount of slab memory (reclaimable and non-reclaimable)
> as a baseline for the allowed number of shadow entries.
>
> It seems to be a good analogy for
In the memcg case count_shadow_nodes() sums the number of pages in lru
lists and the amount of slab memory (reclaimable and non-reclaimable)
as a baseline for the allowed number of shadow entries.
It seems to be a good analogy for the !memcg case, where
node_present_pages() is used. However, it's
From: Richard Gong
Increase the shared memory size from 16Mb to 32Mb so that we can properly
handle the image authorization for 12+ Mb RBF/JIC files.
Signed-off-by: Richard Gong
---
arch/arm64/boot/dts/intel/socfpga_agilex.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, 30 Apr 2020 18:31:40 +0200, =?UTF-8?q?=C5=81ukasz=20Stelmach?= wrote:
> Calling kexec_add_buffer() page-alligns the value of kbuf.memsz, so it
> is not same as the requested value. Hence both bufsz and memsz should
> after kexec_add_buffer() is called should be be reported separately.
>
>
Calling kexec_add_buffer() page-alligns the value of kbuf.memsz, so it
is not same as the requested value. Hence both bufsz and memsz should
after kexec_add_buffer() is called should be be reported separately.
Łukasz Stelmach (2):
arm64: kexec_file: print appropriate variable
x86: kexec_file:
From: Yazen Ghannam
Chip Select memory size reporting on AMD Family 17h was recently fixed
in order to account for interleaving. However, the current method is not
robust.
The Chip Select Address Mask can be used to find the memory size. There
are a couple of cases.
1) For single-rank and dual
>Please send along a paragraph which explains this, for the changelog.
> >Does this patch fix some user-visible problem? If so, should be code
> >be backported into -stable kernels?
> It should go to linux-next, no one has been using it till this patch
> with 32 bits as w/o th
;s example of potential next commit message:
Subject: mm: mmap: increase sockets maximum memory size pgoff for 32bits
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. These offsets are established
already and are part of the confi
On Tue, Aug 13, 2019 at 10:02:54AM +0200, Magnus Karlsson wrote:
On Mon, Aug 12, 2019 at 2:45 PM Ivan Khoronzhuk
wrote:
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
established already and are par
On Mon, Aug 12, 2019 at 2:45 PM Ivan Khoronzhuk
wrote:
>
> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
> established already and are part of configuration interface.
>
> But for 32-bit systems, whi
On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk
wrote:
> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
> established already and are part of configuration interface.
>
> But for 32-bit systems,
On 8/12/19 2:43 PM, Ivan Khoronzhuk wrote:
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
established already and are part of configuration interface.
But for 32-bit systems, while AF_XDP socket confi
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
established already and are part of configuration interface.
But for 32-bit systems, while AF_XDP socket configuration, the values
are to large to pass max
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
established already and are part of configuration interface.
But for 32-bit systems, while AF_XDP socket configuration, the values
are to large to pass max
: Fix perf.data documentation units for memory size
The perf.data-file-format documentation incorrectly says the
HEADER_TOTAL_MEM results are in bytes. The results are in kilobytes
(perf reads the value from /proc/meminfo)
Signed-off-by: Vince Weaver
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc
On Thu, Jul 25, 2019 at 11:57:43AM -0400, Vince Weaver wrote:
>
> The perf.data-file-format documentation incorrectly says the
> HEADER_TOTAL_MEM results are in bytes. The results are in kilobytes
> (perf reads the value from /proc/meminfo)
>
> Signed-off-by: Vince Weaver
Acked-by: Jiri Olsa
The perf.data-file-format documentation incorrectly says the
HEADER_TOTAL_MEM results are in bytes. The results are in kilobytes
(perf reads the value from /proc/meminfo)
Signed-off-by: Vince Weaver
diff --git a/tools/perf/Documentation/perf.data-file-format.txt
b/tools/perf/Documentation/p
From: Yazen Ghannam
Chip Select memory size reporting on AMD Family 17h was recently fixed
in order to account for interleaving. However, the current method is not
robust.
The Chip Select Address Mask can be used to find the memory size. There
are a few cases.
1) For single-rank, use the
From: Yazen Ghannam
Chip Select memory size reporting on AMD Family 17h was recently fixed
in order to account for interleaving. However, the current method is not
robust.
The Chip Select Address Mask can be used to find the memory size. There
are a few cases.
1) For single-rank, use the
On Thu, May 30, 2019 at 11:56:55AM -0700, Song Liu wrote:
> On Wed, May 29, 2019 at 6:05 PM Roman Gushchin wrote:
> >
> > Most bpf map types doing similar checks and bytes to pages
> > conversion during memory allocation and charging.
> >
> > Let's unify these checks by moving them into bpf_map_ch
On Wed, May 29, 2019 at 6:05 PM Roman Gushchin wrote:
>
> Most bpf map types doing similar checks and bytes to pages
> conversion during memory allocation and charging.
>
> Let's unify these checks by moving them into bpf_map_charge_init().
>
> Signed-off-by: Roman Gushchin
Nice, I was thinking
Most bpf map types doing similar checks and bytes to pages
conversion during memory allocation and charging.
Let's unify these checks by moving them into bpf_map_charge_init().
Signed-off-by: Roman Gushchin
---
include/linux/bpf.h | 2 +-
kernel/bpf/arraymap.c | 8 +---
reported required memory size (2/2)
Lock chains are only tracked with CONFIG_PROVE_LOCKING=y. Do not report
the memory required for the lock chain array if CONFIG_PROVE_LOCKING=n.
See also commit:
ca58abcb4a6d ("lockdep: sanitise CONFIG_PROVE_LOCKING")
Include the size of the ch
reported required memory size (1/2)
Change the sizeof(array element time) * (array size) expressions into
sizeof(array). This fixes the size computations of the classhash_table[]
and chainhash_table[] arrays.
The reason is that commit:
a63f38cc4ccf ("locking/lockdep: Convert hash tabl
Change the sizeof(array element time) * (array size) expressions into
sizeof(array). This fixes the size computations of the classhash_table[]
and chainhash_table[] arrays. Commit a63f38cc4ccf ("locking/lockdep:
Convert hash tables to hlists") namely changed the type of the elements
of that array f
Lock chains are only tracked with CONFIG_PROVE_LOCKING=y. Do not report
the memory required for the lock chain array if CONFIG_PROVE_LOCKING=n.
See also commit ca58abcb4a6d ("lockdep: sanitise CONFIG_PROVE_LOCKING").
Include the size of the chain_hlocks[] array.
Cc: Peter Zijlstra
Cc: Waiman Lon
> On Feb 14, 2019, at 3:42 AM, Juergen Gross wrote:
>
> When limiting memory size via kernel parameter "mem=" this should be
> respected even in case of memory made accessible via a PCI card.
>
> Today this kind of memory won't be made usable in initial memo
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added whe
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
param
On 11/02/2019 13:23, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>>> If PCI devices had physical mmio memory areas above this range, we'd
>>> still expect them to work - the option was really only meant to limit
>>> RAM.
>>
>> No, in this case it seems to be real RAM added via PCI. The RAM
* Juergen Gross wrote:
> > If PCI devices had physical mmio memory areas above this range, we'd
> > still expect them to work - the option was really only meant to limit
> > RAM.
>
> No, in this case it seems to be real RAM added via PCI. The RAM is
> initially present in the E820 map, but
On 11/02/2019 13:06, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> When limiting memory size via kernel parameter "mem=" this should be
>> respected even in case of memory made accessible via a PCI card.
>>
>> Today this kind of memory won't
* Juergen Gross wrote:
> When limiting memory size via kernel parameter "mem=" this should be
> respected even in case of memory made accessible via a PCI card.
>
> Today this kind of memory won't be made usable in initial memory
> setup as the memory won&#x
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
param
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added whe
On 23/01/2019 15:35, William Kucharski wrote:
>
>
>> On Jan 22, 2019, at 1:06 AM, Juergen Gross wrote:
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index b9a667d36c55..7fc2a87110a3 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -96,10 +96,16 @@ void mem
> On Jan 22, 2019, at 1:06 AM, Juergen Gross wrote:
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index b9a667d36c55..7fc2a87110a3 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -96,10 +96,16 @@ void mem_hotplug_done(void)
> cpus_read_unlock();
> }
>
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added whe
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
param
Change the sizeof(array element time) * (array size) expressions into
sizeof(array). This fixes the size computations of the classhash_table[]
and chainhash_table[] arrays. Commit a63f38cc4ccf ("locking/lockdep:
Convert hash tables to hlists") namely changed the type of the elements
of that array f
Lock chains are only tracked with CONFIG_PROVE_LOCKING=y. Do not report
the memory required for the lock chain array if CONFIG_PROVE_LOCKING=n.
Fixes: ca58abcb4a6d ("lockdep: sanitise CONFIG_PROVE_LOCKING") # v2.6.23
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van A
Lock chains are only tracked with CONFIG_PROVE_LOCKING=y. Do not report
the memory required for the lock chain array if CONFIG_PROVE_LOCKING=n.
Fixes: ca58abcb4a6d ("lockdep: sanitise CONFIG_PROVE_LOCKING") # v2.6.23
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van A
From: Fabio Estevam
Currently the memory size described in dts is 2GB, which is incorrect.
There are 512MB and 1GB versions of imx7d-pico boards, so remove
the hardcoded memory size and let the bootloader pass the correct
value to the kernel.
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio
From: Fabio Estevam
Currently the memory size described in dts is 2GB, which is incorrect.
There are 512MB and 1GB versions of imx7d-pico boards, so remove
the hardcoded memory size and let the bootloader pass the correct
value to the kernel.
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio
On Mon, Nov 19, 2018 at 5:50 PM Robin Murphy wrote:
>
> On 19/11/2018 14:18, Ramon Fried wrote:
> > On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> > wrote:
> >>
> >> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> -* Because 32-bit DMA masks are so common we expe
On 19/11/2018 14:18, Ramon Fried wrote:
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
-* Because 32-bit DMA masks are so common we expect every architecture
-* to be able to satisfy them - either by not s
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
>
> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
> > > -* Because 32-bit DMA masks are so common we expect every
> > > architecture
> > > -* to be able to satisfy them - either by not supporting more
> > >
This way an architecture with less than 4G of RAM can support dma_mask
smaller than 32-bit without a ZONE_DMA. Apparently that is a common
case on powerpc.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
kernel/dma/direct.c | 28
1 file changed, 16 i
[ oops, I should have looked at the replies first, now I see Ben already
had the same thing to say about #3... ]
On 27/09/18 14:49, Christoph Hellwig wrote:
On Thu, Sep 27, 2018 at 11:50:14AM +1000, Benjamin Herrenschmidt wrote:
-* to be able to satisfy them - either by not supporting
On Thu, Sep 27, 2018 at 11:50:14AM +1000, Benjamin Herrenschmidt wrote:
> > -* to be able to satisfy them - either by not supporting more physical
> > -* memory, or by providing a ZONE_DMA32. If neither is the case, the
> > -* architecture needs to use an IOMMU instead of the direct ma
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Shanker Donthineni
commit 2eca0d6ceea1f108b2d3ac81fb34698c4fd41006 upstream.
Function its_alloc_tables() maintains two local variables, "order" and
and "alloc_size", to h
On 27.6.2018 01:20, Luis Araneda wrote:
> According to the reference manual, the board has two Micron
> MT41K256M16HA-125 DDR3L memory ICs, which have 512 MiB each
>
> Tested on a ZYBO-Z7-20 board
>
> Signed-off-by: Luis Araneda
> ---
> arch/arm/boot/dts/zynq-zybo-z7.dts | 2 +-
> 1 file change
According to the reference manual, the board has two Micron
MT41K256M16HA-125 DDR3L memory ICs, which have 512 MiB each
Tested on a ZYBO-Z7-20 board
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-zybo-z7.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/bo
From: Xiang Chen
There are 28 bytes of protection information record of SSP for
v3 hw, 16 bytes for v2 hw, and probably 24 for v1 hw (forgotten
now).
So use a value big enough in hisi_sas_command_table_ssp.prot to
cover all cases.
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
---
drive
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
From: Sean Wang
There is 2GB DDR3 available on bananapi-r2 board as [1] specified.
[1] http://www.banana-pi.org/r2.html
Signed-off-by: Sean Wang
Cc: Rob Herring
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot
On Mon, 2018-03-05 at 08:16 -0600, Rob Herring wrote:
> On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang wrote:
> > On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote:
> >> On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.w...@mediatek.com wrote:
> >> > From: Sean Wang
> >> >
> >> > There is 2GB DDR3 av
On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang wrote:
> On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote:
>> On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.w...@mediatek.com wrote:
>> > From: Sean Wang
>> >
>> > There is 2GB DDR3 available on bananapi-r2 board as [1] specified.
>> >
>> > [1] http:
On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote:
> On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > There is 2GB DDR3 available on bananapi-r2 board as [1] specified.
> >
> > [1] http://www.banana-pi.org/r2.html
> >
> > Signed-off-by: Sean
On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> There is 2GB DDR3 available on bananapi-r2 board as [1] specified.
>
> [1] http://www.banana-pi.org/r2.html
>
> Signed-off-by: Sean Wang
> ---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 5
The 512 megabyte memory size has served quite well, but more memory
is required when using large trace buffers on large systems. This
commit therefore adds a --memory argument to the kvm.sh script, which
allows the memory size to be specified on the command line, for example,
"--memor
From: Sean Wang
There is 2GB DDR3 available on bananapi-r2 board as [1] specified.
[1] http://www.banana-pi.org/r2.html
Signed-off-by: Sean Wang
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2
On Wed, Jan 24, 2018 at 11:22:12AM -0200, Marco Franchi wrote:
> In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
> 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
> size.
>
> Signed-off-by: Marco Franchi
Applied all, thanks.
On Wed, Jan 24, 2018 at 11:22 AM, Marco Franchi wrote:
> Remove the empty reg property from the SoC dtsi files in order to avoid
> duplicate memory nodes when the correct size is passed in board dts files.
>
> Signed-off-by: Marco Franchi
Reviewed-by: Fabio Estevam
On Wed, Jan 24, 2018 at 11:22 AM, Marco Franchi wrote:
> In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
> 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
> size.
>
> Signed-off-by: Marco Franchi
Reviewed-by: Fabio Estevam
In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
size.
Signed-off-by: Marco Franchi
---
Change since v2:
-change 'memory@0 {' to 'memory {
Remove the empty reg property from the SoC dtsi files in order to avoid
duplicate memory nodes when the correct size is passed in board dts files.
Signed-off-by: Marco Franchi
---
Change since v2:
-none
arch/arm/boot/dts/imx1.dtsi| 2 +-
arch/arm/boot/dts/imx23.dtsi | 2 +-
arch/arm/boot/d
Hi Marco,
On Wed, Jan 24, 2018 at 10:21 AM, Marco Franchi wrote:
> In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
> 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
> size.
>
> Signed-off-by: Marco Fr
Oi Marco,
On Wed, Jan 24, 2018 at 10:21 AM, Marco Franchi wrote:
> In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
> 'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
> size.
>
> Signed-off-by: Marco Fr
Remove the empty reg property from the SoC dtsi files in order to avoid
duplicate memory nodes when the correct size is passed in board dts files.
Signed-off-by: Marco Franchi
---
Change since v1:
-none
arch/arm/boot/dts/imx1.dtsi| 2 +-
arch/arm/boot/dts/imx23.dtsi | 2 +-
arch/arm/boot/d
In preparation for removing 'reg = <0 0>;' from the dtsi SoC files, pass
'reg = <0 0 >;' to the dts/dtsi board files that do not pass the memory
size.
Signed-off-by: Marco Franchi
---
Change since v1:
-none
arch/arm/boot/dts/imx51-zii-rdu1.dts | 5 +++
On Wed, Jan 17, 2018 at 4:06 PM, Jan H. Schönherr wrote:
> The functions devm_memremap_pages() and devm_memremap_pages_release() use
> different ways to calculate the section-aligned amount of memory. The
> latter function may use an incorrect size if the memory region is small
> but straddles a s
The functions devm_memremap_pages() and devm_memremap_pages_release() use
different ways to calculate the section-aligned amount of memory. The
latter function may use an incorrect size if the memory region is small
but straddles a section border.
Use the same code for both.
Fixes: 5f29a77cd957 (
There are several places to perform subtraction to calculate buffer
size such as:
si->si_ofs.cydata_size = si->si_ofs.test_ofs - si->si_ofs.cydata_ofs;
...
p = krealloc(si->si_ptrs.cydata, si->si_ofs.cydata_size, GFP_KERNEL);
Actually, data types of above variables during subtraction are size_t,
On Thu, Nov 02, 2017 at 08:49:35PM -0700, Vince Kim wrote:
> Hello Dmitry,
>
> I attached patch with signed-off-by.
*sigh* did you try compile that?
+ if (si->si_ofs.test_ofs <= si->si_ofs.cydata_ofs)
+ dev_err(cd->dev, "%s: invalid offset test_ofs:%zd,
cydata_ofs:%zd \n",
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
Hi Vince,
On Wed, Nov 01, 2017 at 09:13:58PM -0700, Vince Kim wrote:
> It looks patch send to the maintainer rejected.
>
I can take the patch, but I need your signed-off-by please.
> Can anyone take a look?
>
>
>
> *==*
>
> *Delivery has failed to these recipient
On 10/24/17 at 02:09pm, Dave Young wrote:
> Hi Baoquan,
>
> On 10/24/17 at 01:57pm, Baoquan He wrote:
> > Hi Dave,
> >
> > On 10/24/17 at 01:31pm, Dave Young wrote:
> > > The total memory size we get in kernel is usually slightly less than 2G
> > &g
There are several places to perform subtraction to calculate buffer
size such as:
si->si_ofs.cydata_size = si->si_ofs.test_ofs - si->si_ofs.cydata_ofs;
...
p = krealloc(si->si_ptrs.cydata, si->si_ofs.cydata_size, GFP_KERNEL);
Actually, data types of above variables during subtraction are size_t,
On 10/27/17 9:51 AM, Yang Shi wrote:
On 10/27/17 3:00 AM, Christopher Lameter wrote:
On Thu, 26 Oct 2017, Yang Shi wrote:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 935c4d4..e21b81e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2050,6 +2050,31 @@ extern int _
On 10/27/17 3:00 AM, Christopher Lameter wrote:
On Thu, 26 Oct 2017, Yang Shi wrote:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 935c4d4..e21b81e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2050,6 +2050,31 @@ extern int __meminit __early_pfn_to_nid(unsigned lon
On Thu, 26 Oct 2017, Yang Shi wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 935c4d4..e21b81e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2050,6 +2050,31 @@ extern int __meminit __early_pfn_to_nid(unsigned long
> pfn,
> static inline void zero_resv_u
Total memory size is needed by unreclaimable slub oom to check if
significant memory is used by a single slab. But, the caculation work is
done in show_mem(), so extracting the common code in order to share with
others.
Signed-off-by: Yang Shi
---
include/linux/mm.h | 25
From: Xiang Chen
Currently the size of memory we allocate for SATA
breakpoint buffer is incorrect.
The breakpoint memory size should be as follows:
32 (NCQ tags) * 128 * 2048 (max #devs) = 8MB
Currently we only allocate 0.5MB, but get away with it
as we never have SATA device index >
Hi Baoquan,
On 10/24/17 at 01:57pm, Baoquan He wrote:
> Hi Dave,
>
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > The total memory size we get in kernel is usually slightly less than 2G
> > with a
> > 2G memory module machine. The main reason is bios/firmware reserv
Hi Dave,
On 10/24/17 at 01:31pm, Dave Young wrote:
> The total memory size we get in kernel is usually slightly less than 2G with a
> 2G memory module machine. The main reason is bios/firmware reserve some area
> it will not export all memory as usable to Linux.
>
> 2G memory X86
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
f (!catc->is_f5u011) {
+ u32 *buf;
+ int i;
+
dev_dbg(dev, "Checking memory size\n");
- i = 0x12345678;
- catc_write_mem(catc, 0x7a80, &i, 4);
- i = 0x87654321;
-
On Tue, Jun 06, 2017 at 09:19:04PM +, Chris Packham wrote:
> "mvebu" is the current trend for this family of orion/kirkwood/armada
> SoCs. I can take mv64x60_edac.c and gut it to use as a base.
s/gut it/copy stuff for your own use in your *separate* driver/
Let's leave mv64x60_edac.c alone.
The #address-cells and #size-cells properties need to be accounted for
when dealing with the "memory" device tree node. Use
of_address_to_resource() and resource_size() to retrieve the size of the
memory node which will automatically take the #cells into account.
Signed-off-by: Chris Packham
---
On 07/06/17 04:55, Borislav Petkov wrote:
> On Tue, Jun 06, 2017 at 03:07:04AM +, Chris Packham wrote:
>> I'll wait for feedback before sending a v2.
>
> You can't be expecting me to review PPC code reliably. :-)
Yeah sorry I should have included linuxppc-dev. Will do on v2.
I don't think th
On Tue, Jun 06, 2017 at 03:07:04AM +, Chris Packham wrote:
> I'll wait for feedback before sending a v2.
You can't be expecting me to review PPC code reliably. :-)
AFAIR from the recent discussion, Michael said that the aim is to remove
CONFIG_MV64X60 and since this driver depends on it, that
1 - 100 of 302 matches
Mail list logo
