On Thu 03-08-23 16:07:57, Douglas Anderson wrote:
> The APIs that allow backtracing across CPUs have always had a way to
> exclude the current CPU. This convenience means callers didn't need to
> find a place to allocate a CPU mask just to handle the common case.
>
> Let's extend the API to take a
PCI core API pci_dev_id() can be used to get the BDF number for a pci
device. We don't need to compose it mannually. Use pci_dev_id() to
simplify the code a little bit.
Signed-off-by: Xiongfeng Wang
---
arch/powerpc/platforms/powernv/pci-ioda.c | 6 +++---
1 file changed, 3 insertions(+), 3 dele
PCI core add pci_find_vsec_capability() to query VSEC. We can use that
core API to simplify the code.
The only logical change is that pci_find_vsec_capability check the
Vendor ID before finding the VSEC.
PCI spec rev 5.0 says in 7.9.5.2 Vendor-Specific Header:
VSEC ID - This field is a vendor-d
On 8/3/23 12:48, Ruan Jinjie wrote:
There is no possible for platform_get_irq() to
return 0. Use the return value from platform_get_irq().
Signed-off-by: Ruan Jinjie
---
drivers/soc/xilinx/zynqmp_power.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/x
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
---
drivers/usb/misc/cypress_cy7c63.c | 2 +-
drivers/usb/misc/cytherm.
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
---
drivers/usb/chipidea/udc.c | 2 +-
1 file changed, 1 insertion(+),
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Ruan Jinjie (5):
usb: gadget: udc: Remove unnecessary NULL values
USB: misc: Remove unnecessary
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
---
drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
drivers/usb/gadget/ud
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
---
drivers/usb/usbip/vudc_dev.c | 2 +-
1 file changed, 1 insertion(+)
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
---
drivers/usb/musb/musb_gadget.c | 2 +-
1 file changed, 1 insertion(
On Fri, Jul 28, 2023 at 07:48:27AM -0600, Rob Herring wrote:
> The DT of_device.h and of_platform.h date back to the separate
> of_platform_bus_type before it was merged into the regular platform bus.
> As part of that merge prepping Arm DT support 13 years ago, they
> "temporarily" include each ot
The fsl_mc_driver_register() will set "THIS_MODULE" to driver.owner when
register a fsl_mc_driver driver, so it is redundant initialization to set
driver.owner in dpaa2_dpio_driver statement. Remove it for clean code.
Signed-off-by: Li Zetao
---
drivers/soc/fsl/dpio/dpio-driver.c | 1 -
1 file c
On Wed, Aug 2, 2023 at 8:28 PM Hans Verkuil wrote:
>
> On 02/08/2023 14:02, Shengjiu Wang wrote:
> > On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote:
> >>
> >> On Wed, 02 Aug 2023 09:32:37 +0200,
> >> Hans Verkuil wrote:
> >>>
> >>> Hi all,
> >>>
> >>> On 25/07/2023 08:12, Shengjiu Wang wrote:
On 04/08/2023 14:19, Shengjiu Wang wrote:
> On Wed, Aug 2, 2023 at 8:28 PM Hans Verkuil wrote:
>>
>> On 02/08/2023 14:02, Shengjiu Wang wrote:
>>> On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote:
On Wed, 02 Aug 2023 09:32:37 +0200,
Hans Verkuil wrote:
>
> Hi all,
>
>>
On Wed, Aug 02, 2023 at 08:17:32PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 2, 2023, at 19:37, Linus Torvalds wrote:
> > On Wed, 2 Aug 2023 at 09:16, Nathan Chancellor wrote:
> >>
> >> We see this warning with ARCH=arm64 defconfig + CONFIG_CPU_BIG_ENDIAN=y.
> >
> > Oh Christ. I didn't even realiz
Over the years, platform and driver initialisation have evolved into
more generic ways, and driver or platform specific stuff has gone
away, leaving stale objects behind.
This series aims at cleaning all that up for fs_enet ethernet driver.
Changes in v2:
- Remove a trailing whitespace in the old
CC drivers/net/ethernet/freescale/fs_enet/fs_enet-main.o
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c: In function
'fs_enet_interrupt':
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c:321:40: warning: variable
'fpi' set but not used [-Wunused-but-set-variable]
Remove that v
CHECK drivers/net/ethernet/freescale/fs_enet/mac-fcc.c
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c:550:9: warning: cast removes
address space '__iomem' of expression
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c:550:9: error: subtraction of
different types can't work (different addres
Commit 3dd82a1ea724 ("[POWERPC] CPM: Always use new binding.")
removed last use of init_fec_ioports() and init_fcc_ioports().
Remove stale prototypes then don't include anymore fs_enet_pd.h
which was only included to provide fs_platform_info structure
for the prototypes.
Signed-off-by: Christophe
fs_get_id() hasn't been used since commit b219108cbace ("fs_enet:
Remove !CONFIG_PPC_CPM_NEW_BINDING code")
Remove it.
Signed-off-by: Christophe Leroy
---
include/linux/fs_enet_pd.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_ene
Since commit 3dd82a1ea724 ("[POWERPC] CPM: Always use new binding.")
many fields of fs_platform_info structure are not used anymore.
Remove them.
Signed-off-by: Christophe Leroy
---
include/linux/fs_enet_pd.h | 19 ---
1 file changed, 19 deletions(-)
diff --git a/include/linux/
struct fs_platform_info is only used in fs_enet ethernet driver since
commit 3dd82a1ea724 ("[POWERPC] CPM: Always use new binding.").
Stale prototypes using fs_platform_info were left over in
arch/powerpc/sysdev/fsl_soc.c but they are now removed by
previous patch.
Move struct fs_platform_info in
Three platforms in arch/powerpc/platforms/8xx/ include fs_enet_pd.h
but don't use anything from it.
Remove the includes.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/adder875.c| 1 -
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 1 -
arch/powerpc/platforms/8xx/tqm8xx_
Since commit 3dd82a1ea724 ("[POWERPC] CPM: Always use new binding.")
has_phy field is never set.
Remove dead code and remove the field.
Signed-off-by: Christophe Leroy
---
drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 14 --
include/linux/fs_enet_pd.h | 1
cpm_dpxxx() macros are now always referring to cpm_muram_xxx() fonctions
directly since commit 3dd82a1ea724 ("[POWERPC] CPM: Always use new
binding.")
Use cpm_muram_xxx() functions directly so that the cpm_dpxxx() macros
can be removed in the near future.
Signed-off-by: Christophe Leroy
---
dri
linux/fs_enet_pd.h is not used anymore.
Remove it.
Signed-off-by: Christophe Leroy
---
MAINTAINERS| 1 -
include/linux/fs_enet_pd.h | 118 -
2 files changed, 119 deletions(-)
delete mode 100644 include/linux/fs_enet_pd.h
diff --git a/MAINT
The APIs that allow backtracing across CPUs have always had a way to
exclude the current CPU. This convenience means callers didn't need to
find a place to allocate a CPU mask just to handle the common case.
Let's extend the API to take a CPU ID to exclude instead of just a
boolean. This isn't any
Hi,
On Fri, Aug 4, 2023 at 12:50 AM Michal Hocko wrote:
>
> On Thu 03-08-23 16:07:57, Douglas Anderson wrote:
> > The APIs that allow backtracing across CPUs have always had a way to
> > exclude the current CPU. This convenience means callers didn't need to
> > find a place to allocate a CPU mask
On Fri 04-08-23 06:56:51, Doug Anderson wrote:
> Hi,
>
> On Fri, Aug 4, 2023 at 12:50 AM Michal Hocko wrote:
> >
> > On Thu 03-08-23 16:07:57, Douglas Anderson wrote:
> > > The APIs that allow backtracing across CPUs have always had a way to
> > > exclude the current CPU. This convenience means c
On 04/08/2023 10:04, Xiongfeng Wang wrote:
PCI core API pci_dev_id() can be used to get the BDF number for a pci
device. We don't need to compose it mannually. Use pci_dev_id() to
simplify the code a little bit.
Signed-off-by: Xiongfeng Wang
---
LGTM
Reviewed-by: Frederic Barrat
Fred
Hello,
Le 20/07/2023 à 09:34, hanyu...@208suo.com a écrit :
> Fix below checkpatch errors:
>
> ./arch/powerpc/mm/book3s32/tlb.c:102: ERROR: spaces required around that
> '?' (ctx:VxW)
> ./arch/powerpc/mm/book3s32/tlb.c:102: ERROR: spaces required around that
> ':' (ctx:VxW)
Can you please ex
Hello,
Le 20/07/2023 à 12:17, zhangyongle...@208suo.com a écrit :
> [Vous ne recevez pas souvent de courriers de zhangyongle...@208suo.com.
> D?couvrez pourquoi ceci est important ?
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Fix twoce occurrences of the checkpatch.pl error:
> ERROR:
Hi,
On Fri, Aug 4, 2023 at 8:02 AM Michal Hocko wrote:
>
> > > It would have been slightly safer to modify arch_trigger_cpumask_backtrace
> > > by switching arguments so that some leftovers are captured easier.
> >
> > I'm not sure I understand. Oh, you're saying make the prototype of
> > arch_tr
Le 19/05/2023 à 13:38, Michael Ellerman a écrit :
> Commit 1e8fed873e74 ("powerpc: drop ranges for definition of
> ARCH_FORCE_MAX_ORDER") removed the limits on the possible values for
> ARCH_FORCE_MAX_ORDER.
>
> However removing the ranges entirely causes some common work flows to
> break. For e
On 8/4/23 03:32, Ruan Jinjie wrote:
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
---
drivers/usb/usbip/vudc_dev.c
On Sat, Jul 08, 2023 at 12:12:12PM -0700, Suren Baghdasaryan wrote:
[..]
> Lock VMAs of the parent process when forking a child, which prevents
> concurrent page faults during fork operation and avoids this issue.
> This fix can potentially regress some fork-heavy workloads. Kernel build
> time did
On Thu, Jul 06, 2023, Yu Zhang wrote:
> On Thu, Jul 06, 2023 at 02:29:24PM +0900, David Stevens wrote:
> > On Wed, Jul 5, 2023 at 7:53 PM Yu Zhang wrote:
> > >
> > > On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote:
> > > > On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang
> > > > wrote:
> >
On Tue, Jul 04, 2023, David Stevens wrote:
> From: David Stevens
>
> Introduce __kvm_follow_pfn, which will replace __gfn_to_pfn_memslot.
> __kvm_follow_pfn refactors the old API's arguments into a struct and,
> where possible, combines the boolean arguments into a single flags
> argument.
>
> S
On Wed, Jul 05, 2023, Yu Zhang wrote:
> On Tue, Jul 04, 2023 at 04:50:49PM +0900, David Stevens wrote:
> > From: David Stevens
> >
> > Migrate from __gfn_to_pfn_memslot to __kvm_follow_pfn.
Please turn up your changelog verbosity from ~2 to ~8. E.g. explain the
transition
from async => FOLL_NO
On Thu, Jul 06, 2023, David Stevens wrote:
> On Wed, Jul 5, 2023 at 7:17 PM Yu Zhang wrote:
> >
> > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote:
> > > From: David Stevens
> > >
> > > Stop passing FOLL_GET to __kvm_follow_pfn. This allows the host to map
> > > memory into the gue
On Tue, Jul 04, 2023, David Stevens wrote:
> From: David Stevens
>
> This patch series adds support for mapping VM_IO and VM_PFNMAP memory
> that is backed by struct pages that aren't currently being refcounted
> (e.g. tail pages of non-compound higher order allocations) into the
> guest.
Aplogi
On Fri, 4 Aug 2023 at 14:46, Mateusz Guzik wrote:
>
> I don't see it mentioned in the discussion, so at a risk of ruffling
> feathers or looking really bad I'm going to ask: is the locking of any
> use if the forking process is single-threaded? T
Sadly, we've always been able to access the mm fro
On 8/5/23, Linus Torvalds wrote:
> On Fri, 4 Aug 2023 at 14:46, Mateusz Guzik wrote:
>>
>> I don't see it mentioned in the discussion, so at a risk of ruffling
>> feathers or looking really bad I'm going to ask: is the locking of any
>> use if the forking process is single-threaded? T
>
> Sadly,
On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
>
> I know of these guys, I think they are excluded as is -- they go
> through access_remote_vm, starting with:
> if (mmap_read_lock_killable(mm))
> return 0;
>
> while dup_mmap already write locks the parent's mm.
Oh, you'
On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
wrote:
>
> On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> >
> > I know of these guys, I think they are excluded as is -- they go
> > through access_remote_vm, starting with:
> > if (mmap_read_lock_killable(mm))
> > return
On Fri, Aug 4, 2023 at 5:26 PM Suren Baghdasaryan wrote:
>
> On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
> wrote:
> >
> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> > >
> > > I know of these guys, I think they are excluded as is -- they go
> > > through access_remote_vm, starting with
On 8/5/23, Suren Baghdasaryan wrote:
> On Fri, Aug 4, 2023 at 5:26 PM Suren Baghdasaryan
> wrote:
>>
>> On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
>> wrote:
>> >
>> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
>> > >
>> > > I know of these guys, I think they are excluded as is -- they
On 8/5/23, Linus Torvalds wrote:
> On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
>>
>> I know of these guys, I think they are excluded as is -- they go
>> through access_remote_vm, starting with:
>> if (mmap_read_lock_killable(mm))
>> return 0;
>>
>> while dup_mmap alr
On Fri, Aug 4, 2023 at 5:49 PM Mateusz Guzik wrote:
>
> On 8/5/23, Suren Baghdasaryan wrote:
> > On Fri, Aug 4, 2023 at 5:26 PM Suren Baghdasaryan
> > wrote:
> >>
> >> On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
> >> wrote:
> >> >
> >> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> >>
On 8/5/23, Suren Baghdasaryan wrote:
> On Fri, Aug 4, 2023 at 5:49 PM Mateusz Guzik wrote:
>> However, the other users (that I know of ) go through the mmap
>> semaphore to mess with anything which means they will wait for
>> dup_mmap to finish (or do their work first). I would be surprised if
>>
On Fri, Aug 4, 2023 at 6:17 PM Mateusz Guzik wrote:
>
> On 8/5/23, Suren Baghdasaryan wrote:
> > On Fri, Aug 4, 2023 at 5:49 PM Mateusz Guzik wrote:
> >> However, the other users (that I know of ) go through the mmap
> >> semaphore to mess with anything which means they will wait for
> >> dup_mm
On Fri, Aug 4, 2023 at 6:06 PM Mateusz Guzik wrote:
>
> On 8/5/23, Linus Torvalds wrote:
> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> >>
> >> I know of these guys, I think they are excluded as is -- they go
> >> through access_remote_vm, starting with:
> >> if (mmap_read_lock_
On 2023/8/5 4:09, shuah wrote:
> On 8/4/23 03:32, Ruan Jinjie wrote:
>> The NULL initialization of the pointers assigned by kzalloc() first is
>> not necessary, because if the kzalloc() failed, the pointers will be
>> assigned NULL, otherwise it works as usual. so remove it.
>>
>> Signed-off-by:
53 matches
Mail list logo
