Platform device for card to probe is registered in imx-audio-rpmsg.
According to this change DT node of ASoC CPU DAI device is updated.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/imx-rpmsg.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git
Let imx-audio-rpmsg register platform device for card. So that card
register and unregister can be controlled by rpmsg driver's register
and unregister.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_rpmsg.c | 11 ---
sound/soc/fsl/imx-audio-rpmsg.c | 17 -
2
This rpmsg driver registers device for ASoC platform driver. To align
with platform driver use rpmsg channel name to create device.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/imx-audio-rpmsg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Machine driver uses rpmsg channel name to link this platform component.
However if the component is re-registerd card will not find this new
created component in snd_soc_try_rebind_card().
Explicitly register this component with rpmsg channel name so that
card can always find this component.
echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware
(A) echo start > /sys/class/remoteproc/remoteproc0/state
(B) echo stop > /sys/class/remoteproc/remoteproc0/state
The rpmsg sound card is registered in (A) and unregistered in (B).
After "start", imx-audio-rpmsg
Hi Chancel,
kernel test robot noticed the following build errors:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on broonie-sound/for-next linus/master v6.8-rc7
next-20240306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
Hi Yury,
On Wed, 6 Mar 2024 15:39:06 +0200
Andy Shevchenko wrote:
> On Wed, Mar 06, 2024 at 05:11:19AM -0800, Yury Norov wrote:
> > On Wed, Mar 06, 2024 at 09:07:19AM +0100, Herve Codina wrote:
>
> ...
>
> > Signed-off-by: Yury Norov
>
> Why? Shouldn't be Acked-by?
>
> > Would you like
Hi Yury,
On Wed, 6 Mar 2024 05:06:12 -0800
Yury Norov wrote:
...
> > +static int qmc_hdlc_xlate_ts_info(struct qmc_hdlc *qmc_hdlc,
> > + const struct qmc_chan_ts_info *ts_info, u32
> > *slot_map)
> > +{
> > + DECLARE_BITMAP(ts_mask_avail, 64);
> > +
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: 5b9e00a6004cf837c43fdb8d5290df619de78024 powerpc/4xx: Fix
warp_gpio_leds build failure
elapsed time: 1027m
configs tested: 128
configs skipped: 3
The following configs have been built
Le 07/03/2024 à 06:32, Michael Ellerman a écrit :
> Christophe Leroy writes:
>> Le 06/03/2024 à 13:58, Michael Ellerman a écrit :
>>> If both CONFIG_SENSORS_AMS_PMU and CONFIG_SENSORS_AMS_I2C are unset,
>>> there is an unused variable warning in the ams driver:
>>>
>>>
Christophe Leroy writes:
> Le 06/03/2024 à 13:58, Michael Ellerman a écrit :
>> If both CONFIG_SENSORS_AMS_PMU and CONFIG_SENSORS_AMS_I2C are unset,
>> there is an unused variable warning in the ams driver:
>>
>>drivers/macintosh/ams/ams-core.c: In function 'ams_init':
>>
Hi Chancel,
kernel test robot noticed the following build errors:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on broonie-sound/for-next linus/master v6.8-rc7
next-20240306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On Wed, Mar 06, 2024 at 11:56:56PM +1100, Michael Ellerman wrote:
> pet...@redhat.com writes:
> > From: Peter Xu
> >
> > PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
> > constantly returns 0 for hash MMUs. AFAICT that is fine to be removed,
> > because pXd_huge()
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c |
mutex_destroy() definition is located in the middle of the code related
purely to mutex initialization so place it separately after mutex_init()
Signed-off-by: George Stark
---
Hello Waiman. This is helper patch to make resulting mutex.h look like we
discussed
it in December. It was in you
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
This patch series fixes the problem of devm_led_classdev_register misusing.
The basic problem is described in [1]. Shortly when devm_led_classdev_register()
is used then led_classdev_unregister() called after driver's remove() callback.
led_classdev_unregister() calls driver's brightness_set
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
Since mutex_destroy()
Hi Arnd,
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
> ---
> Changes from v1:
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Naresh noticed that the newly added usage of the PAGE_SIZE macro in
> include/vdso/datapage.h introduced a build regression. I had an older
> patch that I revived to have this defined through Kconfig rather than
>
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
>
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arc, arm64, parisc and powerpc all have their own Kconfig symbols
> in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
> so the common symbols are the ones that are actually used, while
> leaving the
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
On Wed, Mar 06, 2024 at 12:01:42PM +1100, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > Ping? We have been applying this in our CI since it was sent, it would
> > be nice to have this upstream soon so it can start filtering through the
> > stable trees.
>
> Sorry, I was away in January
On Wed, Mar 6, 2024 at 3:15 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
>
On Wed, 6 Mar 2024 15:38:10 +0200 Andy Shevchenko wrote:
> > It's minor, but you can avoid conditionals doing something like:
> >
> > netdev->stats.rx_over_errors += !!(flags &
> > QMC_RX_FLAG_HDLC_OVF);
>
> This is harder to read.
+1
On 3/6/24 10:55, Stefan Berger wrote:
This series resolves an issue on PowerVM and KVM on Power where the memory
the TPM log was held in may become inaccessible or corrupted after a kexec
soft reboot. The solution on these two platforms is to store the whole log
in the device tree because the
On Wed, Mar 06, 2024 at 04:43:11PM +0100, Herve Codina wrote:
> On Wed, 6 Mar 2024 15:43:04 +0200
> Andy Shevchenko wrote:
> > On Wed, Mar 06, 2024 at 05:06:12AM -0800, Yury Norov wrote:
> > > On Wed, Mar 06, 2024 at 09:07:20AM +0100, Herve Codina wrote:
...
> > > > +
If linux,sml-log is available use it to get the TPM log rather than the
pointer found in linux,sml-base. This resolves an issue on PowerVM and KVM
on Power where after a kexec the memory pointed to by linux,sml-base may
have been corrupted. Also, linux,sml-log has replaced linux,sml-base and
linux,sml-base holds the address of a buffer with the TPM log. This
buffer may become invalid after a kexec and therefore embed the whole TPM
log in linux,sml-log. This helps to protect the log since it is properly
carried across a kexec with both of the kexec syscalls.
Signed-off-by: Stefan
This series resolves an issue on PowerVM and KVM on Power where the memory
the TPM log was held in may become inaccessible or corrupted after a kexec
soft reboot. The solution on these two platforms is to store the whole log
in the device tree because the device tree is preserved across a kexec
Hi Andy, Yury,
On Wed, 6 Mar 2024 15:43:04 +0200
Andy Shevchenko wrote:
> On Wed, Mar 06, 2024 at 05:06:12AM -0800, Yury Norov wrote:
> > On Wed, Mar 06, 2024 at 09:07:20AM +0100, Herve Codina wrote:
>
> ...
>
> > > + DECLARE_BITMAP(ts_mask_avail, 64);
> > > + DECLARE_BITMAP(ts_mask, 64);
>
From: Arnd Bergmann
Most architectures only support a single hardcoded page size. In order
to ensure that each one of these sets the corresponding Kconfig symbols,
change over the PAGE_SHIFT definition to the common one and allow
only the hardware page size to be selected.
Acked-by: Guo Ren
From: Arnd Bergmann
arc, arm64, parisc and powerpc all have their own Kconfig symbols
in place of the common CONFIG_PAGE_SIZE_4KB symbols. Change these
so the common symbols are the ones that are actually used, while
leaving the arhcitecture specific ones as the user visible
place for
From: Arnd Bergmann
These four architectures define the same Kconfig symbols for configuring
the page size. Move the logic into a common place where it can be shared
with all other architectures.
Signed-off-by: Arnd Bergmann
---
Changes from v1:
- improve Kconfig help texts
- fix Hexagon
From: Arnd Bergmann
Naresh noticed that the newly added usage of the PAGE_SIZE macro in
include/vdso/datapage.h introduced a build regression. I had an older
patch that I revived to have this defined through Kconfig rather than
through including asm/page.h, which is not allowed in vdso code.
On Wed, Mar 06, 2024 at 05:06:12AM -0800, Yury Norov wrote:
> On Wed, Mar 06, 2024 at 09:07:20AM +0100, Herve Codina wrote:
...
> > + DECLARE_BITMAP(ts_mask_avail, 64);
> > + DECLARE_BITMAP(ts_mask, 64);
> > + DECLARE_BITMAP(map, 64);
> > + bitmap_from_u64(ts_mask_avail,
On Wed, Mar 06, 2024 at 05:11:19AM -0800, Yury Norov wrote:
> On Wed, Mar 06, 2024 at 09:07:19AM +0100, Herve Codina wrote:
...
> Signed-off-by: Yury Norov
Why? Shouldn't be Acked-by?
> Would you like to move this with the rest of the series? If so please
> pull my Sof-by, otherwise I can
On Wed, Mar 06, 2024 at 05:27:51AM -0800, Yury Norov wrote:
> On Wed, Mar 06, 2024 at 09:07:17AM +0100, Herve Codina wrote:
...
> It's minor, but you can avoid conditionals doing something like:
>
> netdev->stats.rx_over_errors += !!(flags &
> QMC_RX_FLAG_HDLC_OVF);
This is
On Wed, Mar 06, 2024 at 09:07:17AM +0100, Herve Codina wrote:
> The QMC HDLC driver provides support for HDLC using the QMC (QUICC
> Multichannel Controller) to transfer the HDLC data.
>
> Signed-off-by: Herve Codina
> Reviewed-by: Christophe Leroy
> Acked-by: Jakub Kicinski
> Reviewed-by:
Le 06/03/2024 à 13:58, Michael Ellerman a écrit :
> If both CONFIG_SENSORS_AMS_PMU and CONFIG_SENSORS_AMS_I2C are unset,
> there is an unused variable warning in the ams driver:
>
>drivers/macintosh/ams/ams-core.c: In function 'ams_init':
>drivers/macintosh/ams/ams-core.c:181:29:
On Wed, Mar 06, 2024 at 09:07:19AM +0100, Herve Codina wrote:
> From: Andy Shevchenko
>
> These helpers scatters or gathers a bitmap with the help of the mask
> position bits parameter.
>
> bitmap_scatter() does the following:
> src: 01011010
> ||
>
On Wed, Mar 06, 2024 at 09:07:20AM +0100, Herve Codina wrote:
> QMC channels support runtime timeslots changes but nothing is done at
> the QMC HDLC driver to handle these changes.
>
> Use existing IFACE ioctl in order to configure the timeslots to use.
>
> Signed-off-by: Herve Codina
>
On 29/2/24 08:00, Takashi Iwai wrote:
On Wed, 21 Feb 2024 13:37:10 +0100,
Richard Fitzgerald wrote:
snd_soc_card_get_kcontrol() must be holding a read lock on
card->controls_rwsem while walking the controls list.
Compare with snd_ctl_find_numid().
The existing function is renamed
If both CONFIG_SENSORS_AMS_PMU and CONFIG_SENSORS_AMS_I2C are unset,
there is an unused variable warning in the ams driver:
drivers/macintosh/ams/ams-core.c: In function 'ams_init':
drivers/macintosh/ams/ams-core.c:181:29: warning: unused variable 'np'
181 | struct device_node
Building eg. 83xx/mpc832x_rdb_defconfig with FPU=n, fails with:
arch/powerpc/platforms/83xx/suspend.c: In function 'mpc83xx_suspend_enter':
arch/powerpc/platforms/83xx/suspend.c:209:17: error: implicit declaration of
function 'enable_kernel_fp'
209 | enable_kernel_fp();
With CONFIG_BUG=n, the 64-bit Book3S build fails with:
arch/powerpc/include/asm/book3s/64/pgtable-64k.h: In function
'get_hugepd_cache_index':
arch/powerpc/include/asm/book3s/64/pgtable-64k.h:51:1: error: no return
statement in function returning non-void
Currently the body of the function
pet...@redhat.com writes:
> From: Peter Xu
>
> PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
> constantly returns 0 for hash MMUs. AFAICT that is fine to be removed,
> because pXd_huge() reflects a hugetlb entry, while it's own hugetlb pgtable
> lookup function
When the watchdog determines that the current soft lockup is due
to an interrupt storm based on CPU utilization, reporting the
most frequent interrupts could be good enough for further
troubleshooting.
Below is an example of interrupt storm. The call tree does not
provide useful information, but
The following softlockup is caused by interrupt storm, but it cannot be
identified from the call tree. Because the call tree is just a snapshot
and doesn't fully capture the behavior of the CPU during the soft lockup.
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
...
Call
show_interrupts() unconditionally accumulates the per CPU interrupt
statistics to determine whether an interrupt was ever raised.
This can be avoided for all interrupts which are not strictly per CPU
and not of type NMI because those interrupts provide already an
accumulated counter. The required
The soft lockup detector lacks a mechanism to identify interrupt storms
as root cause of a lockup. To enable this the detector needs a
mechanism to snapshot the interrupt count statistics on a CPU when the
detector observes a potential lockup scenario and compare that against
the interrupt count
Hi, guys.
I have implemented a low-overhead method for detecting interrupt
storm in softlockup. Please review it, all comments are welcome.
Changes from v11 to v12:
- From Douglas and Thomas, add a new kconfig knob save memory when
the softlock detector code is not enabled.
- Adjust the order
Hi Christophe,
On Tue, Feb 20, 2024 at 04:12:17PM +, Christophe Leroy wrote:
> Hi Michael,
>
> ping ?
>
> Le 01/02/2023 à 15:36, Dawei Li a écrit :
> > Commit fc7a6209d571 ("bus: Make remove callback return void") forces
> > bus_type::remove be void-returned, it doesn't make much sense for
Fix builds with CONFIG_PMAC_BACKLIGHT=y. The include statement for
the backlight header has recently been removed from .
Reported-by: Naresh Kamboju
Closes:
https://lore.kernel.org/dri-devel/ca+g9fysak5tbqqxfc2w4ohlga0cbthmxbeq8qayfxtu75yi...@mail.gmail.com/
Signed-off-by: Thomas Zimmermann
Replace with a forward declaration in to
resolve an unnecessary dependency. Remove pmac_backlight_curve_lookup()
and struct fb_info from source and header files. The function and the
framebuffer struct are unused. No functional changes.
v3:
* Add Fixes tag (Christophe)
* fix
Fix builds with CONFIG_PMAC_BACKLIGHT=y. The include statement for the
backlight header has recently been removed from . Add it to
via-pmu-backlight.c to get the necessary symbols.
Reported-by: Naresh Kamboju
Closes:
After cleaning up in commit 11b4eedfc87d ("fbdev: Do
not include in header"), building with
CONFIG_PMAC_BACKLIGHT=y returns errors about missing declarations.
Patches 1 and 2 resolve the errors. Patch 1 has been reviewed at [1].
Patch 3 removes another dependency between backlight and fbdev
On Thu, Feb 29, 2024 at 09:06:16AM +0530, K Prateek Nayak wrote:
> (+ Xuewen Yan, Ke Wang)
>
> Hello Tobias,
>
<...>
> >
> > Questions:
> > 1. The kworker getting its negative lag occurs in the following scenario
> >- kworker and a cgroup are supposed to execute on the same CPU
> >- one
Hi,
On 2024/3/6 00:57, Thomas Gleixner wrote:
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 2531f3496ab6..a28e5ac5fc79 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -108,6 +108,10 @@ config GENERIC_IRQ_MATRIX_ALLOCATOR
config GENERIC_IRQ_RESERVATION_MODE
On Wed, 6 Mar 2024 at 11:18, K Prateek Nayak wrote:
>
> Hello Vincent,
>
> Thank you for taking a look at the series.
>
> On 3/6/2024 3:29 PM, Vincent Guittot wrote:
> > Hi Prateek,
> >
> > Adding Julia who could be interested in this patchset. Your patchset
> > should trigger idle load balance
Hello Vincent,
Thank you for taking a look at the series.
On 3/6/2024 3:29 PM, Vincent Guittot wrote:
> Hi Prateek,
>
> Adding Julia who could be interested in this patchset. Your patchset
> should trigger idle load balance instead of newly idle load balance
> now when the polling is used. This
Hi Prateek,
Adding Julia who could be interested in this patchset. Your patchset
should trigger idle load balance instead of newly idle load balance
now when the polling is used. This was one reason for not migrating
task in idle CPU
On Tue, 20 Feb 2024 at 18:15, K Prateek Nayak wrote:
>
>
From: Peter Xu
There's one small section already, but since we're going to remove
pXd_huge(), that comment may start to obsolete.
Rewrite that section with more information, hopefully with that the API is
crystal clear on what it implies.
Signed-off-by: Peter Xu
---
include/linux/pgtable.h |
From: Peter Xu
This API is not used anymore, drop it for the whole tree.
Signed-off-by: Peter Xu
---
arch/arm/mm/Makefile | 1 -
arch/arm/mm/hugetlbpage.c | 29 ---
arch/arm64/mm/hugetlbpage.c | 10 ---
From: Peter Xu
Now after we're sure all pXd_huge() definitions are the same as pXd_leaf(),
reuse it. Luckily, pXd_huge() isn't widely used.
Signed-off-by: Peter Xu
---
arch/arm/include/asm/pgtable-3level.h | 2 +-
arch/arm64/include/asm/pgtable.h | 2 +-
arch/arm64/mm/hugetlbpage.c
From: Peter Xu
Huge mapping checks in GUP are slightly redundant and can be simplified.
pXd_huge() now is the same as pXd_leaf(). pmd_trans_huge() and
pXd_devmap() should both imply pXd_leaf(). Time to merge them into one.
Signed-off-by: Peter Xu
---
mm/gup.c | 7 +++
1 file changed, 3
From: Peter Xu
PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
constantly returns 0 for hash MMUs. AFAICT that is fine to be removed,
because pXd_huge() reflects a hugetlb entry, while it's own hugetlb pgtable
lookup function (__find_linux_pte() shared by all powerpc
From: Peter Xu
Unlike most archs, aarch64 defines pXd_huge() and pXd_leaf() slightly
differently. Redefine the pXd_huge() with pXd_leaf().
There used to be two traps for old aarch64 definitions over these APIs that
I found when reading the code around, they're:
(1) 4797ec2dc83a ("arm64: fix
From: Peter Xu
Most of the archs already define these two APIs the same way. ARM is more
complicated in two aspects:
- For pXd_huge() it's always checking against !PXD_TABLE_BIT, while for
pXd_leaf() it's always checking against PXD_TYPE_SECT.
- SECT/TABLE bits are defined differently
From: Peter Xu
It's already confusing that ARM 2-level v.s. 3-level defines SECT bit
differently on pmd/puds. Always use a macro which is much clearer.
Cc: Russell King
Cc: Shawn Guo
Cc: Krzysztof Kozlowski
Cc: Bjorn Andersson
Cc: Arnd Bergmann
Cc: Konrad Dybcio
Cc: Fabio Estevam
Cc:
From: Peter Xu
Please refer to the previous patch on the reasoning for x86. Now sparc is
the only architecture that will allow swap entries to be reported as
pXd_huge(). After this patch, all architectures should forbid swap entries
in pXd_huge().
Cc: David S. Miller
Cc: Andreas Larsson
Cc:
From: Peter Xu
This patch partly reverts below commits:
3a194f3f8ad0 ("mm/hugetlb: make pud_huge() and follow_huge_pud() aware of
non-present pud entry")
cbef8478bee5 ("mm/hugetlb: pmd_huge() returns true for non-present hugepage")
Right now, pXd_huge() definition across kernel is unclear. We
From: Peter Xu
Currently there should have no p4d swap entries so it may not matter much,
however this may help us to rule out swap entries in pXd_huge() API, which
will include p4d_huge(). The p4d_present() checks make it 100% clear that
we won't rely on p4d_huge() for swap entries.
From: Peter Xu
Add a variable to cache p4d in follow_p4d_mask(). It's a good practise to
make sure all the following checks will have a consistent view of the entry.
Signed-off-by: Peter Xu
---
mm/gup.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
From: Peter Xu
Swap pud entries do not always return true for pud_huge() for all archs.
x86 and sparc (so far) allow it, but all the rest do not accept a swap
entry to be reported as pud_huge(). So it's not safe to check swap entries
within pud_huge(). Check swap entries before pud_huge(), so
From: Peter Xu
[based on akpm/mm-unstable latest commit a7f399ae964e]
In previous work [1], we removed the pXd_large() API, which is arch
specific. This patchset further removes the hugetlb pXd_huge() API.
Hugetlb was never special on creating huge mappings when compared with
other huge
On Wed, 2024-02-14 at 15:21 +0530, Mahesh Salgaonkar wrote:
> nmi_enter()/nmi_exit() touches per cpu variables which can lead to
> kernel
> crash when invoked during real mode interrupt handling (e.g. early
> HMI/MCE
> interrupt handler) if percpu allocation comes from vmalloc area.
>
> Early
QMC channels support runtime timeslots changes but nothing is done at
the QMC HDLC driver to handle these changes.
Use existing IFACE ioctl in order to configure the timeslots to use.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
Reviewed-by: Andy
After contributing the driver, add myself as the maintainer for the
Freescale QMC HDLC driver.
Signed-off-by: Herve Codina
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a69..15cd3a8e5866 100644
--- a/MAINTAINERS
+++
Add framer support in the fsl_qmc_hdlc driver in order to be able to
signal carrier changes to the network stack based on the framer status
Also use this framer to provide information related to the E1/T1 line
interface on IF_GET_IFACE and configure the line interface according to
IF_IFACE_{E1,T1}
The QMC HDLC driver provides support for HDLC using the QMC (QUICC
Multichannel Controller) to transfer the HDLC data.
Signed-off-by: Herve Codina
Reviewed-by: Christophe Leroy
Acked-by: Jakub Kicinski
Reviewed-by: Andy Shevchenko
---
drivers/net/wan/Kconfig| 12 +
Hi,
This series introduces the QMC HDLC support.
Patches were previously sent as part of a full feature series and were
previously reviewed in that context:
"Add support for QMC HDLC, framer infrastructure and PEF2256 framer" [1]
In order to ease the merge, the full feature series has been
From: Andy Shevchenko
These helpers scatters or gathers a bitmap with the help of the mask
position bits parameter.
bitmap_scatter() does the following:
src: 01011010
||
+--+|
| ++
| |++|||
| ||
90 matches
Mail list logo
