Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
From: Vishal Verma
With DAX memory regions originating from CXL memory expanders or
NVDIMMs, the kmem driver may be hot-adding huge amounts of system memory
on a system without enough 'regular' main memory to support the memmap
for it. To avoid this, ensure that all kmem managed hotplugged
With memmap on memory, some architecture needs more details w.r.t altmap
such as base_pfn, end_pfn, etc to unmap vmemmap memory. Instead of
computing them again when we remove a memory block embed vmem_altmap
details in struct memory_block if we are using memmap on memory block
feature.
No
Radix vmemmap mapping can map things correctly at the PMD level or PTE
level based on different device boundary checks. Hence we skip the
restrictions w.r.t vmemmap size to be multiple of PMD_SIZE. This also
makes the feature widely useful because to use PMD_SIZE vmemmap area we
require a memory
Add a new kconfig option that can be selected if we want to allow
pageblock alignment by reserving pages in the vmemmap altmap area.
This implies we will be reserving some pages for every memoryblock
This also allows the memmap on memory feature to be widely useful
with different memory block size
Some architectures would want different restrictions. Hence add an
architecture-specific override.
Both the PMD_SIZE check and pageblock alignment check are moved there.
Signed-off-by: Aneesh Kumar K.V
---
mm/memory_hotplug.c | 17 -
1 file changed, 12 insertions(+), 5
If not supported, fallback to not using memap on memmory. This avoids
the need for callers to do the fallback.
Signed-off-by: Aneesh Kumar K.V
---
drivers/acpi/acpi_memhotplug.c | 3 +--
include/linux/memory_hotplug.h | 1 -
mm/memory_hotplug.c| 13 ++---
3 files changed,
Instead of adding menu entry with all supported architectures, add
mm/Kconfig variable and select the same from supported architectures.
No functional change in this patch.
Acked-by: David Hildenbrand
Signed-off-by: Aneesh Kumar K.V
---
arch/arm64/Kconfig | 4 +---
arch/x86/Kconfig | 4 +---
This patch series update memmap on memory feature to fall back to
memmap allocation outside the memory block if the alignment rules are
not met. This makes the feature more useful on architectures like
ppc64 where alignment rules are different with 64K page size.
This patch series is dependent on
Le 10/07/2023 à 22:43, Matthew Wilcox (Oracle) a écrit :
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Acked-by: Mike Rapoport (IBM)
> Cc:
Le 10/07/2023 à 22:24, Matthew Wilcox a écrit :
> On Sat, Mar 18, 2023 at 09:19:04AM +, Christophe Leroy wrote:
>> void set_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
>> pte_t pte, unsigned int nr)
>> {
>> pgprot_t prot;
>> unsigned long pfn;
>>
Christophe Leroy writes:
> Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
>> Architectures like powerpc will like to use different page table allocators
>> and mapping mechanisms to implement vmemmap optimization. Similar to
>> vmemmap_populate allow architectures to implement
>>
Christophe Leroy writes:
> Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
>> dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within
>> vmemmap such that tail page mapping can point to the second PAGE_SIZE area.
>> Enforce that in vmemmap_can_optimize() function.
>>
>>
Christophe Leroy writes:
> Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
>> This helps architectures to override pmd_same and pud_same independently.
>>
>> Signed-off-by: Aneesh Kumar K.V
>
> Reviewed-by: Christophe Leroy
>
> Shouldn't you do it the modern way and use #ifndef pud_same
Hi Ming,
Having no [PATCH 1/2] blk-mq: add blk_mq_max_nr_hw_queues() in inbox.
So I reply here.
At first glance, I think that the cpu hot plug callback hook should
be the remedy for the newly introduced blk_mq_max_nr_hw_queues(),
although it is more complicated.
Consider the scene where
On Mon, Jul 10, 2023 at 5:16 PM Ming Lei wrote:
>
> On Mon, Jul 10, 2023 at 08:41:09AM +0200, Christoph Hellwig wrote:
> > On Sat, Jul 08, 2023 at 10:02:59AM +0800, Ming Lei wrote:
> > > Take blk-mq's knowledge into account for calculating io queues.
> > >
> > > Fix wrong queue mapping in case of
Hi Baoquan,
On Tue, Jul 11, 2023 at 11:35:50AM +0800, Baoquan He wrote:
> On 07/10/23 at 05:14pm, Ming Lei wrote:
> > On Mon, Jul 10, 2023 at 08:41:09AM +0200, Christoph Hellwig wrote:
> > > On Sat, Jul 08, 2023 at 10:02:59AM +0800, Ming Lei wrote:
> > > > Take blk-mq's knowledge into account for
On 07/10/23 at 05:14pm, Ming Lei wrote:
> On Mon, Jul 10, 2023 at 08:41:09AM +0200, Christoph Hellwig wrote:
> > On Sat, Jul 08, 2023 at 10:02:59AM +0800, Ming Lei wrote:
> > > Take blk-mq's knowledge into account for calculating io queues.
> > >
> > > Fix wrong queue mapping in case of kdump
On Tue, Jul 11, 2023 at 1:34 AM Isaku Yamahata wrote:
>
> On Fri, Jul 07, 2023 at 10:35:02AM +0900,
> David Stevens wrote:
>
> > > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > > > > > index e44ab512c3a1..b1607e314497 100644
> > > > > > --- a/arch/x86/kvm/mmu/mmu.c
> > >
From: wuych
Pointer variables of void * type do not require type cast.
Signed-off-by: Wu Yunchuan
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index
built successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alpha defconfig gcc
alpharandconfig-r032-20230710 gcc
arc alldefconfig gcc
arc
defconfig gcc
hexagon randconfig-r041-20230710 clang
hexagon randconfig-r045-20230710 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386defconfig
On Mon, Jul 10, 2023 at 10:51:43AM -0600, Keith Busch wrote:
> On Mon, Jul 10, 2023 at 05:14:15PM +0800, Ming Lei wrote:
> > On Mon, Jul 10, 2023 at 08:41:09AM +0200, Christoph Hellwig wrote:
> > > On Sat, Jul 08, 2023 at 10:02:59AM +0800, Ming Lei wrote:
> > > > Take blk-mq's knowledge into
On 7/10/23 4:21 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> pci_disable_pcie_error_reporting() is unused; remove it.
> pci_enable_pcie_error_reporting() is used only inside aer.c; make it
> static.
Looks fine to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
>
> Bjorn Helgaas (2):
>
On 2023/7/11 00:34, Andrew Lunn wrote:
On Mon, Jul 10, 2023 at 02:39:33PM +0800, Su Hui wrote:
From: wuych
Pointer variables of void * type do not require type cast.
Signed-off-by: wuych
---
drivers/net/wan/fsl_ucc_hdlc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
From: Bjorn Helgaas
pci_enable_pcie_error_reporting() is used only inside aer.c. Stop exposing
it outside the file.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pcie/aer.c | 3 +--
include/linux/aer.h| 6 --
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git
From: Bjorn Helgaas
pci_disable_pcie_error_reporting() has no callers. Remove it.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pcie/aer.c | 12
include/linux/aer.h| 5 -
2 files changed, 17 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index
From: Bjorn Helgaas
pci_disable_pcie_error_reporting() is unused; remove it.
pci_enable_pcie_error_reporting() is used only inside aer.c; make it
static.
Bjorn Helgaas (2):
PCI/AER: Drop unused pci_disable_pcie_error_reporting()
PCI/AER: Unexport pci_enable_pcie_error_reporting()
commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
syscall definition for lookup_dcookie. However, syscall tables still
point to the old sys_lookup_dcookie() definition. Update syscall tables
of all architectures to directly point to sys_ni_syscall() instead.
Signed-off-by: Sohil
On Mon, 2023-07-10 at 14:35 +0200, Christian Brauner wrote:
> On Fri, Jul 07, 2023 at 08:42:31AM -0400, Jeff Layton wrote:
> > On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
> > > v2:
> > > - prepend patches to add missing ctime updates
> > > - add simple_rename_timestamp helper function
>
On Fri, Jul 07, 2023 at 08:42:31AM -0400, Jeff Layton wrote:
> On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
> > v2:
> > - prepend patches to add missing ctime updates
> > - add simple_rename_timestamp helper function
> > - rename ctime accessor functions as
On Wed, 05 Jul 2023 14:58:09 -0400, Jeff Layton wrote:
> v2:
> - prepend patches to add missing ctime updates
> - add simple_rename_timestamp helper function
> - rename ctime accessor functions as inode_get_ctime/inode_set_ctime_*
> - drop individual inode_ctime_set_{sec,nsec} helpers
>
> I've
On Thu, 2023-06-15 at 22:37 +1000, Michael Ellerman wrote:
> There's code in prom_instantiate_sml() to do a "SML handover" (Stored
> Measurement Log) from OF to Linux, before Linux shuts down Open
> Firmware.
>
> This involves creating a buffer to hold the SML, and creating two device
> tree
Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
per-folio.
Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Mike Rapoport (IBM)
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc:
Hi Thomas,
On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit
On Sat, Mar 18, 2023 at 09:19:04AM +, Christophe Leroy wrote:
> void set_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
> pte_t pte, unsigned int nr)
> {
> pgprot_t prot;
> unsigned long pfn;
> /*
>* Make sure hardware valid bit is not set.
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> A follow-up patch will add a pud variant for this same event.
> Using event class makes that addition simpler.
>
> No functional change in this patch.
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Christophe Leroy
> ---
>
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> pudp_set_wrprotect and move_huge_pud helpers are only used when
> CONFIG_TRANSPARENT_HUGEPAGE is enabled. Similar to pmdp_set_wrprotect and
> move_huge_pmd_helpers use architecture override only if
> CONFIG_TRANSPARENT_HUGEPAGE is set
>
>
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> This helps architectures to override pmd_same and pud_same independently.
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Christophe Leroy
Shouldn't you do it the modern way and use #ifndef pud_same instead of a
new __HAVE_ARCH_PUD_SAME
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> Architectures like powerpc will like to use different page table allocators
> and mapping mechanisms to implement vmemmap optimization. Similar to
> vmemmap_populate allow architectures to implement
> vmemap_populate_compound_pages
>
>
On Wed, Jul 05, 2023 at 02:55:16PM +0200, Gerald Schaefer wrote:
> Ah ok, I was aware of that "semi-RCU" fallback logic in tlb_remove_table(),
> but that is rather a generic issue, and not s390-specific. I thought you
> meant some s390-oddity here, of which we have a lot, unfortunately...
> Of
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within
> vmemmap such that tail page mapping can point to the second PAGE_SIZE area.
> Enforce that in vmemmap_can_optimize() function.
>
> Architectures like powerpc also want to
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> We will use this in a later patch to do tlb flush when clearing pud entries
> on powerpc. This is similar to commit 93a98695f2f9 ("mm: change
> pmdp_huge_get_and_clear_full take vm_area_struct as arg")
>
> Signed-off-by: Aneesh Kumar K.V
Le 10/07/2023 à 18:08, Aneesh Kumar K.V a écrit :
> Architectures like powerpc would like to enable transparent huge page pud
> support only with radix translation. To support that add
> has_transparent_pud_hugepage() helper that architectures can override.
>
> Signed-off-by: Aneesh Kumar K.V
From: Omar Sandoval
None of the other accelerated crypto modules are built by default.
Signed-off-by: Omar Sandoval
---
arch/powerpc/crypto/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
index 81ae015861c0..97802c72317c
On Mon, Jul 10, 2023 at 05:14:15PM +0800, Ming Lei wrote:
> On Mon, Jul 10, 2023 at 08:41:09AM +0200, Christoph Hellwig wrote:
> > On Sat, Jul 08, 2023 at 10:02:59AM +0800, Ming Lei wrote:
> > > Take blk-mq's knowledge into account for calculating io queues.
> > >
> > > Fix wrong queue mapping in
> -Original Message-
> From: Azeem Shaikh
> Sent: Sunday, July 9, 2023 9:36 PM
> To: Kees Cook
> Cc: Qiang Zhao ; linux-harden...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Leo Li
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] soc:
From: Omar Sandoval
My stripped down configuration fails to build with:
ERROR: modpost: "skcipher_walk_aead_encrypt"
[arch/powerpc/crypto/aes-gcm-p10-crypto.ko] undefined!
ERROR: modpost: "skcipher_walk_done"
[arch/powerpc/crypto/aes-gcm-p10-crypto.ko] undefined!
ERROR: modpost:
Add some extra vmemmap pr_debug message that will indicate the type of
vmemmap allocations.
For ex: with DAX vmemmap optimization we can find the below details:
[ 187.166580] radix-mmu: PAGE_SIZE vmemmap mapping
[ 187.166587] radix-mmu: PAGE_SIZE vmemmap mapping
[ 187.166591] radix-mmu: Tail
On Fri, Jul 07, 2023 at 10:35:02AM +0900,
David Stevens wrote:
> > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > > > > index e44ab512c3a1..b1607e314497 100644
> > > > > --- a/arch/x86/kvm/mmu/mmu.c
> > > > > +++ b/arch/x86/kvm/mmu/mmu.c
> > > >
> > > > ...
> > > >
> > >
On Mon, Jul 10, 2023 at 02:39:33PM +0800, Su Hui wrote:
> From: wuych
>
> Pointer variables of void * type do not require type cast.
>
> Signed-off-by: wuych
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
On Mon, Jul 10, 2023 at 5:22 PM Thomas Zimmermann wrote:
>
> I'll append a patch to the series that documents this.
>
> Sure.
Thanks!
If you are planning to take it into some other tree:
Acked-by: Miguel Ojeda
Otherwise, I can take it into the `auxdisplay` tree.
Cheers,
Miguel
This is not used by radix anymore.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 11 ---
arch/powerpc/mm/init_64.c| 21 ++---
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git
With 2M PMD-level mapping, we require 32 struct pages and a single vmemmap
page can contain 1024 struct pages (PAGE_SIZE/sizeof(struct page)). Hence
with 64K page size, we don't use vmemmap deduplication for PMD-level
mapping.
Signed-off-by: Aneesh Kumar K.V
---
This is in preparation to update radix to implement vmemmap optimization
for devdax. Below are the rules w.r.t radix vmemmap mapping
1. First try to map things using PMD (2M)
2. With altmap if altmap cross-boundary check returns true, fall back to
PAGE_SIZE
3. If we can't allocate PMD_SIZE
This is enabled only with radix translation and 1G hugepage size. This will
be used with devdax device memory with a namespace alignment of 1G.
Anon transparent hugepage is not supported even though we do have helpers
checking pud_trans_huge(). We should never find that return true. The only
A follow-up patch will add a pud variant for this same event.
Using event class makes that addition simpler.
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/hash_pgtable.c | 2 +-
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
Arm disabled hugetlb vmemmap optimization [1] because hugetlb vmemmap
optimization includes an update of both the permissions (writeable to
read-only) and the output address (pfn) of the vmemmap ptes. That is not
supported without unmapping of pte(marking it invalid) by some
architectures.
With
pudp_set_wrprotect and move_huge_pud helpers are only used when
CONFIG_TRANSPARENT_HUGEPAGE is enabled. Similar to pmdp_set_wrprotect and
move_huge_pmd_helpers use architecture override only if
CONFIG_TRANSPARENT_HUGEPAGE is set
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 2 ++
This helps architectures to override pmd_same and pud_same independently.
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 6fd9b2831338..91def34f7784 100644
---
Architectures like powerpc will like to use different page table allocators
and mapping mechanisms to implement vmemmap optimization. Similar to
vmemmap_populate allow architectures to implement
vmemap_populate_compound_pages
Signed-off-by: Aneesh Kumar K.V
---
mm/sparse-vmemmap.c | 3 +++
1
dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within
vmemmap such that tail page mapping can point to the second PAGE_SIZE area.
Enforce that in vmemmap_can_optimize() function.
Architectures like powerpc also want to enable vmemmap optimization
conditionally (only with radix
We will use this in a later patch to do tlb flush when clearing pud entries
on powerpc. This is similar to commit 93a98695f2f9 ("mm: change
pmdp_huge_get_and_clear_full take vm_area_struct as arg")
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 4 ++--
mm/debug_vm_pgtable.c | 2
Architectures like powerpc would like to enable transparent huge page pud
support only with radix translation. To support that add
has_transparent_pud_hugepage() helper that architectures can override.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/pfn_devs.c | 2 +-
include/linux/pgtable.h
This patch series implements changes required to support DAX vmemmap
optimization for ppc64. The vmemmap optimization is only enabled with radix MMU
translation and 1GB PUD mapping with 64K page size. The patch series also split
hugetlb vmemmap optimization as a separate Kconfig variable so that
Hi
Am 10.07.23 um 16:24 schrieb Miguel Ojeda:
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
`framebuffer_alloc()` does indeed use
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
>
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
`framebuffer_alloc()` does indeed use `kzalloc()`, but the docs do not
mention the
Hi!
On Mon, 2023-07-10 at 16:04 +0200, Thomas Zimmermann wrote:
> > > I won't argue with that, but the flag itself is wrong.
> > > FBINFO_FLAG_DEFAULT is/was for struct fb_info.flags. You have struct
> > > fb_videomode.flag. The valid flags for this field are at [1]. If
> > > anything, the field
Hi
Am 10.07.23 um 15:59 schrieb John Paul Adrian Glaubitz:
Hi Thomas!
On Mon, 2023-07-10 at 15:52 +0200, Thomas Zimmermann wrote:
I would argue that the current code is more readable that your proposed change.
I agree that it's a no-op, but code is not just about functionality but also
Hi Thomas!
On Mon, 2023-07-10 at 15:52 +0200, Thomas Zimmermann wrote:
> > I would argue that the current code is more readable that your proposed
> > change.
> >
> > I agree that it's a no-op, but code is not just about functionality but also
> > readability, isn't it?
>
> I won't argue with
Hi
Am 10.07.23 um 15:42 schrieb John Paul Adrian Glaubitz:
Hi Thomas!
On Mon, 2023-07-10 at 14:50 +0200, Thomas Zimmermann wrote:
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
is 0 and the static
Hi Thomas!
On Mon, 2023-07-10 at 14:50 +0200, Thomas Zimmermann wrote:
> FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
> is 0 and the static declaration already clears the memory area of
>
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
>
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
>
> Flags should signal differences from the default values. After cleaning
> up all
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Helge Deller
---
include/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d5c13f34b09..43458f582f35 100644
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Signed-off-by:
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by a static declaration. So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Signed-off-by: Thomas
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
is 0 and the static declaration already clears the memory area of
sh7763fb_videomode. So remove the assignment.
Signed-off-by: Thomas Zimmermann
Cc: Yoshinori
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by a static declaration. So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by:
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by devm_kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
Add details of the new hv-gpci interface file called
"affinity_domain_via_partition" in the ABI documentation.
Signed-off-by: Kajol Jain
---
.../sysfs-bus-event_source-devices-hv_gpci| 32 +++
1 file changed, 32 insertions(+)
diff --git
The hcall H_GET_PERF_COUNTER_INFO with counter request value as
AFFINITY_DOMAIN_INFORMATION_BY_PARTITION(0XB1), can be used to get
the system affinity domain via partition information. To expose the system
affinity domain via partition information, patch adds sysfs file called
Add details of the new hv-gpci interface file called
"affinity_domain_via_domain" in the ABI documentation.
Signed-off-by: Kajol Jain
---
.../sysfs-bus-event_source-devices-hv_gpci| 32 +++
1 file changed, 32 insertions(+)
diff --git
The hcall H_GET_PERF_COUNTER_INFO with counter request value as
AFFINITY_DOMAIN_INFORMATION_BY_DOMAIN(0XB0), can be used to get
the system affinity domain via domain information. To expose the system
affinity domain via domain information, patch adds sysfs file called
"affinity_domain_via_domain"
Add details of the new hv-gpci interface file called
"affinity_domain_via_virtual_processor" in the ABI documentation.
Signed-off-by: Kajol Jain
---
.../sysfs-bus-event_source-devices-hv_gpci| 32 +++
1 file changed, 32 insertions(+)
diff --git
The hcall H_GET_PERF_COUNTER_INFO with counter request value as
AFFINITY_DOMAIN_INFORMATION_BY_VIRTUAL_PROCESSOR(0XA0), can be used to get
the system affinity domain via virtual processor information. To expose
the system affinity domain via virtual processor information, patch adds
sysfs file
Add details of the new hv-gpci interface file called
"processor_config" in the ABI documentation.
Signed-off-by: Kajol Jain
---
.../sysfs-bus-event_source-devices-hv_gpci| 32 +++
1 file changed, 32 insertions(+)
diff --git
The hcall H_GET_PERF_COUNTER_INFO with counter request value as
PROCESSOR_CONFIG(0X90), can be used to get the system
processor configuration information. To expose the system
processor config information, patch adds sysfs file called
"processor_config" to the "/sys/devices/hv_gpci/interface/"
of
1 - 100 of 117 matches
Mail list logo
