[PATCH] scsi: message: fusion: remove useless variable
Fix the following gcc warning:
drivers/message/fusion/mptsas.c:783:14: warning: variable ‘vtarget’ set
but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/message/fusion/mptsas.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 5eb0b33..c54e823 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -780,13 +780,11 @@ static inline MPT_ADAPTER *rphy_to_ioc(struct sas_rphy
*rphy)
mptsas_add_device_component_starget(MPT_ADAPTER *ioc,
struct scsi_target *starget)
{
- VirtTarget *vtarget;
struct sas_rphy *rphy;
struct mptsas_phyinfo *phy_info = NULL;
struct mptsas_enclosure enclosure_info;
rphy = dev_to_rphy(starget->dev.parent);
- vtarget = starget->hostdata;
phy_info = mptsas_find_phyinfo_by_sas_address(ioc,
rphy->identify.sas_address);
if (!phy_info)
--
1.8.3.1
Re: [PATCH] serial: stm32: optimize spin lock usage
On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.min...@gmail.com wrote: > From: dillon min > > To avoid potential deadlock in spin_lock usage, change to use > spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context. > spin_lock(), spin_unlock() under handler context. > > remove unused local_irq_save/restore call. > > Signed-off-by: dillon min > --- > Was verified on stm32f469-disco board. need more test on stm32mp platform. > > drivers/tty/serial/stm32-usart.c | 27 +-- > 1 file changed, 17 insertions(+), 10 deletions(-) > > diff --git a/drivers/tty/serial/stm32-usart.c > b/drivers/tty/serial/stm32-usart.c > index b3675cf25a69..c4c859b34367 100644 > --- a/drivers/tty/serial/stm32-usart.c > +++ b/drivers/tty/serial/stm32-usart.c > @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port > *port, bool threaded) > struct tty_port *tport = >state->port; > struct stm32_port *stm32_port = to_stm32_port(port); > const struct stm32_usart_offsets *ofs = _port->info->ofs; > - unsigned long c; > + unsigned long c, flags; > u32 sr; > char flag; > > @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port > *port, bool threaded) > uart_insert_char(port, sr, USART_SR_ORE, c, flag); > } > > - spin_unlock(>lock); > + if (threaded) > + spin_unlock_irqrestore(>lock, flags); > + else > + spin_unlock(>lock); You shouldn't have to check for this, see the other patches on the list recently that fixed this up to not be an issue for irq handlers. thanks, greg k-h
[PATCH] [v2] usb: cdns3: Fix runtime PM imbalance on error
When cdns3_gadget_start() fails, a pairing PM usage counter
decrement is needed to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Use pm_runtime_put_sync() to decrease refcount.
---
drivers/usb/cdns3/cdns3-gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c
index 582bfeceedb4..a49fc68ec2ef 100644
--- a/drivers/usb/cdns3/cdns3-gadget.c
+++ b/drivers/usb/cdns3/cdns3-gadget.c
@@ -3255,8 +3255,10 @@ static int __cdns3_gadget_init(struct cdns *cdns)
pm_runtime_get_sync(cdns->dev);
ret = cdns3_gadget_start(cdns);
- if (ret)
+ if (ret) {
+ pm_runtime_put_sync(cdns->dev);
return ret;
+ }
/*
* Because interrupt line can be shared with other components in
--
2.17.1
Re: [PATCH v2 1/9] riscv: add __init section marker to some functions
On Fri, 2 Apr 2021 09:38:02 +0530
Anup Patel wrote:
>
>
> On Wed, Mar 31, 2021 at 10:00 PM Jisheng Zhang
> wrote:
> >
> > From: Jisheng Zhang
> >
> > They are not needed after booting, so mark them as __init to move them
> > to the __init section.
> >
> > Signed-off-by: Jisheng Zhang
> > ---
> > arch/riscv/kernel/traps.c | 2 +-
> > arch/riscv/mm/init.c | 6 +++---
> > arch/riscv/mm/kasan_init.c | 6 +++---
> > arch/riscv/mm/ptdump.c | 2 +-
> > 4 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> > index 1357abf79570..07fdded10c21 100644
> > --- a/arch/riscv/kernel/traps.c
> > +++ b/arch/riscv/kernel/traps.c
> > @@ -197,6 +197,6 @@ int is_valid_bugaddr(unsigned long pc)
> > #endif /* CONFIG_GENERIC_BUG */
> >
> > /* stvec & scratch is already set from head.S */
> > -void trap_init(void)
> > +void __init trap_init(void)
> > {
> > }
>
> The trap_init() is unused currently so you can drop this change
> and remove trap_init() as a separate patch.
the kernel init/main.c expects a trap_init() implementation in architecture
code. Some architecture's implementation is NULL, similar as riscv, for example,
arm, powerpc and so on. However I think you are right, the trap_init() can be
removed, we need a trivial series to provide a __weak but NULL trap_init()
implementation in init/main.c then remove all NULL implementation from
all arch. I can take the task to do the clean up.
>
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 067583ab1bd7..76bf2de8aa59 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -57,7 +57,7 @@ static void __init zone_sizes_init(void)
> > free_area_init(max_zone_pfns);
> > }
> >
> > -static void setup_zero_page(void)
> > +static void __init setup_zero_page(void)
> > {
> > memset((void *)empty_zero_page, 0, PAGE_SIZE);
I think the zero page is already initialized as "0" because empty_zero_page
sits in .bss section. So this setup_zero_page() function can be removed. I
will send a newer version later.
thanks
Re: Re: [PATCH] usb: cdns3: Fix rumtime PM imbalance on error
> On 21-04-07 13:22:26, Dinghao Liu wrote:
> > When cdns3_gadget_start() fails, a pairing PM usage counter
> > decrement is needed to keep the counter balanced.
> >
> > Signed-off-by: Dinghao Liu
> > ---
> > drivers/usb/cdns3/cdns3-gadget.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/cdns3/cdns3-gadget.c
> > b/drivers/usb/cdns3/cdns3-gadget.c
> > index 582bfeceedb4..ad891a108aed 100644
> > --- a/drivers/usb/cdns3/cdns3-gadget.c
> > +++ b/drivers/usb/cdns3/cdns3-gadget.c
> > @@ -3255,8 +3255,11 @@ static int __cdns3_gadget_init(struct cdns *cdns)
> > pm_runtime_get_sync(cdns->dev);
> >
> > ret = cdns3_gadget_start(cdns);
> > - if (ret)
> > + if (ret) {
> > + pm_runtime_mark_last_busy(cdns->dev);
> > + pm_runtime_put_autosuspend(cdns->dev);
> > return ret;
>
> It doesn't need to delay entering runtime suspend, I prefer using
> pm_runtime_put_sync directly.
>
Sounds reasonable, thanks! I will send a new patch soon.
Regards,
Dinghao
[PATCH] [v2] iio: proximity: pulsedlight: Fix rumtime PM imbalance on error
When lidar_write_control() fails, a pairing PM usage counter
decrement is needed to keep the counter balanced.
Fixes: 4ac4e086fd8c5 ("iio: pulsedlight-lidar-lite: add runtime PM")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Add the fix tag.
---
drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
index c685f10b5ae4..cc206bfa09c7 100644
--- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
+++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
@@ -160,6 +160,7 @@ static int lidar_get_measurement(struct lidar_data *data,
u16 *reg)
ret = lidar_write_control(data, LIDAR_REG_CONTROL_ACQUIRE);
if (ret < 0) {
dev_err(>dev, "cannot send start measurement command");
+ pm_runtime_put_noidle(>dev);
return ret;
}
--
2.17.1
Re: Linux 5.12-rc7
On Sun, Apr 11, 2021 at 03:41:18PM -0700, Linus Torvalds wrote:
> Oh well. rc5 was big. rc6 was small. And now rc7 is big again. In
> fact, it's the biggest rc7 (at least in number of commits) we've had
> in the 5.x series.
>
> It's mostly due to networking fixes (of which rc6 had none), and none
> of them should be all that scary, but it's never great when we have
> such a big rc. It's particularly annoying at the end of the release
> window like this.
>
> End result: I'm still waffling about the final 5.12 release. The fact
> that we have a big rc7 does make me think that I'll probably do an rc8
> this time around. But it ends up depending a bit on how the upcoming
> week goes, and if things are deathly quiet, I may end up deciding that
> an rc8 doesn't really make sense.
>
> So we'll see.
>
> Anyway, networking (both core and drivers) is over half of the rc7
> patch, with the rest being a fairly random collection of fixes all
> over. We've got other driver updates (sound, rdma, scsi, usb..) some
> fs fixes (io_uring, umount, btrfs, cifs, ocfs), minor arch fixes (arc,
> arm, parisc, powerpc, s390, x86), and other misc fixes.
>
> The shortlog is appended, although it's obviously not as nice and
> small and readable as I'd have liked at this point in the release..
>
> Please do test,
>
Build results:
total: 151 pass: 151 fail: 0
Qemu test results:
total: 460 pass: 459 fail: 1
Failed tests:
sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs
The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull payload in
skb->head"). It is a spurious problem - the test passes roughly every other
time. When the failure is seen, udhcpc fails to get an IP address and aborts
with SIGTERM. So far I have only seen this with the "sh" architecture.
Guenter
Re: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
On Fri, Apr 9, 2021 at 4:54 PM Chunfeng Yun wrote:
>
> On Fri, 2021-04-09 at 13:45 +0800, Ikjoon Jang wrote:
> > On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun
> > wrote:
> > >
> > > A dedicated wakeup irq will be used to handle runtime suspend/resume,
> > > we use dev_pm_set_dedicated_wake_irq API to take care of requesting
> > > and attaching wakeup irq, then the suspend/resume framework will help
> > > to enable/disable wakeup irq.
> > >
> > > The runtime PM is default off since some platforms may not support it.
> > > users can enable it via power/control (set "auto") in sysfs.
> > >
> > > Signed-off-by: Chunfeng Yun
> > > ---
> > > drivers/usb/host/xhci-mtk.c | 140 +++-
> > > 1 file changed, 124 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > > index a74764ab914a..30927f4064d4 100644
> > > --- a/drivers/usb/host/xhci-mtk.c
> > > +++ b/drivers/usb/host/xhci-mtk.c
> > > @@ -16,6 +16,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -358,7 +359,6 @@ static int usb_wakeup_of_property_parse(struct
> > > xhci_hcd_mtk *mtk,
> > > mtk->uwk_reg_base, mtk->uwk_vers);
> > >
> > > return PTR_ERR_OR_ZERO(mtk->uwk);
> > > -
> > > }
> > >
> > > static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
> > > @@ -458,6 +458,7 @@ static int xhci_mtk_probe(struct platform_device
> > > *pdev)
> > > struct resource *res;
> > > struct usb_hcd *hcd;
> > > int ret = -ENODEV;
> > > + int wakeup_irq;
> > > int irq;
> > >
> > > if (usb_disabled())
> > > @@ -485,6 +486,21 @@ static int xhci_mtk_probe(struct platform_device
> > > *pdev)
> > > if (ret)
> > > return ret;
> > >
> > > + irq = platform_get_irq_byname_optional(pdev, "host");
> > > + if (irq < 0) {
> > > + if (irq == -EPROBE_DEFER)
> > > + return irq;
> > > +
> > > + /* for backward compatibility */
> > > + irq = platform_get_irq(pdev, 0);
> > > + if (irq < 0)
> > > + return irq;
> > > + }
> > > +
> > > + wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
> > > + if (wakeup_irq == -EPROBE_DEFER)
> > > + return wakeup_irq;
> > > +
> > > mtk->lpm_support = of_property_read_bool(node,
> > > "usb3-lpm-capable");
> > > /* optional property, ignore the error if it does not exist */
> > > of_property_read_u32(node, "mediatek,u3p-dis-msk",
> > > @@ -496,9 +512,11 @@ static int xhci_mtk_probe(struct platform_device
> > > *pdev)
> > > return ret;
> > > }
> > >
> > > + pm_runtime_set_active(dev);
> > > + pm_runtime_use_autosuspend(dev);
> > > + pm_runtime_set_autosuspend_delay(dev, 4000);
> > > pm_runtime_enable(dev);
> > > pm_runtime_get_sync(dev);
> > > - device_enable_async_suspend(dev);
> > >
> > > ret = xhci_mtk_ldos_enable(mtk);
> > > if (ret)
> > > @@ -508,12 +526,6 @@ static int xhci_mtk_probe(struct platform_device
> > > *pdev)
> > > if (ret)
> > > goto disable_ldos;
> > >
> > > - irq = platform_get_irq(pdev, 0);
> > > - if (irq < 0) {
> > > - ret = irq;
> > > - goto disable_clk;
> > > - }
> > > -
> > > hcd = usb_create_hcd(driver, dev, dev_name(dev));
> > > if (!hcd) {
> > > ret = -ENOMEM;
> > > @@ -579,8 +591,26 @@ static int xhci_mtk_probe(struct platform_device
> > > *pdev)
> > > if (ret)
> > > goto dealloc_usb2_hcd;
> > >
> > > + if (wakeup_irq > 0) {
> > > + ret = dev_pm_set_dedicated_wake_irq(dev, wakeup_irq);
> > > + if (ret) {
> > > + dev_err(dev, "set wakeup irq %d failed\n",
> > > wakeup_irq);
> > > + goto dealloc_usb3_hcd;
> > > + }
> > > + dev_info(dev, "wakeup irq %d\n", wakeup_irq);
> > > + }
> > > +
> > > + device_enable_async_suspend(dev);
> > > + pm_runtime_mark_last_busy(dev);
> > > + pm_runtime_put_autosuspend(dev);
> > > + pm_runtime_forbid(dev);
> > > +
> > > return 0;
> > >
> > > +dealloc_usb3_hcd:
> > > + usb_remove_hcd(xhci->shared_hcd);
> > > + xhci->shared_hcd = NULL;
> > > +
> > > dealloc_usb2_hcd:
> > > usb_remove_hcd(hcd);
> > >
> > > @@ -601,25 +631,26 @@ static int xhci_mtk_probe(struct platform_device
> > > *pdev)
> > > xhci_mtk_ldos_disable(mtk);
> > >
> > > disable_pm:
> > > - pm_runtime_put_sync(dev);
> > > + pm_runtime_put_sync_autosuspend(dev);
> > > pm_runtime_disable(dev);
> > > return ret;
> > > }
> > >
> > > -static int xhci_mtk_remove(struct platform_device
Re: [PATCH v7] RISC-V: enable XIP
Le 4/9/21 à 10:42 AM, Vitaly Wool a écrit : On Fri, Apr 9, 2021 at 3:59 PM Mike Rapoport wrote: On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote: Also, will that memory properly be exposed in the resource tree as System RAM (e.g., /proc/iomem) ? Otherwise some things (/proc/kcore) won't work as expected - the kernel won't be included in a dump. Do we really need a XIP kernel to included in kdump? And does not it sound weird to expose flash as System RAM in /proc/iomem? ;-) See my other mail, maybe we actually want something different. I have just checked and it does not appear in /proc/iomem. Ok your conclusion would be to have struct page, I'm going to implement this version then using memblock as you described. I'm not sure this is required. With XIP kernel text never gets into RAM, so it does not seem to require struct page. XIP by definition has some limitations relatively to "normal" operation, so lack of kdump could be one of them. I agree. I might be wrong, but IMHO, artificially creating a memory map for part of flash would cause more problems in the long run. Can you elaborate? Nothing particular, just a gut feeling. Usually, when you force something it comes out the wrong way later. It's possible still that MTD_XIP is implemented allowing to write to the flash used for XIP. While flash is being written, memory map doesn't make sense at all. I can't come up with a real life example when it can actually lead to problems but it is indeed weird when System RAM suddenly becomes unreadable. I really don't think exposing it in /proc/iomem is a good idea. BTW, how does XIP account the kernel text on other architectures that implement it? Interesting point, I thought XIP would be something new on RISC-V (well, at least to me :) ). If that concept exists already, we better mimic what existing implementations do. I had quick glance at ARM, it seems that kernel text does not have memory map and does not show up in System RAM. Exactly, and I believe ARM64 won't do that too when it gets its own XIP support (which is underway). memmap does not seem necessary and ARM/ARM64 do not use it. But if someone tries to get a struct page from a physical address that lies in flash, as mentioned by David, that could lead to silent corruptions if something exists at the address where the struct page should be. And it is hard to know which features in the kernel depends on that. Regarding SPARSEMEM, the vmemmap lies in its own region so that's unlikely to happen, so we will catch those invalid accesses (and that's what I observed on riscv). But for FLATMEM, memmap is in the linear mapping, then that could very likely happen silently. Could a simple solution be to force SPARSEMEM for those XIP kernels ? Then wrong things could happen, but we would see those and avoid spending hours to debug :) I will at least send a v8 to remove the pfn_valid modifications for FLATMEM that now returns true to pfn in flash. Thanks, Best regards, Vitaly ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v4 0/7] cpufreq-qcom-hw: Implement full OSM programming
On 19-01-21, 18:45, AngeloGioacchino Del Regno wrote:
> **
> ** NOTE: To "view the full picture", please look at the following
> ** patch series:
> ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355
> ** This is a subset of that series.
> **
>
> Changes in v4:
> - Huge patch series has been split for better reviewability,
> as suggested by Bjorn
> - Rebased code on top of 266991721c15 ("cpufreq: qcom-hw: enable boost
> support")
Bjorn, what am I supposed to do with patchset ? Is there anyone who can give
this some reviews from qcom team ?
--
viresh
Re: [PATCH -next] phy: ti: j721e-wiz: Add missing include linux/slab.h
On 08-04-21, 09:28, Shixin Liu wrote: > When compiling with CONFIG_PHY_J721E_WIZ, Hulk Robot reported: > > drivers/phy/ti/phy-j721e-wiz.c: In function ‘wiz_mux_clk_register’: > drivers/phy/ti/phy-j721e-wiz.c:659:17: error: implicit declaration of > function ‘kzalloc’; did you mean ‘vzalloc’? > [-Werror=implicit-function-declaration] > 659 | parent_names = kzalloc((sizeof(char *) * num_parents), GFP_KERNEL); > | ^~~ > | vzalloc > drivers/phy/ti/phy-j721e-wiz.c:659:15: warning: assignment to ‘const char **’ > from ‘int’ makes pointer from integer without a cast [-Wint-conversion] > 659 | parent_names = kzalloc((sizeof(char *) * num_parents), GFP_KERNEL); > | ^ > drivers/phy/ti/phy-j721e-wiz.c:697:2: error: implicit declaration of function > ‘kfree’; did you mean ‘vfree’? [-Werror=implicit-function-declaration] > 697 | kfree(parent_names); > | ^ > | vfre Applied, thanks -- ~Vinod
Re: [PATCH -next] phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove()
On 07-04-21, 17:27, Yang Yingliang wrote: > This driver's remove path calls cancel_delayed_work(). However, that > function does not wait until the work function finishes. This means > that the callback function may still be running after the driver's > remove function has finished, which would result in a use-after-free. > > Fix by calling cancel_delayed_work_sync(), which ensures that > the work is properly cancelled, no longer running, and unable > to re-schedule itself. Applied, thanks -- ~Vinod
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/asm-generic/bug.h:20,
from arch/x86/include/asm/bug.h:93,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/umh.h:4,
from include/linux/kmod.h:9,
from net/bridge/netfilter/ebtables.c:14:
net/bridge/netfilter/ebtables.c: In function '__ebt_find_table':
net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member
named 'tables'
1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) {
| ^
include/linux/kernel.h:708:26: note: in definition of macro 'container_of'
708 | void *__mptr = (void *)(ptr); \
| ^~~
include/linux/list.h:522:2: note: in expansion of macro 'list_entry'
522 | list_entry((ptr)->next, type, member)
| ^~
include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry'
628 | for (pos = list_first_entry(head, typeof(*pos), member); \
| ^~~~
net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro
'list_for_each_entry'
1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) {
| ^~~
In file included from :
net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member
named 'tables'
1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) {
| ^
include/linux/compiler_types.h:300:9: note: in definition of macro
'__compiletime_assert'
300 | if (!(condition)) \
| ^
include/linux/compiler_types.h:320:2: note: in expansion of macro
'_compiletime_assert'
320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/kernel.h:709:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
| ^~~~
include/linux/kernel.h:709:20: note: in expansion of macro '__same_type'
709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
|^~~
include/linux/list.h:511:2: note: in expansion of macro 'container_of'
511 | container_of(ptr, type, member)
| ^~~~
include/linux/list.h:522:2: note: in expansion of macro 'list_entry'
522 | list_entry((ptr)->next, type, member)
| ^~
include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry'
628 | for (pos = list_first_entry(head, typeof(*pos), member); \
| ^~~~
net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro
'list_for_each_entry'
1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) {
| ^~~
net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no member
named 'tables'
1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) {
| ^
include/linux/compiler_types.h:300:9: note: in definition of macro
'__compiletime_assert'
300 | if (!(condition)) \
| ^
include/linux/compiler_types.h:320:2: note: in expansion of macro
'_compiletime_assert'
320 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/kernel.h:709:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
709 | BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
| ^~~~
include/linux/kernel.h:710:6: note: in expansion of macro '__same_type'
710 | !__same_type(*(ptr), void), \
| ^~~
include/linux/list.h:511:2: note: in expansion of macro 'container_of'
511 | container_of(ptr, type, member)
| ^~~~
include/linux/list.h:522:2: note: in expansion of macro 'list_entry'
522 | list_entry((ptr)->next, type, member)
| ^~
include/linux/list.h:628:13: note: in expansion of macro 'list_first_entry'
628 | for (pos = list_first_entry(head, typeof(*pos), member); \
| ^~~~
net/bridge/netfilter/ebtables.c:1248:2: note: in expansion of macro
'list_for_each_entry'
1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) {
| ^~~
In file included from
Re: [PATCH v6 1/3] bio: limit bio max size
Hi Changheun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mkp-scsi/for-next]
[also build test ERROR on scsi/for-next linus/master v5.12-rc7]
[cannot apply to block/for-next next-20210409]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Changheun-Lee/bio-limit-bio-max-size/20210412-115922
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: nios2-defconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/5d00aa42f58575968c4a7a4b374addaf4f9a5624
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Changheun-Lee/bio-limit-bio-max-size/20210412-115922
git checkout 5d00aa42f58575968c4a7a4b374addaf4f9a5624
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=nios2
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
In file included from include/linux/blkdev.h:19,
from include/linux/blk-cgroup.h:23,
from include/linux/writeback.h:14,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:9,
from block/bio.c:6:
include/linux/bio.h: In function 'bio_full':
include/linux/bio.h:122:29: error: implicit declaration of function
'bio_max_size'; did you mean 'bio_max_segs'?
[-Werror=implicit-function-declaration]
122 | if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
| ^~~~
| bio_max_segs
block/bio.c: At top level:
>> block/bio.c:258:14: warning: no previous prototype for 'bio_max_size'
>> [-Wmissing-prototypes]
258 | unsigned int bio_max_size(struct bio *bio)
| ^~~~
>> block/bio.c:258:14: error: conflicting types for 'bio_max_size'
In file included from include/linux/blkdev.h:19,
from include/linux/blk-cgroup.h:23,
from include/linux/writeback.h:14,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:9,
from block/bio.c:6:
include/linux/bio.h:122:29: note: previous implicit declaration of
'bio_max_size' was here
122 | if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
| ^~~~
block/bio.c: In function 'bio_max_size':
>> block/bio.c:260:31: error: 'struct bio' has no member named 'bi_disk'
260 | struct request_queue *q = bio->bi_disk->queue;
| ^~
cc1: some warnings being treated as errors
vim +/bio_max_size +258 block/bio.c
257
> 258 unsigned int bio_max_size(struct bio *bio)
259 {
> 260 struct request_queue *q = bio->bi_disk->queue;
261
262 if (blk_queue_limit_bio_size(q))
263 return blk_queue_get_max_sectors(q, bio_op(bio))
264 << SECTOR_SHIFT;
265
266 return UINT_MAX;
267 }
268
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v6 1/3] bio: limit bio max size
Hi Changheun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mkp-scsi/for-next]
[also build test ERROR on scsi/for-next linus/master v5.12-rc7]
[cannot apply to block/for-next next-20210409]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Changheun-Lee/bio-limit-bio-max-size/20210412-115922
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: i386-tinyconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/5d00aa42f58575968c4a7a4b374addaf4f9a5624
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Changheun-Lee/bio-limit-bio-max-size/20210412-115922
git checkout 5d00aa42f58575968c4a7a4b374addaf4f9a5624
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/blkdev.h:19,
from include/linux/blk-cgroup.h:23,
from include/linux/writeback.h:14,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:13:
include/linux/bio.h: In function 'bio_full':
>> include/linux/bio.h:122:29: error: implicit declaration of function
>> 'bio_max_size'; did you mean 'bio_max_segs'?
>> [-Werror=implicit-function-declaration]
122 | if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
| ^~~~
| bio_max_segs
cc1: some warnings being treated as errors
--
In file included from include/linux/blkdev.h:19,
from include/linux/blk-cgroup.h:23,
from include/linux/writeback.h:14,
from include/linux/memcontrol.h:22,
from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:13:
include/linux/bio.h: In function 'bio_full':
>> include/linux/bio.h:122:29: error: implicit declaration of function
>> 'bio_max_size'; did you mean 'bio_max_segs'?
>> [-Werror=implicit-function-declaration]
122 | if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
| ^~~~
| bio_max_segs
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:116: arch/x86/kernel/asm-offsets.s]
Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1233: prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:215: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +122 include/linux/bio.h
108
109 /**
110 * bio_full - check if the bio is full
111 * @bio:bio to check
112 * @len:length of one segment to be added
113 *
114 * Return true if @bio is full and one segment with @len bytes can't be
115 * added to the bio, otherwise return false
116 */
117 static inline bool bio_full(struct bio *bio, unsigned len)
118 {
119 if (bio->bi_vcnt >= bio->bi_max_vecs)
120 return true;
121
> 122 if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
123 return true;
124
125 return false;
126 }
127
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v5,4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
[PATCH v5,2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification
This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.
Signed-off-by: "Lee, Chun-Yi"
---
certs/system_keyring.c | 2 +-
crypto/asymmetric_keys/Kconfig | 9 +
crypto/asymmetric_keys/pkcs7_trust.c | 37 +---
include/crypto/pkcs7.h | 3 ++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 4b693da488f1..c9f8bca0b0d3 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -243,7 +243,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
goto error;
}
}
- ret = pkcs7_validate_trust(pkcs7, trusted_keys);
+ ret = pkcs7_validate_trust(pkcs7, trusted_keys, usage);
if (ret < 0) {
if (ret == -ENOKEY)
pr_devel("PKCS#7 signature not signed with a trusted
key\n");
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 1f1f004dc757..1754812df989 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -96,4 +96,13 @@ config SIGNED_PE_FILE_VERIFICATION
This option provides support for verifying the signature(s) on a
signed PE binary.
+config CHECK_CODESIGN_EKU
+ bool "Check codeSigning extended key usage"
+ depends on PKCS7_MESSAGE_PARSER=y
+ depends on SYSTEM_DATA_VERIFICATION
+ help
+ This option provides support for checking the codeSigning extended
+ key usage when verifying the signature in PKCS#7. It affects kernel
+ module verification and kexec PE binary verification.
+
endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index b531df2013c4..077bfef928b6 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -16,12 +16,36 @@
#include
#include "pkcs7_parser.h"
+#ifdef CONFIG_CHECK_CODESIGN_EKU
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ struct public_key *public_key = key->payload.data[asym_crypto];
+
+ switch (usage) {
+ case VERIFYING_MODULE_SIGNATURE:
+ case VERIFYING_KEXEC_PE_SIGNATURE:
+ return !!(public_key->eku & EKU_codeSigning);
+ default:
+ break;
+ }
+ return true;
+}
+#else
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ return true;
+}
+#endif
+
/*
* Check the trust on one PKCS#7 SignedInfo block.
*/
static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
struct pkcs7_signed_info *sinfo,
- struct key *trust_keyring)
+ struct key *trust_keyring,
+ enum key_being_used_for usage)
{
struct public_key_signature *sig = sinfo->sig;
struct x509_certificate *x509, *last = NULL, *p;
@@ -112,6 +136,12 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
return -ENOKEY;
matched:
+ if (!check_codesign_eku(key, usage)) {
+ pr_warn("sinfo %u: The signer %x key is not CodeSigning\n",
+ sinfo->index, key_serial(key));
+ key_put(key);
+ return -ENOKEY;
+ }
ret = verify_signature(key, sig);
key_put(key);
if (ret < 0) {
@@ -156,7 +186,8 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
* May also return -ENOMEM.
*/
int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
-struct key *trust_keyring)
+struct key *trust_keyring,
+enum key_being_used_for usage)
{
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
@@ -167,7 +198,7 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
p->seen = false;
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
- ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring);
+ ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring,
usage);
switch (ret) {
case -ENOKEY:
continue;
diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
index 38ec7f5f9041..b3b48240ba73 100644
--- a/include/crypto/pkcs7.h
+++ b/include/crypto/pkcs7.h
@@ -30,7 +30,8 @@ extern int pkcs7_get_content_data(const struct pkcs7_message
*pkcs7,
* pkcs7_trust.c
*/
extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
- struct key *trust_keyring);
+ struct key *trust_keyring,
+
[PATCH v5,3/4] modsign: Add codeSigning EKU when generating X.509 key generation config
Add codeSigning EKU to the X.509 key generation config for the build time autogenerated kernel key. Signed-off-by: "Lee, Chun-Yi" --- certs/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/certs/Makefile b/certs/Makefile index f4c25b67aad9..1ef4d6ca43b7 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -88,6 +88,7 @@ $(obj)/x509.genkey: @echo >>$@ "keyUsage=digitalSignature" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" + @echo >>$@ "extendedKeyUsage=codeSigning" endif # CONFIG_MODULE_SIG_KEY $(eval $(call config_filename,MODULE_SIG_KEY)) -- 2.16.4
[PATCH v5,1/4] X.509: Add CodeSigning extended key usage parsing
This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.
Signed-off-by: "Lee, Chun-Yi"
---
crypto/asymmetric_keys/x509_cert_parser.c | 24
include/crypto/public_key.h | 1 +
include/linux/oid_registry.h | 5 +
3 files changed, 30 insertions(+)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..65721313b265 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
struct x509_parse_context *ctx = context;
struct asymmetric_key_id *kid;
const unsigned char *v = value;
+ int i = 0;
+ enum OID oid;
pr_debug("Extension: %u\n", ctx->last_oid);
@@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t hdrlen,
return 0;
}
+ if (ctx->last_oid == OID_extKeyUsage) {
+ if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
+ v[1] != vlen - 2)
+ return -EBADMSG;
+ i += 2;
+
+ while (i < vlen) {
+ /* A 10 bytes EKU OID Octet blob =
+* ASN1_OID + size byte + 8 bytes OID */
+ if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) >
vlen)
+ return -EBADMSG;
+
+ oid = look_up_OID(v + i + 2, v[i + 1]);
+ if (oid == OID_codeSigning) {
+ ctx->cert->pub->eku |= EKU_codeSigning;
+ }
+ i += 10;
+ }
+ pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
+ return 0;
+ }
+
return 0;
}
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 47accec68cb0..1ccaebe2a28b 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -28,6 +28,7 @@ struct public_key {
bool key_is_private;
const char *id_type;
const char *pkey_algo;
+ unsigned int eku : 9; /* Extended Key Usage (9-bit) */
};
extern void public_key_free(struct public_key *key);
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 4462ed2c18cd..e20e8eb53b21 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -113,9 +113,14 @@ enum OID {
OID_SM2_with_SM3, /* 1.2.156.10197.1.501 */
OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
+ /* Extended key purpose OIDs [RFC 5280] */
+ OID_codeSigning,/* 1.3.6.1.5.5.7.3.3 */
+
OID__NR
};
+#define EKU_codeSigning(1 << 2)
+
extern enum OID look_up_OID(const void *data, size_t datasize);
extern int sprint_oid(const void *, size_t, char *, size_t);
extern int sprint_OID(enum OID, char *, size_t);
--
2.16.4
[PATCH v5 0/4] Check codeSigning extended key usage extension
NIAP PP_OS certification requests that the OS shall validate the CodeSigning extended key usage extension field for integrity verifiction of exectable code: https://www.niap-ccevs.org/MMO/PP/-442-/ FIA_X509_EXT.1.1 This patchset adds the logic for parsing the codeSigning EKU extension field in X.509. And checking the CodeSigning EKU when verifying signature of kernel module or kexec PE binary in PKCS#7. v5: Fixed the wording in module-signing.rst. v4: Fixed the wording in patch description. v3: - Add codeSigning EKU to x509.genkey key generation config. - Add openssl command option example for generating CodeSign EKU to module-signing.rst document. v2: Changed the help wording in the Kconfig. Lee, Chun-Yi (4): X.509: Add CodeSigning extended key usage parsing PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification modsign: Add codeSigning EKU when generating X.509 key generation config Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU Documentation/admin-guide/module-signing.rst | 6 + certs/Makefile | 1 + certs/system_keyring.c | 2 +- crypto/asymmetric_keys/Kconfig | 9 +++ crypto/asymmetric_keys/pkcs7_trust.c | 37 +--- crypto/asymmetric_keys/x509_cert_parser.c| 24 ++ include/crypto/pkcs7.h | 3 ++- include/crypto/public_key.h | 1 + include/linux/oid_registry.h | 5 9 files changed, 83 insertions(+), 5 deletions(-) -- 2.16.4
[PATCH] serial: stm32: optimize spin lock usage
From: dillon min
To avoid potential deadlock in spin_lock usage, change to use
spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
spin_lock(), spin_unlock() under handler context.
remove unused local_irq_save/restore call.
Signed-off-by: dillon min
---
Was verified on stm32f469-disco board. need more test on stm32mp platform.
drivers/tty/serial/stm32-usart.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index b3675cf25a69..c4c859b34367 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port
*port, bool threaded)
struct tty_port *tport = >state->port;
struct stm32_port *stm32_port = to_stm32_port(port);
const struct stm32_usart_offsets *ofs = _port->info->ofs;
- unsigned long c;
+ unsigned long c, flags;
u32 sr;
char flag;
@@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port
*port, bool threaded)
uart_insert_char(port, sr, USART_SR_ORE, c, flag);
}
- spin_unlock(>lock);
+ if (threaded)
+ spin_unlock_irqrestore(>lock, flags);
+ else
+ spin_unlock(>lock);
+
tty_flip_buffer_push(tport);
- spin_lock(>lock);
+
+ if (threaded)
+ spin_lock_irqsave(>lock, flags);
+ else
+ spin_lock(>lock);
}
static void stm32_usart_tx_dma_complete(void *arg)
@@ -489,13 +497,14 @@ static irqreturn_t stm32_usart_threaded_interrupt(int
irq, void *ptr)
{
struct uart_port *port = ptr;
struct stm32_port *stm32_port = to_stm32_port(port);
+ unsigned long flags;
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
if (stm32_port->rx_ch)
stm32_usart_receive_chars(port, true);
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
return IRQ_HANDLED;
}
@@ -1354,13 +1363,12 @@ static void stm32_usart_console_write(struct console
*co, const char *s,
u32 old_cr1, new_cr1;
int locked = 1;
- local_irq_save(flags);
if (port->sysrq)
locked = 0;
else if (oops_in_progress)
- locked = spin_trylock(>lock);
+ locked = spin_trylock_irqsave(>lock, flags);
else
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
/* Save and disable interrupts, enable the transmitter */
old_cr1 = readl_relaxed(port->membase + ofs->cr1);
@@ -1374,8 +1382,7 @@ static void stm32_usart_console_write(struct console *co,
const char *s,
writel_relaxed(old_cr1, port->membase + ofs->cr1);
if (locked)
- spin_unlock(>lock);
- local_irq_restore(flags);
+ spin_unlock_irqrestore(>lock, flags);
}
static int stm32_usart_console_setup(struct console *co, char *options)
--
2.7.4
Re: [PATCH v7 clocksource 3/5] clocksource: Check per-CPU clock synchronization when marked unstable
On Sun, Apr 11, 2021 at 09:46:12AM -0700, Paul E. McKenney wrote:
> On Sun, Apr 11, 2021 at 12:33:44PM +0200, Thomas Gleixner wrote:
> > On Sat, Apr 10 2021 at 17:20, Paul E. McKenney wrote:
> > > On Sat, Apr 10, 2021 at 11:00:25AM +0200, Thomas Gleixner wrote:
> > >> > + if (WARN_ON_ONCE(!cs))
> > >> > + return;
> > >> > + pr_warn("Checking clocksource %s synchronization from CPU
> > >> > %d.\n",
> > >> > + cs->name, smp_processor_id());
> > >> > + cpumask_clear(_ahead);
> > >> > + cpumask_clear(_behind);
> > >> > + csnow_begin = cs->read(cs);
> > >>
> > >> So this is invoked via work and the actual clocksource change is done
> > >> via work too. Once the clocksource is not longer actively used for
> > >> timekeeping it can go away. What's guaranteeing that this runs prior to
> > >> the clocksource change and 'cs' is valid throughout this function?
> > >
> > > From what I can see, cs->read() doesn't care whether or not the
> > > clocksource has been marked unstable. So it should be OK to call
> > > cs->read() before, during, or after the call to __clocksource_unstable().
> > >
> > > Also, this is only done on clocksources marked CLOCK_SOURCE_VERIFY_PERCPU,
> > > so any clocksource that did not like cs->read() being invoked during
> > > or after the call to __clocksource_unstable() should leave off the
> > > CLOCK_SOURCE_VERIFY_PERCPU bit.
> > >
> > > Or did I take a wrong turn somewhere in the pointers to functions?
> >
> > Right. cs->read() does not care, but what guarantees that cs is valid
> > and not freed yet? It's not an issue with TSC and KVMCLOCK, but
> > conceptually the following is possible:
> >
> > watchdog()
> > queue_work(synccheck);
> > queue_work(clocksource_change);
> >
> > work:
> > synccheck() clocksource_change()
> > preemption...
> > ...
> > some_other_code():
> > unregister_clocksource(cs)
> > free(cs)
> > cs->read() <- UAF
>
> Got it, with the ingenic_tcu_init() function being case in point.
> It invokes clcoksource_unregister() shortly followed by clk_put(), which,
> if I found the correct clk_put(), can kfree() it.
>
> Thank you!
>
> > >> > + queue_work(system_highpri_wq, _verify_work);
> > >>
> > >> This does not guarantee anything. So why does this need an extra work
> > >> function which is scheduled seperately?
> > >
> > > Because I was concerned about doing smp_call_function() while holding
> > > watchdog_lock, which is also acquired elsewhere using spin_lock_irqsave().
> > > And it still looks like on x86 that spin_lock_irqsave() spins with irqs
> > > disabled, which could result in deadlock. The smp_call_function_single()
> > > would wait for the target CPU to enable interrupts, which would not
> > > happen until after the smp_call_function_single() returned due to its
> > > caller holding watchdog_lock.
> > >
> > > Or is there something that I am missing that prevents this deadlock
> > > from occurring?
> >
> > The unstable mechanism is:
> >
> > watchdog()
> > __clocksource_unstable()
> > schedule_work(_work);
> >
> > watchdog_work()
> > kthread_run(clocksource_watchdog_thread);
> >
> > cs_watchdog_thread()
> > mutex_lock(_mutex);
> > if (__clocksource_watchdog_kthread())
> > clocksource_select();
> > mutex_unlock(_mutex);
> >
> > So what prevents you from doing that right in watchdog_work() or even in
> > cs_watchdog_thread() properly ordered against the actual clocksource
> > switch?
> >
> > Hmm?
>
> My own confusion, apparently. :-/
>
> So I need to is inline clocksource_verify_percpu_wq()
> into clocksource_verify_percpu() and then move the call to
> clocksource_verify_percpu() to __clocksource_watchdog_kthread(), right
> before the existing call to list_del_init(). Will do!
Except that this triggers the WARN_ON_ONCE() in smp_call_function_single()
due to interrupts being disabled across that list_del_init().
Possibilities include:
1. Figure out why interrupts must be disabled only sometimes while
holding watchdog_lock, in the hope that they need not be across
the entire critical section for __clocksource_watchdog_kthread().
As in:
local_irq_restore(flags);
clocksource_verify_percpu(cs);
local_irq_save(flags);
Trying this first with lockdep enabled. Might be spectacular.
2. Invoke clocksource_verify_percpu() from its original
location in clocksource_watchdog(), just before the call to
__clocksource_unstable(). This relies on the fact that
clocksource_watchdog() acquires watchdog_lock without
disabling interrupts.
3. Restrict CLOCK_SOURCE_VERIFY_PERCPU to
RE: [PATCH v6 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy
Hi Hans, Barnabás. Thanks for your review very much! I have no concern to change the most of the comments. Just one sysfs_emit replacement will cause problem , adding comments at below. > -Original Message- > From: Hans de Goede > Sent: Wednesday, April 7, 2021 11:16 PM > To: Barnabás Pőcze; Yuan, Perry > Cc: pierre-louis.boss...@linux.intel.com; oder_ch...@realtek.com; > pe...@perex.cz; ti...@suse.com; mgr...@linux.intel.com; Limonciello, > Mario; lgirdw...@gmail.com; broo...@kernel.org; alsa-devel@alsa- > project.org; linux-kernel@vger.kernel.org; platform-driver- > x...@vger.kernel.org; mario.limoncie...@outlook.com; Dell Client Kernel > Subject: Re: [PATCH v6 1/2] platform/x86: dell-privacy: Add support for Dell > hardware privacy > > > [EXTERNAL EMAIL] > > Hi Perry, Barnabás, > > Barnabás thank you for your review. I agree with all your remarks. > > Perry, Thank you for the new version, this version is looking good. > This is almost ready for merging. > > Please fix the review remarks from Barnabás. I also have a couple of small > review remarks myself below. > > On 4/4/21 6:53 PM, Barnabás Pőcze wrote: > > Hi > > > > > > 2021. április 4., vasárnap 10:31 keltezéssel, Perry Yuan írta: > > > >> From: Perry Yuan > >> > >> add support for Dell privacy driver for the Dell units equipped > >> hardware privacy design, which protect users privacy of audio and > >> camera from hardware level. Once the audio or camera privacy mode > >> activated, any applications will not get any audio or video stream > >> when user pressed ctrl+F4 hotkey, audio privacy mode will be enabled, > >> micmute led will be also changed accordingly The micmute led is fully > >> controlled by hardware & EC(embedded controller) and camera mute > >> hotkey is Ctrl+F9. Currently design only emits SW_CAMERA_LENS_COVER > >> event while the camera lens shutter will be changed by EC & > >> HW(hardware) control > >> > >> *The flow is like this: > >> 1) User presses key. HW does stuff with this key (timeout timer is > >> started) > >> 2) WMI event is emitted from BIOS to kernel > >> 3) WMI event is received by dell-privacy > >> 4) KEY_MICMUTE emitted from dell-privacy > >> 5) Userland picks up key and modifies kcontrol for SW mute > >> 6) Codec kernel driver catches and calls ledtrig_audio_set, like this: > >>ledtrig_audio_set(LED_AUDIO_MICMUTE, rt715->micmute_led ? > LED_ON > >> :LED_OFF); > >> 7) If "LED" is set to on dell-privacy notifies EC, and timeout is > >> cancelled, > >>HW mic mute activated. If EC not notified, HW mic mute will also be > >>activated when timeout used up, it is just later than active ack > >> > >> Signed-off-by: Perry Yuan > >> --- > >> v5 -> v6: > >> * addressed feedback from Hans > >> * addressed feedback from Pierre > >> * optimize some debug format with dev_dbg() > >> * remove platform driver,combined privacy acpi driver into single wmi > >> driver file > >> * optimize sysfs interface with string added to be more clearly > >> reading > >> v4 -> v5: > >> * addressed feedback from Randy Dunlap > >> * addressed feedback from Pierre-Louis Bossart > >> * rebase to latest 5.12 rc4 upstream kernel > >> * fix some space alignment problem > >> v3 -> v4: > >> * fix format for Kconfig > >> * add sysfs document > >> * add flow comments to the privacy wmi/acpi driver > >> * addressed feedback from Barnabás Pőcze[Thanks very much] > >> * export privacy_valid to make the global state simpler to query > >> * fix one issue which will block the dell-laptop driver to load when > >> privacy driver invalid > >> * addressed feedback from Pierre-Louis Bossart,remove the EC ID match > >> v2 -> v3: > >> * add sysfs attributes doc > >> v1 -> v2: > >> * query EC handle from EC driver directly. > >> * fix some code style. > >> * add KEY_END to keymap array. > >> * clean platform device when cleanup called > >> * use hexadecimal format for log print in dev_dbg > >> * remove __set_bit for the report keys from probe. > >> * fix keymap leak > >> * add err_free_keymap in dell_privacy_wmi_probe > >> * wmi driver will be unregistered if privacy_acpi_init() fails > >> * add sysfs attribute files for user space query. > >> * add leds micmute driver to privacy acpi > >> * add more design info the commit info > >> --- > >> --- > >> .../testing/sysfs-platform-dell-privacy-wmi | 55 +++ > >> drivers/platform/x86/dell/Kconfig | 14 + > >> drivers/platform/x86/dell/Makefile| 1 + > >> drivers/platform/x86/dell/dell-laptop.c | 23 +- > >> drivers/platform/x86/dell/dell-privacy-wmi.c | 441 > >> ++ drivers/platform/x86/dell/dell-privacy-wmi.h | 32 > ++ > >> drivers/platform/x86/dell/dell-wmi.c | 13 +- > >> 7 files changed, 572 insertions(+), 7 deletions(-) create mode > >> 100644 Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi > >> create mode 100644 drivers/platform/x86/dell/dell-privacy-wmi.c > >> create mode 100644
答复: [PATCH v1 01/14] vfio: Create vfio_fs_type with inode per device
> -邮件原件- > 发件人: Alex Williamson [mailto:alex.william...@redhat.com] > 发送时间: 2021年4月9日 22:24 > 收件人: Zengtao (B) > 抄送: coh...@redhat.com; k...@vger.kernel.org; > linux-kernel@vger.kernel.org; j...@nvidia.com; pet...@redhat.com > 主题: Re: [PATCH v1 01/14] vfio: Create vfio_fs_type with inode per device > > On Fri, 9 Apr 2021 04:54:23 + > "Zengtao (B)" wrote: > > > > -邮件原件- > > > 发件人: Alex Williamson [mailto:alex.william...@redhat.com] > > > 发送时间: 2021年3月9日 5:47 > > > 收件人: alex.william...@redhat.com > > > 抄送: coh...@redhat.com; k...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; j...@nvidia.com; pet...@redhat.com > > > 主题: [PATCH v1 01/14] vfio: Create vfio_fs_type with inode per device > > > > > > By linking all the device fds we provide to userspace to an address > > > space through a new pseudo fs, we can use tools like > > > unmap_mapping_range() to zap all vmas associated with a device. > > > > > > Suggested-by: Jason Gunthorpe > > > Signed-off-by: Alex Williamson > > > --- > > > drivers/vfio/vfio.c | 54 > > > +++ > > > 1 file changed, 54 insertions(+) > > > > > > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c index > > > 38779e6fd80c..abdf8d52a911 100644 > > > --- a/drivers/vfio/vfio.c > > > +++ b/drivers/vfio/vfio.c > > > @@ -32,11 +32,18 @@ > > > #include > > > #include > > > #include > > > +#include > > > +#include > > Minor: keep the headers in alphabetical order. > > They started out that way, but various tree-wide changes ignoring that, and > likely oversights on my part as well, has left us with numerous breaks in that > rule already. > > > > > > > #define DRIVER_VERSION "0.3" > > > #define DRIVER_AUTHOR"Alex Williamson > " > > > #define DRIVER_DESC "VFIO - User Level meta-driver" > > > > > > +#define VFIO_MAGIC 0x5646494f /* "VFIO" */ > > Move to include/uapi/linux/magic.h ? > > Hmm, yeah, I suppose it probably should go there. Thanks. > > FWIW, I'm still working on a next version of this series, currently struggling > how to handle an arbitrary number of vmas per user DMA mapping. Thanks, > Will do some testing on our platform, and want to make sure the issue I reported is included : https://patchwork.kernel.org/project/kvm/patch/1615201890-887-1-git-send-email-prime.z...@hisilicon.com/ Thanks zengtao > Alex
答复: [PATCH v1 01/14] vfio: Create vfio_fs_type with inode per device
> -邮件原件- > 发件人: Jason Gunthorpe [mailto:j...@nvidia.com] > 发送时间: 2021年4月10日 1:32 > 收件人: Alex Williamson > 抄送: Zengtao (B) ; coh...@redhat.com; > k...@vger.kernel.org; linux-kernel@vger.kernel.org; pet...@redhat.com > 主题: Re: [PATCH v1 01/14] vfio: Create vfio_fs_type with inode per device > > On Fri, Apr 09, 2021 at 08:24:00AM -0600, Alex Williamson wrote: > > > > > #define DRIVER_VERSION "0.3" > > > > #define DRIVER_AUTHOR "Alex Williamson > " > > > > #define DRIVER_DESC"VFIO - User Level meta-driver" > > > > > > > > +#define VFIO_MAGIC 0x5646494f /* "VFIO" */ > > > Move to include/uapi/linux/magic.h ? > > > > Hmm, yeah, I suppose it probably should go there. Thanks. > > From my review we haven't been doing that unless it is actually uapi relavent > for some reason (this is not) > Yes, it's not uapi relavent, and I still think it's better to put magic in a single header, and currently not all micros in magic.h are for uapi, some work should be done for that, but no ideas now, :) > In particular with CH having a patch series to eliminate all of these cases > and > drop the constants.. > Interested, could you share the links for that? Thanks Zengtao > Jason
[PATCH] ide-cd: remove useless variable
Fix the following gcc warning:
drivers/ide/ide-cd_ioctl.c:212:6: warning: variable ‘stat’ set but not
used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/ide/ide-cd_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ide/ide-cd_ioctl.c b/drivers/ide/ide-cd_ioctl.c
index 011eab9..22ec8b7 100644
--- a/drivers/ide/ide-cd_ioctl.c
+++ b/drivers/ide/ide-cd_ioctl.c
@@ -209,7 +209,6 @@ int ide_cdrom_select_speed(struct cdrom_device_info *cdi,
int speed)
ide_drive_t *drive = cdi->handle;
struct cdrom_info *cd = drive->driver_data;
u8 buf[ATAPI_CAPABILITIES_PAGE_SIZE];
- int stat;
unsigned char cmd[BLK_MAX_CDB];
if (speed == 0)
@@ -230,7 +229,7 @@ int ide_cdrom_select_speed(struct cdrom_device_info *cdi,
int speed)
cmd[5] = speed & 0xff;
}
- stat = ide_cd_queue_pc(drive, cmd, 0, NULL, NULL, NULL, 0, 0);
+ ide_cd_queue_pc(drive, cmd, 0, NULL, NULL, NULL, 0, 0);
if (!ide_cdrom_get_capabilities(drive, buf)) {
ide_cdrom_update_speed(drive, buf);
--
1.8.3.1
mmotm 2021-04-11-20-47 uploaded
The mm-of-the-moment snapshot 2021-04-11-20-47 has been uploaded to https://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: https://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in https://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory https://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.12-rc7: (patches marked "*" will be included in linux-next) * mm-eliminate-expecting-prototype-kernel-doc-warnings.patch * kasan-fix-hwasan-build-for-gcc.patch * kasan-remove-redundant-config-option.patch * csky-change-a-kconfig-symbol-name-to-fix-e1000-build-error.patch * ia64-remove-duplicate-entries-in-generic_defconfig.patch * ia64-fix-discontigc-section-mismatches.patch * ia64-tools-remove-inclusion-of-ia64-specific-version-of-errnoh-header.patch * ia64-tools-remove-duplicate-definition-of-ia64_mf-on-ia64.patch * mm-mapping_dirty_helpers-guard-hugepage-puds-usage.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * module-remove-duplicate-include-in-arch-ia64-kernel-heads.patch * ia64-kernel-few-typos-fixed-in-the-file-fsyss.patch * ia64-include-asm-minor-typo-fixes-in-the-file-pgtableh.patch * ia64-ensure-proper-numa-distance-and-possible-map-initialization.patch * ia64-drop-unused-ia64_fw_emu-ifdef.patch * ia64-simplify-code-flow-around-swiotlb-init.patch * ia64-trivial-spelling-fixes.patch * ia64-fix-efi_debug-build.patch * ia64-mca-always-make-ia64_mca_debug-an-expression.patch * ia64-drop-marked-broken-discontigmem-and-virtual_mem_map.patch * ia64-module-fix-symbolizer-crash-on-fdescr.patch * sparse-can-do-constant-folding-of-__builtin_bswap.patch * scripts-spellingtxt-add-entries-for-recent-discoveries.patch * scripts-a-new-script-for-checking-duplicate-struct-declaration.patch * scripts-a-new-script-for-checking-duplicate-struct-declaration-fix.patch * sh-remove-duplicate-include-in-tlbh.patch * ocfs2-replace-define_simple_attribute-with-define_debugfs_attribute.patch * ocfs2-map-flags-directly-in-flags_to_o2dlm.patch * ocfs2-fix-a-typo.patch * ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch * ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch * vfs-fs_parser-clean-up-kernel-doc-warnings.patch * watchdog-rename-__touch_watchdog-to-a-better-descriptive-name.patch * watchdog-explicitly-update-timestamp-when-reporting-softlockup.patch * watchdog-softlockup-report-the-overall-time-of-softlockups.patch * watchdog-softlockup-remove-logic-that-tried-to-prevent-repeated-reports.patch * watchdog-fix-barriers-when-printing-backtraces-from-all-cpus.patch * watchdog-fix-barriers-when-printing-backtraces-from-all-cpus-fix.patch * watchdog-cleanup-handling-of-false-positives.patch mm.patch * mm-slab_common-provide-slab_merge-option-for-is_enabledconfig_slab_merge_default-builds.patch * mm-slub-enable-slub_debug-static-key-when-creating-cache-with-explicit-debug-flags.patch * kunit-add-a-kunit-test-for-slub-debugging-functionality.patch * slub-remove-resiliency_test-function.patch * mm-slubc-trivial-typo-fixes.patch * mm-kmemleak-fix-a-typo.patch * mm-page_owner-record-the-timestamp-of-all-pages-during-free.patch * mm-page_owner-remove-unused-parameter-in-__set_page_owner_handle.patch * mm-page_owner-fetch-backtrace-only-for-tracked-pages.patch * mm-page_owner-use-kstrtobool-to-parse-bool-option.patch * mm-page_owner-detect-page_owner-recursion-via-task_struct.patch * mm-page_poison-print-page-owner-info-when-corruption-is-caught.patch * mm-page_poison-print-page-info-when-corruption-is-caught-v2.patch * mm-memtest-add-arch_use_memtest.patch * mm-provide-filemap_range_needs_writeback-helper.patch *
[PATCH V2] mm/page_alloc: Ensure that HUGETLB_PAGE_ORDER is less than MAX_ORDER
pageblock_order must always be less than MAX_ORDER, otherwise it might lead
to an warning during boot. A similar problem got fixed on arm64 platform
with the commit 79cc2ed5a716 ("arm64/mm: Drop THP conditionality from
FORCE_MAX_ZONEORDER"). Assert the above condition before HUGETLB_PAGE_ORDER
gets assigned as pageblock_order. This will help detect the problem earlier
on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
Cc: David Hildenbrand
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
Changes in V2:
- Changed WARN_ON() to BUILD_BUG_ON() per David
Changes in V1:
https://patchwork.kernel.org/project/linux-mm/patch/1617947717-2424-1-git-send-email-anshuman.khand...@arm.com/
mm/page_alloc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cfc72873961d..19283bff4bec 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6875,10 +6875,17 @@ void __init set_pageblock_order(void)
if (pageblock_order)
return;
- if (HPAGE_SHIFT > PAGE_SHIFT)
+ if (HPAGE_SHIFT > PAGE_SHIFT) {
+ /*
+* pageblock_order must always be less than
+* MAX_ORDER. So does HUGETLB_PAGE_ORDER if
+* that is being assigned here.
+*/
+ BUILD_BUG_ON(HUGETLB_PAGE_ORDER >= MAX_ORDER);
order = HUGETLB_PAGE_ORDER;
- else
+ } else {
order = MAX_ORDER - 1;
+ }
/*
* Assume the largest contiguous order of interest is a huge page.
--
2.20.1
[PATCH v6 4/4] dt-bindings: serial: 8250: add aspeed,lpc-io-reg and aspeed,lpc-interrupts
These correspond to the existing lpc_address, sirq, and sirq_polarity
sysfs attributes; the second element of aspeed,lpc-interrupts provides
a replacement for the deprecated aspeed,sirq-polarity-sense property.
Signed-off-by: Zev Weiss
Reviewed-by: Rob Herring
---
.../devicetree/bindings/serial/8250.yaml | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml
b/Documentation/devicetree/bindings/serial/8250.yaml
index 491b9297432d..0e82b076e199 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -12,8 +12,13 @@ maintainers:
allOf:
- $ref: /schemas/serial.yaml#
- if:
- required:
-- aspeed,sirq-polarity-sense
+ anyOf:
+- required:
+- aspeed,lpc-io-reg
+- required:
+- aspeed,lpc-interrupts
+- required:
+- aspeed,sirq-polarity-sense
then:
properties:
compatible:
@@ -190,6 +195,20 @@ properties:
applicable to aspeed,ast2500-vuart.
deprecated: true
+ aspeed,lpc-io-reg:
+$ref: '/schemas/types.yaml#/definitions/uint32'
+description: |
+ The VUART LPC address. Only applicable to aspeed,ast2500-vuart.
+
+ aspeed,lpc-interrupts:
+$ref: "/schemas/types.yaml#/definitions/uint32-array"
+minItems: 2
+maxItems: 2
+description: |
+ A 2-cell property describing the VUART SIRQ number and SIRQ
+ polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
+ applicable to aspeed,ast2500-vuart.
+
required:
- reg
- interrupts
@@ -221,6 +240,7 @@ examples:
};
- |
#include
+#include
serial@1e787000 {
compatible = "aspeed,ast2500-vuart";
reg = <0x1e787000 0x40>;
@@ -228,7 +248,8 @@ examples:
interrupts = <8>;
clocks = < ASPEED_CLK_APB>;
no-loopback-test;
-aspeed,sirq-polarity-sense = < 0x70 25>;
+aspeed,lpc-io-reg = <0x3f8>;
+aspeed,lpc-interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
};
...
--
2.31.1
[PATCH v6 2/4] serial: 8250_aspeed_vuart: refactor sirq and lpc address setting code
This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
out of the sysfs store functions in preparation for adding DT
properties that will be poking the same registers. While we're at it,
these functions now provide some basic bounds-checking on their
arguments.
Signed-off-by: Zev Weiss
Reviewed-by: Andrew Jeffery
---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++---
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index c33e02cbde93..8433f8dbb186 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
}
+static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
+{
+ if (addr > U16_MAX)
+ return -EINVAL;
+
+ writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
+ writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
+
+ return 0;
+}
+
static ssize_t lpc_address_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
struct aspeed_vuart *vuart = dev_get_drvdata(dev);
- unsigned long val;
+ u32 val;
int err;
- err = kstrtoul(buf, 0, );
+ err = kstrtou32(buf, 0, );
if (err)
return err;
- writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
- writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
-
- return count;
+ err = aspeed_vuart_set_lpc_address(vuart, val);
+ return err ? : count;
}
static DEVICE_ATTR_RW(lpc_address);
@@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
}
+static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
+{
+ u8 reg;
+
+ if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >>
ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
+ return -EINVAL;
+
+ sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+ sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+
+ reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+ reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+ reg |= sirq;
+ writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
+
+ return 0;
+}
+
static ssize_t sirq_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
struct aspeed_vuart *vuart = dev_get_drvdata(dev);
unsigned long val;
int err;
- u8 reg;
err = kstrtoul(buf, 0, );
if (err)
return err;
- val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
- val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-
- reg = readb(vuart->regs + ASPEED_VUART_GCRB);
- reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
- reg |= val;
- writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
-
- return count;
+ err = aspeed_vuart_set_sirq(vuart, val);
+ return err ? : count;
}
static DEVICE_ATTR_RW(sirq);
--
2.31.1
[PATCH v6 3/4] serial: 8250_aspeed_vuart: add aspeed,lpc-io-reg and aspeed,lpc-interrupts DT properties
These allow describing all the Aspeed VUART attributes currently
available via sysfs. aspeed,lpc-interrupts provides a replacement for
the deprecated aspeed,sirq-polarity-sense property.
Signed-off-by: Zev Weiss
---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 -
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 8433f8dbb186..3c239d98747f 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -28,6 +28,10 @@
#define ASPEED_VUART_ADDRL 0x28
#define ASPEED_VUART_ADDRH 0x2c
+#define ASPEED_VUART_DEFAULT_LPC_ADDR 0x3f8
+#define ASPEED_VUART_DEFAULT_SIRQ 4
+#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY IRQ_TYPE_LEVEL_LOW
+
struct aspeed_vuart {
struct device *dev;
void __iomem*regs;
@@ -386,6 +390,18 @@ static void aspeed_vuart_auto_configure_sirq_polarity(
aspeed_vuart_set_sirq_polarity(vuart, (value & reg_mask) == 0);
}
+static int aspeed_vuart_map_irq_polarity(u32 dt)
+{
+ switch (dt) {
+ case IRQ_TYPE_LEVEL_LOW:
+ return 0;
+ case IRQ_TYPE_LEVEL_HIGH:
+ return 1;
+ default:
+ return -EINVAL;
+ }
+}
+
static int aspeed_vuart_probe(struct platform_device *pdev)
{
struct of_phandle_args sirq_polarity_sense_args;
@@ -393,8 +409,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
struct aspeed_vuart *vuart;
struct device_node *np;
struct resource *res;
- u32 clk, prop;
- int rc;
+ u32 clk, prop, sirq[2];
+ int rc, sirq_polarity;
np = pdev->dev.of_node;
@@ -501,6 +517,37 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
of_node_put(sirq_polarity_sense_args.np);
}
+ rc = of_property_read_u32(np, "aspeed,lpc-io-reg", );
+ if (rc < 0)
+ prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
+
+ rc = aspeed_vuart_set_lpc_address(vuart, prop);
+ if (rc < 0) {
+ dev_err(>dev, "invalid value in aspeed,lpc-io-reg
property\n");
+ goto err_clk_disable;
+ }
+
+ rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
+ if (rc < 0) {
+ sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
+ sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
+ }
+
+ rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
+ if (rc < 0) {
+ dev_err(>dev, "invalid sirq number in
aspeed,lpc-interrupts property\n");
+ goto err_clk_disable;
+ }
+
+ sirq_polarity = aspeed_vuart_map_irq_polarity(sirq[1]);
+ if (sirq_polarity < 0) {
+ dev_err(>dev, "invalid sirq polarity in
aspeed,lpc-interrupts property\n");
+ rc = sirq_polarity;
+ goto err_clk_disable;
+ }
+
+ aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
+
aspeed_vuart_set_enabled(vuart, true);
aspeed_vuart_set_host_tx_discard(vuart, true);
platform_set_drvdata(pdev, vuart);
--
2.31.1
[PATCH v6 0/4] serial: 8250_aspeed_vuart: generalized DT properties
This series generalizes the aspeed-vuart driver's device tree properties to cover all the attributes it currently exposes via sysfs. The aspeed,sirq-polarity-sense property was a bit of a design mistake in that it ties Aspeed VUART SIRQ polarity to SCU register bits that aren't really inherently related to it; the first patch in this series deprecates it (though we hope to eventually remove it). The rest of the series adds two new properties, aspeed,lpc-io-reg and aspeed,lpc-interrupts. The latter allows describing the SIRQ polarity (along with the interrupt number) directly, providing a simpler replacement for aspeed,sirq-polarity-sense. Changes since v5 [4]: - corrected stale DT property name in commit message - factored aspeed_vuart_map_irq_polarity() out of aspeed_vuart_probe() - fixed commit message subject line prefixes Changes since v4 [3]: - fixed commit reference formatting in commit message Changes since v3 [2]: - renamed properties to match aspeed,ast2400-kcs-bmc Changes since v2 [0]: - expanded to also handle sirq number and lpc address in addition to sirq polarity - added default settings if DT properties not specified - refactored existing sysfs code slightly, adding range checks - cleaned up 'make dt_binding_check' warnings Changes since v1 [1]: - deprecate and retain aspeed,sirq-polarity-sense instead of removing it - drop e3c246d4i dts addition from this series [0] https://lore.kernel.org/openbmc/20210401005702.28271-1-...@bewilderbeest.net/ [1] https://lore.kernel.org/openbmc/20210330002338.335-1-...@bewilderbeest.net/ [2] https://lore.kernel.org/openbmc/20210402004716.15961-1-...@bewilderbeest.net/ [3] https://lore.kernel.org/openbmc/20210402182724.20848-1-...@bewilderbeest.net/ [4] https://lore.kernel.org/openbmc/20210408011637.5361-1-...@bewilderbeest.net/ Zev Weiss (4): dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense serial: 8250_aspeed_vuart: refactor sirq and lpc address setting code serial: 8250_aspeed_vuart: add aspeed,lpc-io-reg and aspeed,lpc-interrupts DT properties dt-bindings: serial: 8250: add aspeed,lpc-io-reg and aspeed,lpc-interrupts .../devicetree/bindings/serial/8250.yaml | 28 - drivers/tty/serial/8250/8250_aspeed_vuart.c | 102 ++ 2 files changed, 109 insertions(+), 21 deletions(-) -- 2.31.1
[PATCH v6 1/4] dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense
This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it was
removed in commit c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq
polarity").
Signed-off-by: Zev Weiss
Reviewed-by: Joel Stanley
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/serial/8250.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml
b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..491b9297432d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -188,6 +188,7 @@ properties:
offset and bit number to identify how the SIRQ polarity should be
configured. One possible data source is the LPC/eSPI mode bit. Only
applicable to aspeed,ast2500-vuart.
+deprecated: true
required:
- reg
--
2.31.1
[RFC v4 net-next 3/4] dt-bindings: net: dsa: add MT7530 interrupt controller binding
Add device tree binding to support MT7530 interrupt controller. Signed-off-by: DENG Qingfang Reviewed-by: Andrew Lunn --- RFC v3 -> RFC v4: - Add #interrupt-cells property. Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt index de04626a8e9d..892b1570c496 100644 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt @@ -81,6 +81,12 @@ Optional properties: - gpio-controller: Boolean; if defined, MT7530's LED controller will run on GPIO mode. - #gpio-cells: Must be 2 if gpio-controller is defined. +- interrupt-controller: Boolean; Enables the internal interrupt controller. + +If interrupt-controller is defined, the following property is required. + +- #interrupt-cells: Must be 1. +- interrupts: Parent interrupt for the interrupt controller. See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional required, optional properties and how the integrated switch subnodes must -- 2.25.1
[RFC v4 net-next 4/4] staging: mt7621-dts: enable MT7530 interrupt controller
Enable MT7530 interrupt controller in the MT7621 SoC.
Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
---
RFC v3 -> RFC v4:
- Add #interrupt-cells property.
drivers/staging/mt7621-dts/mt7621.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 16fc94f65486..0f7e487883a5 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -447,6 +447,10 @@ switch0: switch0@0 {
mediatek,mcm;
resets = < 2>;
reset-names = "mcm";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
ports {
#address-cells = <1>;
--
2.25.1
[RFC v4 net-next 2/4] net: dsa: mt7530: add interrupt support
Add support for MT7530 interrupt controller to handle internal PHYs.
In order to assign an IRQ number to each PHY, the registration of MDIO bus
is also done in this driver.
Signed-off-by: DENG Qingfang
---
RFC v3 -> RFC v4:
- No changes.
drivers/net/dsa/Kconfig | 1 +
drivers/net/dsa/mt7530.c | 266 +++
drivers/net/dsa/mt7530.h | 20 ++-
3 files changed, 258 insertions(+), 29 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index a5f1aa911fe2..264384449f09 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -36,6 +36,7 @@ config NET_DSA_LANTIQ_GSWIP
config NET_DSA_MT7530
tristate "MediaTek MT753x and MT7621 Ethernet switch support"
select NET_DSA_TAG_MTK
+ select MEDIATEK_PHY
help
This enables support for the MediaTek MT7530, MT7531, and MT7621
Ethernet switch chips.
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 2bd1bab71497..da033004a74d 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -596,18 +597,14 @@ mt7530_mib_reset(struct dsa_switch *ds)
mt7530_write(priv, MT7530_MIB_CCR, CCR_MIB_ACTIVATE);
}
-static int mt7530_phy_read(struct dsa_switch *ds, int port, int regnum)
+static int mt7530_phy_read(struct mt7530_priv *priv, int port, int regnum)
{
- struct mt7530_priv *priv = ds->priv;
-
return mdiobus_read_nested(priv->bus, port, regnum);
}
-static int mt7530_phy_write(struct dsa_switch *ds, int port, int regnum,
+static int mt7530_phy_write(struct mt7530_priv *priv, int port, int regnum,
u16 val)
{
- struct mt7530_priv *priv = ds->priv;
-
return mdiobus_write_nested(priv->bus, port, regnum, val);
}
@@ -785,9 +782,8 @@ mt7531_ind_c22_phy_write(struct mt7530_priv *priv, int
port, int regnum,
}
static int
-mt7531_ind_phy_read(struct dsa_switch *ds, int port, int regnum)
+mt7531_ind_phy_read(struct mt7530_priv *priv, int port, int regnum)
{
- struct mt7530_priv *priv = ds->priv;
int devad;
int ret;
@@ -803,10 +799,9 @@ mt7531_ind_phy_read(struct dsa_switch *ds, int port, int
regnum)
}
static int
-mt7531_ind_phy_write(struct dsa_switch *ds, int port, int regnum,
+mt7531_ind_phy_write(struct mt7530_priv *priv, int port, int regnum,
u16 data)
{
- struct mt7530_priv *priv = ds->priv;
int devad;
int ret;
@@ -822,6 +817,22 @@ mt7531_ind_phy_write(struct dsa_switch *ds, int port, int
regnum,
return ret;
}
+static int
+mt753x_phy_read(struct mii_bus *bus, int port, int regnum)
+{
+ struct mt7530_priv *priv = bus->priv;
+
+ return priv->info->phy_read(priv, port, regnum);
+}
+
+static int
+mt753x_phy_write(struct mii_bus *bus, int port, int regnum, u16 val)
+{
+ struct mt7530_priv *priv = bus->priv;
+
+ return priv->info->phy_write(priv, port, regnum, val);
+}
+
static void
mt7530_get_strings(struct dsa_switch *ds, int port, u32 stringset,
uint8_t *data)
@@ -1828,6 +1839,211 @@ mt7530_setup_gpio(struct mt7530_priv *priv)
}
#endif /* CONFIG_GPIOLIB */
+static irqreturn_t
+mt7530_irq_thread_fn(int irq, void *dev_id)
+{
+ struct mt7530_priv *priv = dev_id;
+ bool handled = false;
+ u32 val;
+ int p;
+
+ mutex_lock_nested(>bus->mdio_lock, MDIO_MUTEX_NESTED);
+ val = mt7530_mii_read(priv, MT7530_SYS_INT_STS);
+ mt7530_mii_write(priv, MT7530_SYS_INT_STS, val);
+ mutex_unlock(>bus->mdio_lock);
+
+ for (p = 0; p < MT7530_NUM_PHYS; p++) {
+ if (BIT(p) & val) {
+ unsigned int irq;
+
+ irq = irq_find_mapping(priv->irq_domain, p);
+ handle_nested_irq(irq);
+ handled = true;
+ }
+ }
+
+ return IRQ_RETVAL(handled);
+}
+
+static void
+mt7530_irq_mask(struct irq_data *d)
+{
+ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+ priv->irq_enable &= ~BIT(d->hwirq);
+}
+
+static void
+mt7530_irq_unmask(struct irq_data *d)
+{
+ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+ priv->irq_enable |= BIT(d->hwirq);
+}
+
+static void
+mt7530_irq_bus_lock(struct irq_data *d)
+{
+ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+ mutex_lock_nested(>bus->mdio_lock, MDIO_MUTEX_NESTED);
+}
+
+static void
+mt7530_irq_bus_sync_unlock(struct irq_data *d)
+{
+ struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+ mt7530_mii_write(priv, MT7530_SYS_INT_EN, priv->irq_enable);
+ mutex_unlock(>bus->mdio_lock);
+}
+
+static struct irq_chip mt7530_irq_chip = {
+ .name = KBUILD_MODNAME,
+ .irq_mask = mt7530_irq_mask,
+ .irq_unmask = mt7530_irq_unmask,
+ .irq_bus_lock =
[RFC v4 net-next 1/4] net: phy: add MediaTek PHY driver
Add support for MediaTek PHYs found in MT7530 and MT7531 switches.
The initialization procedure is from the vendor driver, but due to lack
of documentation, the function of some register values remains unknown.
Signed-off-by: DENG Qingfang
---
RFC v3 -> RFC v4:
- Remove unused include.
drivers/net/phy/Kconfig| 5 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mediatek.c | 111 +
3 files changed, 117 insertions(+)
create mode 100644 drivers/net/phy/mediatek.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index a615b3660b05..edd858cec9ec 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -207,6 +207,11 @@ config MARVELL_88X_PHY
Support for the Marvell 88X Dual-port Multi-speed Ethernet
Transceiver.
+config MEDIATEK_PHY
+ tristate "MediaTek PHYs"
+ help
+ Supports the MediaTek switch integrated PHYs.
+
config MICREL_PHY
tristate "Micrel PHYs"
help
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index de683e3abe63..9ed7dbab7770 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_MARVELL_10G_PHY) += marvell10g.o
obj-$(CONFIG_MARVELL_PHY) += marvell.o
obj-$(CONFIG_MARVELL_88X_PHY) += marvell-88x.o
+obj-$(CONFIG_MEDIATEK_PHY) += mediatek.o
obj-$(CONFIG_MESON_GXL_PHY)+= meson-gxl.o
obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
obj-$(CONFIG_MICREL_PHY) += micrel.o
diff --git a/drivers/net/phy/mediatek.c b/drivers/net/phy/mediatek.c
new file mode 100644
index ..1627b7c04345
--- /dev/null
+++ b/drivers/net/phy/mediatek.c
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include
+#include
+
+#define MTK_EXT_PAGE_ACCESS0x1f
+#define MTK_PHY_PAGE_STANDARD 0x
+#define MTK_PHY_PAGE_EXTENDED 0x0001
+#define MTK_PHY_PAGE_EXTENDED_20x0002
+#define MTK_PHY_PAGE_EXTENDED_30x0003
+#define MTK_PHY_PAGE_EXTENDED_2A30 0x2a30
+#define MTK_PHY_PAGE_EXTENDED_52B5 0x52b5
+
+static int mtk_phy_read_page(struct phy_device *phydev)
+{
+ return __phy_read(phydev, MTK_EXT_PAGE_ACCESS);
+}
+
+static int mtk_phy_write_page(struct phy_device *phydev, int page)
+{
+ return __phy_write(phydev, MTK_EXT_PAGE_ACCESS, page);
+}
+
+static void mtk_phy_config_init(struct phy_device *phydev)
+{
+ /* Disable EEE */
+ phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+
+ /* Enable HW auto downshift */
+ phy_modify_paged(phydev, MTK_PHY_PAGE_EXTENDED, 0x14, 0, BIT(4));
+
+ /* Increase SlvDPSready time */
+ phy_select_page(phydev, MTK_PHY_PAGE_EXTENDED_52B5);
+ __phy_write(phydev, 0x10, 0xafae);
+ __phy_write(phydev, 0x12, 0x2f);
+ __phy_write(phydev, 0x10, 0x8fae);
+ phy_restore_page(phydev, MTK_PHY_PAGE_STANDARD, 0);
+
+ /* Adjust 100_mse_threshold */
+ phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x123, 0x);
+
+ /* Disable mcc */
+ phy_write_mmd(phydev, MDIO_MMD_VEND1, 0xa6, 0x300);
+}
+
+static int mt7530_phy_config_init(struct phy_device *phydev)
+{
+ mtk_phy_config_init(phydev);
+
+ /* Increase post_update_timer */
+ phy_write_paged(phydev, MTK_PHY_PAGE_EXTENDED_3, 0x11, 0x4b);
+
+ return 0;
+}
+
+static int mt7531_phy_config_init(struct phy_device *phydev)
+{
+ if (phydev->interface != PHY_INTERFACE_MODE_INTERNAL)
+ return -EINVAL;
+
+ mtk_phy_config_init(phydev);
+
+ /* PHY link down power saving enable */
+ phy_set_bits(phydev, 0x17, BIT(4));
+ phy_clear_bits_mmd(phydev, MDIO_MMD_VEND1, 0xc6, 0x300);
+
+ /* Set TX Pair delay selection */
+ phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x13, 0x404);
+ phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x14, 0x404);
+
+ return 0;
+}
+
+static struct phy_driver mtk_phy_driver[] = {
+ {
+ PHY_ID_MATCH_EXACT(0x03a29412),
+ .name = "MediaTek MT7530 PHY",
+ .config_init= mt7530_phy_config_init,
+ /* Interrupts are handled by the switch, not the PHY
+* itself.
+*/
+ .config_intr= genphy_no_config_intr,
+ .handle_interrupt = genphy_handle_interrupt_no_ack,
+ .read_page = mtk_phy_read_page,
+ .write_page = mtk_phy_write_page,
+ },
+ {
+ PHY_ID_MATCH_EXACT(0x03a29441),
+ .name = "MediaTek MT7531 PHY",
+ .config_init= mt7531_phy_config_init,
+ /* Interrupts are handled by the switch, not the PHY
+* itself.
+*/
+ .config_intr= genphy_no_config_intr,
+ .handle_interrupt = genphy_handle_interrupt_no_ack,
+ .read_page
[RFC v4 net-next 0/4] MT7530 interrupt support
Add support for MT7530 interrupt controller. DENG Qingfang (4): net: phy: add MediaTek PHY driver net: dsa: mt7530: add interrupt support dt-bindings: net: dsa: add MT7530 interrupt controller binding staging: mt7621-dts: enable MT7530 interrupt controller .../devicetree/bindings/net/dsa/mt7530.txt| 6 + drivers/net/dsa/Kconfig | 1 + drivers/net/dsa/mt7530.c | 266 -- drivers/net/dsa/mt7530.h | 20 +- drivers/net/phy/Kconfig | 5 + drivers/net/phy/Makefile | 1 + drivers/net/phy/mediatek.c| 111 drivers/staging/mt7621-dts/mt7621.dtsi| 4 + 8 files changed, 385 insertions(+), 29 deletions(-) create mode 100644 drivers/net/phy/mediatek.c -- 2.25.1
[PATCH] thermal: ti-soc-thermal: remove useless variable
Fix the following gcc warning:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1146:7: warning: variable
‘val’ set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 8a3646e..2df0e09 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1143,13 +1143,12 @@ static int ti_bandgap_restore_ctxt(struct ti_bandgap
*bgp)
for (i = 0; i < bgp->conf->sensor_count; i++) {
struct temp_sensor_registers *tsr;
struct temp_sensor_regval *rval;
- u32 val = 0;
rval = >regval[i];
tsr = bgp->conf->sensors[i].registers;
if (TI_BANDGAP_HAS(bgp, COUNTER))
- val = ti_bandgap_readl(bgp, tsr->bgap_counter);
+ ti_bandgap_readl(bgp, tsr->bgap_counter);
if (TI_BANDGAP_HAS(bgp, TSHUT_CONFIG))
ti_bandgap_writel(bgp, rval->tshut_threshold,
--
1.8.3.1
Re: [PATCH net v3] net: sched: fix packet stuck problem for lockless qdisc
On 2021/4/12 11:21, Hillf Danton wrote:
> On Mon, 12 Apr 2021 09:24:30 Yunsheng Lin wrote:
>> On 2021/4/9 17:09, Hillf Danton wrote:
>>> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
On 25.03.21 04:13, Yunsheng Lin wrote:
I have a setup which is able to reproduce the issue quite reliably:
In a Xen guest I'm mounting 8 NFS shares and run sysbench fileio on
each of them. The average latency reported by sysbench is well below
1 msec, but at least once per hour I get latencies in the minute
range.
With this patch I don't see these high latencies any longer (test
is running for more than 20 hours now).
So you can add my:
Tested-by: Juergen Gross
>>>
>>> If retry is allowed in the dequeue method then a simple seqcount can do the
>>> work of serializing enqueuer and dequeuer. IIUC it was not attempted last
>>> year.
>>
>> At the first glance, I do not think the below patch fix the data race
>
> Thanks for taking a look.
>
>> described in the commit log, as it does not handle the time window
>> between dequeuing and q->seqlock releasing, as below:
>>
> Yes the time window does exist.
>
>> The cpu1 may not see the qdisc->pad changed after pfifo_fast_dequeue(),
>> and cpu2 is not able to take the q->seqlock yet because cpu1 do not
>> release the q->seqlock.
>>
> It's now covered by extending the seqcount aperture a bit.
>
> --- x/net/sched/sch_generic.c
> +++ y/net/sched/sch_generic.c
> @@ -380,14 +380,23 @@ void __qdisc_run(struct Qdisc *q)
> {
> int quota = dev_tx_weight;
> int packets;
> + int seq;
> +
> +again:
> + seq = READ_ONCE(q->pad);
> + smp_rmb();
>
> while (qdisc_restart(q, )) {
> quota -= packets;
> if (quota <= 0) {
> __netif_schedule(q);
> - break;
> + return;
> }
> }
> +
> + smp_rmb();
> + if (seq != READ_ONCE(q->pad))
> + goto again;
As my understanding, there is still time window between q->pad checking
above and q->seqlock releasing in qdisc_run_end().
> }
>
> unsigned long dev_trans_start(struct net_device *dev)
> @@ -632,6 +641,9 @@ static int pfifo_fast_enqueue(struct sk_
> return qdisc_drop(skb, qdisc, to_free);
> }
>
> + qdisc->pad++;
> + smp_wmb();
> +
> qdisc_update_stats_at_enqueue(qdisc, pkt_len);
> return NET_XMIT_SUCCESS;
> }
>
> .
>
Re: [PATCH RFC net-next 1/3] net: dsa: allow for multiple CPU ports
On Sat, Apr 10, 2021 at 03:34:47PM +0200, Ansuel Smith wrote: > Allow for multiple CPU ports in a DSA switch tree. By default the first > CPU port is assigned mimic the original assignement logic. A DSA driver > can define a function to declare a preferred CPU port based on the > provided port. If the function doesn't have a preferred port the CPU > port is assigned using a round-robin way starting from the last assigned > CPU port. > Examples: > There are two CPU port but no port_get_preferred_cpu is provided: > - The old logic is used. Every port is assigned to the first cpu port. > There are two CPU port but the port_get_preferred_cpu return -1: > - The port is assigned using a round-robin way since no preference is > provided. > There are two CPU port and the port_get_preferred_cpu define only one > port and the rest with -1: (wan port with CPU1 and the rest no > preference) > lan1 <-> eth0 > lan2 <-> eth1 > lan3 <-> eth0 > lan4 <-> eth1 > wan <-> eth1 > There are two CPU port and the port_get_preferred assign a preference > for every port: (wan port with CPU1 everything else CPU0) > lan1 <-> eth0 > lan2 <-> eth0 > lan3 <-> eth0 > lan4 <-> eth0 > wan <-> eth1 So, drivers will read the name of every port and decide which CPU port does it use? > > Signed-off-by: Marek Beh�n > Signed-off-by: Ansuel Smith
Re: [PATCH 1/5] mm/swapfile: add percpu_ref support for swap
Miaohe Lin writes:
> We will use percpu-refcount to serialize against concurrent swapoff. This
> patch adds the percpu_ref support for later fixup.
>
> Signed-off-by: Miaohe Lin
> ---
> include/linux/swap.h | 2 ++
> mm/swapfile.c| 25 ++---
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 144727041e78..849ba5265c11 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -240,6 +240,7 @@ struct swap_cluster_list {
> * The in-memory structure used to track swap areas.
> */
> struct swap_info_struct {
> + struct percpu_ref users;/* serialization against concurrent
> swapoff */
> unsigned long flags; /* SWP_USED etc: see above */
> signed shortprio; /* swap priority of this type */
> struct plist_node list; /* entry in swap_active_head */
> @@ -260,6 +261,7 @@ struct swap_info_struct {
> struct block_device *bdev; /* swap device or bdev of swap file */
> struct file *swap_file; /* seldom referenced */
> unsigned int old_block_size;/* seldom referenced */
> + struct completion comp; /* seldom referenced */
> #ifdef CONFIG_FRONTSWAP
> unsigned long *frontswap_map; /* frontswap in-use, one bit per page */
> atomic_t frontswap_pages; /* frontswap pages in-use counter */
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 149e77454e3c..724173cd7d0c 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -511,6 +512,15 @@ static void swap_discard_work(struct work_struct *work)
> spin_unlock(>lock);
> }
>
> +static void swap_users_ref_free(struct percpu_ref *ref)
> +{
> + struct swap_info_struct *si;
> +
> + si = container_of(ref, struct swap_info_struct, users);
> + complete(>comp);
> + percpu_ref_exit(>users);
Because percpu_ref_exit() is used, we cannot use percpu_ref_tryget() in
get_swap_device(), better to add comments there.
> +}
> +
> static void alloc_cluster(struct swap_info_struct *si, unsigned long idx)
> {
> struct swap_cluster_info *ci = si->cluster_info;
> @@ -2500,7 +2510,7 @@ static void enable_swap_info(struct swap_info_struct
> *p, int prio,
>* Guarantee swap_map, cluster_info, etc. fields are valid
>* between get/put_swap_device() if SWP_VALID bit is set
>*/
> - synchronize_rcu();
> + percpu_ref_reinit(>users);
Although the effect is same, I think it's better to use
percpu_ref_resurrect() here to improve code readability.
> spin_lock(_lock);
> spin_lock(>lock);
> _enable_swap_info(p);
> @@ -2621,11 +2631,13 @@ SYSCALL_DEFINE1(swapoff, const char __user *,
> specialfile)
> p->flags &= ~SWP_VALID; /* mark swap device as invalid */
> spin_unlock(>lock);
> spin_unlock(_lock);
> +
> + percpu_ref_kill(>users);
> /*
>* wait for swap operations protected by get/put_swap_device()
>* to complete
>*/
> - synchronize_rcu();
> + wait_for_completion(>comp);
Better to move percpu_ref_kill() after the comments. And maybe revise
the comments.
>
> flush_work(>discard_work);
>
> @@ -3132,7 +3144,7 @@ static bool swap_discardable(struct swap_info_struct
> *si)
> SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
> {
> struct swap_info_struct *p;
> - struct filename *name;
> + struct filename *name = NULL;
> struct file *swap_file = NULL;
> struct address_space *mapping;
> int prio;
> @@ -3163,6 +3175,12 @@ SYSCALL_DEFINE2(swapon, const char __user *,
> specialfile, int, swap_flags)
>
> INIT_WORK(>discard_work, swap_discard_work);
>
> + init_completion(>comp);
> + error = percpu_ref_init(>users, swap_users_ref_free,
> + PERCPU_REF_INIT_DEAD, GFP_KERNEL);
> + if (unlikely(error))
> + goto bad_swap;
> +
> name = getname(specialfile);
> if (IS_ERR(name)) {
> error = PTR_ERR(name);
> @@ -3356,6 +3374,7 @@ SYSCALL_DEFINE2(swapon, const char __user *,
> specialfile, int, swap_flags)
> bad_swap_unlock_inode:
> inode_unlock(inode);
> bad_swap:
> + percpu_ref_exit(>users);
Usually the resource freeing order matches their allocating order
reversely. So, if there's no special reason, please follow that rule.
Best Regards,
Huang, Ying
> free_percpu(p->percpu_cluster);
> p->percpu_cluster = NULL;
> free_percpu(p->cluster_next_cpu);
RE: [PATCH v2] usb: cdnsp: Fixes issue with Configure Endpoint command
>
>On 21-04-07 08:36:29, Pawel Laszczak wrote:
>> From: Pawel Laszczak
>>
>> Patch adds flag EP_UNCONFIGURED to detect whether endpoint was
>> unconfigured. This flag is set in cdnsp_reset_device after Reset Device
>> command. Among others this command disables all non control endpoints.
>> Flag is used in cdnsp_gadget_ep_disable to protect controller against
>> invoking Configure Endpoint command on disabled endpoint. Lack of this
>> protection in some cases caused that Configure Endpoint command completed
>> with Context State Error code completion.
>>
>> Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD
>> Driver")
>> Signed-off-by: Pawel Laszczak
>
>Pawel, it is a little late for v5.12, I apply it to v5.13-rc1 if you
>don't mind.
>
>Peter
Yes, you can apply it to v5.13-rc1.
Thanks.
r
>>
>> ---
>> Changelog:
>> v2:
>> - removed useless blank line
>> - changed the EP_UNCONFIGURED to limit changes in patch
>>
>> drivers/usb/cdns3/cdnsp-gadget.c | 17 -
>> drivers/usb/cdns3/cdnsp-gadget.h | 1 +
>> 2 files changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/cdnsp-gadget.c
>> b/drivers/usb/cdns3/cdnsp-gadget.c
>> index d7d4bdd57f46..56707b6b0f57 100644
>> --- a/drivers/usb/cdns3/cdnsp-gadget.c
>> +++ b/drivers/usb/cdns3/cdnsp-gadget.c
>> @@ -727,7 +727,7 @@ int cdnsp_reset_device(struct cdnsp_device *pdev)
>> * are in Disabled state.
>> */
>> for (i = 1; i < CDNSP_ENDPOINTS_NUM; ++i)
>> -pdev->eps[i].ep_state |= EP_STOPPED;
>> +pdev->eps[i].ep_state |= EP_STOPPED | EP_UNCONFIGURED;
>>
>> trace_cdnsp_handle_cmd_reset_dev(slot_ctx);
>>
>> @@ -942,6 +942,7 @@ static int cdnsp_gadget_ep_enable(struct usb_ep *ep,
>>
>> pep = to_cdnsp_ep(ep);
>> pdev = pep->pdev;
>> +pep->ep_state &= ~EP_UNCONFIGURED;
>>
>> if (dev_WARN_ONCE(pdev->dev, pep->ep_state & EP_ENABLED,
>>"%s is already enabled\n", pep->name))
>> @@ -1023,9 +1024,13 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>> goto finish;
>> }
>>
>> -cdnsp_cmd_stop_ep(pdev, pep);
>> pep->ep_state |= EP_DIS_IN_RROGRESS;
>> -cdnsp_cmd_flush_ep(pdev, pep);
>> +
>> +/* Endpoint was unconfigured by Reset Device command. */
>> +if (!(pep->ep_state & EP_UNCONFIGURED)) {
>> +cdnsp_cmd_stop_ep(pdev, pep);
>> +cdnsp_cmd_flush_ep(pdev, pep);
>> +}
>>
>> /* Remove all queued USB requests. */
>> while (!list_empty(>pending_list)) {
>> @@ -1043,10 +1048,12 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>>
>> cdnsp_endpoint_zero(pdev, pep);
>>
>> -ret = cdnsp_update_eps_configuration(pdev, pep);
>> +if (!(pep->ep_state & EP_UNCONFIGURED))
>> +ret = cdnsp_update_eps_configuration(pdev, pep);
>> +
>> cdnsp_free_endpoint_rings(pdev, pep);
>>
>> -pep->ep_state &= ~EP_ENABLED;
>> +pep->ep_state &= ~(EP_ENABLED | EP_UNCONFIGURED);
>> pep->ep_state |= EP_STOPPED;
>>
>> finish:
>> diff --git a/drivers/usb/cdns3/cdnsp-gadget.h
>> b/drivers/usb/cdns3/cdnsp-gadget.h
>> index 6bbb26548c04..783ca8ffde00 100644
>> --- a/drivers/usb/cdns3/cdnsp-gadget.h
>> +++ b/drivers/usb/cdns3/cdnsp-gadget.h
>> @@ -835,6 +835,7 @@ struct cdnsp_ep {
>> #define EP_WEDGEBIT(4)
>> #define EP0_HALTED_STATUS BIT(5)
>> #define EP_HAS_STREAMS BIT(6)
>> +#define EP_UNCONFIGURED BIT(7)
>>
>> bool skip;
>> };
>> --
>> 2.25.1
>>
>
>--
>
>Thanks,
>Peter Chen
--
Regards,
Pawel Laszczak
Re: [PATCH 2/5] swap: fix do_swap_page() race with swapoff
On 2021/4/12 9:44, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> On 2021/4/10 1:17, Tim Chen wrote:
>>>
>>>
>>> On 4/9/21 1:42 AM, Miaohe Lin wrote:
On 2021/4/9 5:34, Tim Chen wrote:
>
>
> On 4/8/21 6:08 AM, Miaohe Lin wrote:
>> When I was investigating the swap code, I found the below possible race
>> window:
>>
>> CPU 1CPU 2
>> --
>> do_swap_page
>> synchronous swap_readpage
>> alloc_page_vma
>> swapoff
>>release swap_file, bdev, or ...
>
Many thanks for quick review and reply!
> Perhaps I'm missing something. The release of swap_file, bdev etc
> happens after we have cleared the SWP_VALID bit in si->flags in
> destroy_swap_extents
> if I read the swapoff code correctly.
Agree. Let's look this more close:
CPU1 CPU2
- -
swap_readpage
if (data_race(sis->flags & SWP_FS_OPS)) {
swapoff
p->swap_file
= NULL;
struct file *swap_file = sis->swap_file;
struct address_space *mapping = swap_file->f_mapping;[oops!]
...
p->flags = 0;
...
Does this make sense for you?
>>>
>>> p->swapfile = NULL happens after the
>>> p->flags &= ~SWP_VALID, synchronize_rcu(), destroy_swap_extents() sequence
>>> in swapoff().
>>>
>>> So I don't think the sequence you illustrated on CPU2 is in the right order.
>>> That said, without get_swap_device/put_swap_device in swap_readpage, you
>>> could
>>> potentially blow pass synchronize_rcu() on CPU2 and causes a problem. so I
>>> think
>>> the problematic race looks something like the following:
>>>
>>>
>>> CPU1CPU2
>>> - -
>>> swap_readpage
>>> if (data_race(sis->flags & SWP_FS_OPS)) {
>>> swapoff
>>> p->flags = &=
>>> ~SWP_VALID;
>>> ..
>>>
>>> synchronize_rcu();
>>> ..
>>> p->swap_file
>>> = NULL;
>>> struct file *swap_file = sis->swap_file;
>>> struct address_space *mapping = swap_file->f_mapping;[oops!]
>>> ...
>>> ...
>>>
>>
>> Agree. This is also what I meant to illustrate. And you provide a better
>> one. Many thanks!
>
> For the pages that are swapped in through swap cache. That isn't an
> issue. Because the page is locked, the swap entry will be marked with
> SWAP_HAS_CACHE, so swapoff() cannot proceed until the page has been
> unlocked.
>
> So the race is for the fast path as follows,
>
> if (data_race(si->flags & SWP_SYNCHRONOUS_IO) &&
> __swap_count(entry) == 1)
>
> I found it in your original patch description. But please make it more
> explicit to reduce the potential confusing.
Sure. Should I rephrase the commit log to clarify this or add a comment in the
code?
Thanks.
>
> Best Regards,
> Huang, Ying
> .
>
Re: [RESEND,v5,1/2] bio: limit bio max size
On Sun, Apr 11, 2021 at 10:13:01PM +, Damien Le Moal wrote: > On 2021/04/09 23:47, Bart Van Assche wrote: > > On 4/7/21 3:27 AM, Damien Le Moal wrote: > >> On 2021/04/07 18:46, Changheun Lee wrote: > >>> I'll prepare new patch as you recommand. It will be added setting of > >>> limit_bio_size automatically when queue max sectors is determined. > >> > >> Please do that in the driver for the HW that benefits from it. Do not do > >> this > >> for all block devices. > > > > Hmm ... is it ever useful to build a bio with a size that exceeds > > max_hw_sectors when submitting a bio directly to a block device, or in > > other words, if no stacked block driver sits between the submitter and > > the block device? Am I perhaps missing something? > > Device performance wise, the benefits are certainly not obvious to me either. > But for very fast block devices, I think the CPU overhead of building more > smaller BIOs may be significant compared to splitting a large BIO into > multiple > requests. Though it may be good to revisit this with some benchmark numbers. This patch tries to address issue[1] in do_direct_IO() in which Changheun observed that other operations takes time between adding page to bio. However, do_direct_IO() just does following except for adding bio and submitting bio: - retrieves pages at batch(pin 64 pages each time from VM) and - retrieve block mapping(get_more_blocks), which is still done usually very less times for 32MB; for new mapping, clean_bdev_aliases() may take a bit time. If there isn't system memory pressure, pin 64 pages won't be slow, but get_more_blocks() may take a bit time. Changheun, can you check if multiple get_more_blocks() is called for submitting 32MB in your test? In my 32MB sync dio f2fs test on x86_64 VM, one buffer_head mapping can hold 32MB, but it is one freshly new f2fs. I'd suggest to understand the issue completely before figuring out one solution. [1] https://lore.kernel.org/linux-block/20210202041204.28995-1-nanich@samsung.com/ Thanks, Ming
[PATCH] scsi: a100u2w: remove useless variable
Fix the following gcc warning:
drivers/scsi/a100u2w.c:1092:8: warning: variable ‘bios_phys’ set but not
used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/scsi/a100u2w.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
index 66c5143..855a3fe 100644
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -1089,7 +1089,6 @@ static int inia100_probe_one(struct pci_dev *pdev,
int error = -ENODEV;
u32 sz;
unsigned long biosaddr;
- char *bios_phys;
if (pci_enable_device(pdev))
goto out;
@@ -1141,7 +1140,7 @@ static int inia100_probe_one(struct pci_dev *pdev,
biosaddr = host->BIOScfg;
biosaddr = (biosaddr << 4);
- bios_phys = phys_to_virt(biosaddr);
+ phys_to_virt(biosaddr);
if (init_orchid(host)) {/* Initialize orchid chip */
printk("inia100: initial orchid fail!!\n");
goto out_free_escb_array;
--
1.8.3.1
[PATCH v3] drivers/clocksource/mediatek: Ack and disable interrupts on suspend
Interrupts are disabled during suspend before this driver disables its
timers. ARM trusted firmware will abort suspend if the timer irq is
pending, so ack and disable the timer interrupt during suspend.
Signed-off-by: Evan Benn
---
Changes in v3:
Move the ACK from the shutdown to the suspend function.
Changes in v2:
Remove the patch that splits the drivers into 2 files.
drivers/clocksource/timer-mediatek.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/clocksource/timer-mediatek.c
b/drivers/clocksource/timer-mediatek.c
index 9318edcd8963..1ae8fee639bf 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -241,6 +241,27 @@ static void mtk_gpt_enable_irq(struct timer_of *to, u8
timer)
timer_of_base(to) + GPT_IRQ_EN_REG);
}
+static void mtk_gpt_resume(struct clock_event_device *clk)
+{
+ struct timer_of *to = to_timer_of(clk);
+
+ mtk_gpt_enable_irq(to, TIMER_CLK_EVT);
+}
+
+static void mtk_gpt_suspend(struct clock_event_device *clk)
+{
+ struct timer_of *to = to_timer_of(clk);
+
+ /* Disable all interrupts */
+ writel(0x0, timer_of_base(to) + GPT_IRQ_EN_REG);
+
+ /* This is called with interrupts disabled,
+* so we need to ack any interrupt that is pending
+* Or for example ATF will prevent a suspend from completing.
+*/
+ writel(0x3f, timer_of_base(to) + GPT_IRQ_ACK_REG);
+}
+
static struct timer_of to = {
.flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
@@ -286,6 +307,8 @@ static int __init mtk_gpt_init(struct device_node *node)
to.clkevt.set_state_oneshot = mtk_gpt_clkevt_shutdown;
to.clkevt.tick_resume = mtk_gpt_clkevt_shutdown;
to.clkevt.set_next_event = mtk_gpt_clkevt_next_event;
+ to.clkevt.suspend = mtk_gpt_suspend;
+ to.clkevt.resume = mtk_gpt_resume;
to.of_irq.handler = mtk_gpt_interrupt;
ret = timer_of_init(node, );
--
2.31.1.295.g9ea45b61b8-goog
Re: [PATCH 4/5] mm/swap_state: fix potential faulted in race in swap_ra_info()
On 2021/4/12 8:55, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> On 2021/4/9 16:50, Huang, Ying wrote:
>>> Miaohe Lin writes:
>>>
While we released the pte lock, somebody else might faulted in this pte.
So we should check whether it's swap pte first to guard against such race
or swp_type would be unexpected. And we can also avoid some unnecessary
readahead cpu cycles possibly.
Fixes: ec560175c0b6 ("mm, swap: VMA based swap readahead")
Signed-off-by: Miaohe Lin
---
mm/swap_state.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 709c260d644a..3bf0d0c297bc 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -724,10 +724,10 @@ static void swap_ra_info(struct vm_fault *vmf,
{
struct vm_area_struct *vma = vmf->vma;
unsigned long ra_val;
- swp_entry_t entry;
+ swp_entry_t swap_entry;
unsigned long faddr, pfn, fpfn;
unsigned long start, end;
- pte_t *pte, *orig_pte;
+ pte_t *pte, *orig_pte, entry;
unsigned int max_win, hits, prev_win, win, left;
#ifndef CONFIG_64BIT
pte_t *tpte;
@@ -742,8 +742,13 @@ static void swap_ra_info(struct vm_fault *vmf,
faddr = vmf->address;
orig_pte = pte = pte_offset_map(vmf->pmd, faddr);
- entry = pte_to_swp_entry(*pte);
- if ((unlikely(non_swap_entry(entry {
+ entry = *pte;
+ if (unlikely(!is_swap_pte(entry))) {
+ pte_unmap(orig_pte);
+ return;
+ }
+ swap_entry = pte_to_swp_entry(entry);
+ if ((unlikely(non_swap_entry(swap_entry {
pte_unmap(orig_pte);
return;
}
>>>
>>> This isn't a real issue. entry or swap_entry isn't used in this
>>
>> Agree. It seems the entry or swap_entry here is just used for check whether
>> pte is still valid swap_entry.
>
> If you check the git history, you will find that the check has been
> necessary before. Because the function is used earlier in
> do_swap_page() at that time.
>
I see. Many thanks for explanation. :)
> Best Regards,
> Huang, Ying
> .
>
[PATCH v6 3/3] bio: add limit_bio_size sysfs
Add limit_bio_size block sysfs node to limit bio size.
Queue flag QUEUE_FLAG_LIMIT_BIO_SIZE will be set if limit_bio_size is set.
And bio max size will be limited by queue max sectors via
QUEUE_FLAG_LIMIT_BIO_SIZE set.
Signed-off-by: Changheun Lee
---
Documentation/ABI/testing/sysfs-block | 10 ++
Documentation/block/queue-sysfs.rst | 7 +++
block/blk-sysfs.c | 3 +++
3 files changed, 20 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block
b/Documentation/ABI/testing/sysfs-block
index e34cdeeeb9d4..86a7b15410cf 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -316,3 +316,13 @@ Description:
does not complete in this time then the block driver timeout
handler is invoked. That timeout handler can decide to retry
the request, to fail it or to start a device recovery strategy.
+
+What: /sys/block//queue/limit_bio_size
+Date: Feb, 2021
+Contact: Changheun Lee
+Description:
+ (RW) Toggle for set/clear QUEUE_FLAG_LIMIT_BIO_SIZE queue flag.
+ Queue flag QUEUE_FLAG_LIMIT_BIO_SIZE will be set if
limit_bio_size
+ is set. And bio max size will be limited by queue max sectors.
+ QUEUE_FLAG_LIMIT_BIO_SIZE will be cleared if limit_bio_size is
+ cleard. And limit of bio max size will be cleard.
diff --git a/Documentation/block/queue-sysfs.rst
b/Documentation/block/queue-sysfs.rst
index 4dc7f0d499a8..220d183a4c11 100644
--- a/Documentation/block/queue-sysfs.rst
+++ b/Documentation/block/queue-sysfs.rst
@@ -286,4 +286,11 @@ sequential zones of zoned block devices (devices with a
zoned attributed
that reports "host-managed" or "host-aware"). This value is always 0 for
regular block devices.
+limit_bio_size (RW)
+---
+This indicates QUEUE_FLAG_LIMIT_BIO_SIZE queue flag value. And
+QUEUE_FLAG_LIMIT_BIO_SIZE can be changed via set(1)/clear(0) this node.
+bio max size will be limited by queue max sectors via set this node. And
+limit of bio max size will be cleard via clear this node.
+
Jens Axboe , February 2009
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 0f4f0c8a7825..4625d5319daf 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -294,6 +294,7 @@ QUEUE_SYSFS_BIT_FNS(nonrot, NONROT, 1);
QUEUE_SYSFS_BIT_FNS(random, ADD_RANDOM, 0);
QUEUE_SYSFS_BIT_FNS(iostats, IO_STAT, 0);
QUEUE_SYSFS_BIT_FNS(stable_writes, STABLE_WRITES, 0);
+QUEUE_SYSFS_BIT_FNS(limit_bio_size, LIMIT_BIO_SIZE, 0);
#undef QUEUE_SYSFS_BIT_FNS
static ssize_t queue_zoned_show(struct request_queue *q, char *page)
@@ -625,6 +626,7 @@ QUEUE_RW_ENTRY(queue_nonrot, "rotational");
QUEUE_RW_ENTRY(queue_iostats, "iostats");
QUEUE_RW_ENTRY(queue_random, "add_random");
QUEUE_RW_ENTRY(queue_stable_writes, "stable_writes");
+QUEUE_RW_ENTRY(queue_limit_bio_size, "limit_bio_size");
static struct attribute *queue_attrs[] = {
_requests_entry.attr,
@@ -659,6 +661,7 @@ static struct attribute *queue_attrs[] = {
_rq_affinity_entry.attr,
_iostats_entry.attr,
_stable_writes_entry.attr,
+ _limit_bio_size_entry.attr,
_random_entry.attr,
_poll_entry.attr,
_wc_entry.attr,
--
2.29.0
[PATCH v6 2/3] ufs: set QUEUE_FLAG_LIMIT_BIO_SIZE
Set QUEUE_FLAG_LIMIT_BIO_SIZE queue flag to limit bio max size to
queue max sectors size for UFS device.
Signed-off-by: Changheun Lee
---
drivers/scsi/scsi_lib.c | 2 ++
drivers/scsi/ufs/ufshcd.c | 1 +
include/scsi/scsi_host.h | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7d52a11e1b61..73ce6ba7903a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1838,6 +1838,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct
request_queue *q)
* Devices that require a bigger alignment can increase it later.
*/
blk_queue_dma_alignment(q, max(4, dma_get_cache_alignment()) - 1);
+
+ blk_queue_set_limit_bio_size(q, shost->limit_bio_size);
}
EXPORT_SYMBOL_GPL(__scsi_init_queue);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index d3d05e997c13..000eb5ab022e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -9313,6 +9313,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem
*mmio_base, unsigned int irq)
host->max_channel = UFSHCD_MAX_CHANNEL;
host->unique_id = host->host_no;
host->max_cmd_len = UFS_CDB_SIZE;
+ host->limit_bio_size = true;
hba->max_pwr_info.is_valid = false;
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index e30fd963b97d..486f61588717 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -607,6 +607,8 @@ struct Scsi_Host {
unsigned int max_segment_size;
unsigned long dma_boundary;
unsigned long virt_boundary_mask;
+ unsigned int limit_bio_size;
+
/*
* In scsi-mq mode, the number of hardware queues supported by the LLD.
*
--
2.29.0
[PATCH v6 1/3] bio: limit bio max size
bio size can grow up to 4GB when muli-page bvec is enabled.
but sometimes it would lead to inefficient behaviors.
in case of large chunk direct I/O, - 32MB chunk read in user space -
all pages for 32MB would be merged to a bio structure if the pages
physical addresses are contiguous. it makes some delay to submit
until merge complete. bio max size should be limited to a proper size.
When 32MB chunk read with direct I/O option is coming from userspace,
kernel behavior is below now in do_direct_IO() loop. it's timeline.
| bio merge for 32MB. total 8,192 pages are merged.
| total elapsed time is over 2ms.
|-- ... --->|
| 8,192 pages merged a bio.
| at this time, first bio
submit is done.
| 1 bio is split to 32 read
request and issue.
|--->
|--->
|--->
..
|--->
|--->|
total 19ms elapsed to complete 32MB read done from
device. |
If bio max size is limited with 1MB, behavior is changed below.
| bio merge for 1MB. 256 pages are merged for each bio.
| total 32 bio will be made.
| total elapsed time is over 2ms. it's same.
| but, first bio submit timing is fast. about 100us.
|--->|--->|--->|---> ... -->|--->|--->|--->|--->|
| 256 pages merged a bio.
| at this time, first bio submit is done.
| and 1 read request is issued for 1 bio.
|--->
|--->
|--->
..
|--->
|--->|
total 17ms elapsed to complete 32MB read done from device. |
As a result, read request issue timing is faster if bio max size is limited.
Current kernel behavior with multipage bvec, super large bio can be created.
And it lead to delay first I/O request issue.
Signed-off-by: Changheun Lee
---
block/bio.c| 13 -
block/blk-settings.c | 17 +
include/linux/bio.h| 2 +-
include/linux/blkdev.h | 4
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 50e579088aca..e4d6169106b6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -255,6 +255,17 @@ void bio_init(struct bio *bio, struct bio_vec *table,
}
EXPORT_SYMBOL(bio_init);
+unsigned int bio_max_size(struct bio *bio)
+{
+ struct request_queue *q = bio->bi_disk->queue;
+
+ if (blk_queue_limit_bio_size(q))
+ return blk_queue_get_max_sectors(q, bio_op(bio))
+ << SECTOR_SHIFT;
+
+ return UINT_MAX;
+}
+
/**
* bio_reset - reinitialize a bio
* @bio: bio to reset
@@ -866,7 +877,7 @@ bool __bio_try_merge_page(struct bio *bio, struct page
*page,
struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
if (page_is_mergeable(bv, page, len, off, same_page)) {
- if (bio->bi_iter.bi_size > UINT_MAX - len) {
+ if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
*same_page = false;
return false;
}
diff --git a/block/blk-settings.c b/block/blk-settings.c
index b4aa2f37fab6..1d94b97cea4f 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -928,6 +928,23 @@ void blk_queue_set_zoned(struct gendisk *disk, enum
blk_zoned_model model)
}
EXPORT_SYMBOL_GPL(blk_queue_set_zoned);
+/**
+ * blk_queue_set_limit_bio_size - set limit bio size flag
+ * @q: the request queue for the device
+ * @limit: limit bio size on(true), or off
+ *
+ * bio max size will be limited to queue max sectors size,
+ * if limit is true.
+ */
+void blk_queue_set_limit_bio_size(struct request_queue *q, bool limit)
+{
+ if (limit)
+ blk_queue_flag_set(QUEUE_FLAG_LIMIT_BIO_SIZE, q);
+ else
+ blk_queue_flag_clear(QUEUE_FLAG_LIMIT_BIO_SIZE, q);
+}
+EXPORT_SYMBOL_GPL(blk_queue_set_limit_bio_size);
+
static int __init blk_settings_init(void)
{
blk_max_low_pfn = max_low_pfn - 1;
diff --git a/include/linux/bio.h b/include/linux/bio.h
index d0246c92a6e8..830c784967c0 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -119,7 +119,7 @@ static inline bool bio_full(struct bio *bio, unsigned len)
if (bio->bi_vcnt >= bio->bi_max_vecs)
return true;
- if
[PATCH v6 0/3] limit bio max size
I found a inefficient behavior from multipage bvec. Large chunk DIO scenario is that. This patch series could be a solution to improve it. Changheun Lee (3): bio: limit bio max size ufs: set QUEUE_FLAG_LIMIT_BIO_SIZE bio: add limit_bio_size sysfs Documentation/ABI/testing/sysfs-block | 10 ++ Documentation/block/queue-sysfs.rst | 7 +++ block/bio.c | 13 - block/blk-settings.c | 17 + block/blk-sysfs.c | 3 +++ drivers/scsi/scsi_lib.c | 2 ++ drivers/scsi/ufs/ufshcd.c | 1 + include/linux/bio.h | 2 +- include/linux/blkdev.h| 4 include/scsi/scsi_host.h | 2 ++ 10 files changed, 59 insertions(+), 2 deletions(-) -- 2.29.0
Re: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from pwm nodes rv1108.dtsi
On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker wrote: > > A test with the command below gives this error: > > /arch/arm/boot/dts/rv1108-evb.dt.yaml: > pwm@1028: 'interrupts' does not match any of the regexes: > 'pinctrl-[0-9]+' > > "interrupts" is an undocumented property, so remove them > from pwm nodes in rv1108.dtsi. > > make ARCH=arm dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml > > Signed-off-by: Johan Jonker Given that the interrupts were specified, meaning they are wired up in hardware, shouldn't the solution be to add the interrupts property to the binding instead? After all, the device tree describes the actual hardware, not just what the implementations need. ChenYu
Re: [Question] Is there a race window between swapoff vs synchronous swap_readpage
On 2021/3/30 15:27, Yu Zhao wrote: > On Tue, Mar 30, 2021 at 12:57 AM Huang, Ying wrote: >> >> Yu Zhao writes: >> >>> On Mon, Mar 29, 2021 at 9:44 PM Huang, Ying wrote: Miaohe Lin writes: > On 2021/3/30 9:57, Huang, Ying wrote: >> Hi, Miaohe, >> >> Miaohe Lin writes: >> >>> Hi all, >>> I am investigating the swap code, and I found the below possible race >>> window: >>> >>> CPU 1 CPU 2 >>> - - >>> do_swap_page >>> skip swapcache case (synchronous swap_readpage) >>> alloc_page_vma >>> swapoff >>> release >>> swap_file, bdev, or ... >>> swap_readpage >>> check sis->flags is ok >>> access swap_file, bdev or ...[oops!] >>> si->flags = 0 >>> >>> The swapcache case is ok because swapoff will wait on the page_lock of >>> swapcache page. >>> Is this will really happen or Am I miss something ? >>> Any reply would be really grateful. Thanks! :) >> >> This appears possible. Even for swapcache case, we can't guarantee the > > Many thanks for reply! > >> swap entry gotten from the page table is always valid too. The > > The page table may change at any time. And we may thus do some useless > work. > But the pte_same() check could handle these races correctly if these do > not > result in oops. > >> underlying swap device can be swapped off at the same time. So we use >> get/put_swap_device() for that. Maybe we need similar stuff here. > > Using get/put_swap_device() to guard against swapoff for swap_readpage() > sounds > really bad as swap_readpage() may take really long time. Also such race > may not be > really hurtful because swapoff is usually done when system shutdown only. > I can not figure some simple and stable stuff out to fix this. Any > suggestions or > could anyone help get rid of such race? Some reference counting on the swap device can prevent swap device from swapping-off. To reduce the performance overhead on the hot-path as much as possible, it appears we can use the percpu_ref. >>> >>> Hi, >>> >>> I've been seeing crashes when testing the latest kernels with >>> stress-ng --class vm -a 20 -t 600s --temp-path /tmp >>> >>> I haven't had time to look into them yet: >>> >>> DEBUG_VM: >>> BUG: unable to handle page fault for address: 905c33c9a000 >>> Call Trace: >>>get_swap_pages+0x278/0x590 >>>get_swap_page+0x1ab/0x280 >>>add_to_swap+0x7d/0x130 >>>shrink_page_list+0xf84/0x25f0 >>>reclaim_pages+0x313/0x430 >>>madvise_cold_or_pageout_pte_range+0x95c/0xaa0 >> >> If my understanding were correct, two bugs are reported? One above and >> one below? If so, and the above one is reported firstly. Can you share >> the full bug message reported in dmesg? > > No, they are from two different kernel configs. I saw the first crash > and didn't know what to look. So I turned on KASAN to see if it gives > more clue. Unfortunately I haven't had time to spend more time on it. > >> Can you convert the call trace to source line? And the commit of the >> kernel? Or the full kconfig? So I can build it by myself. > > It seems to be very reproducible if you enable these three options, on > 5.12, 5.11, 5.10 which is where I gave up trying. > >>> CONFIG_MEMCG_SWAP=y >>> CONFIG_THP_SWAP=y >>> CONFIG_ZSWAP=y > > I'll dig into the log and see if I could at least give you the line > numbers. Kernel config attached. Thanks! > Maybe we could try to fix this issue here with more detailed info. Thanks. > And the command line I used, which is nothing fancy: > >>> stress-ng --class vm -a 20 -t 600s --temp-path /tmp > >>> KASAN: >>> == >>> BUG: KASAN: slab-out-of-bounds in __frontswap_store+0xc9/0x2e0 >>> Read of size 8 at addr 88901f646f18 by task stress-ng-mrema/31329 >>> CPU: 2 PID: 31329 Comm: stress-ng-mrema Tainted: G SI L >>> 5.12.0-smp-DEV #2 >>> Call Trace: >>>dump_stack+0xff/0x165 >>>print_address_description+0x81/0x390 >>>__kasan_report+0x154/0x1b0 >>>? __frontswap_store+0xc9/0x2e0 >>>? __frontswap_store+0xc9/0x2e0 >>>kasan_report+0x47/0x60 >>>kasan_check_range+0x2f3/0x340 >>>__kasan_check_read+0x11/0x20 >>>__frontswap_store+0xc9/0x2e0 >>>swap_writepage+0x52/0x80 >>>pageout+0x489/0x7f0 >>>shrink_page_list+0x1b11/0x2c90 >>>reclaim_pages+0x6ca/0x930 >>>madvise_cold_or_pageout_pte_range+0x1260/0x13a0 >>> >>> Allocated by task 16813: >>>kasan_kmalloc+0xb0/0xe0 >>>
Re: [PATCH] mm/frontswap: fix frontswap_register_ops() race with swapon and swapoff
On 2021/4/11 4:02, Yu Zhao wrote:
> On Sat, Apr 10, 2021 at 5:01 AM Miaohe Lin wrote:
>>
>> On 2021/4/10 18:42, Yu Zhao wrote:
>>> On Sat, Apr 10, 2021 at 1:30 AM Miaohe Lin wrote:
Hi:
On 2021/4/5 18:20, Miaohe Lin wrote:
> frontswap_register_ops can race with swapon. Consider the following scene:
Any comment or suggestion? Or is this race window too theoretical to fix?
Thanks.
>>>
>>> Let me run a stress test and get back to you (within a day or so).
>>
>> That's very kind of you. Many thanks!
>
> I'm still getting the following crash. Probably I should try the other
> series you sent earlier too?
>
> BUG: unable to handle page fault for address: aa7937d82000
> RIP: 0010:scan_swap_map_slots+0x12b/0x7f0
> Call Trace:
> get_swap_pages+0x278/0x590
>get_swap_page+0x1ab/0x280
>add_to_swap+0x7d/0x130
>shrink_page_list+0xf84/0x25f0
>reclaim_pages+0x313/0x430
> madvise_cold_or_pageout_pte_range+0x95c/0xaa0
>walk_p4d_range+0x43f/0x790
>walk_pgd_range+0xf1/0x150
>__walk_page_range+0x6f/0x1b0
>walk_page_range+0xbe/0x1e
>do_madvise+0x271/0x720
Sorry about it! This patch is fix the frontswap_register_ops() race with
swapon/swapoff.
And the earlier patch is fix the race I found when I was investigating the swap
code. So
this crash may not be included.
>
> CPU1 CPU2
>
> frontswap_register_ops
> fill bitmap a
> ops->init
> sys_swapon
> enable_swap_info
> frontswap_init without new ops
> add ops to frontswap_ops list
> check if swap_active_head changed
> add to swap_active_head
>
> So the frontswap_ops init is missed on the new swap device. Consider the
> another scene:
> CPU1CPU2
>
> frontswap_register_ops
> fill bitmap a
> ops->init
> add ops to frontswap_ops list
> sys_swapon
> enable_swap_info
> frontswap_init with new ops
> add to swap_active_head
> check if swap_active_head changed
> ops->init for new swap device [twice!]
>
> The frontswap_ops init will be called two times on the new swap device
> this
> time. frontswap_register_ops can also race with swapoff. Consider the
> following scene:
>
> CPU1CPU2
>
> sys_swapoff
> removed from swap_active_head
> frontswap_register_ops
> fill bitmap a
> ops->init without swap device
> add ops to frontswap_ops list
> invalidate_area with new ops
> check if swap_active_head changed
>
> We could call invalidate_area on a swap device under swapoff with
> frontswap
> is uninitialized yet. Fix all these by using swapon_mutex to guard against
> race with swapon and add swap_info_get_if_under_swapoff() to collect swap
> devices under swapoff.
>
> Fixes: d1dc6f1bcf1e ("frontswap: allow multiple backends")
> Signed-off-by: Miaohe Lin
> ---
> include/linux/swapfile.h | 2 ++
> mm/frontswap.c | 40 +---
> mm/swapfile.c| 13 -
> 3 files changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/swapfile.h b/include/linux/swapfile.h
> index e06febf62978..7ae15d917828 100644
> --- a/include/linux/swapfile.h
> +++ b/include/linux/swapfile.h
> @@ -9,8 +9,10 @@
> extern spinlock_t swap_lock;
> extern struct plist_head swap_active_head;
> extern struct swap_info_struct *swap_info[];
> +extern struct mutex swapon_mutex;
> extern int try_to_unuse(unsigned int, bool, unsigned long);
> extern unsigned long generic_max_swapfile_size(void);
> extern unsigned long max_swapfile_size(void);
> +extern struct swap_info_struct *swap_info_get_if_under_swapoff(int type);
>
> #endif /* _LINUX_SWAPFILE_H */
> diff --git a/mm/frontswap.c b/mm/frontswap.c
> index 130e301c5ac0..c16bfc7550b5 100644
> --- a/mm/frontswap.c
> +++ b/mm/frontswap.c
> @@ -123,12 +123,26 @@ void frontswap_register_ops(struct frontswap_ops
> *ops)
>
> bitmap_zero(a, MAX_SWAPFILES);
> bitmap_zero(b, MAX_SWAPFILES);
> -
> + mutex_lock(_mutex);
> spin_lock(_lock);
>
[PATCH v2] nfc: pn533: remove redundant assignment
From: wengjianfeng
In many places,first assign a value to a variable and then return
the variable. which is redundant, we should directly return the value.
in pn533_rf_field funciton,return rc also in the if statement, so we
use return 0 to replace the last return rc.
Signed-off-by: wengjianfeng
---
drivers/nfc/pn533/i2c.c | 8 ++--
drivers/nfc/pn533/pn533.c | 17 -
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 0207e66..795da9b 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -40,11 +40,8 @@ static int pn533_i2c_send_ack(struct pn533 *dev, gfp_t flags)
struct i2c_client *client = phy->i2c_dev;
static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
/* spec 6.2.1.3: Preamble, SoPC (2), ACK Code (2), Postamble */
- int rc;
-
- rc = i2c_master_send(client, ack, 6);
- return rc;
+ return i2c_master_send(client, ack, 6);
}
static int pn533_i2c_send_frame(struct pn533 *dev,
@@ -199,8 +196,7 @@ static int pn533_i2c_probe(struct i2c_client *client,
>i2c_dev->dev);
if (IS_ERR(priv)) {
- r = PTR_ERR(priv);
- return r;
+ return PTR_ERR(priv);
}
phy->priv = priv;
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index f1469ac..e196732 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -489,12 +489,8 @@ static int pn533_send_data_async(struct pn533 *dev, u8
cmd_code,
pn533_send_async_complete_t complete_cb,
void *complete_cb_context)
{
- int rc;
-
- rc = __pn533_send_async(dev, cmd_code, req, complete_cb,
+ return __pn533_send_async(dev, cmd_code, req, complete_cb,
complete_cb_context);
-
- return rc;
}
static int pn533_send_cmd_async(struct pn533 *dev, u8 cmd_code,
@@ -502,12 +498,8 @@ static int pn533_send_cmd_async(struct pn533 *dev, u8
cmd_code,
pn533_send_async_complete_t complete_cb,
void *complete_cb_context)
{
- int rc;
-
- rc = __pn533_send_async(dev, cmd_code, req, complete_cb,
+ return __pn533_send_async(dev, cmd_code, req, complete_cb,
complete_cb_context);
-
- return rc;
}
/*
@@ -2617,7 +2609,7 @@ static int pn533_rf_field(struct nfc_dev *nfc_dev, u8 rf)
return rc;
}
- return rc;
+ return 0;
}
static int pn532_sam_configuration(struct nfc_dev *nfc_dev)
@@ -2791,7 +2783,6 @@ struct pn533 *pn53x_common_init(u32 device_type,
struct device *dev)
{
struct pn533 *priv;
- int rc = -ENOMEM;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -2833,7 +2824,7 @@ struct pn533 *pn53x_common_init(u32 device_type,
error:
kfree(priv);
- return ERR_PTR(rc);
+ return ERR_PTR(-ENOMEM);
}
EXPORT_SYMBOL_GPL(pn53x_common_init);
--
1.9.1
Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hi, On Sat, Apr 10, 2021 at 08:52:22PM +0200, Uwe Kleine-König wrote: > Hello, > > one more comment: > > On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote: > > +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_chip > > *chip) > > all functions but this one start have the common prefix "visconti_pwm_". > I like the concept of a common prefix and so you could rename this > function to visconti_pwm_from_chip or similar. OK, I will change. > > Best regards > Uwe > Best regards, Nobuhiro
[PATCH] scsi: 3w-9xxx: remove useless variable
Fix the following gcc warning:
drivers/scsi/3w-9xxx.c:942:24: warning: variable ‘response_que_value’
set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/scsi/3w-9xxx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index b96e82d..1856a99 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -939,13 +939,13 @@ static int twa_decode_bits(TW_Device_Extension *tw_dev,
u32 status_reg_value)
/* This function will empty the response queue */
static int twa_empty_response_queue(TW_Device_Extension *tw_dev)
{
- u32 status_reg_value, response_que_value;
+ u32 status_reg_value;
int count = 0, retval = 1;
status_reg_value = readl(TW_STATUS_REG_ADDR(tw_dev));
while (((status_reg_value & TW_STATUS_RESPONSE_QUEUE_EMPTY) == 0) &&
(count < TW_MAX_RESPONSE_DRAIN)) {
- response_que_value = readl(TW_RESPONSE_QUEUE_REG_ADDR(tw_dev));
+ readl(TW_RESPONSE_QUEUE_REG_ADDR(tw_dev));
status_reg_value = readl(TW_STATUS_REG_ADDR(tw_dev));
count++;
}
--
1.8.3.1
Re: [PATCH] MIPS: Fix strnlen_user access check
On 04/11/2021 07:04 PM, Jinyang He wrote:
Commit 04324f44cb69 ("MIPS: Remove get_fs/set_fs") brought a problem for
strnlen_user(). Jump out when checking access_ok() with condition that
(s + strlen(s)) < __UA_LIMIT <= (s + n). The old __strnlen_user_asm()
just checked (ua_limit & s) without checking (ua_limit & (s + n)).
Therefore, find strlen form s to __UA_LIMIT - 1 in that condition.
Signed-off-by: Jinyang He
---
arch/mips/include/asm/uaccess.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
index 91bc7fb..85ba0c8 100644
--- a/arch/mips/include/asm/uaccess.h
+++ b/arch/mips/include/asm/uaccess.h
@@ -630,8 +630,15 @@ static inline long strnlen_user(const char __user *s, long
n)
{
long res;
- if (!access_ok(s, n))
- return -0;
+ if (unlikely(n <= 0))
+ return 0;
+
+ if (!access_ok(s, n)) {
+ if (!access_ok(s, 0))
+ return 0;
+
+ n = __UA_LIMIT - (unsigned long)s - 1;
+ }
might_fault();
__asm__ __volatile__(
The following simple changes are OK to fix this issue?
diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
index 91bc7fb..eafc99b 100644
--- a/arch/mips/include/asm/uaccess.h
+++ b/arch/mips/include/asm/uaccess.h
@@ -630,8 +630,8 @@ static inline long strnlen_user(const char __user *s, long
n)
{
long res;
- if (!access_ok(s, n))
- return -0;
+ if (!access_ok(s, 1))
+ return 0;
might_fault();
__asm__ __volatile__(
Thanks,
Tiezhu
Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hi Uwe,
Thanks for your review.
On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> just a few small details left to criticize ...
>
> On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > new file mode 100644
> > index ..99d83f94ed86
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-visconti.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Toshiba Visconti pulse-width-modulation controller driver
> > + *
> > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> > + *
> > + * Authors: Nobuhiro Iwamatsu
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> > +
> > +#define PIPGM_PWMC_PWMACT BIT(5)
> > +#define PIPGM_PWMC_CLK_MASKGENMASK(1, 0)
> > +#define PIPGM_PWMC_POLARITY_MASK GENMASK(5, 5)
> > +
> > +struct visconti_pwm_chip {
> > + struct pwm_chip chip;
> > + void __iomem *base;
> > +};
> > +
> > +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_chip
> > *chip)
> > +{
> > + return container_of(chip, struct visconti_pwm_chip, chip);
> > +}
> > +
> > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device
> > *pwm,
> > + const struct pwm_state *state)
> > +{
> > + struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > + u32 period, duty_cycle, pwmc0;
> > +
> > + /*
> > +* pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > +* When the settings of the PWM are modified, the new values are
> > shadowed in hardware until
> > +* the period register (PCSR) is written and the currently running
> > period is completed. This
> > +* way the hardware switches atomically from the old setting to the new.
> > +* Also, disabling the hardware completes the currently running period
> > and keeps the output
> > +* at low level at all times.
>
> Can you please put a paragraph analogous to the one in pwm-sifive in the
> same format. This simplified keeping an overview about the oddities of
> the various supported chips.
OK, I will check pwm-sifive's, and add.
>
> > +*/
> > + if (!state->enabled) {
> > + writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > + return 0;
> > + }
> > +
> > [...]
> > +
> > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct
> > pwm_device *pwm,
> > + struct pwm_state *state)
> > +{
> > + struct visconti_pwm_chip *priv = chip_to_priv(chip);
> > + u32 period, duty, pwmc0, pwmc0_clk;
> > +
> > + period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> > + if (period)
> > + state->enabled = true;
> > + else
> > + state->enabled = false;
>
> If PIPGM_PCSR is 0 the hardware is still active and setting a new
> configuration completes the currently running period, right? Then I
> think having always state->enabled = true is a better match.
>
If PIPGM_PCSR is 0, the hardware is stopped. Even if the settings of
other registers are written, the values of other registers will not work
unless PIPGM_PCSR is written.
However, as a logic, if PIPGM_PCSR becomes 0, it is only
visconti_pwm_apply () in this driver,
so I think that this process should always be state-> enabled = true
as you pointed out.
I wil drop this, thanks.
> > + duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
> > + pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
> > + pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
> > +
> > + state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
> > + state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
> > + if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
> > + state->polarity = PWM_POLARITY_INVERSED;
> > + else
> > + state->polarity = PWM_POLARITY_NORMAL;
> > +}
> > +
> > [...]
> > +
> > +static int visconti_pwm_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > + struct visconti_pwm_chip *priv;
> > + int ret;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + priv->chip.dev = dev;
> > + priv->chip.ops = _pwm_ops;
> > + priv->chip.npwm = 4;
> > +
> > + ret = pwmchip_add(>chip);
> > + if (ret < 0)
> > + return dev_err_probe(>dev, ret, "Cannot register visconti
> > PWM\n");
>
> Thierry told to have picked up my patch to add the function
> devm_pwmchip_add. I just double checked
[PATCH] staging: emxx_udc: remove useless variable
Fix the following gcc warning: vers/staging/emxx_udc/emxx_udc.c:41:19: warning: ‘driver_desc’ defined but not used [-Wunused-const-variable=]. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/staging/emxx_udc/emxx_udc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c index 3536c03..741147a 100644 --- a/drivers/staging/emxx_udc/emxx_udc.c +++ b/drivers/staging/emxx_udc/emxx_udc.c @@ -38,7 +38,6 @@ static int vbus_irq; static const char driver_name[] = "emxx_udc"; -static const char driver_desc[] = DRIVER_DESC; /*===*/ /* Prototype */ -- 1.8.3.1
Re: [PATCH v3 12/27] perf parse-events: Support no alias assigned event inside hybrid PMU
Hi Jiri,
On 4/9/2021 9:47 PM, Jiri Olsa wrote:
On Mon, Mar 29, 2021 at 03:00:31PM +0800, Jin Yao wrote:
SNIP
+ struct parse_events_state *parse_state)
{
struct perf_event_attr attr;
LIST_HEAD(config_terms);
@@ -521,7 +526,7 @@ int parse_events_add_cache(struct list_head *list, int *idx,
i = parse_events__add_cache_hybrid(list, idx, ,
config_name ? : name, _terms,
- );
+ , parse_state);
if (hybrid)
return i;
@@ -1481,7 +1486,7 @@ int parse_events_add_pmu(struct parse_events_state *parse_state,
struct perf_pmu *pmu;
struct evsel *evsel;
struct parse_events_error *err = parse_state->error;
- bool use_uncore_alias;
+ bool use_uncore_alias, found = false;
LIST_HEAD(config_terms);
if (verbose > 1) {
@@ -1530,8 +1535,28 @@ int parse_events_add_pmu(struct parse_events_state
*parse_state,
}
}
- if (!parse_state->fake_pmu && perf_pmu__check_alias(pmu, head_config, ))
+ if (!parse_state->fake_pmu &&
+ perf_pmu__check_alias(pmu, head_config, , )) {
return -EINVAL;
+ }
+
ok, let's not polute surronding functions and make strict check
on what we want in here.. we are after following events:
cpu_xxx/L1-dcache/
cpu_xxx/l1-d|/
...
right?
Yes, we only focus on the cache events now.
so we are after events with single term in head_config that has name in:
L1-dcache|l1-d|l1d|L1-data |
L1-icache|l1-i|l1i|L1-instruction |
LLC|L2 |
dTLB|d-tlb|Data-TLB |
iTLB|i-tlb|Instruction-TLB |
branch|branches|bpu|btb|bpc |
node
I think that with such direct check the code will be more straight
forward, also let's move it to parse-events-hybrid
Do you suggest we just use string comparison for doing the direct check?
e.g.
if (strstr(term->config, "L1-dcache"))
...
Of course, we can define a string array first and use a loop for string
comparison.
+ if (!parse_state->fake_pmu && head_config && !found &&
+ perf_pmu__is_hybrid(name)) {
+ struct parse_events_term *term;
+ int ret;
+
+ list_for_each_entry(term, head_config, list) {
+ if (!term->config)
+ continue;
+
+ ret = parse_events__with_hybrid_pmu(parse_state,
+ term->config,
+ name, ,
+ list);
do we need to call the parsing again? could we just call
parse_events__add_cache_hybrid?
jirka
If we do the direct check for cache events, I think we don't need the parsing
again.
As I mentioned above, we need to define a string array and compare with
term->config one by one.
I'm OK for this solution. :)
Thanks
Jin Yao
+ if (found)
+ return ret;
+ }
+ }
if (verbose > 1) {
fprintf(stderr, "After aliases, add event pmu '%s' with '",
@@ -1605,6 +1630,15 @@ int parse_events_multi_pmu_add(struct parse_events_state
*parse_state,
struct perf_pmu *pmu = NULL;
int ok = 0;
SNIP
[PATCH] vfio/iommu_type1: Remove unused pinned_page_dirty_scope in vfio_iommu
pinned_page_dirty_scope is optimized out by commit 010321565a7d
("vfio/iommu_type1: Mantain a counter for non_pinned_groups"),
but appears again due to some issues during merging branches.
We can safely remove it here.
Signed-off-by: Keqian Zhu
---
However, I'm not clear about the root problem. Is there a bug in git?
---
drivers/vfio/vfio_iommu_type1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45cbfd4879a5..4d1f10a33d74 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -77,7 +77,6 @@ struct vfio_iommu {
boolv2;
boolnesting;
booldirty_page_tracking;
- boolpinned_page_dirty_scope;
boolcontainer_open;
};
--
2.19.1
Re: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
On Sun, Apr 11, 2021 at 09:20:59PM CDT, Joel Stanley wrote:
On Mon, 12 Apr 2021 at 02:16, Andrew Jeffery wrote:
On Thu, 1 Apr 2021, at 15:12, Zev Weiss wrote:
> + {
> + status = "okay";
> + aspeed,sirq-active-high;
This should probably go away, but otherwise,
Zev, this has already been merged (both to mainline for v5.13 and in
openbmc), so any fixups need to come as patches on top of the existing
code.
Got it, thanks -- I figured I'd wait until the DT-properties patches got
approved & merged (I'll be sending v6 of that shortly) and then send an
incremental update for the e3c246d4i dts to match the final form of
those.
Zev
Re: linux-next: Tree for Apr 9 (x86 boot problem)
On 4/9/21 4:51 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210408: > Hi, I cannot boot linux-next 20210408 nor 20210409 on an antique x86_64 laptop (Toshiba Portege). After many failed tests, I finally resorted to git bisect, which led me to: git bisect start # good: [e49d033bddf5b565044e2abe4241353959bc9120] Linux 5.12-rc6 git bisect good e49d033bddf5b565044e2abe4241353959bc9120 # bad: [e99d8a8495175df8cb8b739f8cf9b0fc9d0cd3b5] Add linux-next specific files for 20210409 git bisect bad e99d8a8495175df8cb8b739f8cf9b0fc9d0cd3b5 # good: [24c5f79572740c1744a7ec2e9e21b541acab6de3] Merge remote-tracking branch 'crypto/master' git bisect good 24c5f79572740c1744a7ec2e9e21b541acab6de3 # bad: [4b90473874c7b6af320b9815f82ac305fd8807f7] Merge remote-tracking branch 'ftrace/for-next' git bisect bad 4b90473874c7b6af320b9815f82ac305fd8807f7 # good: [9cf3382276b26848891c7e072db0a774fadd10e4] Merge remote-tracking branch 'sound/for-next' git bisect good 9cf3382276b26848891c7e072db0a774fadd10e4 # good: [f8d16164c586548d7ccedc058ca9ae547e0cebbe] Merge remote-tracking branch 'mmc/next' git bisect good f8d16164c586548d7ccedc058ca9ae547e0cebbe # good: [761ab817c8710fd601d90bfc5179b0f83b1424bb] Merge remote-tracking branch 'devicetree/for-next' git bisect good 761ab817c8710fd601d90bfc5179b0f83b1424bb # bad: [9ed0086faca0aefcc429a219ab1bd80654093937] Merge branch 'objtool/core' git bisect bad 9ed0086faca0aefcc429a219ab1bd80654093937 # good: [4abeb983d38461f36b0aefa909d8b420c60b05be] Merge branch 'x86/core' git bisect good 4abeb983d38461f36b0aefa909d8b420c60b05be # bad: [6842a3ece3b7c0d558b6664dd6bf19b9ec4fc526] Merge branch 'timers/core' git bisect bad 6842a3ece3b7c0d558b6664dd6bf19b9ec4fc526 # bad: [5247390b761f1f9e255a59123ffab302a83a581b] Merge branch 'x86/boot' git bisect bad 5247390b761f1f9e255a59123ffab302a83a581b # good: [7dfe553affd0d003c7535b7ba60d09193471ea9d] x86/syscalls: Fix -Wmissing-prototypes warnings from COND_SYSCALL() git bisect good 7dfe553affd0d003c7535b7ba60d09193471ea9d # good: [fda215642945f0b128e91c24c9b90c567f008887] Merge branch 'x86/build' git bisect good fda215642945f0b128e91c24c9b90c567f008887 # good: [e14cfb3bdd0f82147d09e9f46bedda6302f28ee1] x86/boot/compressed: Avoid gcc-11 -Wstringop-overread warning git bisect good e14cfb3bdd0f82147d09e9f46bedda6302f28ee1 # bad: [4c674481dcf9974834b96622fa4b079c176f36f9] x86/setup: Merge several reservations of start of memory git bisect bad 4c674481dcf9974834b96622fa4b079c176f36f9 I reverted both of these patches and the laptop boots successfully: commit a799c2bd29d19c565f37fa038b31a0a1d44d0e4d Author: Mike Rapoport Date: Tue Mar 2 12:04:05 2021 +0200 x86/setup: Consolidate early memory reservations && commit 4c674481dcf9974834b96622fa4b079c176f36f9 Author: Mike Rapoport Date: Tue Mar 2 12:04:06 2021 +0200 x86/setup: Merge several reservations of start of memory There is no (zero, nil) console display when I try to boot next 0408 or 0409. I connected a USB serial debug cable and booted with earlyprintk=dbgp,keep and still got nothing. The attached boot log is linux-next 20210409 minus the 2 patches listed above. Mike- what data would you like to see? -- ~Randy Reported-by: Randy Dunlap boot0409-2.log.gz Description: application/gzip
Re: [PATCH v5 0/6] Add SiFive FU740 PCIe host controller driver support
Lorenzo Pieralisi 於 2021年4月9日 週五 下午4:54寫道： > > On Tue, 6 Apr 2021 17:26:28 +0800, Greentime Hu wrote: > > This patchset includes SiFive FU740 PCIe host controller driver. We also > > add pcie_aux clock and pcie_power_on_reset controller to prci driver for > > PCIe driver to use it. > > > > This is tested with e1000e: Intel(R) PRO/1000 Network Card, AMD Radeon R5 > > 230 graphics card and SP M.2 PCIe Gen 3 SSD in SiFive Unmatched based on > > v5.11 Linux kernel. > > > > [...] > > Applied to pci/dwc [dropped patch 6], thanks! > > [1/6] clk: sifive: Add pcie_aux clock in prci driver for PCIe driver > https://git.kernel.org/lpieralisi/pci/c/f3ce593b1a > [2/6] clk: sifive: Use reset-simple in prci driver for PCIe driver > https://git.kernel.org/lpieralisi/pci/c/0a78fcfd3d > [3/6] MAINTAINERS: Add maintainers for SiFive FU740 PCIe driver > https://git.kernel.org/lpieralisi/pci/c/8bb1c66a90 > [4/6] dt-bindings: PCI: Add SiFive FU740 PCIe host controller > https://git.kernel.org/lpieralisi/pci/c/b86d55c107 > [5/6] PCI: fu740: Add SiFive FU740 PCIe host controller driver > https://git.kernel.org/lpieralisi/pci/c/327c333a79 > > Thanks, > Lorenzo Hi Palmer, Since the PCIE driver has been applied, would you please pick patch 6 to RISC-V for-next tree? Thank you. :)
Re: linux-next: Signed-off-by missing for commit in the block tree
On 4/11/21 8:26 PM, Sowjanya Komatineni wrote:
>
> On 4/11/21 7:14 PM, Jens Axboe wrote:
>> On 4/11/21 4:34 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Commit
>>>
>>>6fa6517fe62e ("ata: ahci_tegra: call tegra_powergate_power_off only when
>>> PM domain is not present")
>>>
>>> is missing a Signed-off-by from its author.
>> Sowjana, please reply that you're OK with me adding your Signed-off-by to
>> that
>> patch.
>>
> Sorry I should have checked that. Thanks Jens. Sure I am OK with it.
Added, thanks.
--
Jens Axboe
Re: linux-next: Signed-off-by missing for commit in the block tree
On 4/11/21 7:14 PM, Jens Axboe wrote:
On 4/11/21 4:34 PM, Stephen Rothwell wrote:
Hi all,
Commit
6fa6517fe62e ("ata: ahci_tegra: call tegra_powergate_power_off only when PM
domain is not present")
is missing a Signed-off-by from its author.
Sowjana, please reply that you're OK with me adding your Signed-off-by to that
patch.
Sorry I should have checked that. Thanks Jens. Sure I am OK with it.
Thank you
Sowjanya
linux-next: manual merge of the vfs tree with the xfs tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/xfs/xfs_ioctl.c
between commits:
ceaf603c7024 ("xfs: move the di_projid field to struct xfs_inode")
031474c28a3a ("xfs: move the di_extsize field to struct xfs_inode")
b33ce57d3e61 ("xfs: move the di_cowextsize field to struct xfs_inode")
4800887b4574 ("xfs: cleanup xfs_fill_fsxattr")
ee7b83fd365e ("xfs: use a union for i_cowextsize and i_flushiter")
db07349da2f5 ("xfs: move the di_flags field to struct xfs_inode")
3e09ab8fdc4d ("xfs: move the di_flags2 field to struct xfs_inode")
from the xfs tree and commit:
280cad4ac884 ("xfs: convert to fileattr")
from the vfs tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/xfs/xfs_ioctl.c
index 708b77341a70,bbda105a2ce5..
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@@ -1056,76 -1057,16 +1057,18 @@@ xfs_ioc_ag_geometry
static void
xfs_fill_fsxattr(
struct xfs_inode*ip,
- boolattr,
- struct fsxattr *fa)
+ int whichfork,
+ struct fileattr *fa)
{
+ struct xfs_mount*mp = ip->i_mount;
- struct xfs_ifork*ifp = attr ? ip->i_afp : >i_df;
+ struct xfs_ifork*ifp = XFS_IFORK_PTR(ip, whichfork);
- simple_fill_fsxattr(fa, xfs_ip2xflags(ip));
+ fileattr_fill_xflags(fa, xfs_ip2xflags(ip));
- fa->fsx_extsize = ip->i_d.di_extsize << ip->i_mount->m_sb.sb_blocklog;
- fa->fsx_cowextsize = ip->i_d.di_cowextsize <<
- ip->i_mount->m_sb.sb_blocklog;
- fa->fsx_projid = ip->i_d.di_projid;
+
+ fa->fsx_extsize = XFS_FSB_TO_B(mp, ip->i_extsize);
+ if (ip->i_diflags2 & XFS_DIFLAG2_COWEXTSIZE)
+ fa->fsx_cowextsize = XFS_FSB_TO_B(mp, ip->i_cowextsize);
+ fa->fsx_projid = ip->i_projid;
if (ifp && (ifp->if_flags & XFS_IFEXTENTS))
fa->fsx_nextents = xfs_iext_count(ifp);
else
@@@ -1212,10 -1167,10 +1169,10 @@@ static in
xfs_ioctl_setattr_xflags(
struct xfs_trans*tp,
struct xfs_inode*ip,
- struct fsxattr *fa)
+ struct fileattr *fa)
{
struct xfs_mount*mp = ip->i_mount;
- uint64_tdi_flags2;
+ uint64_ti_flags2;
/* Can't change realtime flag if any extents are allocated. */
if ((ip->i_df.if_nextents || ip->i_delayed_blks) &&
@@@ -1348,8 -1289,11 +1291,11 @@@ xfs_ioctl_setattr_check_extsize
xfs_extlen_tsize;
xfs_fsblock_t extsize_fsb;
+ if (!fa->fsx_valid)
+ return 0;
+
if (S_ISREG(VFS_I(ip)->i_mode) && ip->i_df.if_nextents &&
- ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != fa->fsx_extsize))
+ ((ip->i_extsize << mp->m_sb.sb_blocklog) != fa->fsx_extsize))
return -EINVAL;
if (fa->fsx_extsize == 0)
@@@ -1520,18 -1476,18 +1478,19 @@@ xfs_fileattr_set
* extent size hint should be set on the inode. If no extent size flags
* are set on the inode then unconditionally clear the extent size hint.
*/
- if (ip->i_d.di_flags & (XFS_DIFLAG_EXTSIZE | XFS_DIFLAG_EXTSZINHERIT))
- ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog;
- else
- ip->i_d.di_extsize = 0;
- if (xfs_sb_version_has_v3inode(>m_sb) &&
- (ip->i_d.di_flags2 & XFS_DIFLAG2_COWEXTSIZE))
- ip->i_d.di_cowextsize = fa->fsx_cowextsize >>
- mp->m_sb.sb_blocklog;
+ if (ip->i_diflags & (XFS_DIFLAG_EXTSIZE | XFS_DIFLAG_EXTSZINHERIT))
+ ip->i_extsize = XFS_B_TO_FSB(mp, fa->fsx_extsize);
else
- ip->i_d.di_cowextsize = 0;
+ ip->i_extsize = 0;
+
+ if (xfs_sb_version_has_v3inode(>m_sb)) {
+ if (ip->i_diflags2 & XFS_DIFLAG2_COWEXTSIZE)
+ ip->i_cowextsize = XFS_B_TO_FSB(mp, fa->fsx_cowextsize);
+ else
+ ip->i_cowextsize = 0;
+ }
+ skip_xattr:
error = xfs_trans_commit(tp);
/*
pgplfd4mMyBsv.pgp
Description: OpenPGP digital signature
Re: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
On Mon, 12 Apr 2021 at 02:16, Andrew Jeffery wrote:
> On Thu, 1 Apr 2021, at 15:12, Zev Weiss wrote:
> > + {
> > + status = "okay";
> > + aspeed,sirq-active-high;
>
> This should probably go away, but otherwise,
Zev, this has already been merged (both to mainline for v5.13 and in
openbmc), so any fixups need to come as patches on top of the existing
code.
Cheers,
Joel
Re: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
On Thu, 1 Apr 2021, at 15:12, Zev Weiss wrote:
> This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
> mini-ITX board that we hope can provide a decent platform for OpenBMC
> development.
>
> This initial device-tree provides the necessary configuration for
> basic BMC functionality such as host power control, serial console and
> KVM support, and POST code snooping.
>
> Signed-off-by: Zev Weiss
> Reviewed-by: Joel Stanley
> ---
>
> Changes since v2:
> - un-bungled filename in dtb-$(CONFIG_ARCH_ASPEED)
> Changes since v1:
> - added entry to dtb-$(CONFIG_ARCH_ASPEED)
> - added board to compatible
> - added pinctrl properties to adc
> - split out of mostly-unrelated patch series
>
> arch/arm/boot/dts/Makefile| 1 +
> .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 202 ++
> 2 files changed, 203 insertions(+)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e75e..c22151b50ddc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1406,6 +1406,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-ampere-mtjade.dtb \
> aspeed-bmc-arm-centriq2400-rep.dtb \
> aspeed-bmc-arm-stardragon4800-rep2.dtb \
> + aspeed-bmc-asrock-e3c246d4i.dtb \
> aspeed-bmc-bytedance-g220a.dtb \
> aspeed-bmc-facebook-cmm.dtb \
> aspeed-bmc-facebook-galaxy100.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> new file mode 100644
> index ..dcab6e78dfa4
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include
> +#include
> +
> +/{
> + model = "ASRock E3C246D4I BMC";
> + compatible = "asrock,e3c246d4i-bmc", "aspeed,ast2500";
> +
> + aliases {
> + serial4 =
> + };
> +
> + chosen {
> + stdout-path =
> + bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + heartbeat {
> + /* BMC_HB_LED_N */
> + gpios = < ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "timer";
> + };
> +
> + system-fault {
> + /* SYSTEM_FAULT_LED_N */
> + gpios = < ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + panic-indicator;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + uid-button {
> + label = "uid-button";
> + gpios = < ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = < 0>, < 1>, < 2>, < 3>, < 4>,
> + < 5>, < 6>, < 7>, < 8>, < 9>,
> + < 10>, < 11>, < 12>;
> + };
> +};
> +
> + {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + m25p,fast-read;
> + label = "bmc";
> + spi-max-frequency = <1>; /* 100 MHz */
> +#include "openbmc-flash-layout.dtsi"
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + aspeed,sirq-active-high;
This should probably go away, but otherwise,
Reviewed-by: Andrew Jeffery
[PATCH] gpio: mxs: remove useless function
Fix the following gcc warning:
drivers/gpio/gpio-mxs.c:63:19: warning: kernel/sys_ni.cunused function
'is_imx28_gpio'.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpio/gpio-mxs.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
index dfc0c1e..524b668 100644
--- a/drivers/gpio/gpio-mxs.c
+++ b/drivers/gpio/gpio-mxs.c
@@ -60,11 +60,6 @@ static inline int is_imx23_gpio(struct mxs_gpio_port *port)
return port->devid == IMX23_GPIO;
}
-static inline int is_imx28_gpio(struct mxs_gpio_port *port)
-{
- return port->devid == IMX28_GPIO;
-}
-
/* Note: This driver assumes 32 GPIOs are handled in one register */
static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
--
1.8.3.1
Re: BUG: unable to handle kernel paging request in __build_skb
On Sun, Apr 11, 2021 at 9:31 PM Hao Sun wrote: > > Hi > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > the Linux kernel, I found the following bug report, but I'm not sure > about this. > Sorry, I do not have a reproducing program for this bug. > I hope that the stack trace information in the crash log can help you > locate the problem. > > Here is the details: > commit: 4ebaab5fb428374552175aa39832abf5cedb916a > version: linux 5.12 > git tree:kmsan > > == > RAX: ffda RBX: 0059c080 RCX: 0047338d > RDX: 0010 RSI: 20002400 RDI: 0003 > RBP: 7fb6512c2c90 R08: R09: > R10: R11: 0246 R12: 0005 > R13: 7fffbb36285f R14: 7fffbb362a00 R15: 7fb6512c2dc0 > BUG: unable to handle page fault for address: a73d01c96a40 > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > PGD 1810067 P4D 1810067 PUD 1915067 PMD 4b84067 PTE 0 > Oops: 0002 [#1] SMP > CPU: 0 PID: 6273 Comm: syz-executor Not tainted 5.12.0-rc6+ #1 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.13.0-1ubuntu1.1 04/01/2014 > RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:64 > Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 > f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa > 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 > RSP: 0018:9f3d01c9b930 EFLAGS: 00010082 > RAX: a73d01c96a00 RBX: 0020 RCX: 0020 > RDX: 0020 RSI: RDI: a73d01c96a40 > RBP: 9f3d01c9b960 R08: c239000f R09: a73d01c96a40 > R10: 7dee4e6b R11: b2000782 R12: > R13: 0020 R14: R15: 9f3d01c96a40 > FS: 7fb6512c3700() GS:97407fa0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: a73d01c96a40 CR3: 30087005 CR4: 00770ef0 > PKRU: 5554 > Call Trace: > kmsan_internal_unpoison_shadow+0x1d/0x70 mm/kmsan/kmsan.c:110 > __msan_memset+0x64/0xb0 mm/kmsan/kmsan_instr.c:130 > __build_skb_around net/core/skbuff.c:209 [inline] > __build_skb+0x34b/0x520 net/core/skbuff.c:243 > netlink_alloc_large_skb net/netlink/af_netlink.c:1193 [inline] > netlink_sendmsg+0xdc1/0x14d0 net/netlink/af_netlink.c:1902 > sock_sendmsg_nosec net/socket.c:654 [inline] > sock_sendmsg net/socket.c:674 [inline] I don't have an idea what might be up, but some context: This happens in __build_skb_around at memset(shinfo, 0, offsetof(struct skb_shared_info, dataref)); on vmalloc'd memory in netloc_alloc_large_skb: data = vmalloc(size); if (data == NULL) return NULL; skb = __build_skb(data, size);
Re: linux-next: Signed-off-by missing for commit in the block tree
On 4/11/21 4:34 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 6fa6517fe62e ("ata: ahci_tegra: call tegra_powergate_power_off only when PM
> domain is not present")
>
> is missing a Signed-off-by from its author.
Sowjana, please reply that you're OK with me adding your Signed-off-by to that
patch.
--
Jens Axboe
Re: [RFC] [PATCH] ipc/util.c: Use binary search for max_idx
On Wed, 07 Apr 2021, Manfred Spraul wrote:
If semctl(), msgctl() and shmctl() are called with IPC_INFO, SEM_INFO,
MSG_INFO or SHM_INFO, then the return value is the index of the highest
used entry in the kernel's internal array recording information about
all SysV objects of the requested type for the current namespace.
(This information can be used with repeated ..._STAT or ..._STAT_ANY
operations to obtain information about all SysV objects on the system.)
If the current highest used entry is destroyed, then the new highest
used entry is determined by looping over all possible values.
With the introduction of IPCMNI_EXTEND_SHIFT, this could be a
loop over 16 million entries.
So the lineal search, starting from the end of the range, won't suck
as long as there aren't big holes in the range from the max_idx to
the next max_idx, minimizing the amount of idr_find calls - this was
accepted as the cost of doing caching the max_idx for O(1) access.
Of course, when not the case, the binary search can save a lot of cycles,
and I agree it's overall better than trying to predict rmid patterns.
As there is no get_last() function for idr structures:
Implement a "get_last()" using a binary search.
Right, nor do I think there are any users that try to avoid the lookup
caching the value.
As far as I see, ipc is the only user that needs get_last(), thus
implement it in ipc/util.c and not in a central location.
I find your implementation to be both obscure and elegant :)
Some nit comments below, but I agree with the idea, with the observation
that the search will always do the worst case amount of logN loops, even
when the retval is found (in which normal implementations would just
break out of the looping).
Acked-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/util.c | 44 +++-
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index cfa0045e748d..0121bf6b2617 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
@@ -450,6 +451,40 @@ static void ipc_kht_remove(struct ipc_ids *ids, struct
kern_ipc_perm *ipcp)
ipc_kht_params);
}
+/**
+ * ipc_get_maxusedidx - get highest in-use index
+ * @ids: ipc identifier set
+ * @limit: highest possible index.
+ *
+ * The function determines the highest in use index value.
+ * ipc_ids.rwsem needs to be owned by the caller.
+ * If no ipc object is allocated, then -1 is returned.
+ */
+static int ipc_get_maxusedidx(struct ipc_ids *ids, int limit)
+{
+ void *val;
+ int tmpidx;
+ int i;
+ int retval;
+
+ i = ilog2(limit+1);
+
+ retval = 0;
+ for (; i >= 0; i--) {
+ tmpidx = retval | (1max_idx == ipc_get_maxusedidx(10-1) == 9;
So this will loop from 1 << 3 to 1 << 0:
idr_get_next(7) == T ==> retval = 8
idr_get_next(11) == F
idr_get_next(9) == T ==> retval = 10
idr_get_next(10) == F
return 10 - 1; // good
And with holes, ie: 1 2 7 10, so RMID(10) should update next to 7:
ipc_get_maxusedidx(10-1) == 7
idr_get_next(7) == T ==> retval = 8
idr_get_next(11) == F
idr_get_next(9) == F
idr_get_next(8) == F
return 8 - 1; // good
+ retval--;
+ return retval;
Instead, just do?
return retval - 1;
+}
+
/**
* ipc_rmid - remove an ipc identifier
* @ids: ipc identifier set
@@ -468,11 +503,10 @@ void ipc_rmid(struct ipc_ids *ids, struct kern_ipc_perm
*ipcp)
ipcp->deleted = true;
if (unlikely(idx == ids->max_idx)) {
- do {
- idx--;
- if (idx == -1)
- break;
- } while (!idr_find(>ipcs_idr, idx));
+
+ idx = ids->max_idx-1;
+ if (idx >= 0)
+ idx = ipc_get_maxusedidx(ids, idx);
ids->max_idx = idx;
We already have ipc_get_maxidx(), so the naming here is a bit strange.
How about renaming ipc_get_maxusedidx() to ipc_get_nextidx() and let it
handle the whole logic, pass along the ids->max_id without decrementing?
if (unlikely(idx == ids->max_idx))
ids->max_idx = ipc_get_nextidx(ids->max_idx);
Thanks,
Davidlohr
Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support
On 4/11/2021 4:53 PM, Vladimir Oltean wrote: > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote: >> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >>> On Sat, 10 Apr 2021 15:34:46 +0200 >>> Ansuel Smith wrote: >>> Hi, this is a respin of the Marek series in hope that this time we can finally make some progress with dsa supporting multi-cpu port. This implementation is similar to the Marek series but with some tweaks. This adds support for multiple-cpu port but leave the driver the decision of the type of logic to use about assigning a CPU port to the various port. The driver can also provide no preference and the CPU port is decided using a round-robin way. >>> >>> In the last couple of months I have been giving some thought to this >>> problem, and came up with one important thing: if there are multiple >>> upstream ports, it would make a lot of sense to dynamically reallocate >>> them to each user port, based on which user port is actually used, and >>> at what speed. >>> >>> For example on Turris Omnia we have 2 CPU ports and 5 user ports. All >>> ports support at most 1 Gbps. Round-robin would assign: >>> CPU port 0 - Port 0 >>> CPU port 1 - Port 1 >>> CPU port 0 - Port 2 >>> CPU port 1 - Port 3 >>> CPU port 0 - Port 4 >>> >>> Now suppose that the user plugs ethernet cables only into ports 0 and 2, >>> with 1, 3 and 4 free: >>> CPU port 0 - Port 0 (plugged) >>> CPU port 1 - Port 1 (free) >>> CPU port 0 - Port 2 (plugged) >>> CPU port 1 - Port 3 (free) >>> CPU port 0 - Port 4 (free) >>> >>> We end up in a situation where ports 0 and 2 share 1 Gbps bandwidth to >>> CPU, and the second CPU port is not used at all. >>> >>> A mechanism for automatic reassignment of CPU ports would be ideal here. >>> >>> What do you guys think? >> >> The reason why I don't think this is such a great idea is because the >> CPU port assignment is a major reconfiguration step which should at the >> very least be done while the network is down, to avoid races with the >> data path (something which this series does not appear to handle). >> And if you allow the static user-port-to-CPU-port assignment to change >> every time a link goes up/down, I don't think you really want to force >> the network down through the entire switch basically. >> >> So I'd be tempted to say 'tough luck' if all your ports are not up, and >> the ones that are are assigned statically to the same CPU port. It's a >> compromise between flexibility and simplicity, and I would go for >> simplicity here. That's the most you can achieve with static assignment, >> just put the CPU ports in a LAG if you want better dynamic load balancing >> (for details read on below). > > Just one more small comment, because I got so carried away with > describing what I already had in mind, that I forgot to completely > address your idea. > > I think that DSA should provide the means to do what you want but not > the policy. Could not agree more, this point is what has historically prevented any multi-CPU port patch series from landing because what everyone seems to have wanted so far is along these lines: - assign LAN ports 0-3 to CPU port #0 - assign WAN port 4 to CPU port #1 and do that from Device Tree, problem solved? Not entirely unfortunately. Being able to change the mapping via iproute2 is definitively an improvement, and to echo to your comment on the iproute2 change proper we can try to agree on a more specialized syntax. > Meaning that you can always write a user space program that > monitors the NETLINK_ROUTE rtnetlink through a socket and listens for > link state change events on it with poll(), then does whatever (like > moves the static user-to-CPU port mapping in the way that is adequate to > your network's requirements). The link up/down events are already > emitted, and the patch set here gives user space the rope to hang itself. That seems like an entirely reasonable approach to me, and solving how to map a given user-port to a particular CPU port definitively belongs in user-space, within the constraints expressed by what the switch driver can do of course. > > If you need inspiration, one user of the rtnetlink socket that I know of > is ptp4l: > https://github.com/richardcochran/linuxptp/blob/master/rtnl.c > -- Florian
Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support
On 4/11/2021 11:39 AM, Andrew Lunn wrote: > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >> On Sat, 10 Apr 2021 15:34:46 +0200 >> Ansuel Smith wrote: >> >>> Hi, >>> this is a respin of the Marek series in hope that this time we can >>> finally make some progress with dsa supporting multi-cpu port. >>> >>> This implementation is similar to the Marek series but with some tweaks. >>> This adds support for multiple-cpu port but leave the driver the >>> decision of the type of logic to use about assigning a CPU port to the >>> various port. The driver can also provide no preference and the CPU port >>> is decided using a round-robin way. >> >> In the last couple of months I have been giving some thought to this >> problem, and came up with one important thing: if there are multiple >> upstream ports, it would make a lot of sense to dynamically reallocate >> them to each user port, based on which user port is actually used, and >> at what speed. >> >> For example on Turris Omnia we have 2 CPU ports and 5 user ports. All >> ports support at most 1 Gbps. Round-robin would assign: >> CPU port 0 - Port 0 >> CPU port 1 - Port 1 >> CPU port 0 - Port 2 >> CPU port 1 - Port 3 >> CPU port 0 - Port 4 >> >> Now suppose that the user plugs ethernet cables only into ports 0 and 2, >> with 1, 3 and 4 free: >> CPU port 0 - Port 0 (plugged) >> CPU port 1 - Port 1 (free) >> CPU port 0 - Port 2 (plugged) >> CPU port 1 - Port 3 (free) >> CPU port 0 - Port 4 (free) >> >> We end up in a situation where ports 0 and 2 share 1 Gbps bandwidth to >> CPU, and the second CPU port is not used at all. >> >> A mechanism for automatic reassignment of CPU ports would be ideal here. > > One thing you need to watch out for here source MAC addresses. I've > not looked at the details, so this is more a heads up, it needs to be > thought about. > > DSA slaves get there MAC address from the master interface. For a > single CPU port, all the slaves have the same MAC address. What > happens when you have multiple CPU ports? Does the slave interface get > the MAC address from its CPU port? It seems to be addressed by this part of patch 2: + if (ether_addr_equal(dev->dev_addr, master->dev_addr)) + eth_hw_addr_inherit(dev, cpu_dev); although this could create an interesting set of issues if done fully dynamically while the data path is active. > What happens when a slave moves > from one CPU interface to another CPU interface? Does its MAC address > change. ARP is going to be unhappy for a while? Also, how is the > switch deciding on which CPU port to use? Some switches are probably > learning the MAC address being used by the interface and doing > forwarding based on that. So you might need unique slave MAC > addresses, and when a slave moves, it takes it MAC address with it, > and you hope the switch learns about the move. But considered trapped > frames as opposed to forwarded frames. So BPDU, IGMP, etc. Generally, > you only have the choice to send such trapped frames to one CPU > port. So potentially, such frames are going to ingress on the wrong > port. Does this matter? What about multicast? How do you control what > port that ingresses on? What about RX filters on the master > interfaces? Could it be we added it to the wrong master? > > For this series to make progress, we need to know what has been > tested, and if all the more complex functionality works, not just > basic pings. Agreed. -- Florian
Re: Linux 5.12-rc7
Hallo
thanks all for the new kernel.
however, I see the following since linux-5.12-rc6 (when I started
testing 5.12)
I'm, as a non-developer, quiet not sure what the warning mean or better
how important they need to be taken, cause the box run's fine, so far.
I'm not sure if the warnings, etc. are only caused by the new compiler,
what is: gcc version 11.0.1 20210405 (Red Hat 11.0.1-0) (GCC) on an
Fedora 34 (beta) box or if it's something else.
during compilation:
===
...
In function ‘poly1305_simd_init’,
inlined from ‘crypto_poly1305_setdctxkey’ at
arch/x86/crypto/poly1305_glue.c:150:4,
inlined from ‘crypto_poly1305_setdctxkey’ at
arch/x86/crypto/poly1305_glue.c:144:21,
inlined from ‘poly1305_update_arch’ at
arch/x86/crypto/poly1305_glue.c:181:8:
arch/x86/crypto/poly1305_glue.c:86:9: warning: ‘poly1305_init_x86_64’
reading 32 bytes from a region of size 16 [-Wstringop-overread]
86 | poly1305_init_x86_64(ctx, key);
| ^~
arch/x86/crypto/poly1305_glue.c: In function ‘poly1305_update_arch’:
arch/x86/crypto/poly1305_glue.c:86:9: note: referencing argument 2 of
type ‘const u8 *’ {aka ‘const unsigned char *’}
arch/x86/crypto/poly1305_glue.c:18:17: note: in a call to function
‘poly1305_init_x86_64’
18 | asmlinkage void poly1305_init_x86_64(void *ctx,
| ^~~~
...
CC security/selinux/ss/sidtab.o
In file included from ./include/linux/string.h:269,
from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:22,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:59,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from ./include/linux/rcupdate.h:27,
from ./include/linux/rbtree.h:22,
from ./include/linux/iova.h:14,
from ./include/linux/intel-iommu.h:14,
from arch/x86/kernel/tboot.c:9:
In function ‘memcmp’,
inlined from ‘tboot_probe’ at arch/x86/kernel/tboot.c:70:6:
./include/linux/fortify-string.h:19:33: warning: ‘__builtin_memcmp_eq’
specified bound 16 exceeds source size 0 [-Wstringop-overread]
19 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:235:16: note: in expansion of macro
‘__underlying_memcmp’
235 | return __underlying_memcmp(p, q, size);
|^~~
...
CC net/core/fib_rules.o
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7628:3:
drivers/gpu/drm/i915/intel_pm.c:3057:9: warning:
‘intel_print_wm_latency’ reading 16 bytes from a region of size 10
[-Wstringop-overread]
3057 | intel_print_wm_latency(dev_priv, "Primary",
dev_priv->wm.pri_latency);
|
^
drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
drivers/gpu/drm/i915/intel_pm.c:3057:9: note: referencing argument 3 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7628:3:
drivers/gpu/drm/i915/intel_pm.c:3058:9: warning:
‘intel_print_wm_latency’ reading 16 bytes from a region of size 10
[-Wstringop-overread]
3058 | intel_print_wm_latency(dev_priv, "Sprite",
dev_priv->wm.spr_latency);
|
^~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
drivers/gpu/drm/i915/intel_pm.c:3058:9: note: referencing argument 3 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7628:3:
drivers/gpu/drm/i915/intel_pm.c:3059:9: warning:
‘intel_print_wm_latency’ reading 16 bytes from a region of size 10
[-Wstringop-overread]
linux-next: manual merge of the vfs tree with the overlayfs tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/overlayfs/file.c
between commit:
d46b7cd68336 ("ovl: plumb through flush method")
from the overlayfs tree and commit:
ae7db6c8bc98 ("ovl: remove unneeded ioctls")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/overlayfs/file.c
index 6e454a294046,9bd4167cc7fb..
--- a/fs/overlayfs/file.c
+++ b/fs/overlayfs/file.c
@@@ -716,11 -590,6 +610,7 @@@ const struct file_operations ovl_file_o
.mmap = ovl_mmap,
.fallocate = ovl_fallocate,
.fadvise= ovl_fadvise,
- .unlocked_ioctl = ovl_ioctl,
+ .flush = ovl_flush,
- #ifdef CONFIG_COMPAT
- .compat_ioctl = ovl_compat_ioctl,
- #endif
.splice_read= generic_file_splice_read,
.splice_write = iter_file_splice_write,
pgpBpgL3zl_0U.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 11/27] perf pmu: Support 'cycles' and 'branches' inside hybrid PMU
Hi Jiri,
On 4/9/2021 9:48 PM, Jiri Olsa wrote:
On Mon, Mar 29, 2021 at 03:00:30PM +0800, Jin Yao wrote:
On hybrid platform, user may want to enable the hardware event
only on one PMU. So following syntax is supported:
cpu_core//
cpu_atom//
# perf stat -e cpu_core/cpu-cycles/ -a -- sleep 1
Performance counter stats for 'system wide':
6,049,336 cpu_core/cpu-cycles/
1.003577042 seconds time elapsed
It enables the event 'cpu-cycles' only on cpu_core pmu.
But for 'cycles' and 'branches', the syntax doesn't work.
because the alias is not there.. but there's:
cpu/cpu-cycles/
cpu/branch-instructions/
doing the same thing.. what's wrong with that?
I have a feeling we discussed this in the previous
version.. did I give up? ;-)
Yes, we discussed this in previous threads. :)
Now I'm fine to keep the original behavior. Because the syntax 'cpu/cycles/' and 'cpu/branches/' are
not supported by current perf.
SNIP
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index beff29981101..72e5ae5e868e 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -916,6 +916,35 @@ static int pmu_max_precise(const char *name)
return max_precise;
}
+static void perf_pmu__add_hybrid_aliases(struct list_head *head)
+{
+ static struct pmu_event pme_hybrid_fixup[] = {
+ {
+ .name = "cycles",
+ .event = "event=0x3c",
+ },
+ {
+ .name = "branches",
+ .event = "event=0xc4",
+ },
+ {
+ .name = 0,
+ .event = 0,
+ },
if you really need to access these 2 events with special name,
why not add it through the json.. let's not have yet another
place that defines aliases ... also this should be model specific
no?
Yes, defining in json is a good idea if we really need to support 'cpu/cycles/'
and 'cpu/branches/'.
Anyway, I will drop this patch in next version.
Thanks
Jin Yao
jirka
linux-next: manual merge of the vfs tree with the btrfs tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/btrfs/ioctl.c
between commit:
2911da32d543 ("btrfs: use btrfs_inode_lock/btrfs_inode_unlock inode lock
helpers")
from the btrfs tree and commit:
d9b32b140987 ("btrfs: convert to fileattr")
from the vfs tree.
I fixed it up (I used the vfs tree version (which removed inode_lock()
in various places) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp4nwGQBhKsL.pgp
Description: OpenPGP digital signature
Sie haben eine Spende von 1.000.000,00 Euro
Herzliche Glückwünsche!!! Die Azim Premji Foundation hat Ihnen eine Spende in Höhe von 1.000.000,00 Euro geleistet. Weitere Informationen finden Sie hier: http://en.wikipedia.org/wiki/Azim_Premji und fordern Sie jetzt eine E-Mail an: prejimsfoundat...@gmail.com Vielen Dank Herr Azim Premji
Re: [PATCH] fs/buffer.c: Delete redundant uptodate check for buffer
+Cc: Andrew Morton
On 2021/4/1 14:57, Shaokun Zhang wrote:
> From: Yang Guo
>
> The buffer uptodate state has been checked in function set_buffer_uptodate,
> there is no need use buffer_uptodate before calling set_buffer_uptodate and
> delete it.
>
> Cc: Alexander Viro
> Signed-off-by: Yang Guo
> Signed-off-by: Shaokun Zhang
> ---
> fs/buffer.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 673cfbef9eec..2c0d0b3f3203 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -2055,8 +2055,7 @@ int __block_write_begin_int(struct page *page, loff_t
> pos, unsigned len,
> block_end = block_start + blocksize;
> if (block_end <= from || block_start >= to) {
> if (PageUptodate(page)) {
> - if (!buffer_uptodate(bh))
> - set_buffer_uptodate(bh);
> + set_buffer_uptodate(bh);
> }
> continue;
> }
> @@ -2088,8 +2087,7 @@ int __block_write_begin_int(struct page *page, loff_t
> pos, unsigned len,
> }
> }
> if (PageUptodate(page)) {
> - if (!buffer_uptodate(bh))
> - set_buffer_uptodate(bh);
> + set_buffer_uptodate(bh);
> continue;
> }
> if (!buffer_uptodate(bh) && !buffer_delay(bh) &&
>
[tip:core/rcu] BUILD SUCCESS 120b566d1df22a0a4543ac0e8aef875c49dd2c21
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/rcu branch HEAD: 120b566d1df22a0a4543ac0e8aef875c49dd2c21 Merge branch 'for-mingo-rcu' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu elapsed time: 723m configs tested: 135 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig riscvallmodconfig x86_64 allyesconfig i386 allyesconfig riscvallyesconfig nios2 defconfig sh sh7724_generic_defconfig sparcalldefconfig armxcep_defconfig umkunit_defconfig xtensaxip_kc705_defconfig powerpc ppc64e_defconfig armhisi_defconfig xtensa iss_defconfig arm spitz_defconfig m68kmvme147_defconfig mipsgpr_defconfig microblaze defconfig xtensageneric_kc705_defconfig mips db1xxx_defconfig arm netwinder_defconfig openrisc simple_smp_defconfig sh ecovec24_defconfig s390 zfcpdump_defconfig m68k m5208evb_defconfig parisc defconfig pariscgeneric-64bit_defconfig s390 allmodconfig xtensa common_defconfig sh defconfig nds32 defconfig sh se7619_defconfig arm pxa910_defconfig m68k allyesconfig mips cavium_octeon_defconfig m68km5307c3_defconfig mipsomega2p_defconfig powerpc katmai_defconfig mips ath79_defconfig h8300 h8s-sim_defconfig arm hackkit_defconfig sh urquell_defconfig mips maltasmvp_eva_defconfig x86_64 alldefconfig powerpc canyonlands_defconfig sh landisk_defconfig h8300h8300h-sim_defconfig mips decstation_64_defconfig arm cm_x300_defconfig shedosk7760_defconfig sparc sparc64_defconfig cskydefconfig sh se7343_defconfig powerpcsam440ep_defconfig mips cu1830-neo_defconfig s390 alldefconfig powerpc ppc40x_defconfig powerpc ps3_defconfig powerpc redwood_defconfig arm rpc_defconfig m68k sun3x_defconfig arm ep93xx_defconfig riscv rv32_defconfig mips ip22_defconfig xtensa cadence_csp_defconfig powerpc mpc837x_rdb_defconfig powerpc mpc834x_itx_defconfig powerpc mgcoge_defconfig mipsar7_defconfig parisc allyesconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig arc allyesconfig nds32 allnoconfig nios2allyesconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig s390 allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210411 i386
[tip:locking/core] BUILD SUCCESS c9450f728cfba0613163ed85f8c26eeeeed9def2
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core branch HEAD: c9450f728cfba0613163ed85f8c26ed9def2 Merge branch 'for-mingo-lkmm' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into locking/core elapsed time: 723m configs tested: 115 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig riscvallmodconfig x86_64 allyesconfig i386 allyesconfig riscvallyesconfig sh sh7724_generic_defconfig xtensaxip_kc705_defconfig powerpc ppc64e_defconfig armhisi_defconfig xtensa iss_defconfig arm spitz_defconfig m68kmvme147_defconfig mipsgpr_defconfig microblaze defconfig xtensageneric_kc705_defconfig mips db1xxx_defconfig arm netwinder_defconfig openrisc simple_smp_defconfig sh ecovec24_defconfig mips cavium_octeon_defconfig m68km5307c3_defconfig mipsomega2p_defconfig pariscgeneric-64bit_defconfig powerpc katmai_defconfig mips ath79_defconfig h8300 h8s-sim_defconfig arm hackkit_defconfig sh urquell_defconfig mips maltasmvp_eva_defconfig x86_64 alldefconfig powerpc canyonlands_defconfig powerpc ps3_defconfig powerpc redwood_defconfig arm rpc_defconfig m68k sun3x_defconfig arm ep93xx_defconfig riscv rv32_defconfig mips ip22_defconfig xtensa cadence_csp_defconfig powerpc mpc837x_rdb_defconfig powerpc mpc834x_itx_defconfig powerpc mgcoge_defconfig mipsar7_defconfig parisc allyesconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210411 i386 randconfig-a001-20210411 i386 randconfig-a006-20210411 i386 randconfig-a005-20210411 i386 randconfig-a004-20210411 i386 randconfig-a002-20210411 i386 randconfig-a015-20210411 i386 randconfig-a014-20210411 i386 randconfig-a013-20210411 i386 randconfig-a012-20210411 i386 randconfig-a016-20210411 i386 randconfig-a011-20210411 x86_64 randconfig-a003-20210411 x86_64 randconfig-a002-20210411 x86_64 randconfig-a001-20210411 x86_64 randconfig-a005-20210411 x86_64 randconfig-a006-20210411 x86_64 randconfig-a004-20210411 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig
[tip:master] BUILD SUCCESS 3f29baf9d62e86e5af51c8d1087ec78bf436e923
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 3f29baf9d62e86e5af51c8d1087ec78bf436e923 Merge branch 'core/rcu' elapsed time: 723m configs tested: 106 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig sh sh7724_generic_defconfig xtensaxip_kc705_defconfig powerpc ppc64e_defconfig armhisi_defconfig xtensa iss_defconfig xtensageneric_kc705_defconfig mips db1xxx_defconfig arm netwinder_defconfig openrisc simple_smp_defconfig sh ecovec24_defconfig mips cavium_octeon_defconfig m68km5307c3_defconfig mipsomega2p_defconfig pariscgeneric-64bit_defconfig powerpc katmai_defconfig mips ath79_defconfig h8300 h8s-sim_defconfig arm hackkit_defconfig sh urquell_defconfig mips maltasmvp_eva_defconfig x86_64 alldefconfig powerpc canyonlands_defconfig powerpc ps3_defconfig powerpc redwood_defconfig arm rpc_defconfig powerpc mpc834x_itx_defconfig powerpc mgcoge_defconfig mipsar7_defconfig parisc allyesconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig s390defconfig nios2 defconfig arc allyesconfig nds32 allnoconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210411 i386 randconfig-a001-20210411 i386 randconfig-a006-20210411 i386 randconfig-a005-20210411 i386 randconfig-a004-20210411 i386 randconfig-a002-20210411 i386 randconfig-a015-20210411 i386 randconfig-a014-20210411 i386 randconfig-a013-20210411 i386 randconfig-a012-20210411 i386 randconfig-a016-20210411 i386 randconfig-a011-20210411 x86_64 randconfig-a003-20210411 x86_64 randconfig-a002-20210411 x86_64 randconfig-a001-20210411 x86_64 randconfig-a005-20210411 x86_64 randconfig-a006-20210411 x86_64 randconfig-a004-20210411 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig
Re: [PATCH v3 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hi,
On Sat, Apr 10, 2021 at 03:56:58PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Sat, Apr 10, 2021 at 06:34:55AM +0900, Nobuhiro Iwamatsu wrote:
> > > > +static int visconti_pwm_remove(struct platform_device *pdev)
> > > > +{
> > > > + struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
> > > > +
> > > > + return pwmchip_remove(>chip);
> > >
> > > I think Uwe would prefer this to be done separately because he's working
> > > towards removing the return value from pwmchip_remove() and if we start
> > > ignoring it in new drivers that will make life easier going forward.
> > >
> > > So this should just be:
> > >
> > > pwmchip_remove(>chip);
> > >
> > > return 0;
> >
> > I understand your suggestion.
> > However, it looks like the pwmchip_remove() hasn't been updated yet.
> > I will wait for the update of pwmchip_remove.
>
> pwmchip_remove will always return 0 since b2c200e3f2fd which is in v5.3.
> So Thierry's suggestion is safe and indeed welcome.
Sorry, I was looking at a different function.
I will fix this.
Best regards,
Nobuhiro
Re: [PATCH] x86/efi: Do not release sub-1MB memory regions when the crashkernel option is specified
> On Apr 11, 2021, at 6:14 PM, Baoquan He wrote: > > On 04/09/21 at 07:59pm, H. Peter Anvin wrote: >> Why don't we do this unconditionally? At the very best we gain half a >> megabyte of memory (except the trampoline, which has to live there, but it >> is only a few kilobytes.) > > This is a great suggestion, thanks. I think we can fix it in this way to > make code simpler. Then the specific caring of real mode in > efi_free_boot_services() can be removed too. > This whole situation makes me think that the code is buggy before and buggy after. The issue here (I think) is that various pieces of code want to reserve specific pieces of otherwise-available low memory for their own nefarious uses. I don’t know *why* crash kernel needs this, but that doesn’t matter too much. I propose that the right solution is to give low-memory-reserving code paths two chances to do what they need: once at the very beginning and once after EFI boot services are freed. Alternatively, just reserve *all* otherwise unused sub 1M memory up front, then release it right after releasing boot services, and then invoke the special cases exactly once. In either case, the result is that the crashkernel mess gets unified with the trampoline mess. One way the result is called twice and needs to be more careful, and the other way it’s called only once. Just skipping freeing boot services seems wrong. It doesn’t unmap boot services, and skipping that is incorrect, I think. And it seems to result in a bogus memory map in which the system thinks that some crashkernel memory is EFI memory instead. Let’s please just fix the problem instead of papering over it with more hacks. > Thanks > Baoquan >
Re: [PATCH 2/5] swap: fix do_swap_page() race with swapoff
Miaohe Lin writes:
> On 2021/4/10 1:17, Tim Chen wrote:
>>
>>
>> On 4/9/21 1:42 AM, Miaohe Lin wrote:
>>> On 2021/4/9 5:34, Tim Chen wrote:
On 4/8/21 6:08 AM, Miaohe Lin wrote:
> When I was investigating the swap code, I found the below possible race
> window:
>
> CPU 1 CPU 2
> - -
> do_swap_page
> synchronous swap_readpage
> alloc_page_vma
> swapoff
> release swap_file, bdev, or ...
>>>
>>> Many thanks for quick review and reply!
>>>
Perhaps I'm missing something. The release of swap_file, bdev etc
happens after we have cleared the SWP_VALID bit in si->flags in
destroy_swap_extents
if I read the swapoff code correctly.
>>> Agree. Let's look this more close:
>>> CPU1CPU2
>>> - -
>>> swap_readpage
>>> if (data_race(sis->flags & SWP_FS_OPS)) {
>>> swapoff
>>> p->swap_file
>>> = NULL;
>>> struct file *swap_file = sis->swap_file;
>>> struct address_space *mapping = swap_file->f_mapping;[oops!]
>>> ...
>>> p->flags = 0;
>>> ...
>>>
>>> Does this make sense for you?
>>
>> p->swapfile = NULL happens after the
>> p->flags &= ~SWP_VALID, synchronize_rcu(), destroy_swap_extents() sequence
>> in swapoff().
>>
>> So I don't think the sequence you illustrated on CPU2 is in the right order.
>> That said, without get_swap_device/put_swap_device in swap_readpage, you
>> could
>> potentially blow pass synchronize_rcu() on CPU2 and causes a problem. so I
>> think
>> the problematic race looks something like the following:
>>
>>
>> CPU1 CPU2
>> --
>> swap_readpage
>> if (data_race(sis->flags & SWP_FS_OPS)) {
>> swapoff
>>p->flags = &=
>> ~SWP_VALID;
>>..
>>
>> synchronize_rcu();
>>..
>>p->swap_file
>> = NULL;
>> struct file *swap_file = sis->swap_file;
>> struct address_space *mapping = swap_file->f_mapping;[oops!]
>>...
>> ...
>>
>
> Agree. This is also what I meant to illustrate. And you provide a better one.
> Many thanks!
For the pages that are swapped in through swap cache. That isn't an
issue. Because the page is locked, the swap entry will be marked with
SWAP_HAS_CACHE, so swapoff() cannot proceed until the page has been
unlocked.
So the race is for the fast path as follows,
if (data_race(si->flags & SWP_SYNCHRONOUS_IO) &&
__swap_count(entry) == 1)
I found it in your original patch description. But please make it more
explicit to reduce the potential confusing.
Best Regards,
Huang, Ying
Re: [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > The existing IPMI chardev encodes IPMI behaviours as the name suggests. > > However, KCS devices are useful beyond IPMI (or keyboards), as they > > provide a means to generate IRQs and exchange arbitrary data between a > > BMC and its host system. > > I only noticed the series after Joel asked about the DT changes on the arm > side. One question though: > > How does this related to the drivers/input/serio/ framework that also talks > to the keyboard controller for things that are not keyboards? I've taken a brief look and I feel they're somewhat closely related. It's plausible that we could wrangle the code so the Aspeed and Nuvoton KCS drivers move under drivers/input/serio. If you squint, the i8042 serio device driver has similarities with what the Aspeed and Nuvoton device drivers are providing to the KCS IPMI stack. Both the KCS IPMI and raw chardev I've implemented in this patch need both read and write access to the status register (STR). serio could potentially expose its value through serio_interrupt() using the SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this sentence. We'd need some extra support for writing STR via the serio API. I'm not sure that fits into the abstraction (unless we make serio_write() take a flags argument?). In that vein, the serio_raw interface is close to the functionality that the raw chardev provides in this patch, though again serio_raw lacks userspace access to STR. Flags are ignored in the ->interrupt() callback so all values received via ->interrupt() are exposed as data. The result is there's no way to take care of SERIO_OOB_DATA in the read() path. Given that, I think we'd have to expose an ioctl() to access the STR value after taking care of SERIO_OOB_DATA in ->interrupt(). I'm not sure where that lands us. Dmitry, any thoughts here? > Are these > separate communication channels on adjacent I/O ports, or does there > need to be some arbitration? As it stands there's no arbitration. Cheers, Andrew
Re: [PATCH] gdrom: fix compilation error
On 4/11/21 7:12 PM, Bart Van Assche wrote: > On 4/11/21 3:43 PM, Chaitanya Kulkarni wrote: >> Use the right name for the struct request variable that removes the >> following compilation error :- >> >> make --silent --keep-going --jobs=8 >> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=sh >> CROSS_COMPILE=sh4-linux-gnu- 'CC=sccache sh4-linux-gnu-gcc' >> 'HOSTCC=sccache gcc' >> >> In file included from /builds/linux/include/linux/scatterlist.h:9, >> from /builds/linux/include/linux/dma-mapping.h:10, >> from /builds/linux/drivers/cdrom/gdrom.c:16: >> /builds/linux/drivers/cdrom/gdrom.c: In function 'gdrom_readdisk_dma': >> /builds/linux/drivers/cdrom/gdrom.c:586:61: error: 'rq' undeclared >> (first use in this function) >> 586 | __raw_writel(page_to_phys(bio_page(req->bio)) + bio_offset(rq->bio), >> | ^~ > > How about adding a Fixes: tag? Indeed, that's definitely missing. I've added it and applied it. -- Jens Axboe
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
On Sun, Apr 11, 2021 at 10:57:54AM +0300, Kalle Valo wrote:
> Shawn Guo writes:
>
> > Add optional brcm,ccode-map property to support translation from ISO3166
> > country code to brcmfmac firmware country code and revision.
> >
> > Signed-off-by: Shawn Guo
> > ---
> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > index cffb2d6876e3..a65ac4384c04 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > @@ -15,6 +15,12 @@ Optional properties:
> > When not specified the device will use in-band SDIO interrupts.
> > - interrupt-names : name of the out-of-band interrupt, which must be set
> > to "host-wake".
> > + - brcm,ccode-map : multiple strings for translating ISO3166 country code
> > to
> > + brcmfmac firmware country code and revision. Each string must be in
> > + format "AA-BB-num" where:
> > + AA is the ISO3166 country code which must be 2 characters.
> > + BB is the firmware country code which must be 2 characters.
> > + num is the revision number which must fit into signed integer.
> >
> > Example:
> >
> > @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> > interrupt-parent = <>;
> > interrupts = <10 8>; /* PH10 / EINT10 */
> > interrupt-names = "host-wake";
> > + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
>
> The commit log does not answer "Why?". Why this needs to be in device
> tree and, for example, not hard coded in the driver?
Thanks for the comment, Kalle. Actually, this is something I need some
input from driver maintainers. I can see this country code mapping
table is chipset specific, and can be hard coded in driver per chip id
and revision. But on the other hand, it makes some sense to have this
table in device tree, as the country code that need to be supported
could be a device specific configuration.
Shawn
Re: [PATCH net v3] net: sched: fix packet stuck problem for lockless qdisc
On 2021/4/9 17:09, Hillf Danton wrote:
> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
>> On 25.03.21 04:13, Yunsheng Lin wrote:
>> I have a setup which is able to reproduce the issue quite reliably:
>>
>> In a Xen guest I'm mounting 8 NFS shares and run sysbench fileio on
>> each of them. The average latency reported by sysbench is well below
>> 1 msec, but at least once per hour I get latencies in the minute
>> range.
>>
>> With this patch I don't see these high latencies any longer (test
>> is running for more than 20 hours now).
>>
>> So you can add my:
>>
>> Tested-by: Juergen Gross
>>
>
> If retry is allowed in the dequeue method then a simple seqcount can do the
> work of serializing enqueuer and dequeuer. IIUC it was not attempted last
> year.
At the first glance, I do not think the below patch fix the data race
described in the commit log, as it does not handle the time window
between dequeuing and q->seqlock releasing, as below:
The cpu1 may not see the qdisc->pad changed after pfifo_fast_dequeue(),
and cpu2 is not able to take the q->seqlock yet because cpu1 do not
release the q->seqlock.
>
> --- x/net/sched/sch_generic.c
> +++ y/net/sched/sch_generic.c
> @@ -632,6 +632,9 @@ static int pfifo_fast_enqueue(struct sk_
> return qdisc_drop(skb, qdisc, to_free);
> }
>
> + qdisc->pad++;
> + smp_wmb();
> +
> qdisc_update_stats_at_enqueue(qdisc, pkt_len);
> return NET_XMIT_SUCCESS;
> }
> @@ -641,6 +644,11 @@ static struct sk_buff *pfifo_fast_dequeu
> struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
> struct sk_buff *skb = NULL;
> int band;
> + int seq;
> +
> +again:
> + seq = READ_ONCE(qdisc->pad);
> + smp_rmb();
>
> for (band = 0; band < PFIFO_FAST_BANDS && !skb; band++) {
> struct skb_array *q = band2list(priv, band);
> @@ -652,10 +660,15 @@ static struct sk_buff *pfifo_fast_dequeu
> }
> if (likely(skb)) {
> qdisc_update_stats_at_dequeue(qdisc, skb);
> - } else {
> - WRITE_ONCE(qdisc->empty, true);
> + return skb;
> }
>
> + smp_rmb();
> + if (seq != READ_ONCE(qdisc->pad))
> + goto again;
> +
> + WRITE_ONCE(qdisc->empty, true);
> +
> return skb;
> }
>
>
> .
>
[PATCH v2] HID: i2c-hid: Skip ELAN power-on command after reset
Previous commit 43b7029f475e ("HID: i2c-hid:
Send power-on command after reset"), it fixed issue for SIS touchscreen.
For ELAN touchscreen, we found our boot code of IC was not flexible enough
to receive and handle this command.
Once the FW main code of our controller is crashed for some reason,
the controller could not be enumerated successfully to be recognized
by the system host. therefore, it lost touch functionality.
Add quirk for skip send power-on command after reset.
It will impact to ELAN touchscreen and touchpad on HID over I2C projects.
Signed-off-by: Johnny Chuang
---
Changes in v2:
- move comment to quirk entry
---
drivers/hid/i2c-hid/i2c-hid-core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 9993133..957d865 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -45,6 +45,7 @@
#define I2C_HID_QUIRK_BOGUS_IRQBIT(4)
#define I2C_HID_QUIRK_RESET_ON_RESUME BIT(5)
#define I2C_HID_QUIRK_BAD_INPUT_SIZE BIT(6)
+#define I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESETBIT(7)
/* flags */
@@ -178,6 +179,12 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_RESET_ON_RESUME },
{ USB_VENDOR_ID_ITE, I2C_DEVICE_ID_ITE_LENOVO_LEGION_Y720,
I2C_HID_QUIRK_BAD_INPUT_SIZE },
+/*
+ * Sending the wakeup after reset actually break ELAN touchscreen controller
+ * Add I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET to skip wakeup after reset
+ */
+ { USB_VENDOR_ID_ELAN, HID_ANY_ID,
+I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET },
{ 0, 0 }
};
@@ -461,7 +468,8 @@ static int i2c_hid_hwreset(struct i2c_client *client)
}
/* At least some SIS devices need this after reset */
- ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
+ if (!(ihid->quirks & I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET))
+ ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
out_unlock:
mutex_unlock(>reset_lock);
--
2.7.4
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
On Fri, Apr 09, 2021 at 01:46:06PM -0500, Rob Herring wrote:
> On Thu, Apr 08, 2021 at 07:30:21PM +0800, Shawn Guo wrote:
> > Add optional brcm,ccode-map property to support translation from ISO3166
> > country code to brcmfmac firmware country code and revision.
> >
> > Signed-off-by: Shawn Guo
> > ---
> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> > 1 file changed, 7 insertions(+)
>
> Can you convert this to schema first.
Yes. Will do, after driver maintainers agree with the direction.
>
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > index cffb2d6876e3..a65ac4384c04 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > @@ -15,6 +15,12 @@ Optional properties:
> > When not specified the device will use in-band SDIO interrupts.
> > - interrupt-names : name of the out-of-band interrupt, which must be set
> > to "host-wake".
> > + - brcm,ccode-map : multiple strings for translating ISO3166 country code
> > to
> > + brcmfmac firmware country code and revision. Each string must be in
> > + format "AA-BB-num" where:
> > + AA is the ISO3166 country code which must be 2 characters.
> > + BB is the firmware country code which must be 2 characters.
> > + num is the revision number which must fit into signed integer.
>
> Signed? So "AA-BB--num"?
Hmm, for some reason, kernel driver uses signed integer to hold the
revision. It's just a reflecting of that.
>
> You should be able to do something like:
>
> items:
> pattern: '^[A-Z][A-Z]-[A-Z][A-Z]-[0-9]+$'
Ah, yes, that's much better and distinct. Thanks for the suggestion.
Shawn
>
> >
> > Example:
> >
> > @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> > interrupt-parent = <>;
> > interrupts = <10 8>; /* PH10 / EINT10 */
> > interrupt-names = "host-wake";
> > + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
> > };
> > };
> > --
> > 2.17.1
> >
Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
On Sun, Apr 11, 2021 at 11:33:18AM +0100, Matthew Wilcox wrote:
> Basically, we have three aligned dwords here. We can either alias with
> @flags and the first word of @lru, or the second word of @lru and @mapping,
> or @index and @private. @flags is a non-starter. If we use @mapping,
> then you have to set it to NULL before you free it, and I'm not sure
> how easy that will be for you. If that's trivial, then we could use
> the layout:
>
> unsigned long _pp_flags;
> unsigned long pp_magic;
> union {
> dma_addr_t dma_addr;/* might be one or two words */
> unsigned long _pp_align[2];
> };
> unsigned long pp_pfmemalloc;
> unsigned long xmi;
I forgot about the munmap path. That calls zap_page_range() which calls
set_page_dirty() which calls page_mapping(). If we use page->mapping,
that's going to get interpreted as an address_space pointer.
*sigh*. Foiled at every turn.
I'm kind of inclined towards using two (or more) bits for PageSlab as
we discussed here:
https://lore.kernel.org/linux-mm/01000163efe179fe-d6270c58-eaba-482f-a6bd-334667250ef7-000...@email.amazonses.com/
so we have PageKAlloc that's true for PageSlab, PagePool, PageDMAPool,
PageVMalloc, PageFrag and maybe a few other kernel-internal allocations.
(see also here:)
https://lore.kernel.org/linux-mm/20180518194519.3820-18-wi...@infradead.org/
Re: [PATCH v3 09/27] perf parse-events: Create two hybrid cache events
Hi Jiri,
On 4/9/2021 9:48 PM, Jiri Olsa wrote:
On Mon, Mar 29, 2021 at 03:00:28PM +0800, Jin Yao wrote:
SNIP
index 1bbd0ba92ba7..3692fa3c964a 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -458,6 +458,7 @@ int parse_events_add_cache(struct list_head *list, int *idx,
int cache_type = -1, cache_op = -1, cache_result = -1;
char *op_result[2] = { op_result1, op_result2 };
int i, n;
+ bool hybrid;
/*
* No fallback - if we cannot get a clear cache type
@@ -517,6 +518,13 @@ int parse_events_add_cache(struct list_head *list, int
*idx,
if (get_config_terms(head_config, _terms))
return -ENOMEM;
}
+
+ i = parse_events__add_cache_hybrid(list, idx, ,
+ config_name ? : name, _terms,
+ );
+ if (hybrid)
+ return i;
please define 'ret' for the return value, i is confusing
thanks,
jirka
Previously I wanted to save a 'ret' variable, but yes it's confusing. I will define 'ret' in next
version.
Thanks
Jin Yao
+
return add_event(list, idx, , config_name ? : name, _terms);
}
--
2.17.1
Re: [PATCH v2] USB:ohci:fix ohci interruption problem
On 2021/4/9 23:07, Alan Stern wrote:
> On Fri, Apr 09, 2021 at 03:47:02PM +0800, Longfang Liu wrote:
>> The operating method of the system entering S4 sleep mode:
>> echo reboot > /sys/power/disk
>> echo disk > /sys/power/state
>>
>> When OHCI enters the S4 sleep state, check the log and find that
>> the USB sleep process will call check_root_hub_suspend() and
>> ohci_bus_suspend() instead ohci_suspend() and ohci_bus_suspend(),
>> which will cause the OHCI interrupt to not be closed.
>>
>> At this time, if just one device interrupt is reported. the
>> driver will not process and close this device interrupt. It will cause
>> the entire system to be stuck during sleep, causing the device to
>> fail to respond.
>>
>> When the abnormal interruption reaches 100,000 times, the system will
>> forcibly close the interruption and make the device unusable.
>>
>> Because the root cause of the problem is that ohci_suspend is not
>> called to perform normal interrupt shutdown operations when the system
>> enters S4 sleep mode.
>>
>> Therefore, our solution is to specify freeze interface in this mode to
>> perform normal suspend_common() operations, and call ohci_suspend()
>> after check_root_hub_suspend() is executed through the suspend_common()
>> operation.
>>
>> Signed-off-by: Longfang Liu
>> ---
>>
>> Changes in V2:
>> - Modify comment and patch version information.
>
> Please, instead of sending the same incorrect patch over and over again,
> spend some time figuring out what is really going wrong. I have already
> explained why this patch is not the right thing to do.
>
> You have to determine why the poweroff callback in hcd-pci.c (which
> points to hcd_pci_suspend) isn't getting called. That's the real
> explanation for your problem.
>
> Alan Stern
>
Ok! I need to analyze the PCI device sleep and wake process to see
why it will not be called.
Thanks,
Longfang.
>> Changes in V1:
>> - Call suspend_common by adding the hcd_pci_freeze function turn off
>> the interrupt instead of adding a shutdown operation in ohci_bus_suspend
>> to turn off the interrupt.
>>
>> drivers/usb/core/hcd-pci.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
>> index 1547aa6..c5844a3 100644
>> --- a/drivers/usb/core/hcd-pci.c
>> +++ b/drivers/usb/core/hcd-pci.c
>> @@ -509,6 +509,11 @@ static int resume_common(struct device *dev, int event)
>>
>> #ifdef CONFIG_PM_SLEEP
>>
>> +static int hcd_pci_freeze(struct device *dev)
>> +{
>> +return suspend_common(dev, device_may_wakeup(dev));
>> +}
>> +
>> static int hcd_pci_suspend(struct device *dev)
>> {
>> return suspend_common(dev, device_may_wakeup(dev));
>> @@ -605,7 +610,7 @@ const struct dev_pm_ops usb_hcd_pci_pm_ops = {
>> .suspend_noirq = hcd_pci_suspend_noirq,
>> .resume_noirq = hcd_pci_resume_noirq,
>> .resume = hcd_pci_resume,
>> -.freeze = check_root_hub_suspended,
>> +.freeze = hcd_pci_freeze,
>> .freeze_noirq = check_root_hub_suspended,
>> .thaw_noirq = NULL,
>> .thaw = NULL,
>> --
>> 2.8.1
>>
> .
>
Re: [PATCH] staging: fieldbus: simplify devm_anybuss_host_common_probe
在 2021/4/9 19:58, Sven Van Asbroeck 写道:
Hello Tian, thank you for the contribution. See below.
On Fri, Apr 9, 2021 at 4:33 AM Tian Tao wrote:
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Tian Tao
---
drivers/staging/fieldbus/anybuss/host.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/fieldbus/anybuss/host.c
b/drivers/staging/fieldbus/anybuss/host.c
index 549cb7d5..2924e68 100644
--- a/drivers/staging/fieldbus/anybuss/host.c
+++ b/drivers/staging/fieldbus/anybuss/host.c
@@ -1406,7 +1406,7 @@ void anybuss_host_common_remove(struct anybuss_host *host)
}
EXPORT_SYMBOL_GPL(anybuss_host_common_remove);
-static void host_release(struct device *dev, void *res)
+static void host_release(void *res)
{
struct anybuss_host **dr = res;
You're expecting a double pointer as the argument here...
What about doing it like this?
diff --git a/drivers/staging/fieldbus/anybuss/host.c
b/drivers/staging/fieldbus/anybuss/host.c
index 549cb7d5..c97df91 100644
--- a/drivers/staging/fieldbus/anybuss/host.c
+++ b/drivers/staging/fieldbus/anybuss/host.c
@@ -1406,32 +1406,26 @@ void anybuss_host_common_remove(struct
anybuss_host *host)
}
EXPORT_SYMBOL_GPL(anybuss_host_common_remove);
-static void host_release(struct device *dev, void *res)
+static void host_release(void *res)
{
- struct anybuss_host **dr = res;
-
- anybuss_host_common_remove(*dr);
+ anybuss_host_common_remove(res);
}
struct anybuss_host * __must_check
devm_anybuss_host_common_probe(struct device *dev,
const struct anybuss_ops *ops)
{
- struct anybuss_host **dr;
struct anybuss_host *host;
-
- dr = devres_alloc(host_release, sizeof(struct anybuss_host *),
- GFP_KERNEL);
- if (!dr)
- return ERR_PTR(-ENOMEM);
+ int ret;
host = anybuss_host_common_probe(dev, ops);
- if (IS_ERR(host)) {
- devres_free(dr);
+ if (IS_ERR(host))
return host;
- }
- *dr = host;
- devres_add(dev, dr);
+
+ ret = devm_add_action_or_reset(dev, host_release, host);
+ if (ret)
+ return ERR_PTR(ret);
+
return host;
}
@@ -1417,21 +1417,17 @@ struct anybuss_host * __must_check
devm_anybuss_host_common_probe(struct device *dev,
const struct anybuss_ops *ops)
{
- struct anybuss_host **dr;
struct anybuss_host *host;
-
- dr = devres_alloc(host_release, sizeof(struct anybuss_host *),
- GFP_KERNEL);
- if (!dr)
- return ERR_PTR(-ENOMEM);
+ int ret;
host = anybuss_host_common_probe(dev, ops);
- if (IS_ERR(host)) {
- devres_free(dr);
+ if (IS_ERR(host))
return host;
- }
- *dr = host;
- devres_add(dev, dr);
+
+ ret = devm_add_action_or_reset(dev, host_release, host);
... yet you pass in a single pointer here. Is that going to work?
+ if (ret)
+ return ERR_PTR(ret);
+
return host;
}
EXPORT_SYMBOL_GPL(devm_anybuss_host_common_probe);
--
2.7.4
.
Re: [PATCH v3 10/27] perf parse-events: Create two hybrid raw events
Hi Jiri,
On 4/9/2021 9:49 PM, Jiri Olsa wrote:
On Mon, Mar 29, 2021 at 03:00:29PM +0800, Jin Yao wrote:
SNIP
+ name, config_terms, pmu);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
int parse_events__add_numeric_hybrid(struct parse_events_state *parse_state,
struct list_head *list,
struct perf_event_attr *attr,
@@ -91,6 +126,9 @@ int parse_events__add_numeric_hybrid(struct
parse_events_state *parse_state,
if (attr->type != PERF_TYPE_RAW) {
return add_hw_hybrid(parse_state, list, attr, name,
config_terms);
+ } else {
+ return add_raw_hybrid(parse_state, list, attr, name,
+ config_terms);
}
return -1;
no need for the return -1
jirka
Yes, no need return -1 here.
if (attr->type != PERF_TYPE_RAW) {
return add_hw_hybrid(parse_state, list, attr, name,
config_terms);
}
return add_raw_hybrid(parse_state, list, attr, name,
config_terms);
Thanks
Jin Yao
--
2.17.1
