Re: [PATCH v5 4/5] cpufreq: qcom: Update the bandwidth levels on frequency change
On 2020-06-01 16:31, Viresh Kumar wrote:
On 29-05-20, 17:00, Sibi Sankar wrote:
> > +static int qcom_cpufreq_update_opp(struct device *cpu_dev,
> > +unsigned long freq_khz,
> > +unsigned long volt)
> > +{
> > + unsigned long freq_hz = freq_khz * 1000;
> > +
> > + if (dev_pm_opp_adjust_voltage(cpu_dev, freq_hz, volt, volt, volt))
> > + return dev_pm_opp_add(cpu_dev, freq_hz, volt);
>
> What's going on here ? Why add OPP here ?
We update the voltage if opp were
initially added as part of
dev_pm_opp_of_add_table. However
if the cpu node does not have an
opp table associated with it, we
do a opp_add_v1 instead.
Instead of depending on the failure of dev_pm_opp_adjust_voltage(),
pass a flag to qcom_cpufreq_update_opp() which will decide if we want
to adjust voltage or add an opp.
Sure will add it in the next
re-spin.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH] seg6: Fix slab-out-of-bounds in fl6_update_dst()
When update flowi6 daddr in fl6_update_dst() for srcrt, the used index
of segments should be segments_left minus one per RFC8754
(section 4.3.1.1) S15 S16. Otherwise it may results in an out-of-bounds
read.
Reported-by: syzbot+e8c028b62439eac42...@syzkaller.appspotmail.com
Fixes: 0cb7498f234e ("seg6: fix SRH processing to comply with RFC8754")
Signed-off-by: YueHaibing
---
net/ipv6/exthdrs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 5a8bbcdcaf2b..f5304bf33ab1 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -1353,7 +1353,7 @@ struct in6_addr *fl6_update_dst(struct flowi6 *fl6,
{
struct ipv6_sr_hdr *srh = (struct ipv6_sr_hdr *)opt->srcrt;
- fl6->daddr = srh->segments[srh->segments_left];
+ fl6->daddr = srh->segments[srh->segments_left - 1];
break;
}
default:
--
2.17.1
Re: [PATCH] i2c: sh_mobile: Fix compilation warning
> Almost after an year, wondering on how you reached this patch now :) Another developer sent the same patch. And last time I was unsure if I liked the new code better (for reasons I can't recall anymore); this time it was clear to me. signature.asc Description: PGP signature
Re: [PATCH 5.4 000/142] 5.4.44-rc1 review
On Mon, 1 Jun 2020 at 23:36, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.44 release. > There are 142 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 03 Jun 2020 17:38:19 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.44-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.4.44-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: 1fd4226c4fe1a358bb8277e25ebb03950180443a git describe: v5.4.43-143-g1fd4226c4fe1 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.43-143-g1fd4226c4fe1 No regressions (compared to build v5.4.43) No fixes (compared to build v5.4.43) Ran 31360 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kselftest/networking * libgpiod * linux-log-parser * ltp-commands-tests * ltp-containers-tests * ltp-dio-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * perf * libhugetlbfs * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * network-basic-tests * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-native/networking * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * kselftest-vsyscall-mode-none/networking -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap
On 2020/6/2 下午12:56, Michael S. Tsirkin wrote:
On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote:
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on vhost/linux-next]
[also build test ERROR on linus/master v5.7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please seehttps://stackoverflow.com/a/37406982]
url:https://github.com/0day-ci/linux/commits/Jason-Wang/vDPA-doorbell-mapping/20200531-070834
base:https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: m68k-randconfig-r011-20200601 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wgethttps://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
drivers/vhost/vdpa.c: In function 'vhost_vdpa_fault':
drivers/vhost/vdpa.c:754:22: error: implicit declaration of function
'pgprot_noncached' [-Werror=implicit-function-declaration]
754 | vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
| ^~~~
drivers/vhost/vdpa.c:754:22: error: incompatible types when assigning to type
'pgprot_t' {aka 'struct '} from type 'int'
cc1: some warnings being treated as errors
vim +/pgprot_noncached +754 drivers/vhost/vdpa.c
742
743 static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf)
744 {
745 struct vhost_vdpa *v = vmf->vma->vm_file->private_data;
746 struct vdpa_device *vdpa = v->vdpa;
747 const struct vdpa_config_ops *ops = vdpa->config;
748 struct vdpa_notification_area notify;
749 struct vm_area_struct *vma = vmf->vma;
750 u16 index = vma->vm_pgoff;
751
752 notify = ops->get_vq_notification(vdpa, index);
753
> 754 vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
755 if (remap_pfn_range(vma, vmf->address & PAGE_MASK,
756 notify.addr >> PAGE_SHIFT, PAGE_SIZE,
757 vma->vm_page_prot))
758 return VM_FAULT_SIGBUS;
759
760 return VM_FAULT_NOPAGE;
761 }
762
Yes well, all this remapping clearly has no chance to work
on systems without CONFIG_MMU.
It looks to me mmap can work according to Documentation/nommu-mmap.txt.
But I'm not sure it's worth to bother.
Thanks
Re: [PATCH 5.6 000/177] 5.6.16-rc1 review
On Mon, 1 Jun 2020 at 23:43, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.6.16 release. > There are 177 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 03 Jun 2020 17:38:19 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.16-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.6.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.6.16-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.6.y git commit: c72fcbc7d224903b8241afc1202a414575c1e557 git describe: v5.6.15-178-gc72fcbc7d224 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.6-oe/build/v5.6.15-178-gc72fcbc7d224 No regressions (compared to build v5.6.15) No fixes (compared to build v5.6.15) Ran 31253 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * libgpiod * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-sched-tests * ltp-syscalls-tests * perf * v4l2-compliance * ltp-cve-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * kselftest/net * kselftest/networking * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-open-posix-tests * network-basic-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-native/networking * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * kselftest-vsyscall-mode-none/networking -- Linaro LKFT https://lkft.linaro.org
[PATCH] net: genetlink: Fix memleak in genl_family_rcv_msg_dumpit()
dumpit info is freed by cb->done now (genl_lock_done()/ genl_parallel_done()), however if any error occurs before cb->done is called, info and attrs will leak. unreferenced object 0x888119904840 (size 32): comm "syz-executor.0", pid 857, jiffies 4295306979 (age 18.692s) hex dump (first 32 bytes): 60 2d 5a af ff ff ff ff c0 d6 a5 ae ff ff ff ff `-Z. 00 00 00 00 00 00 00 00 60 b4 25 ac ff ff ff ff `.%. backtrace: [<48573ee1>] kmalloc include/linux/slab.h:555 [inline] [<48573ee1>] genl_dumpit_info_alloc net/netlink/genetlink.c:463 [inline] [<48573ee1>] genl_family_rcv_msg_dumpit net/netlink/genetlink.c:598 [inline] [<48573ee1>] genl_family_rcv_msg net/netlink/genetlink.c:715 [inline] [<48573ee1>] genl_rcv_msg+0x7b7/0xce0 net/netlink/genetlink.c:735 [<6d27610a>] netlink_rcv_skb+0x139/0x390 net/netlink/af_netlink.c:2469 [] genl_rcv+0x24/0x40 net/netlink/genetlink.c:746 [ ] netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] [ ] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1329 [<27eb500d>] netlink_sendmsg+0x793/0xc80 net/netlink/af_netlink.c:1918 [<6e6952a8>] sock_sendmsg_nosec net/socket.c:652 [inline] [<6e6952a8>] sock_sendmsg+0x139/0x170 net/socket.c:672 Fixes: 1927f41a22a0 ("net: genetlink: introduce dump info struct to be available during dumpit op") Signed-off-by: YueHaibing --- net/netlink/genetlink.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 9f357aa22b94..cd719aecb0e2 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c @@ -548,8 +548,6 @@ static int genl_lock_done(struct netlink_callback *cb) rc = ops->done(cb); genl_unlock(); } - genl_family_rcv_msg_attrs_free(info->family, info->attrs, true); - genl_dumpit_info_free(info); return rc; } @@ -561,8 +559,6 @@ static int genl_parallel_done(struct netlink_callback *cb) if (ops->done) rc = ops->done(cb); - genl_family_rcv_msg_attrs_free(info->family, info->attrs, true); - genl_dumpit_info_free(info); return rc; } @@ -594,7 +590,6 @@ static int genl_family_rcv_msg_dumpit(const struct genl_family *family, return PTR_ERR(attrs); no_attrs: - /* Allocate dumpit info. It is going to be freed by done() callback. */ info = genl_dumpit_info_alloc(); if (!info) { genl_family_rcv_msg_attrs_free(family, attrs, true); @@ -630,6 +625,9 @@ static int genl_family_rcv_msg_dumpit(const struct genl_family *family, err = __netlink_dump_start(net->genl_sock, skb, nlh, &c); } + genl_family_rcv_msg_attrs_free(info->family, info->attrs, true); + genl_dumpit_info_free(info); + return err; } -- 2.20.1
Re: [PATCH 1/1] blk-mq: get ctx in order to handle BLK_MQ_S_INACTIVE in blk_mq_get_tag()
On Mon, Jun 01, 2020 at 11:17:49PM -0700, Dongli Zhang wrote:
> When scheduler is set, we hit below page fault when we offline cpu.
>
> [ 1061.007725] BUG: kernel NULL pointer dereference, address: 0040
> [ 1061.008710] #PF: supervisor read access in kernel mode
> [ 1061.009492] #PF: error_code(0x) - not-present page
> [ 1061.010241] PGD 0 P4D 0
> [ 1061.010614] Oops: [#1] SMP PTI
> [ 1061.011130] CPU: 0 PID: 122 Comm: kworker/0:1H Not tainted 5.7.0-rc7+ #2'
> ... ...
> [ 1061.013760] Workqueue: kblockd blk_mq_run_work_fn
> [ 1061.014446] RIP: 0010:blk_mq_put_tag+0xf/0x30
> ... ...
> [ 1061.017726] RSP: 0018:a5c18037fc70 EFLAGS: 00010287
> [ 1061.018475] RAX: RBX: a5c18037fcf0 RCX:
> 0004
> [ 1061.019507] RDX: RSI: RDI:
> 911535dc1180
> ... ...
> [ 1061.028454] Call Trace:
> [ 1061.029307] blk_mq_get_tag+0x26e/0x280
> [ 1061.029866] ? wait_woken+0x80/0x80
> [ 1061.030378] blk_mq_get_driver_tag+0x99/0x110
> [ 1061.031009] blk_mq_dispatch_rq_list+0x107/0x5e0
> [ 1061.031672] ? elv_rb_del+0x1a/0x30
> [ 1061.032178] blk_mq_do_dispatch_sched+0xe2/0x130
> [ 1061.032844] __blk_mq_sched_dispatch_requests+0xcc/0x150
> [ 1061.033638] blk_mq_sched_dispatch_requests+0x2b/0x50
> [ 1061.034239] __blk_mq_run_hw_queue+0x75/0x110
> [ 1061.034867] process_one_work+0x15c/0x370
> [ 1061.035450] worker_thread+0x44/0x3d0
> [ 1061.035980] kthread+0xf3/0x130
> [ 1061.036440] ? max_active_store+0x80/0x80
> [ 1061.037018] ? kthread_bind+0x10/0x10
> [ 1061.037554] ret_from_fork+0x35/0x40
> [ 1061.038073] Modules linked in:
> [ 1061.038543] CR2: 0040
> [ 1061.038962] ---[ end trace d20e1df7d028e69f ]---
>
> This is because blk_mq_get_driver_tag() would be used to allocate tag once
> scheduler (e.g., mq-deadline) is set. However, in order to handle
> BLK_MQ_S_INACTIVE in blk_mq_get_tag(), we need to set data->ctx for
> blk_mq_put_tag().
>
> Fixes: bf0beec0607db3c6 ("blk-mq: drain I/O when all CPUs in a hctx are
> offline")
> Signed-off-by: Dongli Zhang
> ---
> This is based on for-next because currently the pull request for v5.8 is
> not picked by mainline.
>
> block/blk-mq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 9a36ac1c1fa1..8bf6c06a86c1 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1056,6 +1056,7 @@ bool blk_mq_get_driver_tag(struct request *rq)
> {
> struct blk_mq_alloc_data data = {
> .q = rq->q,
> + .ctx = rq->mq_ctx,
> .hctx = rq->mq_hctx,
> .flags = BLK_MQ_REQ_NOWAIT,
> .cmd_flags = rq->cmd_flags,
Reviewed-by: Ming Lei
--
Ming
Re: [PATCH v4 7/7] mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix mx25uw51245g
Hi Pratyush,
> Subject
>
> Re: [PATCH v4 7/7] mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports
for
> Macronix mx25uw51245g
>
> On 29/05/20 03:36PM, Mason Yang wrote:
> > Macronix mx25uw51245g is a SPI NOR that supports 1-1-1/8-8-8 mode.
> >
> > Correct the dummy cycles to device for various frequencies
> > after xSPI profile 1.0 table parsed.
> >
> > Enable mx25uw51245g to Octal DTR mode by executing the command
sequences
> > to change to octal DTR mode.
> >
> > Signed-off-by: Mason Yang
> > ---
> > drivers/mtd/spi-nor/macronix.c | 55
++
> > 1 file changed, 55 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/macronix.c
b/drivers/mtd/spi-nor/macronix.c
> > index 96735d8..6c9a24c 100644
> > --- a/drivers/mtd/spi-nor/macronix.c
> > +++ b/drivers/mtd/spi-nor/macronix.c
> > @@ -8,6 +8,57 @@
> >
> > #include "core.h"
> >
> > +#define MXIC_CR2_DUMMY_SET_ADDR 0x300
> > +
> > +/* Fixup the dummy cycles to device and setup octa_dtr_enable() */
> > +static void mx25uw51245g_post_sfdp_fixups(struct spi_nor *nor)
> > +{
> > + struct spi_nor_flash_parameter *params = nor->params;
> > + int ret;
> > + u8 rdc, wdc;
> > +
> > + ret = spi_nor_read_cr2(nor, MXIC_CR2_DUMMY_SET_ADDR, &rdc);
> > + if (ret)
> > + return;
> > +
> > + /* Refer to dummy cycle and frequency table(MHz) */
> > + switch (params->dummy_cycles) {
> > + case 10: /* 10 dummy cycles for 104 MHz */
> > + wdc = 5;
> > + break;
> > + case 12: /* 12 dummy cycles for 133 MHz */
> > + wdc = 4;
> > + break;
> > + case 16: /* 16 dummy cycles for 166 MHz */
> > + wdc = 2;
> > + break;
> > + case 18: /* 18 dummy cycles for 173 MHz */
> > + wdc = 1;
> > + break;
> > + case 20: /* 20 dummy cycles for 200 MHz */
> > + default:
> > + wdc = 0;
> > + }
>
> I don't get the point of this. You already know the fastest the
> mx25uw51245g flash can run at. Why not just use the maximum dummy
> cycles? SPI NOR doesn't know the speed the controller is running at so
> the best it can do is use the maximum dummy cycles possible so it never
> falls short. Sure, it will be _slightly_ less performance, but we will
> be sure to read the correct data, which is much much more important.
In general, 200MHz needs 20 dummy cycles but some powerful device may only
needs 18 dummy cycles or less.
Set a proper dummy cycles for a better performance.
>
> Is it possible to have two chips which have _exactly_ the same ID but
> one supports say 200MHz frequency but the other doesn't? Without that,
> we can just enable the maximum and move on.
>
thanks for your time & comments.
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or
personal data, which is protected by applicable laws. Please be reminded that
duplication, disclosure, distribution, or use of this e-mail (and/or its
attachments) or any part thereof is prohibited. If you receive this e-mail in
error, please notify us immediately and delete this mail as well as its
attachment(s) from your system. In addition, please be informed that
collection, processing, and/or use of personal data is prohibited unless
expressly permitted by personal data protection laws. Thank you for your
attention and cooperation.
Macronix International Co., Ltd.
=
Re: [RFC][PATCH] usb: typec: tcpci_rt1711h: Try to avoid screaming irq causing boot hangs
Hi, John Stultz 于2020年6月2日周二 上午4:39写道： > > On Sat, May 30, 2020 at 3:30 AM Jun Li wrote: > > > > Hi John, > > > > John Stultz 于2020年5月30日周六 下午12:02写道： > > > > > > I've recently (since 5.7-rc1) started noticing very rare hangs > > > pretty early in bootup on my HiKey960 board. > > > > > > They have been particularly difficult to debug, as the system > > > seems to not respond at all to sysrq- commands. However, the > > > system is alive as I'll occaionally see firmware loading timeout > > > errors after awhile. Adding changes like initcall_debug and > > > lockdep weren't informative, as it tended to cause the problem > > > to hide. > > > > > > I finally tried to dig in a bit more on this today, and noticed > > > that the last dmesg output before the hang was usually: > > > "random: crng init done" > > > > > > So I dumped the stack at that point, and saw it was being called > > > from the pl061 gpio irq, and the hang always occurred when the > > > crng init finished on cpu 0. Instrumenting that more I could see > > > that when the issue triggered, we were getting a stream of irqs. > > > > > > Chasing further, I found the screaming irq was for the rt1711h, > > > and narrowed down that we were hitting the !chip->tcpci check > > > which immediately returns IRQ_HANDLED, but does not stop the > > > irq from triggering immediately afterwards. > > > > > > This patch slightly reworks the logic, so if we hit the irq > > > before the chip->tcpci has been assigned, we still read and > > > write the alert register, but just skip calling tcpci_irq(). > > > > > > With this change, I haven't managed to trip over the problem > > > (though it hasn't been super long - but I did confirm I hit > > > the error case and it didn't hang the system). > > > > > > I still have some concern that I don't know why this cropped > > > up since 5.7-rc, as there haven't been any changes to the > > > driver since 5.4 (or before). It may just be the initialization > > > timing has changed due to something else, and its just exposed > > > this issue? I'm not sure, and that's not super re-assuring. > > > > > > Anyway, I'd love to hear your thoughts if this looks like a sane > > > fix or not. > > > > I think a better solution may be move the irq request after port register, > > we should fire the irq after everything is setup. > > does below change works for you? > > Unfortunately the patch didn't seem to apply, but I recreated it by > hand. I agree this looks like it should address the issue and I've not > managed to trigger the problem in my (admittedly somewhat brief) > attempts at testing. > > Thanks for sending it out. Do you want to submit the patch and I'll > provide a Tested-by tag, or would it help for me to submit your > suggested change? OK, I will send out a patch against Greg's tree. Li Jun > > thanks > -john
[PATCH 2/3] ARM: dts: imx: Change esdhc node name on i.MX2/i.MX3/i.MX5 SoCs
Change i.MX2/i.MX3/i.MX5 SoCs esdhc node name from esdhc to mmc to
be compliant with yaml schema, it requires the nodename to be "mmc".
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx25.dtsi | 4 ++--
arch/arm/boot/dts/imx35.dtsi | 6 +++---
arch/arm/boot/dts/imx50.dtsi | 8
arch/arm/boot/dts/imx51.dtsi | 8
arch/arm/boot/dts/imx53.dtsi | 8
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 4eaf4eb..b045c6d 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -453,7 +453,7 @@
interrupts = <22>;
};
- esdhc1: esdhc@53fb4000 {
+ esdhc1: mmc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
interrupts = <9>;
@@ -462,7 +462,7 @@
status = "disabled";
};
- esdhc2: esdhc@53fb8000 {
+ esdhc2: mmc@53fb8000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb8000 0x4000>;
interrupts = <8>;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 502112b..e154087 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -231,7 +231,7 @@
#interrupt-cells = <2>;
};
- esdhc1: esdhc@53fb4000 {
+ esdhc1: mmc@53fb4000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fb4000 0x4000>;
interrupts = <7>;
@@ -240,7 +240,7 @@
status = "disabled";
};
- esdhc2: esdhc@53fb8000 {
+ esdhc2: mmc@53fb8000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fb8000 0x4000>;
interrupts = <8>;
@@ -249,7 +249,7 @@
status = "disabled";
};
- esdhc3: esdhc@53fbc000 {
+ esdhc3: mmc@53fbc000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fbc000 0x4000>;
interrupts = <9>;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 1f4ecbc..377951a 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -115,7 +115,7 @@
reg = <0x5000 0x4>;
ranges;
- esdhc1: esdhc@50004000 {
+ esdhc1: mmc@50004000 {
compatible = "fsl,imx50-esdhc",
"fsl,imx53-esdhc";
reg = <0x50004000 0x4000>;
interrupts = <1>;
@@ -127,7 +127,7 @@
status = "disabled";
};
- esdhc2: esdhc@50008000 {
+ esdhc2: mmc@50008000 {
compatible = "fsl,imx50-esdhc",
"fsl,imx53-esdhc";
reg = <0x50008000 0x4000>;
interrupts = <2>;
@@ -176,7 +176,7 @@
status = "disabled";
};
- esdhc3: esdhc@5002 {
+ esdhc3: mmc@5002 {
compatible = "fsl,imx50-esdhc",
"fsl,imx53-esdhc";
reg = <0x5002 0x4000>;
interrupts = <3>;
@@ -188,7 +188,7 @@
status = "disabled";
};
- esdhc4: esdhc@50024000 {
+ esdhc4: mmc@50024000 {
compatible = "fsl,imx50-esdhc",
"fsl,imx53-esdhc";
reg = <0x50024000 0x4000>;
interrupts = <4>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index c83bc77..db5827d 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -185,7 +185,7 @@
reg = <0x7000 0x4>;
ranges;
- esdhc1: esdhc@70004000 {
+ esdhc1: mmc@70004
[PATCH 1/3] ARM: dts: imx: Change sdhci node name on i.MX27/i.MX31 SoCs
Change i.MX27/i.MX31 node name from sdhci to mmc to be compliant
with yaml schema, it requires the nodename to be "mmc".
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx27.dtsi | 6 +++---
arch/arm/boot/dts/imx31.dtsi | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index ee04771..47de96b 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -265,7 +265,7 @@
status = "disabled";
};
- sdhci1: sdhci@10013000 {
+ sdhci1: mmc@10013000 {
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x10013000 0x1000>;
interrupts = <11>;
@@ -277,7 +277,7 @@
status = "disabled";
};
- sdhci2: sdhci@10014000 {
+ sdhci2: mmc@10014000 {
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x10014000 0x1000>;
interrupts = <10>;
@@ -431,7 +431,7 @@
status = "disabled";
};
- sdhci3: sdhci@1001e000 {
+ sdhci3: mmc@1001e000 {
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x1001e000 0x1000>;
interrupts = <9>;
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 4f3d7ab..eedf2d7 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -173,7 +173,7 @@
reg = <0x5000 0x10>;
ranges;
- sdhci1: sdhci@50004000 {
+ sdhci1: mmc@50004000 {
compatible = "fsl,imx31-mmc";
reg = <0x50004000 0x4000>;
interrupts = <9>;
@@ -184,7 +184,7 @@
status = "disabled";
};
- sdhci2: sdhci@50008000 {
+ sdhci2: mmc@50008000 {
compatible = "fsl,imx31-mmc";
reg = <0x50008000 0x4000>;
interrupts = <8>;
--
2.7.4
[PATCH 3/3] ARM: dts: imx: Change usdhc node name on i.MX6/i.MX7 SoCs
Change i.MX6/i.MX7 SoCs usdhc node name from usdhc to mmc to be
compliant with yaml schema, it requires the nodename to be "mmc".
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6qdl.dtsi | 8
arch/arm/boot/dts/imx6sl.dtsi | 8
arch/arm/boot/dts/imx6sx.dtsi | 8
arch/arm/boot/dts/imx6ul.dtsi | 4 ++--
arch/arm/boot/dts/imx7s.dtsi | 6 +++---
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index deb09df..346a52f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1056,7 +1056,7 @@
<0 126 IRQ_TYPE_LEVEL_HIGH>;
};
- usdhc1: usdhc@219 {
+ usdhc1: mmc@219 {
compatible = "fsl,imx6q-usdhc";
reg = <0x0219 0x4000>;
interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -1068,7 +1068,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
@@ -1080,7 +1080,7 @@
status = "disabled";
};
- usdhc3: usdhc@2198000 {
+ usdhc3: mmc@2198000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x02198000 0x4000>;
interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
@@ -1092,7 +1092,7 @@
status = "disabled";
};
- usdhc4: usdhc@219c000 {
+ usdhc4: mmc@219c000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x0219c000 0x4000>;
interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 11e7bf3..e2d2532 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -854,7 +854,7 @@
status = "disabled";
};
- usdhc1: usdhc@219 {
+ usdhc1: mmc@219 {
compatible = "fsl,imx6sl-usdhc",
"fsl,imx6q-usdhc";
reg = <0x0219 0x4000>;
interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -866,7 +866,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6sl-usdhc",
"fsl,imx6q-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
@@ -878,7 +878,7 @@
status = "disabled";
};
- usdhc3: usdhc@2198000 {
+ usdhc3: mmc@2198000 {
compatible = "fsl,imx6sl-usdhc",
"fsl,imx6q-usdhc";
reg = <0x02198000 0x4000>;
interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
@@ -890,7 +890,7 @@
status = "disabled";
};
- usdhc4: usdhc@219c000 {
+ usdhc4: mmc@219c000 {
compatible = "fsl,imx6sl-usdhc",
"fsl,imx6q-usdhc";
reg = <0x0219c000 0x4000>;
interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 995e1b1..430c21a 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -943,7 +943,7 @@
status = "disabled";
};
- usdhc1: usdhc@219 {
+ usdhc1: mmc@219 {
compatible = "fsl,imx6sx-usdhc",
"fsl,imx6sl-usdhc";
reg = <0x0219 0x4000>;
interrupts = ;
@@ -955,7 +955,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6sx-usdhc",
"fsl,imx6sl-usdhc";
reg = <0x02194000 0x4000>;
interrupts = ;
@@ -
Re: [GIT PULL] EFI changes for v5.8
On Tue, 2 Jun 2020 at 01:02, Linus Torvalds wrote: > > On Mon, Jun 1, 2020 at 1:38 PM Linus Torvalds > wrote: > > > > Ok, I'll try to remember, but I probably won't. So it would be lovely > > to be reminded when I get the arm pull. > > Well, the arm pull already came in, and mentioned it, and it all > looked entirely local and simple, so it's all good. > > Or rather, it's all _potentially_ good, but completely untested by yours > truly. > > rmk said he'd take a look, but maybe Ard might want to peek at it too. > Builds and boots fine via EFI on ARM32, thanks.
Re: [PATCH v4 1/7] mtd: spi-nor: sfdp: get octal mode maximum speed from BFPT
Hi Pratyush, > > Subject > > Re: [PATCH v4 1/7] mtd: spi-nor: sfdp: get octal mode maximum speed from BFPT > > On 29/05/20 03:36PM, Mason Yang wrote: > > Get maximum operation speed of device in octal mode from > > BFPT 20th DWORD. > > I don't like the idea of getting the maximum operation speed from BFPT > when the Profile 1.0 table already tells us that. For example, the > 200MHz operation dummy cycles field in the 4th DWORD says that a value > of 0 means the frequency is not supported. So the Profile 1.0 table > already tells us what frequencies the flash can run at in xSPI Profile > 1.0 mode. As JEDEC spec. mentioned that Operation faster than 200MHz is not part of the current xSPI Spec. However, this does not prevent vendors from making devices that operate at higher speed. In addition, current xSPP profile 1.0 table only defined up to 200MHz. > > So IMO we should use the Profile 1.0 table for this instead because > it will be a localized change which is easier to maintain. I also get > the feeling it will be less prone to mis-interpretations. > > > Signed-off-by: Mason Yang > > --- thanks for your time & comments. Mason CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. = CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =
RE: [PATCH] exfat: optimize dir-cache
> > Optimize directory access based on exfat_entry_set_cache. > > - Hold bh instead of copied d-entry. > > - Modify bh->data directly instead of the copied d-entry. > > - Write back the retained bh instead of rescanning the d-entry-set. > > And > > - Remove unused cache related definitions. > > > > Signed-off-by: Tetsuhiro Kohada > > > > Reviewed-by: Sungjong Seo Applied your 5 patches. Thanks!
[PATCH 1/1] blk-mq: get ctx in order to handle BLK_MQ_S_INACTIVE in blk_mq_get_tag()
When scheduler is set, we hit below page fault when we offline cpu.
[ 1061.007725] BUG: kernel NULL pointer dereference, address: 0040
[ 1061.008710] #PF: supervisor read access in kernel mode
[ 1061.009492] #PF: error_code(0x) - not-present page
[ 1061.010241] PGD 0 P4D 0
[ 1061.010614] Oops: [#1] SMP PTI
[ 1061.011130] CPU: 0 PID: 122 Comm: kworker/0:1H Not tainted 5.7.0-rc7+ #2'
... ...
[ 1061.013760] Workqueue: kblockd blk_mq_run_work_fn
[ 1061.014446] RIP: 0010:blk_mq_put_tag+0xf/0x30
... ...
[ 1061.017726] RSP: 0018:a5c18037fc70 EFLAGS: 00010287
[ 1061.018475] RAX: RBX: a5c18037fcf0 RCX: 0004
[ 1061.019507] RDX: RSI: RDI: 911535dc1180
... ...
[ 1061.028454] Call Trace:
[ 1061.029307] blk_mq_get_tag+0x26e/0x280
[ 1061.029866] ? wait_woken+0x80/0x80
[ 1061.030378] blk_mq_get_driver_tag+0x99/0x110
[ 1061.031009] blk_mq_dispatch_rq_list+0x107/0x5e0
[ 1061.031672] ? elv_rb_del+0x1a/0x30
[ 1061.032178] blk_mq_do_dispatch_sched+0xe2/0x130
[ 1061.032844] __blk_mq_sched_dispatch_requests+0xcc/0x150
[ 1061.033638] blk_mq_sched_dispatch_requests+0x2b/0x50
[ 1061.034239] __blk_mq_run_hw_queue+0x75/0x110
[ 1061.034867] process_one_work+0x15c/0x370
[ 1061.035450] worker_thread+0x44/0x3d0
[ 1061.035980] kthread+0xf3/0x130
[ 1061.036440] ? max_active_store+0x80/0x80
[ 1061.037018] ? kthread_bind+0x10/0x10
[ 1061.037554] ret_from_fork+0x35/0x40
[ 1061.038073] Modules linked in:
[ 1061.038543] CR2: 0040
[ 1061.038962] ---[ end trace d20e1df7d028e69f ]---
This is because blk_mq_get_driver_tag() would be used to allocate tag once
scheduler (e.g., mq-deadline) is set. However, in order to handle
BLK_MQ_S_INACTIVE in blk_mq_get_tag(), we need to set data->ctx for
blk_mq_put_tag().
Fixes: bf0beec0607db3c6 ("blk-mq: drain I/O when all CPUs in a hctx are
offline")
Signed-off-by: Dongli Zhang
---
This is based on for-next because currently the pull request for v5.8 is
not picked by mainline.
block/blk-mq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 9a36ac1c1fa1..8bf6c06a86c1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1056,6 +1056,7 @@ bool blk_mq_get_driver_tag(struct request *rq)
{
struct blk_mq_alloc_data data = {
.q = rq->q,
+ .ctx = rq->mq_ctx,
.hctx = rq->mq_hctx,
.flags = BLK_MQ_REQ_NOWAIT,
.cmd_flags = rq->cmd_flags,
--
2.17.1
RE: [PATCH] driver core: platform: expose numa_node to users in sysfs
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, June 2, 2020 6:11 PM
> To: Song Bao Hua (Barry Song)
> Cc: raf...@kernel.org; io...@lists.linux-foundation.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> ; Zengtao (B) ; Robin
> Murphy
> Subject: Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
>
> On Tue, Jun 02, 2020 at 05:09:57AM +, Song Bao Hua (Barry Song) wrote:
> > > >
> > > > Platform devices are NUMA? That's crazy, and feels like a total
> > > > abuse of platform devices and drivers that really should belong on a
> "real"
> > > > bus.
> > >
> > > I am not sure if it is an abuse of platform device. But smmu is a
> > > platform device, drivers/iommu/arm-smmu-v3.c is a platform driver.
> > > In a typical ARM server, there are maybe multiple SMMU devices which
> > > can support IO virtual address and page tables for other devices on
> > > PCI-like busses.
> > > Each different SMMU device might be close to different NUMA node.
> > > There is really a hardware topology.
> > >
> > > If you have multiple CPU packages in a NUMA server, some platform
> > > devices might Belong to CPU0, some other might belong to CPU1.
> >
> > Those devices are populated by acpi_iort for an ARM server:
> >
> > drivers/acpi/arm64/iort.c:
> >
> > static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
> > .name = "arm-smmu-v3",
> > .dev_dma_configure = arm_smmu_v3_dma_configure,
> > .dev_count_resources = arm_smmu_v3_count_resources,
> > .dev_init_resources = arm_smmu_v3_init_resources,
> > .dev_set_proximity = arm_smmu_v3_set_proximity, };
> >
> > void __init acpi_iort_init(void)
> > {
> > acpi_status status;
> >
> > status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
> > ...
> > iort_check_id_count_workaround(iort_table);
> > iort_init_platform_devices();
> > }
> >
> > static void __init iort_init_platform_devices(void) {
> > ...
> >
> > for (i = 0; i < iort->node_count; i++) {
> > if (iort_node >= iort_end) {
> > pr_err("iort node pointer overflows, bad
> table\n");
> > return;
> > }
> >
> > iort_enable_acs(iort_node);
> >
> > ops = iort_get_dev_cfg(iort_node);
> > if (ops) {
> > fwnode = acpi_alloc_fwnode_static();
> > if (!fwnode)
> > return;
> >
> > iort_set_fwnode(iort_node, fwnode);
> >
> > ret = iort_add_platform_device(iort_node, ops);
> > if (ret) {
> > iort_delete_fwnode(iort_node);
> > acpi_free_fwnode_static(fwnode);
> > return;
> > }
> > }
> >
> > ...
> > }
> > ...
> > }
> >
> > NUMA node is got from ACPI:
> >
> > static int __init arm_smmu_v3_set_proximity(struct device *dev,
> > struct acpi_iort_node
> > *node) {
> > struct acpi_iort_smmu_v3 *smmu;
> >
> > smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
> > if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
> > int dev_node = acpi_map_pxm_to_node(smmu->pxm);
> >
> > ...
> >
> > set_dev_node(dev, dev_node);
> > ...
> > }
> > return 0;
> > }
> >
> > Barry
>
> That's fine, but those are "real" devices, not platform devices, right?
>
Most platform devices are "real" memory-mapped hardware devices. For an
embedded system, almost all "simple-bus"
devices are populated from device trees as platform devices. Only a part of
platform devices are not "real" hardware.
Smmu is a memory-mapped device. It is totally like most other platform devices
populated in a
memory space mapped in cpu's local space. It uses ioremap to map registers, use
readl/writel to read/write its
space.
> What platform device has this issue? What one will show up this way with
> the new patch?
if platform device shouldn't be a real hardware, there is no platform device
with a hardware topology.
But platform devices are "real" hardware at most time. Smmu is a "real" device,
but it is a platform device in Linux.
>
> thanks,
>
> greg k-h
-barry
[PATCH -next] IB/hfi1: Use free_netdev() in hfi1_netdev_free()
dummy_netdev shold be freed by free_netdev() instead of
kfree(). Also remove unneeded variable 'priv'
Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev")
Signed-off-by: YueHaibing
---
drivers/infiniband/hw/hfi1/netdev_rx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/netdev_rx.c
b/drivers/infiniband/hw/hfi1/netdev_rx.c
index 58af6a454761..63688e85e8da 100644
--- a/drivers/infiniband/hw/hfi1/netdev_rx.c
+++ b/drivers/infiniband/hw/hfi1/netdev_rx.c
@@ -371,12 +371,9 @@ int hfi1_netdev_alloc(struct hfi1_devdata *dd)
void hfi1_netdev_free(struct hfi1_devdata *dd)
{
- struct hfi1_netdev_priv *priv;
-
if (dd->dummy_netdev) {
- priv = hfi1_netdev_priv(dd->dummy_netdev);
dd_dev_info(dd, "hfi1 netdev freed\n");
- kfree(dd->dummy_netdev);
+ free_netdev(dd->dummy_netdev);
dd->dummy_netdev = NULL;
}
}
--
2.17.1
Re: [PATCH v2] blkdev: Replace blksize_bits() with ilog2()
On Tue, Jun 02, 2020 at 07:51:52AM +0200, Christoph Hellwig wrote: > On Mon, Jun 01, 2020 at 10:44:26AM +0200, Greg KH wrote: > > But does this code path actually show up anywhere that is actually > > measurable as mattering? > > > > If so, please show that benchmark results. > > I think the requests are starting to be a bit unreasonable. Tao is > replacing a reimplementation of a standard function with that standard > function / compiler builtin. We don't put such a high burden on that. That's fine, but to say it is "faster" usually means we want to see it actually going faster somehow :) > And once the proper existing fields are used where possible as shown > in my reply just replacing the rest seems totally obvious - quite > contrary I think keeping a reimplementation would need a high bar. Your patch makes sense, I was not objecting to that. thanks, greg k-h
Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
On Tue, Jun 02, 2020 at 05:09:57AM +, Song Bao Hua (Barry Song) wrote:
> > >
> > > Platform devices are NUMA? That's crazy, and feels like a total abuse
> > > of platform devices and drivers that really should belong on a "real"
> > > bus.
> >
> > I am not sure if it is an abuse of platform device. But smmu is a platform
> > device,
> > drivers/iommu/arm-smmu-v3.c is a platform driver.
> > In a typical ARM server, there are maybe multiple SMMU devices which can
> > support
> > IO virtual address and page tables for other devices on PCI-like busses.
> > Each different SMMU device might be close to different NUMA node. There is
> > really a hardware topology.
> >
> > If you have multiple CPU packages in a NUMA server, some platform devices
> > might
> > Belong to CPU0, some other might belong to CPU1.
>
> Those devices are populated by acpi_iort for an ARM server:
>
> drivers/acpi/arm64/iort.c:
>
> static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
> .name = "arm-smmu-v3",
> .dev_dma_configure = arm_smmu_v3_dma_configure,
> .dev_count_resources = arm_smmu_v3_count_resources,
> .dev_init_resources = arm_smmu_v3_init_resources,
> .dev_set_proximity = arm_smmu_v3_set_proximity,
> };
>
> void __init acpi_iort_init(void)
> {
> acpi_status status;
>
> status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
> ...
> iort_check_id_count_workaround(iort_table);
> iort_init_platform_devices();
> }
>
> static void __init iort_init_platform_devices(void)
> {
> ...
>
> for (i = 0; i < iort->node_count; i++) {
> if (iort_node >= iort_end) {
> pr_err("iort node pointer overflows, bad table\n");
> return;
> }
>
> iort_enable_acs(iort_node);
>
> ops = iort_get_dev_cfg(iort_node);
> if (ops) {
> fwnode = acpi_alloc_fwnode_static();
> if (!fwnode)
> return;
>
> iort_set_fwnode(iort_node, fwnode);
>
> ret = iort_add_platform_device(iort_node, ops);
> if (ret) {
> iort_delete_fwnode(iort_node);
> acpi_free_fwnode_static(fwnode);
> return;
> }
> }
>
> ...
> }
> ...
> }
>
> NUMA node is got from ACPI:
>
> static int __init arm_smmu_v3_set_proximity(struct device *dev,
> struct acpi_iort_node *node)
> {
> struct acpi_iort_smmu_v3 *smmu;
>
> smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
> if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
> int dev_node = acpi_map_pxm_to_node(smmu->pxm);
>
> ...
>
> set_dev_node(dev, dev_node);
> ...
> }
> return 0;
> }
>
> Barry
That's fine, but those are "real" devices, not platform devices, right?
What platform device has this issue? What one will show up this way
with the new patch?
thanks,
greg k-h
Re: [PATCH v2 2/2] vhost: convert get_user_pages() --> pin_user_pages()
> This code was using get_user_pages*(), in approximately a "Case 5" > scenario (accessing the data within a page), using the categorization > from [1]. That means that it's time to convert the get_user_pages*() + > put_page() calls to pin_user_pages*() + unpin_user_pages() calls. > > There is some helpful background in [2]: basically, this is a small > part of fixing a long-standing disconnect between pinning pages, and > file systems' use of those pages. > > [1] Documentation/core-api/pin_user_pages.rst > > [2] "Explicit pinning of user-space pages": > https://lwn.net/Articles/807108/ > > Cc: Michael S. Tsirkin > Cc: Jason Wang > Cc: k...@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: net...@vger.kernel.org > Signed-off-by: John Hubbard > --- > drivers/vhost/vhost.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > index 21a59b598ed8..596132a96cd5 100644 > --- a/drivers/vhost/vhost.c > +++ b/drivers/vhost/vhost.c > @@ -1762,15 +1762,14 @@ static int set_bit_to_user(int nr, void __user *addr) > int bit = nr + (log % PAGE_SIZE) * 8; > int r; > > - r = get_user_pages_fast(log, 1, FOLL_WRITE, &page); > + r = pin_user_pages_fast(log, 1, FOLL_WRITE, &page); > if (r < 0) > return r; > BUG_ON(r != 1); > base = kmap_atomic(page); > set_bit(bit, base); > kunmap_atomic(base); > - set_page_dirty_lock(page); > - put_page(page); > + unpin_user_pages_dirty_lock(&page, 1, true); > return 0; > } Acked-by: Pankaj Gupta
Re: [PATCH] iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver
On Sun, May 31, 2020 at 03:40:17PM +0100, Jonathan Cameron wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Mon, 25 May 2020 13:27:44 +0300 > Alexandru Ardelean wrote: > > > Since changes can come from all sort of places, it may make sense to have > > this symbol as a dependency to make sure that the 'make allmodconfig' && > > 'make allyesconfig' build rules cover this driver as well for a > > compile-build/test. > > > > It seemed useful [recently] when trying to apply a change for this. > > > > Signed-off-by: Alexandru Ardelean > Makes sense. Given this sort of change can expose weird an wonderful > dependencies that were previously hidden, I'll be wanting an > ack from at91 people. Agree. Acked-by: Ludovic Desroches Regards Ludovic > > Jonathan > > > --- > > drivers/iio/adc/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > > index c48c0005..c1f4c0aec265 100644 > > --- a/drivers/iio/adc/Kconfig > > +++ b/drivers/iio/adc/Kconfig > > @@ -294,7 +294,7 @@ config ASPEED_ADC > > > > config AT91_ADC > > tristate "Atmel AT91 ADC" > > - depends on ARCH_AT91 > > + depends on ARCH_AT91 || COMPILE_TEST > > depends on INPUT && SYSFS > > select IIO_BUFFER > > select IIO_TRIGGERED_BUFFER >
Re: [PATCH v2] 9p/xen: increase XEN_9PFS_RING_ORDER
Stefano Stabellini wrote on Mon, Jun 01, 2020: > > LGTM, I'll try to find some time to test this by the end of next week or > > will trust you if I can't make it -- ping me around June 1st if I don't > > reply again until then... > > Ping :-) I actually did think about this patch this weekend! . . .but didn't quite make it :/ Anyway, as promised pushed to linux-next, I'll submit this for 5.8 -- Dominique
Re: [PATCH v3] afs: Fix memory leak in afs_put_sysnames()
> Cc: # v4.17+ Are capital letters tolerated for this special email address? Regards, Markus
Re: iommu: Improve exception handling in iommu_group_alloc()
On Tue, Jun 02, 2020 at 07:01:02AM +0200, Markus Elfring wrote: > >> * I suggest to avoid the specification of duplicate function calls. > >> Will it be helpful to add a few jump targets? > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162#n455 > > > > I don't think it is helpful or readable to add some jump targets here, > > since the exception handling is very simple here. > > Do you disagree to the application of the Linux coding style then > for the recommended exception handling? No, that's not what I mean. My point is the exception handling in this patch is simple and no need to add 'goto' statement which does not help to improve readability. And I agree it is helpful for the cases where a function exits from multiple locations and more same cleanup work need to do.
Re: [PATCH v2] blkdev: Replace blksize_bits() with ilog2()
On Mon, Jun 01, 2020 at 10:44:26AM +0200, Greg KH wrote: > But does this code path actually show up anywhere that is actually > measurable as mattering? > > If so, please show that benchmark results. I think the requests are starting to be a bit unreasonable. Tao is replacing a reimplementation of a standard function with that standard function / compiler builtin. We don't put such a high burden on that. And once the proper existing fields are used where possible as shown in my reply just replacing the rest seems totally obvious - quite contrary I think keeping a reimplementation would need a high bar.
Re: [v2] afs: Fix memory leak in afs_put_sysnames()
>> * Is freeing and releasing an item a duplicate operation anyhow? > > You're missing the point. afs_put_sysnames() does release the things the > object points to (ie. the content), It is possible to distinguish the release of system resources for further items. > but not the object itself. How does this view fit to the proposed addition "kfree(sysnames);"? https://lore.kernel.org/linux-fsdevel/20200602013045.321855-1-chengzhih...@huawei.com/ https://lore.kernel.org/patchwork/patch/1251323/ Regards, Markus
linux-next: manual merge of the tty tree with the devicetree tree
Hi all,
Today's linux-next merge of the tty tree got a conflict in:
Documentation/devicetree/bindings/serial/rs485.yaml
between commit:
9f60a65bc5e6 ("dt-bindings: Clean-up schema indentation formatting")
from the devicetree tree and commit:
01c38ecff8b1 ("dt-bindings: serial: Add binding for rs485 bus termination
GPIO")
from the tty 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 Documentation/devicetree/bindings/serial/rs485.yaml
index 8141e4aad530,a9ad17864889..
--- a/Documentation/devicetree/bindings/serial/rs485.yaml
+++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@@ -39,6 -41,9 +39,10 @@@ properties
$ref: /schemas/types.yaml#/definitions/flag
rs485-rx-during-tx:
- description: enables the receiving of data even while sending data.
- $ref: /schemas/types.yaml#/definitions/flag
+description: enables the receiving of data even while sending data.
+$ref: /schemas/types.yaml#/definitions/flag
+
+ rs485-term-gpios:
+ description: GPIO pin to enable RS485 bus termination.
+ maxItems: 1
+...
pgpC_WLMO0Bi9.pgp
Description: OpenPGP digital signature
[PATCH] media: staging: tegra-vde: add missing pm_runtime_put_autosuspend
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put_autosuspend if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/staging/media/tegra-vde/vde.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/tegra-vde/vde.c
b/drivers/staging/media/tegra-vde/vde.c
index d3e63512a765..52cdd4a91e93 100644
--- a/drivers/staging/media/tegra-vde/vde.c
+++ b/drivers/staging/media/tegra-vde/vde.c
@@ -776,8 +776,10 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
*vde,
goto release_dpb_frames;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_autosuspend(dev);
goto unlock;
+ }
/*
* We rely on the VDE registers reset value, otherwise VDE
--
2.17.1
[PATCH] spi: img-spfi: add missing pm_runtime_pu
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-img-spfi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-img-spfi.c b/drivers/spi/spi-img-spfi.c
index 8543f5ed1099..c3d0452ac78a 100644
--- a/drivers/spi/spi-img-spfi.c
+++ b/drivers/spi/spi-img-spfi.c
@@ -785,8 +785,10 @@ static int img_spfi_resume(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret)
+ if (ret) {
+ pm_runtime_put(dev);
return ret;
+ }
spfi_reset(spfi);
pm_runtime_put(dev);
--
2.17.1
[PATCH] iommu/vt-d: Don't apply gfx quirks to untrusted devices
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.
Signed-off-by: Rajat Jain
---
drivers/iommu/intel-iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ef0a5246700e5..f2a480168a02f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -6214,6 +6214,11 @@ const struct iommu_ops intel_iommu_ops = {
static void quirk_iommu_igfx(struct pci_dev *dev)
{
+ if (dev->untrusted) {
+ pci_warn(dev, "skipping iommu quirk for untrusted gfx dev\n");
+ return;
+ }
+
pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
dmar_map_gfx = 0;
}
@@ -6255,6 +6260,11 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D,
quirk_iommu_igfx);
static void quirk_iommu_rwbf(struct pci_dev *dev)
{
+ if (dev->untrusted) {
+ pci_warn(dev, "skipping iommu quirk for untrusted dev\n");
+ return;
+ }
+
/*
* Mobile 4 Series Chipset neglects to set RWBF capability,
* but needs it. Same seems to hold for the desktop versions.
@@ -6285,6 +6295,11 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev
*dev)
{
unsigned short ggc;
+ if (dev->untrusted) {
+ pci_warn(dev, "skipping iommu quirk for untrusted gfx dev\n");
+ return;
+ }
+
if (pci_read_config_word(dev, GGC, &ggc))
return;
@@ -6318,6 +6333,13 @@ static void __init check_tylersburg_isoch(void)
pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
if (!pdev)
return;
+
+ if (pdev->untrusted) {
+ pci_warn(pdev, "skipping iommu quirk due to untrusted dev\n");
+ pci_dev_put(pdev);
+ return;
+ }
+
pci_dev_put(pdev);
/* System Management Registers. Might be hidden, in which case
@@ -6327,6 +6349,12 @@ static void __init check_tylersburg_isoch(void)
if (!pdev)
return;
+ if (pdev->untrusted) {
+ pci_warn(pdev, "skipping iommu quirk due to untrusted dev\n");
+ pci_dev_put(pdev);
+ return;
+ }
+
if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
pci_dev_put(pdev);
return;
--
2.27.0.rc2.251.g90737beb825-goog
Re: [PATCH RFCv2 9/9] arm64: Support async page fault
Hi Marc, Paolo, On 6/1/20 7:21 PM, Paolo Bonzini wrote: On 31/05/20 14:44, Marc Zyngier wrote: Is there an ARM-approved way to reuse the S2 fault syndromes to detect async page faults? It would mean being able to set an ESR_EL2 register value into ESR_EL1, and there is nothing in the architecture that would allow that, I understand that this is not what you want to do and I'm not proposing it, but I want to understand this better: _in practice_ do CPUs check closely what is written in ESR_EL1? In any case, the only way to implement this, it seems to me, would be a completely paravirtualized exception vector that doesn't use ESR at all. On the other hand, for the page ready (interrupt) side assigning a PPI seems complicated but doable. Marc suggested to use SDEI in another reply. I think it might be the appropriate way to deliver page-not-present. To some extent, it could be regarded as exception, which doesn't use ESR at all. It matches with what Paolo is thinking of: paravirtualized exception vector that doesn't use ESR at all. However, it seems it's not supported in kvm-arm yet. So I assume it needs to be developed from scratch. Marc, could you please help to confirm? Thanks in advance. I agree with Paolo PPI (interrupt) might be the best way to deliver page-ready currently. I don't think SDEI is suitable because there are no big difference between SDEI and currently used DABT injection to some extent. With SDEI, We will have the issues we are facing. For example, some critical code section isn't safe to receive SDEI if I'm correct. Thanks, Gavin [...]
[PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ
Add an FAQ entry to the KUnit documentation with some tips for troubleshooting KUnit and kunit_tool. These suggestions largely came from an email thread: https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 Signed-off-by: David Gow --- Documentation/dev-tools/kunit/faq.rst | 32 +++ 1 file changed, 32 insertions(+) diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index ea55b2467653..40109d425988 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -61,3 +61,35 @@ test, or an end-to-end test. kernel by installing a production configuration of the kernel on production hardware with a production userspace and then trying to exercise some behavior that depends on interactions between the hardware, the kernel, and userspace. + +KUnit isn't working, what should I do? +== + +Unfortunately, there are a number of things which can break, but here are some +things to try. + +1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output`` + parameter. This might show details or error messages hidden by the kunit_tool + parser. +2. Instead of running ``kunit.py run``, try running ``kunit.py config``, + ``kunit.py build``, and ``kunit.py exec`` independently. This can help track + down where an issue is occurring. (If you think the parser is at fault, you + can run it manually against stdin or a file with ``kunit.py parse``.) +3. Running the UML kernel directly can often reveal issues or error messages + kunit_tool ignores. This should be as simple as running ``./vmlinux`` after + building the UML kernel (e.g., by using ``kunit.py build``). Note that UML + has some unusual requirements (such as the host having a tmpfs filesystem + mounted), and has had issues in the past when built statically and the host + has KASLR enabled. (On older host kernels, you may need to run ``setarch + `uname -m` -R ./vmlinux`` to disable KASLR.) +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test + (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config + around, so you can see what config was used after running ``kunit.py run``. + It also preserves any config changes you might make, so you can + enable/disable things with ``make ARCH=um menuconfig`` or similar, and then + re-run kunit_tool. +5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py run`` + may help clean up any residual config items which could be causing problems. + +If none of the above tricks help, you are always welcome to email any issues to +kunit-...@googlegroups.com. -- 2.27.0.rc2.251.g90737beb825-goog
Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
On Tue, Jun 2, 2020 at 3:29 AM John Donnelly wrote: > > Hi . See below ! > > > On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma wrote: > > > > Hi John, > > > > On Tue, Jun 2, 2020 at 1:01 AM John Donnelly > > wrote: > >> > >> Hi, > >> > >> > >> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote: > >>> Hi Chen, > >>> > >>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou wrote: > This patch series enable reserving crashkernel above 4G in arm64. > > There are following issues in arm64 kdump: > 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail > when there is no enough low memory. > 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above > 4G, > in this case, if swiotlb or DMA buffers are required, crash dump kernel > will boot failure because there is no low memory available for > allocation. > > To solve these issues, introduce crashkernel=X,low to reserve specified > size low memory. > Crashkernel=X tries to reserve memory for the crash dump kernel under > 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified > size low memory for crash kdump kernel devices firstly and then reserve > memory above 4G. > > When crashkernel is reserved above 4G in memory, that is, > crashkernel=X,low > is specified simultaneously, kernel should reserve specified size low > memory > for crash dump kernel devices. So there may be two crash kernel regions, > one > is below 4G, the other is above 4G. > In order to distinct from the high region and make no effect to the use > of > kexec-tools, rename the low region as "Crash kernel (low)", and add DT > property > "linux,low-memory-range" to crash dump kernel's dtb to pass the low > region. > > Besides, we need to modify kexec-tools: > arm64: kdump: add another DT property to crash dump kernel's dtb(see [1]) > > The previous changes and discussions can be retrieved from: > > Changes since [v7] > - Move x86 CRASH_ALIGN to 2M > Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M. > - Update Documentation/devicetree/bindings/chosen.txt > Add corresponding documentation to > Documentation/devicetree/bindings/chosen.txt suggested by Arnd. > - Add Tested-by from Jhon and pk > > Changes since [v6] > - Fix build errors reported by kbuild test robot. > > Changes since [v5] > - Move reserve_crashkernel_low() into kernel/crash_core.c. > - Delete crashkernel=X,high. > - Modify crashkernel=X,low. > If crashkernel=X,low is specified simultaneously, reserve spcified size > low > memory for crash kdump kernel devices firstly and then reserve memory > above 4G. > In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, > and then > pass to crash dump kernel by DT property "linux,low-memory-range". > - Update Documentation/admin-guide/kdump/kdump.rst. > > Changes since [v4] > - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike. > > Changes since [v3] > - Add memblock_cap_memory_ranges back for multiple ranges. > - Fix some compiling warnings. > > Changes since [v2] > - Split patch "arm64: kdump: support reserving crashkernel above 4G" as > two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate > patch. > > Changes since [v1]: > - Move common reserve_crashkernel_low() code into kernel/kexec_core.c. > - Remove memblock_cap_memory_ranges() i added in v1 and implement that > in fdt_enforce_memory_region(). > There are at most two crash kernel regions, for two crash kernel regions > case, we cap the memory range [min(regs[*].start), max(regs[*].end)] > and then remove the memory range in the middle. > > [1]: > https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$ > [v1]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$ > [v2]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$ > [v3]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$ > [v4]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$ > [v5]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADt
[PATCH v2] driver core: platform: expose numa_node to users in sysfs
For some platform devices like iommu, particually ARM smmu, users may
care about the numa locality. for example, if threads and drivers run
near iommu, they may get much better performance on dma_unmap_sg.
For other platform devices, users may still want to know the hardware
topology.
Cc: Prime Zeng
Cc: Robin Murphy
Signed-off-by: Barry Song
---
-v2: add the numa_node entry in Documentation/ABI/
Documentation/ABI/testing/sysfs-bus-platform | 10
drivers/base/platform.c | 26 +++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-platform
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a6124b27..e8f5958c1d18 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,13 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none". Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What: /sys/bus/platform/devices/.../numa_node
+Date: June 2020
+Contact: Barry Song
+Description:
+ This file contains the NUMA node to which the platform device
+ is attached. It won't be visible if the node is unknown. The
+ value comes from an ACPI _PXM method or a similar firmware
+ source. Initial users for this file would be devices like
+ arm smmu which are populated by arm64 acpi_iort.
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b27d0f6c18c9..7794b9a38d82 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device *dev,
}
static DEVICE_ATTR_RW(driver_override);
+static ssize_t numa_node_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", dev_to_node(dev));
+}
+static DEVICE_ATTR_RO(numa_node);
+
+static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
attribute *a,
+ int n)
+{
+ struct device *dev = container_of(kobj, typeof(*dev), kobj);
+
+ if (a == &dev_attr_numa_node.attr &&
+ dev_to_node(dev) == NUMA_NO_NODE)
+ return 0;
+
+ return a->mode;
+}
static struct attribute *platform_dev_attrs[] = {
&dev_attr_modalias.attr,
+ &dev_attr_numa_node.attr,
&dev_attr_driver_override.attr,
NULL,
};
-ATTRIBUTE_GROUPS(platform_dev);
+
+static struct attribute_group platform_dev_group = {
+ .attrs = platform_dev_attrs,
+ .is_visible = platform_dev_attrs_visible,
+};
+__ATTRIBUTE_GROUPS(platform_dev);
static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
{
--
2.23.0
Re: [PATCH v3 1/1] clk: rockchip: rk3288: Handle clock tree for rk3288w
Hi Heiko,
Thank you very much for your quick review!
On 6/1/20 10:09 PM, Heiko Stübner wrote:
Hi Mylène,
Am Montag, 1. Juni 2020, 17:14:42 CEST schrieb Mylène Josserand:
The revision rk3288w has a different clock tree about "hclk_vio"
clock, according to the BSP kernel code.
This patch handles this difference by detecting which device-tree
we are using. If it is a "rockchip,rk3288-cru", let's register
the clock tree as it was before. If the compatible is
"rockchip,rk3288w-cru", we will apply the difference according to this
version of this SoC.
Noticed that this new device-tree compatible must be handled by
bootloader.
Signed-off-by: Mylène Josserand
approach looks good, but you should also update the clock-controller
dt-binding for the new compatible.
Okay, I will. As it was not implemented in the Kernel, I didn't know if
I should add it.
Style nits below.
---
drivers/clk/rockchip/clk-rk3288.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index cc2a177bbdbf..5018d2f1e54c 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p,
CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 0, GFLAGS),
- DIV(0, "hclk_vio", "aclk_vio0", 0,
- RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p,
CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 2, GFLAGS),
@@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3,
IFLAGS),
};
+static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio1", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
please keep indentations as they were, the sub-lines starting where they
are is actually intentional :-)
Oups, I didn't know, I will update this in my V4.
+};
+
+static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio0", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
same here
same here
+};
+
static const char *const rk3288_critical_clocks[] __initconst = {
"aclk_cpu",
"aclk_peri",
@@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
RK3288_GRF_SOC_STATUS1);
rockchip_clk_register_branches(ctx, rk3288_clk_branches,
ARRAY_SIZE(rk3288_clk_branches));
+
+ if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
+ rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
+
ARRAY_SIZE(rk3288w_hclkvio_branch));
+ else
+ rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
+
ARRAY_SIZE(rk3288_hclkvio_branch));
+
rockchip_clk_protect_critical(rk3288_critical_clocks,
ARRAY_SIZE(rk3288_critical_clocks));
Best regards,
Mylène
Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
On 6/1/20 10:21 PM, Lukas Bulwahn wrote:
> Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
> watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
> slipped in a minor mistake.
>
> Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
>
> Update file entry to intended file location.
>
> Signed-off-by: Lukas Bulwahn
Reviewed-by: Guenter Roeck
> ---
> Julius, Evan, please ack.
>
> Wim, please pick this minor patch into your -next tree.
>
> applies cleanly on next-20200529
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b045b70e54df..dcfb09700b96 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
> M: Julius Werner
> R: Evan Benn
> S: Maintained
> -F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
> +F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
> F: drivers/watchdog/arm_smc_wdt.c
>
> ARM SMMU DRIVERS
>
Re: [PATCH v7 3/6] irqchip: RISC-V per-HART local interrupt controller driver
On Tue, Jun 2, 2020 at 1:49 AM Atish Patra wrote:
>
> On Mon, Jun 1, 2020 at 2:16 AM Anup Patel wrote:
> >
> > The RISC-V per-HART local interrupt controller manages software
> > interrupts, timer interrupts, external interrupts (which are routed
> > via the platform level interrupt controller) and other per-HART
> > local interrupts.
> >
> > We add a driver for the RISC-V local interrupt controller, which
> > eventually replaces the RISC-V architecture code, allowing for a
> > better split between arch code and drivers.
> >
> > The driver is compliant with RISC-V Hart-Level Interrupt Controller
> > DT bindings located at:
> > Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> >
> > Co-developed-by: Palmer Dabbelt
> > Signed-off-by: Palmer Dabbelt
> > Signed-off-by: Anup Patel
> > Acked-by: Palmer Dabbelt
> > ---
> > arch/riscv/Kconfig| 1 +
> > arch/riscv/include/asm/irq.h | 2 -
> > arch/riscv/kernel/irq.c | 33 +--
> > arch/riscv/kernel/traps.c | 2 -
> > drivers/irqchip/Kconfig | 13 +++
> > drivers/irqchip/Makefile | 1 +
> > drivers/irqchip/irq-riscv-intc.c | 146 ++
> > drivers/irqchip/irq-sifive-plic.c | 30 --
> > include/linux/cpuhotplug.h| 1 +
> > 9 files changed, 188 insertions(+), 41 deletions(-)
> > create mode 100644 drivers/irqchip/irq-riscv-intc.c
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 90a008e28f7e..822cb0e1a380 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -40,6 +40,7 @@ config RISCV
> > select HAVE_PERF_REGS
> > select HAVE_PERF_USER_STACK_DUMP
> > select HAVE_SYSCALL_TRACEPOINTS
> > + select HANDLE_DOMAIN_IRQ
> > select IRQ_DOMAIN
> > select SPARSE_IRQ
> > select SYSCTL_EXCEPTION_TRACE
> > diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
> > index 0183e15ace66..a9e5f07a7e9c 100644
> > --- a/arch/riscv/include/asm/irq.h
> > +++ b/arch/riscv/include/asm/irq.h
> > @@ -10,8 +10,6 @@
> > #include
> > #include
> >
> > -#define NR_IRQS 0
> > -
> > void riscv_timer_interrupt(void);
> >
> > #include
> > diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
> > index bb0bfcd537e7..eb8777642ce6 100644
> > --- a/arch/riscv/kernel/irq.c
> > +++ b/arch/riscv/kernel/irq.c
> > @@ -7,7 +7,6 @@
> >
> > #include
> > #include
> > -#include
> > #include
> > #include
> >
> > @@ -19,39 +18,13 @@ int arch_show_interrupts(struct seq_file *p, int prec)
> >
> > asmlinkage __visible void __irq_entry do_IRQ(struct pt_regs *regs)
> > {
> > - struct pt_regs *old_regs;
> > -
> > - switch (regs->cause & ~CAUSE_IRQ_FLAG) {
> > - case RV_IRQ_TIMER:
> > - old_regs = set_irq_regs(regs);
> > - irq_enter();
> > - riscv_timer_interrupt();
> > - irq_exit();
> > - set_irq_regs(old_regs);
> > - break;
> > -#ifdef CONFIG_SMP
> > - case RV_IRQ_SOFT:
> > - /*
> > -* We only use software interrupts to pass IPIs, so if a
> > non-SMP
> > -* system gets one, then we don't know what to do.
> > -*/
> > - handle_IPI(regs);
> > - break;
> > -#endif
> > - case RV_IRQ_EXT:
> > - old_regs = set_irq_regs(regs);
> > - irq_enter();
> > + if (handle_arch_irq)
> > handle_arch_irq(regs);
> > - irq_exit();
> > - set_irq_regs(old_regs);
> > - break;
> > - default:
> > - pr_alert("unexpected interrupt cause 0x%lx", regs->cause);
> > - BUG();
> > - }
> > }
> >
> > void __init init_IRQ(void)
> > {
> > irqchip_init();
> > + if (!handle_arch_irq)
> > + panic("No interrupt controller found.");
> > }
> > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> > index 7f58fa53033f..f48c76aadbf3 100644
> > --- a/arch/riscv/kernel/traps.c
> > +++ b/arch/riscv/kernel/traps.c
> > @@ -178,6 +178,4 @@ void trap_init(void)
> > csr_write(CSR_SCRATCH, 0);
> > /* Set the exception vector address */
> > csr_write(CSR_TVEC, &handle_exception);
> > - /* Enable interrupts */
> > - csr_write(CSR_IE, IE_SIE);
> > }
> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > index a85aada04a64..95d6137a8117 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -493,6 +493,19 @@ config TI_SCI_INTA_IRQCHIP
> > If you wish to use interrupt aggregator irq resources managed by
> > the
> > TI System Controller, say Y here. Otherwise, say N.
> >
> > +config RISCV_INTC
> > + bool "RISC-V Local Interrupt Controller"
> > + depends on RISCV
> > + default y
> > + help
> > +
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 06/02/2020 10:18 AM, John Hubbard wrote: > On 2020-06-01 21:20, Anshuman Khandual wrote: > ... >>> also important: maybe this patch should also be tracking other causes >>> of THP PMD migration failure, in order to get a truer accounting of the >>> situation. > > I hope one of the experts here can weigh in on that... > >> Is there any other failure reasons which are only specific to THP migration. >> Else, adding stats about generic migration failure reasons will just blur >> the overall understanding about THP migration successes and failure cases >> that results in splitting. >> > > Thinking about that: we do have PGMIGRATE_SUCCESS and PGMIGRATE_FAIL, so I > suppose comparing those numbers with the new THP_PMD_MIGRATION_SUCCESS and > THP_PMD_MIGRATION_FAILURE events should cover it. That is right. > > However, the fact that this is under discussion hints at the need for a > bit of documentation help. What do you think about adding some notes about > all of this to, say, Documentation/vm/page_migration.rst ? Sure but probably bit later. Because I am also planning to add couple of trace events for THP migration, hence will update the documentation part for both VM stat and trace events together.
[PATCH] spi: tegra20-slink: add missing pm_runtime_put
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-slink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..0675b36d647b 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1192,6 +1192,7 @@ static int tegra_slink_resume(struct device *dev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
dev_err(dev, "pm runtime failed, e = %d\n", ret);
+ pm_runtime_put(dev);
return ret;
}
tegra_slink_writel(tspi, tspi->command_reg, SLINK_COMMAND);
--
2.17.1
RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
Hi Oleksij, > Subject: Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M > > On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng@nxp.com wrote: > > From: Peng Fan > > > > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs > > > > Reviewed-by: Dong Aisheng > > Signed-off-by: Peng Fan > > --- > > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > index 26b7a88c2fea..906377acf2cd 100644 > > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > @@ -18,7 +18,8 @@ Messaging Unit Device Node: > > Required properties: > > --- > > - compatible : should be "fsl,-mu", the supported chips include > > - imx6sx, imx7s, imx8qxp, imx8qm. > > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn, > > + imx8mp. > > The "fsl,imx6sx-mu" compatible is seen as generic and should > > be included together with SoC specific compatible. > > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" > > -- > > 2.16.4 > > > > > > Hi Peng, > > The fsl,mu.yaml was already taken by Rob, so one or other patch will break by > merge. I assume you should drop this change. Yes. I'll rebase this patch based on Rob's tree. Thanks for reminding me. Thanks, Peng. > > > Regards, > Oleksij > -- > Pengutronix e.K. | > | > Steuerwalder Str. 21 | > http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: > +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: > +49-5121-206917- |
drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: "CONFIG_RAM_BASE" redefined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f359287765c04711ff54fbd11645271d8e5ff763 commit: 5b49c82dadfe0f3741778f57385f964ec1514863 csky: Add PCI support date: 3 months ago config: csky-randconfig-r024-20200602 (attached as .config) compiler: csky-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 git checkout 5b49c82dadfe0f3741778f57385f964ec1514863 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=csky If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot All warnings (new ones prefixed by >>, old ones prefixed by <<): In file included from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/module.h:12, from drivers/net/ethernet/intel/e1000/e1000.h:10, from drivers/net/ethernet/intel/e1000/e1000_main.c:4: include/asm-generic/fixmap.h: In function 'fix_to_virt': include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~ include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert' 330 | if (!(condition)) | ^ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ 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/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON' 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~~~ In file included from drivers/net/ethernet/intel/e1000/e1000_hw.h:11, from drivers/net/ethernet/intel/e1000/e1000.h:54, from drivers/net/ethernet/intel/e1000/e1000_main.c:4: drivers/net/ethernet/intel/e1000/e1000_osdep.h: At top level: >> drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: >> "CONFIG_RAM_BASE" redefined 13 | #define CONFIG_RAM_BASE 0x6 | In file included from include/linux/kconfig.h:5, from : ./include/generated/autoconf.h:1690: note: this is the location of the previous definition 1690 | #define CONFIG_RAM_BASE 0x0 | -- In file included from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/module.h:12, from drivers/net/ethernet/intel/e1000/e1000.h:10, from drivers/net/ethernet/intel/e1000/e1000_hw.c:8: include/asm-generic/fixmap.h: In function 'fix_to_virt': include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~ include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert' 330 | if (!(condition)) | ^ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ 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/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON' 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~~~ In file included from drivers/net/ethernet/intel/e1000/e1000_hw.h:11, from drivers/net/ethernet/intel/e1000/e1000.h:54, from drivers/net/ethernet/intel/e1000/e1000_hw.c:8: drivers/net/ethernet/intel/e1000/e1000_osdep.h: At top level: >> drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: >> "CONFIG_RAM_BASE" redefined 13 | #define CONFIG_RAM_BASE 0x6 | In file included from include/linux/kconfig.h:5, from : ./include/generated/autoconf.h:1690: note: this is the location of the previous definition 1690 | #define CONFIG_RAM_BASE 0x0 | drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 'e1000_phy_init_script': drivers/net/ethernet/intel/e1000/e1000_hw.c:132:6: warning: variable 'ret_val' set but not used [-Wunused-but-set-variable] 132 | u32 ret_val; | ^~~ drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 'e1000_reset_hw': drivers/net/ethernet/intel/e1000/e1000_hw.c:380:6: warning:
[PATCH v2 net-next 03/10] net: mscc: ocelot: allocated rules to different hardware VCAP TCAMs by chain index
There are three hardware TCAMs for ocelot chips: IS1, IS2 and ES0. Each
one supports different actions. The hardware flow order is: IS1->IS2->ES0.
This patch add three blocks to store rules according to chain index.
chain 0 is offloaded to IS1, chain 1 is offloaded to IS2, and egress chain
0 is offloaded to ES0.
Using action goto chain to express flow order as follows:
tc filter add dev swp0 chain 0 parent : flower skip_sw \
action goto chain 1
Signed-off-by: Xiaoliang Yang
---
drivers/net/ethernet/mscc/ocelot_ace.c| 51 +++
drivers/net/ethernet/mscc/ocelot_ace.h| 7 ++--
drivers/net/ethernet/mscc/ocelot_flower.c | 46 +---
include/soc/mscc/ocelot.h | 2 +-
include/soc/mscc/ocelot_vcap.h| 4 +-
5 files changed, 81 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ace.c
index 748c618db7d8..b76593b40097 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -341,6 +341,8 @@ static void is2_action_set(struct ocelot *ocelot, struct
vcap_data *data,
vcap_action_set(vcap, data, VCAP_IS2_ACT_CPU_QU_NUM, 0);
vcap_action_set(vcap, data, VCAP_IS2_ACT_CPU_COPY_ENA, 0);
break;
+ default:
+ break;
}
}
@@ -644,9 +646,9 @@ static void is2_entry_set(struct ocelot *ocelot, int ix,
}
static void vcap_entry_get(struct ocelot *ocelot, struct ocelot_ace_rule *rule,
- int ix)
+ int ix, int block_id)
{
- const struct vcap_props *vcap = &ocelot->vcap[VCAP_IS2];
+ const struct vcap_props *vcap = &ocelot->vcap[block_id];
struct vcap_data data;
int row, count;
u32 cnt;
@@ -663,6 +665,19 @@ static void vcap_entry_get(struct ocelot *ocelot, struct
ocelot_ace_rule *rule,
rule->stats.pkts = cnt;
}
+static void vcap_entry_set(struct ocelot *ocelot, int ix,
+ struct ocelot_ace_rule *ace,
+ int block_id)
+{
+ switch (block_id) {
+ case VCAP_IS2:
+ is2_entry_set(ocelot, ix, ace);
+ break;
+ default:
+ break;
+ }
+}
+
static void ocelot_ace_rule_add(struct ocelot *ocelot,
struct ocelot_acl_block *block,
struct ocelot_ace_rule *rule)
@@ -790,7 +805,7 @@ static bool ocelot_ace_is_problematic_non_mac_etype(struct
ocelot_ace_rule *ace)
static bool ocelot_exclusive_mac_etype_ace_rules(struct ocelot *ocelot,
struct ocelot_ace_rule *ace)
{
- struct ocelot_acl_block *block = &ocelot->acl_block;
+ struct ocelot_acl_block *block = &ocelot->acl_block[VCAP_IS2];
struct ocelot_ace_rule *tmp;
unsigned long port;
int i;
@@ -824,15 +839,16 @@ static bool ocelot_exclusive_mac_etype_ace_rules(struct
ocelot *ocelot,
return true;
}
-int ocelot_ace_rule_offload_add(struct ocelot *ocelot,
+int ocelot_ace_rule_offload_add(struct ocelot *ocelot, int block_id,
struct ocelot_ace_rule *rule,
struct netlink_ext_ack *extack)
{
- struct ocelot_acl_block *block = &ocelot->acl_block;
+ struct ocelot_acl_block *block = &ocelot->acl_block[block_id];
struct ocelot_ace_rule *ace;
int i, index;
- if (!ocelot_exclusive_mac_etype_ace_rules(ocelot, rule)) {
+ if (block_id == VCAP_IS2 &&
+ !ocelot_exclusive_mac_etype_ace_rules(ocelot, rule)) {
NL_SET_ERR_MSG_MOD(extack,
"Cannot mix MAC_ETYPE with non-MAC_ETYPE
rules");
return -EBUSY;
@@ -847,11 +863,11 @@ int ocelot_ace_rule_offload_add(struct ocelot *ocelot,
/* Move down the rules to make place for the new rule */
for (i = block->count - 1; i > index; i--) {
ace = ocelot_ace_rule_get_rule_index(block, i);
- is2_entry_set(ocelot, i, ace);
+ vcap_entry_set(ocelot, i, ace, block_id);
}
/* Now insert the new rule */
- is2_entry_set(ocelot, index, rule);
+ vcap_entry_set(ocelot, index, rule, block_id);
return 0;
}
@@ -902,10 +918,10 @@ static void ocelot_ace_rule_del(struct ocelot *ocelot,
block->count--;
}
-int ocelot_ace_rule_offload_del(struct ocelot *ocelot,
+int ocelot_ace_rule_offload_del(struct ocelot *ocelot, int block_id,
struct ocelot_ace_rule *rule)
{
- struct ocelot_acl_block *block = &ocelot->acl_block;
+ struct ocelot_acl_block *block = &ocelot->acl_block[block_id];
struct ocelot_ace_rule del_ace;
struct ocelot_ace_rule *ace;
int i, index;
@@ -921,29 +937,29 @@ int ocelot_ace_rule_offload_del(stru
Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng@nxp.com wrote: > From: Peng Fan > > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs > > Reviewed-by: Dong Aisheng > Signed-off-by: Peng Fan > --- > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > index 26b7a88c2fea..906377acf2cd 100644 > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > @@ -18,7 +18,8 @@ Messaging Unit Device Node: > Required properties: > --- > - compatible : should be "fsl,-mu", the supported chips include > - imx6sx, imx7s, imx8qxp, imx8qm. > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn, > + imx8mp. > The "fsl,imx6sx-mu" compatible is seen as generic and should > be included together with SoC specific compatible. > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" > -- > 2.16.4 > > Hi Peng, The fsl,mu.yaml was already taken by Rob, so one or other patch will break by merge. I assume you should drop this change. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
[PATCH] spi: tegra20-slink: add missing pm_runtime_put if pm_runtime_get_sync fails
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-slink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..9509b7cb14e4 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -756,6 +756,7 @@ static int tegra_slink_setup(struct spi_device *spi)
ret = pm_runtime_get_sync(tspi->dev);
if (ret < 0) {
dev_err(tspi->dev, "pm runtime failed, e = %d\n", ret);
+ pm_runtime_put(tspi->dev);
return ret;
}
--
2.17.1
Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)
Hello, On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote: > > Apologies for the delayed update. Its been quite some time since I > posted the last version (v5), but I have been really caught up in some > other critical issues. > > Changes since v5: > > - v5 can be viewed here: > http://lists.infradead.org/pipermail/kexec/2019-November/024055.html > - Addressed review comments from James Morse and Boris. > - Added Tested-by received from John on v5 patchset. > - Rebased against arm64 (for-next/ptr-auth) branch which has Amit's > patchset for ARMv8.3-A Pointer Authentication feature vmcoreinfo > applied. > > Changes since v4: > > - v4 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-November/023961.html > - Addressed comments from Dave and added patches for documenting > new variables appended to vmcoreinfo documentation. > - Added testing report shared by Akashi for PATCH 2/5. > > Changes since v3: > > - v3 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-March/022590.html > - Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo > instead of PTRS_PER_PGD. > - Added a new patch (via [PATCH 3/3]), which fixes a simple typo in > 'Documentation/arm64/memory.rst' > > Changes since v2: > > - v2 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-March/022531.html > - Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPARSEMEM > ifdef sections, as suggested by Kazu. > - Updated vmcoreinfo documentation to add description about > 'MAX_PHYSMEM_BITS' variable (via [PATCH 3/3]). > > Changes since v1: > > - v1 was sent out as a single patch which can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-February/022411.html > > - v2 breaks the single patch into two independent patches: > [PATCH 1/2] appends 'PTRS_PER_PGD' to vmcoreinfo for arm64 arch, whereas > [PATCH 2/2] appends 'MAX_PHYSMEM_BITS' to vmcoreinfo in core kernel code > (all archs) > > This patchset primarily fixes the regression reported in user-space > utilities like 'makedumpfile' and 'crash-utility' on arm64 architecture > with the availability of 52-bit address space feature in underlying > kernel. These regressions have been reported both on CPUs which don't > support ARMv8.2 extensions (i.e. LVA, LPA) and are running newer kernels > and also on prototype platforms (like ARMv8 FVP simulator model) which > support ARMv8.2 extensions and are running newer kernels. > > The reason for these regressions is that right now user-space tools > have no direct access to these values (since these are not exported > from the kernel) and hence need to rely on a best-guess method of > determining value of 'vabits_actual' and 'MAX_PHYSMEM_BITS' supported > by underlying kernel. > > Exporting these values via vmcoreinfo will help user-land in such cases. > In addition, as per suggestion from makedumpfile maintainer (Kazu), > it makes more sense to append 'MAX_PHYSMEM_BITS' to > vmcoreinfo in the core code itself rather than in arm64 arch-specific > code, so that the user-space code for other archs can also benefit from > this addition to the vmcoreinfo and use it as a standard way of > determining 'SECTIONS_SHIFT' value in user-land. > > Cc: Boris Petkov > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: Jonathan Corbet > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Steve Capper > Cc: Catalin Marinas > Cc: Ard Biesheuvel > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Benjamin Herrenschmidt > Cc: Dave Anderson > Cc: Kazuhito Hagio > Cc: John Donnelly > Cc: scott.bran...@broadcom.com > Cc: Amit Kachhap > Cc: x...@kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: ke...@lists.infradead.org > > Bhupesh Sharma (2): > crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo > arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo > > Documentation/admin-guide/kdump/vmcoreinfo.rst | 16 > arch/arm64/include/asm/pgtable-hwdef.h | 1 + > arch/arm64/kernel/crash_core.c | 10 ++ > kernel/crash_core.c| 1 + > 4 files changed, 28 insertions(+) Ping. @James Morse , Others Please share if you have some comments regarding this patchset. Thanks, Bhupesh
[PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot
Ever since 5.7-rc1, if we call ath10k_qmi_remove_msa_permission(), the db845c hard crashes on reboot, resulting in the device getting stuck in the usb crash debug mode and not coming back up wihthout a hard power off. This hack avoids the issue by returning early in ath10k_qmi_event_server_exit(). A better solution is very much desired! Feedback and suggestions welcome! Cc: Rakesh Pillai Cc: Govind Singh Cc: Bjorn Andersson Cc: Niklas Cassel Cc: Manivannan Sadhasivam Cc: Amit Pundir Cc: Brian Norris Cc: Kalle Valo Cc: ath...@lists.infradead.org Reported-by: Amit Pundir Signed-off-by: John Stultz --- drivers/net/wireless/ath/ath10k/qmi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c index 85dce43c5439..ab38562ce1cb 100644 --- a/drivers/net/wireless/ath/ath10k/qmi.c +++ b/drivers/net/wireless/ath/ath10k/qmi.c @@ -854,6 +854,11 @@ static void ath10k_qmi_event_server_exit(struct ath10k_qmi *qmi) struct ath10k *ar = qmi->ar; struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar); + /* +* HACK: Calling ath10k_qmi_remove_msa_permission causes +* hardware to hard crash on reboot +*/ + return; ath10k_qmi_remove_msa_permission(qmi); ath10k_core_free_board_files(ar); if (!test_bit(ATH10K_SNOC_FLAG_UNREGISTERING, &ar_snoc->flags)) -- 2.17.1
[PATCH v2 net-next 04/10] net: mscc: ocelot: change vcap to be compatible with full and quad entry
When calculating vcap data offset, the function only supports half key entry. This patch modify vcap_data_offset_get function to calculate a correct data offset when setting VCAP Type-Group to VCAP_TG_FULL or VCAP_TG_QUARTER. Signed-off-by: Xiaoliang Yang --- drivers/net/ethernet/mscc/ocelot_ace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c b/drivers/net/ethernet/mscc/ocelot_ace.c index b76593b40097..8c384b0771bb 100644 --- a/drivers/net/ethernet/mscc/ocelot_ace.c +++ b/drivers/net/ethernet/mscc/ocelot_ace.c @@ -175,8 +175,8 @@ static void vcap_data_offset_get(const struct vcap_props *vcap, u32 i, col, offset, count, cnt, base; u32 width = vcap->tg_width; - count = (data->tg_sw == VCAP_TG_HALF ? 2 : 4); - col = (ix % 2); + count = (1 << (data->tg_sw - 1)); + col = (ix % count); cnt = (vcap->sw_count / count); base = (vcap->sw_count - col * cnt - cnt); data->tg_value = 0; -- 2.17.1
[PATCH v2 net-next 10/10] net: dsa: tag_ocelot: use VLAN information from tagging header when available
From: Vladimir Oltean
When the Extraction Frame Header contains a valid classified VLAN, use
that instead of the VLAN header present in the packet.
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_ocelot.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/net/dsa/tag_ocelot.c b/net/dsa/tag_ocelot.c
index b0c98ee4e13b..253188b0e56b 100644
--- a/net/dsa/tag_ocelot.c
+++ b/net/dsa/tag_ocelot.c
@@ -181,9 +181,16 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
struct net_device *netdev,
struct packet_type *pt)
{
+ struct dsa_port *cpu_dp = netdev->dsa_ptr;
+ struct dsa_switch *ds = cpu_dp->ds;
+ struct ocelot *ocelot = ds->priv;
+ struct ocelot_port *ocelot_port;
u64 src_port, qos_class;
u8 *start = skb->data;
+ struct ethhdr *hdr;
u8 *extraction;
+ u64 vlan_tci;
+ u16 vid;
/* Revert skb->data by the amount consumed by the DSA master,
* so it points to the beginning of the frame.
@@ -211,6 +218,7 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
packing(extraction, &src_port, 46, 43, OCELOT_TAG_LEN, UNPACK, 0);
packing(extraction, &qos_class, 19, 17, OCELOT_TAG_LEN, UNPACK, 0);
+ packing(extraction, &vlan_tci, 15, 0, OCELOT_TAG_LEN, UNPACK, 0);
skb->dev = dsa_master_find_slave(netdev, 0, src_port);
if (!skb->dev)
@@ -225,6 +233,27 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
skb->offload_fwd_mark = 1;
skb->priority = qos_class;
+ /* The VID from the extraction header contains the classified VLAN. But
+* if VLAN awareness is off and no retagging is done via VCAP IS1, that
+* classified VID will always be the pvid of the src_port.
+* port. We want Linux to see the classified VID, but only if the switch
+* intended to send the packet as untagged, i.e. if the VID is different
+* than the CPU port's untagged (native) VID.
+*/
+ vid = vlan_tci & VLAN_VID_MASK;
+ hdr = eth_hdr(skb);
+ ocelot_port = ocelot->ports[src_port];
+ if (hdr->h_proto == htons(ETH_P_8021Q) && vid != ocelot_port->pvid) {
+ u16 dummy_vlan_tci;
+
+ skb_push_rcsum(skb, ETH_HLEN);
+ __skb_vlan_pop(skb, &dummy_vlan_tci);
+ skb_pull_rcsum(skb, ETH_HLEN);
+ skb_reset_network_header(skb);
+ skb_reset_transport_header(skb);
+ __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tci);
+ }
+
return skb;
}
--
2.17.1
[PATCH v2 net-next 05/10] net: mscc: ocelot: VCAP IS1 support
VCAP IS1 is a VCAP module which can filter MAC, IP, VLAN, protocol, and
TCP/UDP ports keys, and do Qos classified and VLAN retag actions.
This patch added VCAP IS1 support in ocelot ace driver, which can supports
vlan modify and skbedit priority action of tc filter.
Usage:
tc qdisc add dev swp0 ingress
tc filter add dev swp0 protocol 802.1Q parent : flower \
skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c| 102 +++
drivers/net/ethernet/mscc/ocelot.c| 7 +
drivers/net/ethernet/mscc/ocelot_ace.c| 198 +-
drivers/net/ethernet/mscc/ocelot_ace.h| 11 ++
drivers/net/ethernet/mscc/ocelot_flower.c | 11 ++
drivers/net/ethernet/mscc/ocelot_regs.c | 1 +
include/soc/mscc/ocelot.h | 1 +
include/soc/mscc/ocelot_vcap.h| 91 ++
8 files changed, 421 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index ef3bf875e64c..f08a5f1c61a5 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -16,6 +16,8 @@
#define VSC9959_VCAP_IS2_CNT 1024
#define VSC9959_VCAP_IS2_ENTRY_WIDTH 376
#define VSC9959_VCAP_PORT_CNT 6
+#define VSC9959_VCAP_IS1_CNT 256
+#define VSC9959_VCAP_IS1_ENTRY_WIDTH 376
/* TODO: should find a better place for these */
#define USXGMII_BMCR_RESET BIT(15)
@@ -337,6 +339,7 @@ static const u32 *vsc9959_regmap[] = {
[QSYS] = vsc9959_qsys_regmap,
[REW] = vsc9959_rew_regmap,
[SYS] = vsc9959_sys_regmap,
+ [S1]= vsc9959_vcap_regmap,
[S2]= vsc9959_vcap_regmap,
[PTP] = vsc9959_ptp_regmap,
[GCB] = vsc9959_gcb_regmap,
@@ -369,6 +372,11 @@ static const struct resource vsc9959_target_io_res[] = {
.end= 0x001,
.name = "sys",
},
+ [S1] = {
+ .start = 0x005,
+ .end= 0x00503ff,
+ .name = "s1",
+ },
[S2] = {
.start = 0x006,
.end= 0x00603ff,
@@ -559,6 +567,80 @@ static const struct ocelot_stat_layout
vsc9959_stats_layout[] = {
{ .offset = 0x111, .name = "drop_green_prio_7", },
};
+struct vcap_field vsc9959_vcap_is1_keys[] = {
+ [VCAP_IS1_HK_TYPE] = { 0, 1},
+ [VCAP_IS1_HK_LOOKUP]= { 1, 2},
+ [VCAP_IS1_HK_IGR_PORT_MASK] = { 3, 7},
+ [VCAP_IS1_HK_RSV] = { 10, 9},
+ [VCAP_IS1_HK_OAM_Y1731] = { 19, 1},
+ [VCAP_IS1_HK_L2_MC] = { 20, 1},
+ [VCAP_IS1_HK_L2_BC] = { 21, 1},
+ [VCAP_IS1_HK_IP_MC] = { 22, 1},
+ [VCAP_IS1_HK_VLAN_TAGGED] = { 23, 1},
+ [VCAP_IS1_HK_VLAN_DBL_TAGGED] = { 24, 1},
+ [VCAP_IS1_HK_TPID] = { 25, 1},
+ [VCAP_IS1_HK_VID] = { 26, 12},
+ [VCAP_IS1_HK_DEI] = { 38, 1},
+ [VCAP_IS1_HK_PCP] = { 39, 3},
+ /* Specific Fields for IS1 Half Key S1_NORMAL */
+ [VCAP_IS1_HK_L2_SMAC] = { 42, 48},
+ [VCAP_IS1_HK_ETYPE_LEN] = { 90, 1},
+ [VCAP_IS1_HK_ETYPE] = { 91, 16},
+ [VCAP_IS1_HK_IP_SNAP] = {107, 1},
+ [VCAP_IS1_HK_IP4] = {108, 1},
+ /* Layer-3 Information */
+ [VCAP_IS1_HK_L3_FRAGMENT] = {109, 1},
+ [VCAP_IS1_HK_L3_FRAG_OFS_GT0] = {110, 1},
+ [VCAP_IS1_HK_L3_OPTIONS]= {111, 1},
+ [VCAP_IS1_HK_L3_DSCP] = {112, 6},
+ [VCAP_IS1_HK_L3_IP4_SIP]= {118, 32},
+ /* Layer-4 Information */
+ [VCAP_IS1_HK_TCP_UDP] = {150, 1},
+ [VCAP_IS1_HK_TCP] = {151, 1},
+ [VCAP_IS1_HK_L4_SPORT] = {152, 16},
+ [VCAP_IS1_HK_L4_RNG]= {168, 8},
+ /* Specific Fields for IS1 Half Key S1_5TUPLE_IP4 */
+ [VCAP_IS1_HK_IP4_INNER_TPID]= { 42, 1},
+ [VCAP_IS1_HK_IP4_INNER_VID] = { 43, 12},
+ [VCAP_IS1_HK_IP4_INNER_DEI] = { 55, 1},
+ [VCAP_IS1_HK_IP4_INNER_PCP] = { 56, 3},
+ [VCAP_IS1_HK_IP4_IP4] = { 59, 1},
+ [VCAP_IS1_HK_IP4_L3_FRAGMENT] = { 60, 1},
+ [VCAP_IS1_HK_IP4_L3_FRAG_OFS_GT0] = { 61, 1},
+ [VCAP_IS1_HK_IP4_L3_OPTIONS]= { 62, 1},
+ [VCAP_IS1_HK_IP4_L3_DSCP] = { 63, 6},
+ [VCAP_IS1_HK_IP4_L3_IP4_DIP]
[PATCH v2 net-next 09/10] net: dsa: felix: correct VCAP IS2 keys offset
Some of IS2 IP4_TCP_UDP keys are not correct, like L4_DPORT, L4_SPORT
and other L4 keys. It causes the issue that VCAP IS2 could not filter
a right dst/src port for TCP/UDP packages.
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index fceba87509ba..539f3c062b50 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -730,17 +730,17 @@ struct vcap_field vsc9959_vcap_is2_keys[] = {
[VCAP_IS2_HK_DIP_EQ_SIP]= {118, 1},
/* IP4_TCP_UDP (TYPE=100) */
[VCAP_IS2_HK_TCP] = {119, 1},
- [VCAP_IS2_HK_L4_SPORT] = {120, 16},
- [VCAP_IS2_HK_L4_DPORT] = {136, 16},
+ [VCAP_IS2_HK_L4_DPORT] = {120, 16},
+ [VCAP_IS2_HK_L4_SPORT] = {136, 16},
[VCAP_IS2_HK_L4_RNG]= {152, 8},
[VCAP_IS2_HK_L4_SPORT_EQ_DPORT] = {160, 1},
[VCAP_IS2_HK_L4_SEQUENCE_EQ0] = {161, 1},
- [VCAP_IS2_HK_L4_URG]= {162, 1},
- [VCAP_IS2_HK_L4_ACK]= {163, 1},
- [VCAP_IS2_HK_L4_PSH]= {164, 1},
- [VCAP_IS2_HK_L4_RST]= {165, 1},
- [VCAP_IS2_HK_L4_SYN]= {166, 1},
- [VCAP_IS2_HK_L4_FIN]= {167, 1},
+ [VCAP_IS2_HK_L4_FIN]= {162, 1},
+ [VCAP_IS2_HK_L4_SYN]= {163, 1},
+ [VCAP_IS2_HK_L4_RST]= {164, 1},
+ [VCAP_IS2_HK_L4_PSH]= {165, 1},
+ [VCAP_IS2_HK_L4_ACK]= {166, 1},
+ [VCAP_IS2_HK_L4_URG]= {167, 1},
[VCAP_IS2_HK_L4_1588_DOM] = {168, 8},
[VCAP_IS2_HK_L4_1588_VER] = {176, 4},
/* IP4_OTHER (TYPE=101) */
--
2.17.1
[PATCH v2 net-next 08/10] net: ocelot: return error if rule is not found
Return error if rule is not found in rule list to avoid Kernel panic.
Signed-off-by: Xiaoliang Yang
---
drivers/net/ethernet/mscc/ocelot_ace.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ace.c
index bf2b7a03c832..2ba2859fa2cd 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -982,9 +982,9 @@ static int ocelot_ace_rule_get_index_id(struct
ocelot_acl_block *block,
list_for_each_entry(tmp, &block->rules, list) {
++index;
if (rule->id == tmp->id)
- break;
+ return index;
}
- return index;
+ return -ENOENT;
}
static struct ocelot_ace_rule*
@@ -1197,6 +1197,8 @@ int ocelot_ace_rule_offload_del(struct ocelot *ocelot,
int block_id,
/* Gets index of the rule */
index = ocelot_ace_rule_get_index_id(block, rule);
+ if (index < 0)
+ return -ENOENT;
/* Delete rule */
ocelot_ace_rule_del(ocelot, block, rule);
@@ -1221,6 +1223,9 @@ int ocelot_ace_rule_stats_update(struct ocelot *ocelot,
int block_id,
int index;
index = ocelot_ace_rule_get_index_id(block, rule);
+ if (index < 0)
+ return -ENOENT;
+
vcap_entry_get(ocelot, rule, index, block_id);
/* After we get the result we need to clear the counters */
--
2.17.1
[PATCH v2 net-next 07/10] net: mscc: ocelot: multiple actions support
Support multiple actions for each flower rule, multiple actions can only
set on the same VCAP, and all actions can mix with action goto chain.
Action drop, trap, and police on VCAP IS2 could not be mixed.
Signed-off-by: Xiaoliang Yang
---
drivers/net/ethernet/mscc/ocelot_ace.c| 15 +--
drivers/net/ethernet/mscc/ocelot_ace.h| 8 +++-
drivers/net/ethernet/mscc/ocelot_flower.c | 14 +-
3 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ace.c
index 76d679b8d15e..bf2b7a03c832 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -651,20 +651,23 @@ static void is1_action_set(struct ocelot *ocelot, struct
vcap_data *data,
const struct vcap_props *vcap = &ocelot->vcap[VCAP_IS1];
switch (ace->action) {
+ case OCELOT_ACL_ACTION_PRIORITY:
case OCELOT_ACL_ACTION_VLAN_MODIFY:
- vcap_action_set(vcap, data, VCAP_IS1_ACT_VID_REPLACE_ENA, 1);
+ vcap_action_set(vcap, data, VCAP_IS1_ACT_VID_REPLACE_ENA,
+ ace->vlan_modify.ena);
vcap_action_set(vcap, data, VCAP_IS1_ACT_VID_ADD_VAL,
ace->vlan_modify.vid);
- vcap_action_set(vcap, data, VCAP_IS1_ACT_PCP_DEI_ENA, 1);
+ vcap_action_set(vcap, data, VCAP_IS1_ACT_PCP_DEI_ENA,
+ ace->vlan_modify.ena);
vcap_action_set(vcap, data, VCAP_IS1_ACT_PCP_VAL,
ace->vlan_modify.pcp);
vcap_action_set(vcap, data, VCAP_IS1_ACT_DEI_VAL,
ace->vlan_modify.dei);
- break;
- case OCELOT_ACL_ACTION_PRIORITY:
- vcap_action_set(vcap, data, VCAP_IS1_ACT_QOS_ENA, 1);
+
+ vcap_action_set(vcap, data, VCAP_IS1_ACT_QOS_ENA,
+ ace->qos_modify.ena);
vcap_action_set(vcap, data, VCAP_IS1_ACT_QOS_VAL,
- ace->qos_val);
+ ace->qos_modify.qos_val);
break;
default:
break;
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.h
b/drivers/net/ethernet/mscc/ocelot_ace.h
index 70fe45d747fb..02fa81b3fe92 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.h
+++ b/drivers/net/ethernet/mscc/ocelot_ace.h
@@ -97,6 +97,12 @@ struct ocelot_ace_action_vlan {
u16 vid;
u8 pcp;
u8 dei;
+ u8 ena;
+};
+
+struct ocelot_ace_action_qos {
+ u8 qos_val;
+ u8 ena;
};
struct ocelot_ace_frame_etype {
@@ -212,6 +218,7 @@ struct ocelot_ace_rule {
enum ocelot_vcap_bit dmac_bc;
struct ocelot_ace_vlan vlan;
struct ocelot_ace_action_vlan vlan_modify;
+ struct ocelot_ace_action_qos qos_modify;
enum ocelot_ace_type type;
union {
@@ -225,7 +232,6 @@ struct ocelot_ace_rule {
} frame;
struct ocelot_policer pol;
u32 pol_ix;
- u8 qos_val;
};
int ocelot_ace_rule_offload_add(struct ocelot *ocelot, int block_id,
diff --git a/drivers/net/ethernet/mscc/ocelot_flower.c
b/drivers/net/ethernet/mscc/ocelot_flower.c
index d598e103c796..6ce37f152f12 100644
--- a/drivers/net/ethernet/mscc/ocelot_flower.c
+++ b/drivers/net/ethernet/mscc/ocelot_flower.c
@@ -32,9 +32,6 @@ static int ocelot_flower_parse_action(struct flow_cls_offload
*f,
s64 burst;
u64 rate;
- if (!flow_offload_has_one_action(&f->rule->action))
- return -EOPNOTSUPP;
-
if (!flow_action_basic_hw_stats_check(&f->rule->action,
f->common.extack))
return -EOPNOTSUPP;
@@ -42,14 +39,20 @@ static int ocelot_flower_parse_action(struct
flow_cls_offload *f,
flow_action_for_each(i, a, &f->rule->action) {
switch (a->id) {
case FLOW_ACTION_DROP:
+ if (i)
+ return -EOPNOTSUPP;
ace->action = OCELOT_ACL_ACTION_DROP;
allowed_chain = 1;
break;
case FLOW_ACTION_TRAP:
+ if (i)
+ return -EOPNOTSUPP;
ace->action = OCELOT_ACL_ACTION_TRAP;
allowed_chain = 1;
break;
case FLOW_ACTION_POLICE:
+ if (i)
+ return -EOPNOTSUPP;
ace->action = OCELOT_ACL_ACTION_POLICE;
rate = a->police.rate_bytes_ps;
ace->pol.rate = div_u64(rate, 1000) * 8;
@@ -62,18 +65,19 @@ static int ocelot_flower_parse_action(struct
flow_cls_offload *f,
NL_SET_ERR_MSG_MOD(extack, "HW only support
goto next chain\n");
[PATCH v2 net-next 06/10] net: mscc: ocelot: VCAP ES0 support
VCAP ES0 is an egress VCAP working on all outgoing frames.
This patch added ES0 driver to support vlan push action of tc filter.
Usage:
tc filter add dev swp1 egress protocol 802.1Q flower skip_sw
vlan_id 1 vlan_prio 1 action vlan push id 2 priority 2
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c| 59 ++
drivers/net/ethernet/mscc/ocelot.c| 4 ++
drivers/net/ethernet/mscc/ocelot_ace.c| 74 ++-
drivers/net/ethernet/mscc/ocelot_ace.h| 2 +
drivers/net/ethernet/mscc/ocelot_flower.c | 29 ++---
include/soc/mscc/ocelot.h | 1 +
include/soc/mscc/ocelot_vcap.h| 42 +
7 files changed, 203 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index f08a5f1c61a5..fceba87509ba 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -18,6 +18,7 @@
#define VSC9959_VCAP_PORT_CNT 6
#define VSC9959_VCAP_IS1_CNT 256
#define VSC9959_VCAP_IS1_ENTRY_WIDTH 376
+#define VSC9959_VCAP_ES0_CNT1024
/* TODO: should find a better place for these */
#define USXGMII_BMCR_RESET BIT(15)
@@ -339,6 +340,7 @@ static const u32 *vsc9959_regmap[] = {
[QSYS] = vsc9959_qsys_regmap,
[REW] = vsc9959_rew_regmap,
[SYS] = vsc9959_sys_regmap,
+ [S0]= vsc9959_vcap_regmap,
[S1]= vsc9959_vcap_regmap,
[S2]= vsc9959_vcap_regmap,
[PTP] = vsc9959_ptp_regmap,
@@ -372,6 +374,11 @@ static const struct resource vsc9959_target_io_res[] = {
.end= 0x001,
.name = "sys",
},
+ [S0] = {
+ .start = 0x004,
+ .end= 0x00403ff,
+ .name = "s0",
+ },
[S1] = {
.start = 0x005,
.end= 0x00503ff,
@@ -567,6 +574,38 @@ static const struct ocelot_stat_layout
vsc9959_stats_layout[] = {
{ .offset = 0x111, .name = "drop_green_prio_7", },
};
+struct vcap_field vsc9959_vcap_es0_keys[] = {
+ [VCAP_ES0_EGR_PORT] = { 0, 3},
+ [VCAP_ES0_IGR_PORT] = { 3, 3},
+ [VCAP_ES0_RSV] = { 6, 2},
+ [VCAP_ES0_L2_MC]= { 8, 1},
+ [VCAP_ES0_L2_BC]= { 9, 1},
+ [VCAP_ES0_VID] = { 10, 12},
+ [VCAP_ES0_DP] = { 22, 1},
+ [VCAP_ES0_PCP] = { 23, 3},
+};
+
+struct vcap_field vsc9959_vcap_es0_actions[] = {
+ [VCAP_ES0_ACT_PUSH_OUTER_TAG] = { 0, 2},
+ [VCAP_ES0_ACT_PUSH_INNER_TAG] = { 2, 1},
+ [VCAP_ES0_ACT_TAG_A_TPID_SEL] = { 3, 2},
+ [VCAP_ES0_ACT_TAG_A_VID_SEL]= { 5, 1},
+ [VCAP_ES0_ACT_TAG_A_PCP_SEL]= { 6, 2},
+ [VCAP_ES0_ACT_TAG_A_DEI_SEL]= { 8, 2},
+ [VCAP_ES0_ACT_TAG_B_TPID_SEL] = { 10, 2},
+ [VCAP_ES0_ACT_TAG_B_VID_SEL]= { 12, 1},
+ [VCAP_ES0_ACT_TAG_B_PCP_SEL]= { 13, 2},
+ [VCAP_ES0_ACT_TAG_B_DEI_SEL]= { 15, 2},
+ [VCAP_ES0_ACT_VID_A_VAL]= { 17, 12},
+ [VCAP_ES0_ACT_PCP_A_VAL]= { 29, 3},
+ [VCAP_ES0_ACT_DEI_A_VAL]= { 32, 1},
+ [VCAP_ES0_ACT_VID_B_VAL]= { 33, 12},
+ [VCAP_ES0_ACT_PCP_B_VAL]= { 45, 3},
+ [VCAP_ES0_ACT_DEI_B_VAL]= { 48, 1},
+ [VCAP_ES0_ACT_RSV] = { 49, 23},
+ [VCAP_ES0_ACT_HIT_STICKY] = { 72, 1},
+};
+
struct vcap_field vsc9959_vcap_is1_keys[] = {
[VCAP_IS1_HK_TYPE] = { 0, 1},
[VCAP_IS1_HK_LOOKUP]= { 1, 2},
@@ -740,6 +779,26 @@ struct vcap_field vsc9959_vcap_is2_actions[] = {
};
static const struct vcap_props vsc9959_vcap_props[] = {
+ [VCAP_ES0] = {
+ .tg_width = 1,
+ .sw_count = 1,
+ .entry_count = VSC9959_VCAP_ES0_CNT,
+ .entry_width = 29,
+ .action_count = VSC9959_VCAP_ES0_CNT + 6,
+ .action_width = 72,
+ .action_type_width = 0,
+ .action_table = {
+ [ES0_ACTION_TYPE_NORMAL] = {
+ .width = 72,
+ .count = 1
+ },
+ },
+ .counter_words = 1,
+ .counter_width = 1,
+ .target = S0,
+ .keys = vsc9959_vcap_es0_keys,
+ .actions = vsc9959_vcap_es0_actions,
+ },
[VCAP_IS1] = {
.tg_width = 2,
.sw_count = 4,
diff --git
[PATCH v2 net-next 02/10] net: mscc: ocelot: generalize existing code for VCAP
From: Vladimir Oltean
The Ocelot driver only supports VCAP IS2, the security enforcement block
which implements Access Control List actions (trap, drop, police).
In preparation of VCAP IS1 support, generalize the existing code to work
with any VCAP. In that direction, move all VCAP instantiation-specific
data to struct vcap_props, and pass that as an argument to each function
that does the key and action packing. Only the high-level functions need
to have access to ocelot->vcap[VCAP_IS2].
Signed-off-by: Vladimir Oltean
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix.c| 2 -
drivers/net/dsa/ocelot/felix.h| 2 -
drivers/net/dsa/ocelot/felix_vsc9959.c| 25 +-
drivers/net/ethernet/mscc/ocelot_ace.c| 400 --
drivers/net/ethernet/mscc/ocelot_board.c | 5 +-
drivers/net/ethernet/mscc/ocelot_flower.c | 1 +
drivers/net/ethernet/mscc/ocelot_regs.c | 20 +-
drivers/net/ethernet/mscc/ocelot_s2.h | 64
include/soc/mscc/ocelot.h | 21 +-
include/soc/mscc/ocelot_vcap.h| 62
10 files changed, 313 insertions(+), 289 deletions(-)
delete mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 66648986e6e3..4508d6063fd9 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -432,8 +432,6 @@ static int felix_init_structs(struct felix *felix, int
num_phys_ports)
ocelot->num_stats = felix->info->num_stats;
ocelot->shared_queue_sz = felix->info->shared_queue_sz;
ocelot->num_mact_rows = felix->info->num_mact_rows;
- ocelot->vcap_is2_keys = felix->info->vcap_is2_keys;
- ocelot->vcap_is2_actions= felix->info->vcap_is2_actions;
ocelot->vcap= felix->info->vcap;
ocelot->ops = felix->info->ops;
diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
index a891736ca006..b1b6ecfa5a55 100644
--- a/drivers/net/dsa/ocelot/felix.h
+++ b/drivers/net/dsa/ocelot/felix.h
@@ -21,8 +21,6 @@ struct felix_info {
unsigned intnum_stats;
int num_ports;
int num_tx_queues;
- struct vcap_field *vcap_is2_keys;
- struct vcap_field *vcap_is2_actions;
const struct vcap_props *vcap;
int switch_pci_bar;
int imdio_pci_bar;
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index 1dd9e348152d..ef3bf875e64c 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -156,14 +156,16 @@ static const u32 vsc9959_qs_regmap[] = {
REG_RESERVED(QS_INH_DBG),
};
-static const u32 vsc9959_s2_regmap[] = {
- REG(S2_CORE_UPDATE_CTRL,0x00),
- REG(S2_CORE_MV_CFG, 0x04),
- REG(S2_CACHE_ENTRY_DAT, 0x08),
- REG(S2_CACHE_MASK_DAT, 0x000108),
- REG(S2_CACHE_ACTION_DAT,0x000208),
- REG(S2_CACHE_CNT_DAT, 0x000308),
- REG(S2_CACHE_TG_DAT,0x000388),
+static const u32 vsc9959_vcap_regmap[] = {
+ /* VCAP_CORE_CFG */
+ REG(VCAP_CORE_UPDATE_CTRL, 0x00),
+ REG(VCAP_CORE_MV_CFG, 0x04),
+ /* VCAP_CORE_CACHE */
+ REG(VCAP_CACHE_ENTRY_DAT, 0x08),
+ REG(VCAP_CACHE_MASK_DAT,0x000108),
+ REG(VCAP_CACHE_ACTION_DAT, 0x000208),
+ REG(VCAP_CACHE_CNT_DAT, 0x000308),
+ REG(VCAP_CACHE_TG_DAT, 0x000388),
};
static const u32 vsc9959_qsys_regmap[] = {
@@ -335,7 +337,7 @@ static const u32 *vsc9959_regmap[] = {
[QSYS] = vsc9959_qsys_regmap,
[REW] = vsc9959_rew_regmap,
[SYS] = vsc9959_sys_regmap,
- [S2]= vsc9959_s2_regmap,
+ [S2]= vsc9959_vcap_regmap,
[PTP] = vsc9959_ptp_regmap,
[GCB] = vsc9959_gcb_regmap,
};
@@ -677,6 +679,9 @@ static const struct vcap_props vsc9959_vcap_props[] = {
},
.counter_words = 4,
.counter_width = 32,
+ .target = S2,
+ .keys = vsc9959_vcap_is2_keys,
+ .actions = vsc9959_vcap_is2_actions,
},
};
@@ -1401,8 +1406,6 @@ struct felix_info felix_info_vsc9959 = {
.ops= &vsc9959_ops,
.stats_layout = vsc9959_stats_layout,
.num_stats = ARRAY_SIZE(vsc9959_stats_layout),
- .vcap_is2_keys = vsc9959_vcap_is2_keys,
- .vcap_is2_actions = vsc9959_vcap_is2_actions,
.vcap = vsc9959_vcap_props,
.shared_queue
[PATCH v2 net-next 01/10] net: mscc: ocelot: introduce a new ocelot_target_{read,write} API
From: Vladimir Oltean
There are some targets (register blocks) in the Ocelot switch that are
instantiated more than once. For example, the VCAP IS1, IS2 and ES0
blocks all share the same register layout for interacting with the cache
for the TCAM and the action RAM.
For the VCAPs, the procedure for servicing them is actually common. We
just need an API specifying which VCAP we are talking to, and we do that
via these raw ocelot_target_read and ocelot_target_write accessors.
In plain ocelot_read, the target is encoded into the register enum
itself:
u16 target = reg >> TARGET_OFFSET;
For the VCAPs, the registers are currently defined like this:
enum ocelot_reg {
[...]
S2_CORE_UPDATE_CTRL = S2 << TARGET_OFFSET,
S2_CORE_MV_CFG,
S2_CACHE_ENTRY_DAT,
S2_CACHE_MASK_DAT,
S2_CACHE_ACTION_DAT,
S2_CACHE_CNT_DAT,
S2_CACHE_TG_DAT,
[...]
};
which is precisely what we want to avoid, because we'd have to duplicate
the same register map for S1 and for S0, and then figure out how to pass
VCAP instance-specific registers to the ocelot_read calls (basically
another lookup table that undoes the effect of shifting with
TARGET_OFFSET).
So for some targets, propose a more raw API, similar to what is
currently done with ocelot_port_readl and ocelot_port_writel. Those
targets can only be accessed with ocelot_target_{read,write} and not
with ocelot_{read,write} after the conversion, which is fine.
The VCAP registers are not actually modified to use this new API as of
this patch. They will be modified in the next one.
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/mscc/ocelot_io.c | 17 +
include/soc/mscc/ocelot.h | 14 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/net/ethernet/mscc/ocelot_io.c
b/drivers/net/ethernet/mscc/ocelot_io.c
index b229b1cb68ef..9b52d82f5399 100644
--- a/drivers/net/ethernet/mscc/ocelot_io.c
+++ b/drivers/net/ethernet/mscc/ocelot_io.c
@@ -59,6 +59,23 @@ void ocelot_port_writel(struct ocelot_port *port, u32 val,
u32 reg)
}
EXPORT_SYMBOL(ocelot_port_writel);
+u32 __ocelot_target_read_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 reg, u32 offset)
+{
+ u32 val;
+
+ regmap_read(ocelot->targets[target],
+ ocelot->map[target][reg] + offset, &val);
+ return val;
+}
+
+void __ocelot_target_write_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 val, u32 reg, u32 offset)
+{
+ regmap_write(ocelot->targets[target],
+ocelot->map[target][reg] + offset, val);
+}
+
int ocelot_regfields_init(struct ocelot *ocelot,
const struct reg_field *const regfields)
{
diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 4953e9994df3..2ac08f3b8f68 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -578,6 +578,16 @@ struct ocelot_policer {
#define ocelot_rmw_rix(ocelot, val, m, reg, ri) __ocelot_rmw_ix(ocelot, val,
m, reg, reg##_RSZ * (ri))
#define ocelot_rmw(ocelot, val, m, reg) __ocelot_rmw_ix(ocelot, val, m, reg, 0)
+#define ocelot_target_read_ix(ocelot, target, reg, gi, ri)
__ocelot_target_read_ix(ocelot, target, reg, reg##_GSZ * (gi) + reg##_RSZ *
(ri))
+#define ocelot_target_read_gix(ocelot, target, reg, gi)
__ocelot_target_read_ix(ocelot, target, reg, reg##_GSZ * (gi))
+#define ocelot_target_read_rix(ocelot, target, reg, ri)
__ocelot_target_read_ix(ocelot, target, reg, reg##_RSZ * (ri))
+#define ocelot_target_read(ocelot, target, reg)
__ocelot_target_read_ix(ocelot, target, reg, 0)
+
+#define ocelot_target_write_ix(ocelot, target, val, reg, gi, ri)
__ocelot_target_write_ix(ocelot, target, val, reg, reg##_GSZ * (gi) + reg##_RSZ
* (ri))
+#define ocelot_target_write_gix(ocelot, target, val, reg, gi)
__ocelot_target_write_ix(ocelot, target, val, reg, reg##_GSZ * (gi))
+#define ocelot_target_write_rix(ocelot, target, val, reg, ri)
__ocelot_target_write_ix(ocelot, target, val, reg, reg##_RSZ * (ri))
+#define ocelot_target_write(ocelot, target, val, reg)
__ocelot_target_write_ix(ocelot, target, val, reg, 0)
+
/* I/O */
u32 ocelot_port_readl(struct ocelot_port *port, u32 reg);
void ocelot_port_writel(struct ocelot_port *port, u32 val, u32 reg);
@@ -585,6 +595,10 @@ u32 __ocelot_read_ix(struct ocelot *ocelot, u32 reg, u32
offset);
void __ocelot_write_ix(struct ocelot *ocelot, u32 val, u32 reg, u32 offset);
void __ocelot_rmw_ix(struct ocelot *ocelot, u32 val, u32 mask, u32 reg,
u32 offset);
+u32 __ocelot_target_read_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 reg, u32 offset);
+void __ocelot_target_write_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 val, u32 reg, u32 offset);
/* Hardwa
[PATCH v2 net-next 00/10] net: ocelot: VCAP IS1 and ES0 support
This series patches adds support for VCAP IS1 and ES0 module, each VCAP
correspond to a flow chain to offload.
VCAP IS1 supports FLOW_ACTION_VLAN_MANGLE action to filter MAC, IP,
VLAN, protocol, and TCP/UDP ports keys and retag vlian tag,
FLOW_ACTION_PRIORITY action to classify packages to different Qos in hw.
VCAP ES0 supports FLOW_ACTION_VLAN_PUSH action to filter vlan keys
and push a specific vlan tag to frames.
Changes since v1->v2:
- Use different chain to assign rules to different hardware VCAP, and
use action goto chain to express flow order.
- Add FLOW_ACTION_PRIORITY to add Qos classification on VCAP IS1.
- Multiple actions support.
- Fix some code issues.
Vladimir Oltean (3):
net: mscc: ocelot: introduce a new ocelot_target_{read,write} API
net: mscc: ocelot: generalize existing code for VCAP
net: dsa: tag_ocelot: use VLAN information from tagging header when
available
Xiaoliang Yang (7):
net: mscc: ocelot: allocated rules to different hardware VCAP TCAMs by
chain index
net: mscc: ocelot: change vcap to be compatible with full and quad
entry
net: mscc: ocelot: VCAP IS1 support
net: mscc: ocelot: VCAP ES0 support
net: mscc: ocelot: multiple actions support
net: ocelot: return error if rule is not found
net: dsa: felix: correct VCAP IS2 keys offset
drivers/net/dsa/ocelot/felix.c| 2 -
drivers/net/dsa/ocelot/felix.h| 2 -
drivers/net/dsa/ocelot/felix_vsc9959.c| 202 +-
drivers/net/ethernet/mscc/ocelot.c| 11 +
drivers/net/ethernet/mscc/ocelot_ace.c| 729 --
drivers/net/ethernet/mscc/ocelot_ace.h| 26 +-
drivers/net/ethernet/mscc/ocelot_board.c | 5 +-
drivers/net/ethernet/mscc/ocelot_flower.c | 95 ++-
drivers/net/ethernet/mscc/ocelot_io.c | 17 +
drivers/net/ethernet/mscc/ocelot_regs.c | 21 +-
drivers/net/ethernet/mscc/ocelot_s2.h | 64 --
include/soc/mscc/ocelot.h | 39 +-
include/soc/mscc/ocelot_vcap.h| 199 +-
net/dsa/tag_ocelot.c | 29 +
14 files changed, 1105 insertions(+), 336 deletions(-)
delete mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
--
2.17.1
RE: [PATCH 2/4] firmware: imx: add resource management api
> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
>
> > From: Peng Fan
> > Sent: Thursday, April 23, 2020 3:00 PM
> >
> > Add resource management API, when we have multiple partition running
> > together, resources not owned to current partition should not be used.
> >
> > Reviewed-by: Leonard Crestez
> > Signed-off-by: Peng Fan
> > ---
> > drivers/firmware/imx/Makefile | 2 +-
> > drivers/firmware/imx/rm.c | 40 +
> > include/linux/firmware/imx/sci.h| 1 +
> > include/linux/firmware/imx/svc/rm.h | 69
> > +
> > 4 files changed, 111 insertions(+), 1 deletion(-) create mode 100644
> > drivers/firmware/imx/rm.c create mode 100644
> > include/linux/firmware/imx/svc/rm.h
> >
> > diff --git a/drivers/firmware/imx/Makefile
> > b/drivers/firmware/imx/Makefile index 08bc9ddfbdfb..17ea3613e142
> > 100644
> > --- a/drivers/firmware/imx/Makefile
> > +++ b/drivers/firmware/imx/Makefile
> > @@ -1,4 +1,4 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> > -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> > +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o
> > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new
> > file mode 100644 index ..7b0334de5486
> > --- /dev/null
> > +++ b/drivers/firmware/imx/rm.c
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + *
> > + * File containing client-side RPC functions for the RM service.
> > +These
> > + * function are ported to clients that communicate to the SC.
> > + */
> > +
> > +#include
> > +
> > +struct imx_sc_msg_rm_rsrc_owned {
> > + struct imx_sc_rpc_msg hdr;
> > + u16 resource;
> > +} __packed __aligned(4);
> > +
> > +/*
> > + * This function check @resource is owned by current partition or not
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in] resourceresource the control is associated with
> > + *
> > + * @return Returns 0 for success and < 0 for errors.
> > + */
> > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > +resource) {
> > + struct imx_sc_msg_rm_rsrc_owned msg;
> > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > + hdr->size = 2;
> > +
> > + msg.resource = resource;
> > +
> > + imx_scu_call_rpc(ipc, &msg, true);
>
> No need check err return?
No. it use hdr->func as the resource owner bool.
However imx_scu_call_rpc also use hdr->func
to check error value or not.
When hdr->func is 1, imx_sc_to_linux_errno
will report it -EINVAL. However here 1 means
not owned.
>
> > +
> > + return hdr->func;
> > +}
> > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > diff --git a/include/linux/firmware/imx/sci.h
> > b/include/linux/firmware/imx/sci.h
> > index 17ba4e405129..b5c5a56f29be 100644
> > --- a/include/linux/firmware/imx/sci.h
> > +++ b/include/linux/firmware/imx/sci.h
> > @@ -15,6 +15,7 @@
> >
> > #include #include
> >
> > +#include
> >
> > int imx_scu_enable_general_irq_channel(struct device *dev); int
> > imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> > a/include/linux/firmware/imx/svc/rm.h
> > b/include/linux/firmware/imx/svc/rm.h
> > new file mode 100644
> > index ..fc6ea62d9d0e
> > --- /dev/null
> > +++ b/include/linux/firmware/imx/svc/rm.h
> > @@ -0,0 +1,69 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017-2019 NXP
>
> Update copyright
ok
>
> > + *
> > + * Header file containing the public API for the System Controller
> > +(SC)
> > + * Power Management (PM) function. This includes functions for power
> > +state
> > + * control, clock control, reset control, and wake-up event control.
>
> Fix the code comments
>
> Otherwise, I'm fine with this patch.
Ok.
Thanks,
Peng.
>
> Regards
> Aisheng
>
> > + *
> > + * RM_SVC (SVC) Resource Management Service
> > + *
> > + * Module for the Resource Management (RM) service.
> > + */
> > +
> > +#ifndef _SC_RM_API_H
> > +#define _SC_RM_API_H
> > +
> > +#include
> > +
> > +/*
> > + * This type is used to indicate RPC RM function calls.
> > + */
> > +enum imx_sc_rm_func {
> > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> > + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> > + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> > + IMX_SC_RM_FUNC_GET_DID = 26,
> > + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> > + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> > + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> > + IMX_SC_RM_FUNC_SET_PARENT = 6,
> > + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> > + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> > + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> > +
[RESEND PATCH v1 5/6] staging: greybus: audio: Add helper APIs for dynamic audio modules
Greybus Codec driver allows modules to be dynamically added and removed,
which further requires updating the DAPM configurations as well.
With current snd_soc architecture, dynamic audio modules is not yet
supported. This patch provides helper APIs to update DAPM configurations
in response to modules which are dynamically added or removed. The
source is primarily based on snd_dapm.c
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/Makefile | 2 +-
drivers/staging/greybus/audio_codec.c | 13 +-
drivers/staging/greybus/audio_helper.c | 197 +
drivers/staging/greybus/audio_helper.h | 17 +++
4 files changed, 224 insertions(+), 5 deletions(-)
create mode 100644 drivers/staging/greybus/audio_helper.c
create mode 100644 drivers/staging/greybus/audio_helper.h
diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile
index 627e44f2a983..3b4b6cabff19 100644
--- a/drivers/staging/greybus/Makefile
+++ b/drivers/staging/greybus/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_GREYBUS_VIBRATOR)+= gb-vibrator.o
# Greybus Audio is a bunch of modules
gb-audio-module-y := audio_module.o audio_topology.o
-gb-audio-codec-y := audio_codec.o
+gb-audio-codec-y := audio_codec.o audio_helper.o
gb-audio-gb-y := audio_gb.o
gb-audio-apbridgea-y := audio_apbridgea.o
gb-audio-manager-y := audio_manager.o audio_manager_module.o
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index bbd072acda5c..866b3342515f 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -14,6 +14,7 @@
#include "audio_codec.h"
#include "audio_apbridgea.h"
#include "audio_manager.h"
+#include "audio_helper.h"
static struct gbaudio_codec_info *gbcodec;
@@ -874,7 +875,7 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
/* card already instantiated, create widgets here only */
if (component->card->instantiated) {
- snd_soc_dapm_link_component_dai_widgets(component->card,
+ gbaudio_dapm_link_component_dai_widgets(component->card,
&component->dapm);
#ifdef CONFIG_SND_JACK
/*
@@ -1004,19 +1005,23 @@ void gbaudio_unregister_module(struct
gbaudio_module_info *module)
if (module->dapm_routes) {
dev_dbg(component->dev, "Removing %d routes\n",
module->num_dapm_routes);
+ /* verify routes with controls are removed */
snd_soc_dapm_del_routes(&component->dapm, module->dapm_routes,
module->num_dapm_routes);
}
if (module->controls) {
dev_dbg(component->dev, "Removing %d controls\n",
module->num_controls);
- snd_soc_remove_codec_controls(component, module->controls,
- module->num_controls);
+ /* release control semaphore */
+ up_write(&card->controls_rwsem);
+ gbaudio_remove_component_controls(component, module->controls,
+ module->num_controls);
+ down_write(&card->controls_rwsem);
}
if (module->dapm_widgets) {
dev_dbg(component->dev, "Removing %d widgets\n",
module->num_dapm_widgets);
- snd_soc_dapm_free_controls(&component->dapm,
+ gbaudio_dapm_free_controls(&component->dapm,
module->dapm_widgets,
module->num_dapm_widgets);
}
diff --git a/drivers/staging/greybus/audio_helper.c
b/drivers/staging/greybus/audio_helper.c
new file mode 100644
index ..e2f113a811ee
--- /dev/null
+++ b/drivers/staging/greybus/audio_helper.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Greybus Audio Sound SoC helper APIs
+ */
+
+#include
+#include
+#include
+#include
+
+#define gbaudio_dapm_for_each_direction(dir) \
+ for ((dir) = SND_SOC_DAPM_DIR_IN; (dir) <= SND_SOC_DAPM_DIR_OUT; \
+ (dir)++)
+
+static void gbaudio_dapm_link_dai_widget(struct snd_soc_dapm_widget *dai_w,
+struct snd_soc_card *card)
+{
+ struct snd_soc_dapm_widget *w;
+ struct snd_soc_dapm_widget *src, *sink;
+ struct snd_soc_dai *dai = dai_w->priv;
+
+ /* ...find all widgets with the same stream and link them */
+ list_for_each_entry(w, &card->widgets, list) {
+ if (w->dapm != dai_w->dapm)
+ continue;
+
+ switch (w->id) {
+ case snd_soc_dapm_dai_in:
+ case snd_soc_dapm_dai_out:
+ continue;
+ default:
+ break;
+ }
+
+
[RESEND PATCH v1 4/6] staging: greybus: audio: Resolve compilation error in topology parser
Fix compilation errors for GB Audio topology parser code with recent
kernel versions.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_topology.c | 130 +++
1 file changed, 61 insertions(+), 69 deletions(-)
diff --git a/drivers/staging/greybus/audio_topology.c
b/drivers/staging/greybus/audio_topology.c
index 4ac30accf226..7d5e87341a5c 100644
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -5,8 +5,8 @@
* Copyright 2015-2016 Linaro Ltd.
*/
+#include
#include "audio_codec.h"
-#include "greybus_protocols.h"
#define GBAUDIO_INVALID_ID 0xFF
@@ -165,15 +165,15 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol
*kcontrol,
struct gbaudio_ctl_pvt *data;
struct gb_audio_ctl_elem_info *info;
struct gbaudio_module_info *module;
- struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- struct gbaudio_codec_info *gbcodec = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct gbaudio_codec_info *gb = snd_soc_component_get_drvdata(comp);
- dev_dbg(codec->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
+ dev_dbg(comp->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
data = (struct gbaudio_ctl_pvt *)kcontrol->private_value;
info = (struct gb_audio_ctl_elem_info *)data->info;
if (!info) {
- dev_err(codec->dev, "NULL info for %s\n", uinfo->id.name);
+ dev_err(comp->dev, "NULL info for %s\n", uinfo->id.name);
return -EINVAL;
}
@@ -193,7 +193,7 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol
*kcontrol,
uinfo->value.enumerated.items = max;
if (uinfo->value.enumerated.item > max - 1)
uinfo->value.enumerated.item = max - 1;
- module = find_gb_module(gbcodec, kcontrol->id.name);
+ module = find_gb_module(gb, kcontrol->id.name);
if (!module)
return -EINVAL;
name = gbaudio_map_controlid(module, data->ctl_id,
@@ -201,7 +201,7 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol
*kcontrol,
strlcpy(uinfo->value.enumerated.name, name, NAME_SIZE);
break;
default:
- dev_err(codec->dev, "Invalid type: %d for %s:kcontrol\n",
+ dev_err(comp->dev, "Invalid type: %d for %s:kcontrol\n",
info->type, kcontrol->id.name);
break;
}
@@ -216,11 +216,11 @@ static int gbcodec_mixer_ctl_get(struct snd_kcontrol
*kcontrol,
struct gbaudio_ctl_pvt *data;
struct gb_audio_ctl_elem_value gbvalue;
struct gbaudio_module_info *module;
- struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- struct gbaudio_codec_info *gb = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct gbaudio_codec_info *gb = snd_soc_component_get_drvdata(comp);
struct gb_bundle *bundle;
- dev_dbg(codec->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
+ dev_dbg(comp->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
module = find_gb_module(gb, kcontrol->id.name);
if (!module)
return -EINVAL;
@@ -239,7 +239,7 @@ static int gbcodec_mixer_ctl_get(struct snd_kcontrol
*kcontrol,
gb_pm_runtime_put_autosuspend(bundle);
if (ret) {
- dev_err_ratelimited(codec->dev, "%d:Error in %s for %s\n", ret,
+ dev_err_ratelimited(comp->dev, "%d:Error in %s for %s\n", ret,
__func__, kcontrol->id.name);
return ret;
}
@@ -262,7 +262,7 @@ static int gbcodec_mixer_ctl_get(struct snd_kcontrol
*kcontrol,
le32_to_cpu(gbvalue.value.enumerated_item[1]);
break;
default:
- dev_err(codec->dev, "Invalid type: %d for %s:kcontrol\n",
+ dev_err(comp->dev, "Invalid type: %d for %s:kcontrol\n",
info->type, kcontrol->id.name);
ret = -EINVAL;
break;
@@ -278,11 +278,11 @@ static int gbcodec_mixer_ctl_put(struct snd_kcontrol
*kcontrol,
struct gbaudio_ctl_pvt *data;
struct gb_audio_ctl_elem_value gbvalue;
struct gbaudio_module_info *module;
- struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- struct gbaudio_codec_info *gb = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct gbaudio_codec_info *gb = snd_soc_component_get_drvdata(comp);
struct gb_bundle *bundle;
- dev_dbg(codec->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
+ dev_dbg(comp->dev, "Entered %s:%s\n", __func__,
[PATCH] spi: tegra20-slink: call pm_runtime_put if pm_runtime_get_sync fails
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-slink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..15361db00982 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1118,6 +1118,7 @@ static int tegra_slink_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
+ pm_runtime_put(&pdev->dev);
goto exit_pm_disable;
}
tspi->def_command_reg = SLINK_M_S;
--
2.17.1
[RESEND PATCH v1 6/6] staging: greybus: audio: Enable GB codec, audio module compilation.
Currently, GB codec and audio module is conditionally compiled based on GREYBUS_AUDIO_MSM8994. However, audio module is not dependent on MSM8994 platform and can be used generically with any platform that follows GB Audio class specification. Also, GB codec driver corresponds to dummy codec represented by I2S port available on Toshiba AP Bridge. Added config option for the same in kconfig file and accordingly updated Makefile. Signed-off-by: Vaibhav Agarwal --- drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 4 ++-- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/Kconfig b/drivers/staging/greybus/Kconfig index d4777f5a8b90..cbcfcbba239b 100644 --- a/drivers/staging/greybus/Kconfig +++ b/drivers/staging/greybus/Kconfig @@ -3,7 +3,7 @@ if GREYBUS config GREYBUS_AUDIO tristate "Greybus Audio Class driver" - depends on SOUND + depends on SOUND && SND_SOC ---help--- Select this option if you have a device that follows the Greybus Audio Class specification. @@ -11,6 +11,18 @@ config GREYBUS_AUDIO To compile this code as a module, chose M here: the module will be called gb-audio.ko +config GREYBUS_AUDIO_APB_CODEC + tristate "Greybus APBridge Audio codec driver" + depends on SND_SOC && GREYBUS_AUDIO + help + Select this option if you have a Toshiba APB device that has I2S + ports and acts as a Greybus "Dummy codec". This device is a + bridge from an APB-I2S port to a Unipro network. + + To compile this code as a module, chose M here: the module + will be called gb-audio-codec.ko + + config GREYBUS_BOOTROM tristate "Greybus Bootrom Class driver" ---help--- diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile index 3b4b6cabff19..7c5e89622334 100644 --- a/drivers/staging/greybus/Makefile +++ b/drivers/staging/greybus/Makefile @@ -40,8 +40,8 @@ gb-audio-manager-y:= audio_manager.o audio_manager_module.o #ccflags-y += -DGB_AUDIO_MANAGER_SYSFS #endif -obj-$(CONFIG_GREYBUS_AUDIO_MSM8994)+= gb-audio-codec.o -obj-$(CONFIG_GREYBUS_AUDIO_MSM8994)+= gb-audio-module.o +obj-$(CONFIG_GREYBUS_AUDIO_APB_CODEC) += gb-audio-codec.o +obj-$(CONFIG_GREYBUS_AUDIO_APB_CODEC) += gb-audio-module.o obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-gb.o obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-apbridgea.o obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-manager.o -- 2.26.2
[RESEND PATCH v1 2/6] staging: greybus: audio: Maintain jack list within GB Audio module
As per the current implementation for GB codec driver, a jack list is
maintained for each module. And it expects the list to be populated by
the snd_soc_jack structure which would require modifications in
mainstream code.
However, this is not a necessary requirement and the list can be easily
maintained within gbaudio_module_info as well. This patch provides the
relevant changes for the same.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_codec.c | 76 ++
drivers/staging/greybus/audio_codec.h | 10 +++-
drivers/staging/greybus/audio_module.c | 20 ---
3 files changed, 60 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index ebf8484f0ae7..a2ee587e5a79 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -712,7 +712,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
struct snd_soc_card *card)
{
int ret;
-
+ struct gbaudio_jack *gba_jack, *n;
struct snd_soc_jack *jack;
struct snd_soc_jack_pin *headset, *button;
@@ -728,7 +728,8 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
headset->pin = module->jack_name;
headset->mask = module->jack_mask;
- jack = &module->headset_jack;
+ gba_jack = &module->headset;
+ jack = &gba_jack->jack;
ret = snd_soc_card_jack_new(card, module->jack_name, module->jack_mask,
jack, headset, 1);
@@ -737,6 +738,9 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
return ret;
}
+ /* Add to module's jack list */
+ list_add(&gba_jack->list, &module->jack_list);
+
if (!module->button_mask)
return 0;
@@ -745,20 +749,24 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
button = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
if (!button) {
ret = -ENOMEM;
- goto free_headset;
+ goto free_jack;
}
button->pin = module->button_name;
button->mask = module->button_mask;
- jack = &module->button_jack;
+ gba_jack = &module->button;
+ jack = &gba_jack->jack;
ret = snd_soc_card_jack_new(card, module->button_name,
module->button_mask, jack, button, 1);
if (ret) {
dev_err(module->dev, "Failed to create button jack\n");
- goto free_headset;
+ goto free_jack;
}
+ /* Add to module's jack list */
+ list_add(&gba_jack->list, &module->jack_list);
+
/*
* Currently, max 4 buttons are supported with following key mapping
* BTN_0 = KEY_MEDIA
@@ -768,58 +776,55 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
*/
if (module->button_mask & SND_JACK_BTN_0) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_0,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
KEY_MEDIA);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- goto free_button;
+ goto free_jack;
}
}
if (module->button_mask & SND_JACK_BTN_1) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_1,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
KEY_VOICECOMMAND);
if (ret) {
dev_err(module->dev, "Failed to set BTN_1\n");
- goto free_button;
+ goto free_jack;
}
}
if (module->button_mask & SND_JACK_BTN_2) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_2,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
KEY_VOLUMEUP);
if (ret) {
dev_err(module->dev, "Failed to set BTN_2\n");
- goto free_button;
+ goto free_jack;
}
}
if (module->button_mask & SND_JACK_BTN_3) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_3,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
KEY_VOLUMEDOWN);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- goto free_button;
+ goto free_jack;
}
}
/* FIXME
* verify if this is really required
set_bit(INPUT_PROP_NO_DUMMY_RELEASE,
- module->button_jack.jack-
[RESEND PATCH v1 3/6] staging: greybus: audio: Resolve compilation errors for GB codec module
Due to dependencies on ASoC framework changes, GB dummy codec module
compilation is currently disabled. This patch updates codec driver as
per the latest ASoC APIs.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_codec.c | 87 +--
drivers/staging/greybus/audio_codec.h | 2 +-
2 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index a2ee587e5a79..bbd072acda5c 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -832,7 +832,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
int gbaudio_register_module(struct gbaudio_module_info *module)
{
int ret;
- struct snd_soc_codec *codec;
+ struct snd_soc_component *component;
struct snd_card *card;
struct gbaudio_jack *gba_jack = NULL;
struct snd_soc_jack *jack = NULL;
@@ -842,8 +842,8 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
return -EAGAIN;
}
- codec = gbcodec->codec;
- card = codec->card->snd_card;
+ component = gbcodec->component;
+ card = component->card->snd_card;
down_write(&card->controls_rwsem);
@@ -862,19 +862,20 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
}
if (module->dapm_widgets)
- snd_soc_dapm_new_controls(&codec->dapm, module->dapm_widgets,
+ snd_soc_dapm_new_controls(&component->dapm,
+ module->dapm_widgets,
module->num_dapm_widgets);
if (module->controls)
- snd_soc_add_codec_controls(codec, module->controls,
- module->num_controls);
+ snd_soc_add_component_controls(component, module->controls,
+ module->num_controls);
if (module->dapm_routes)
- snd_soc_dapm_add_routes(&codec->dapm, module->dapm_routes,
+ snd_soc_dapm_add_routes(&component->dapm, module->dapm_routes,
module->num_dapm_routes);
/* card already instantiated, create widgets here only */
- if (codec->card->instantiated) {
- snd_soc_dapm_link_component_dai_widgets(codec->card,
- &codec->dapm);
+ if (component->card->instantiated) {
+ snd_soc_dapm_link_component_dai_widgets(component->card,
+ &component->dapm);
#ifdef CONFIG_SND_JACK
/*
* register jack devices for this module
@@ -882,7 +883,7 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
*/
list_for_each_entry(gba_jack, &module->jack_list, list) {
jack = &gba_jack->jack;
- snd_device_register(codec->card->snd_card,
+ snd_device_register(component->card->snd_card,
jack->jack);
}
#endif
@@ -892,9 +893,9 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
list_add(&module->list, &gbcodec->module_list);
mutex_unlock(&gbcodec->lock);
- if (codec->card->instantiated)
- ret = snd_soc_dapm_new_widgets(&codec->dapm);
- dev_dbg(codec->dev, "Registered %s module\n", module->name);
+ if (component->card->instantiated)
+ ret = snd_soc_dapm_new_widgets(component->card);
+ dev_dbg(component->dev, "Registered %s module\n", module->name);
up_write(&card->controls_rwsem);
return ret;
@@ -965,19 +966,19 @@ static void gbaudio_codec_cleanup(struct
gbaudio_module_info *module)
void gbaudio_unregister_module(struct gbaudio_module_info *module)
{
- struct snd_soc_codec *codec = gbcodec->codec;
- struct snd_card *card = codec->card->snd_card;
+ struct snd_soc_component *component = gbcodec->component;
+ struct snd_card *card = component->card->snd_card;
struct gbaudio_jack *gba_jack, *n;
struct snd_soc_jack *jack;
int mask;
- dev_dbg(codec->dev, "Unregister %s module\n", module->name);
+ dev_dbg(component->dev, "Unregister %s module\n", module->name);
down_write(&card->controls_rwsem);
mutex_lock(&gbcodec->lock);
gbaudio_codec_cleanup(module);
list_del(&module->list);
- dev_dbg(codec->dev, "Process Unregister %s module\n", module->name);
+ dev_dbg(component->dev, "Process Unregister %s module\n", module->name);
mutex_unlock(&gbcodec->lock);
#ifdef CONFIG_SND_JACK
@@ -994,99 +995,97 @@ void gbaudio_unregister_module(struct gbaudio_module_info
*module)
dev_dbg(module->dev, "Re
[RESEND PATCH v1 1/6] staging: greybus: audio: Update snd_jack FW usage as per new APIs
snd_soc_jack APIs are modified in recent kernel versions. This patch
updates the codec driver to resolve the compilation errors related to
jack framework.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_codec.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index 08746c85dea6..ebf8484f0ae7 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -709,17 +709,29 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
};
static int gbaudio_init_jack(struct gbaudio_module_info *module,
-struct snd_soc_codec *codec)
+struct snd_soc_card *card)
{
int ret;
+ struct snd_soc_jack *jack;
+ struct snd_soc_jack_pin *headset, *button;
+
if (!module->jack_mask)
return 0;
snprintf(module->jack_name, NAME_SIZE, "GB %d Headset Jack",
module->dev_id);
- ret = snd_soc_jack_new(codec, module->jack_name, module->jack_mask,
- &module->headset_jack);
+
+ headset = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
+ if (!headset)
+ return -ENOMEM;
+
+ headset->pin = module->jack_name;
+ headset->mask = module->jack_mask;
+ jack = &module->headset_jack;
+
+ ret = snd_soc_card_jack_new(card, module->jack_name, module->jack_mask,
+ jack, headset, 1);
if (ret) {
dev_err(module->dev, "Failed to create new jack\n");
return ret;
@@ -730,11 +742,21 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
snprintf(module->button_name, NAME_SIZE, "GB %d Button Jack",
module->dev_id);
- ret = snd_soc_jack_new(codec, module->button_name, module->button_mask,
- &module->button_jack);
+ button = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
+ if (!button) {
+ ret = -ENOMEM;
+ goto free_headset;
+ }
+
+ button->pin = module->button_name;
+ button->mask = module->button_mask;
+ jack = &module->button_jack;
+
+ ret = snd_soc_card_jack_new(card, module->button_name,
+ module->button_mask, jack, button, 1);
if (ret) {
dev_err(module->dev, "Failed to create button jack\n");
- return ret;
+ goto free_headset;
}
/*
@@ -750,7 +772,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_MEDIA);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- return ret;
+ goto free_button;
}
}
@@ -759,7 +781,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_VOICECOMMAND);
if (ret) {
dev_err(module->dev, "Failed to set BTN_1\n");
- return ret;
+ goto free_button;
}
}
@@ -768,7 +790,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_VOLUMEUP);
if (ret) {
dev_err(module->dev, "Failed to set BTN_2\n");
- return ret;
+ goto free_button;
}
}
@@ -777,7 +799,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_VOLUMEDOWN);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- return ret;
+ goto free_button;
}
}
@@ -788,6 +810,18 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
*/
return 0;
+
+free_button:
+ jack = &module->button_jack;
+ snd_device_free(card->snd_card, jack->jack);
+ list_del(&jack->list);
+
+free_headset:
+ jack = &module->headset_jack;
+ snd_device_free(card->snd_card, jack->jack);
+ list_del(&jack->list);
+
+ return ret;
}
int gbaudio_register_module(struct gbaudio_module_info *module)
@@ -815,7 +849,7 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
return -EINVAL;
}
- ret = gbaudio_init_jack(module, codec);
+ ret = gbaudio_init_jack(module, component->card);
if (ret) {
up_write(&card->controls_rwsem);
return ret;
@@ -942,7 +976,8 @@ void gbaudio_unregister_module(struct gbaudio_module_info
*module)
#ifdef CONFIG_SND_JACK
/* free jack devices
[RESEND PATCH v1 0/6] Enable Greybus Audio codec driver
[REQUEST] This patch series intends to "Enable Greybus Audio codec driver" existing in the staging tree. I have shared the original patch series with Greybus-Dev mailing list and as per the suggestion from Alexandre, I'm also interested to push Greybus Audio to sound soc tree. Thus, now I'm resending it to ASoc maintainers for review. Following is the top level SW design for GB Codec driver and GB Audio modules. +--+ +-->+GBA Module 1 | | +--+ +---+ || | || Greybus | +--+ | SND SOC| Audio+-->+GBA Module 2 | | Framework | Codec| +--+ || Driver | || | +---+ +--+ +-->+GBA Module N | +--+ Patch 5 contains the changes to provide helper APIs to link DAPM DAI widgets for the module added and remove/free component controls for the module removed dynamically. Eventually, I propose to extend snd_soc_xxx APIs for this purpose. Kindly share your inputs. [COVER LETTER] The existing GB Audio codec driver is dependent on MSM8994 Audio driver. During the development stage, this depdency was configured due to various changes involved in MSM Audio driver to enable addtional codec card and some of the changes proposed in mainline ASoC framework. However, these are not the real dependencies and some of them can be easily removed. The folowing patch series includes the changes to resolve unnecessary depedencies and make the codec driver functional with the latest kernel. Patch 1,2: Incudes jack framework related changes. Patch 3,4,5: Resolves compilation error observed with the latest kernel and also provides helper APIs required to allow dynamic addition/removal of modules. Patch 6: Finally provides config options and related Makefile changes to enable GB Codec driver. Thanks to Alexandre for raising the headsup [1] and motivating me to provide the necessary changes. [1] https://lore.kernel.org/lkml/20200507212912.599433-1-alexandre.bell...@bootlin.com/ Vaibhav Agarwal (6): staging: greybus: audio: Update snd_jack FW usage as per new APIs staging: greybus: audio: Maintain jack list within GB Audio module staging: greybus: audio: Resolve compilation errors for GB codec module staging: greybus: audio: Resolve compilation error in topology parser staging: greybus: audio: Add helper APIs for dynamic audio modules staging: greybus: audio: Enable GB codec, audio module compilation. drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 6 +- drivers/staging/greybus/audio_codec.c| 187 + drivers/staging/greybus/audio_codec.h| 12 +- drivers/staging/greybus/audio_helper.c | 197 +++ drivers/staging/greybus/audio_helper.h | 17 ++ drivers/staging/greybus/audio_module.c | 20 +-- drivers/staging/greybus/audio_topology.c | 130 +++ 8 files changed, 427 insertions(+), 156 deletions(-) create mode 100644 drivers/staging/greybus/audio_helper.c create mode 100644 drivers/staging/greybus/audio_helper.h base-commit: ae73e7784871ebe2c43da619b4a1e2c9ff81508d -- 2.26.2
[PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
slipped in a minor mistake.
Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
Update file entry to intended file location.
Signed-off-by: Lukas Bulwahn
---
Julius, Evan, please ack.
Wim, please pick this minor patch into your -next tree.
applies cleanly on next-20200529
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b045b70e54df..dcfb09700b96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
M: Julius Werner
R: Evan Benn
S: Maintained
-F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
+F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
F: drivers/watchdog/arm_smc_wdt.c
ARM SMMU DRIVERS
--
2.17.1
[PATCH] spi: sprd: call pm_runtime_put if pm_runtime_get_sync fails
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put_noidle if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-sprd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-sprd.c b/drivers/spi/spi-sprd.c
index 6678f1cbc566..860032af4b98 100644
--- a/drivers/spi/spi-sprd.c
+++ b/drivers/spi/spi-sprd.c
@@ -1018,6 +1018,7 @@ static int sprd_spi_remove(struct platform_device *pdev)
ret = pm_runtime_get_sync(ss->dev);
if (ret < 0) {
dev_err(ss->dev, "failed to resume SPI controller\n");
+ pm_runtime_put_noidle(&pdev->dev);
return ret;
}
--
2.17.1
Re: [PATCH v5 0/2] add SW BOOST support for CPPC
On 30-05-20, 10:08, Xiongfeng Wang wrote: > ACPI spec 6.2 section 8.4.7.1 provide the following two CPC registers. > > "Highest performance is the absolute maximum performance an individual > processor may reach, assuming ideal conditions. This performance level > may not be sustainable for long durations, and may only be achievable if > other platform components are in a specific state; for example, it may > require other processors be in an idle state. > > Nominal Performance is the maximum sustained performance level of the > processor, assuming ideal operating conditions. In absence of an > external constraint (power, thermal, etc.) this is the performance level > the platform is expected to be able to maintain continuously. All > processors are expected to be able to sustain their nominal performance > state simultaneously." > > We can use Highest Performance as the max performance in boost mode and > Nomial Performance as the max performance in non-boost mode. If the > Highest Performance is greater than the Nominal Performance, we assume > SW BOOST is supported. > > Changelog: > > v4 -> v5: > add 'cpu_hotplug_lock' before calling '.set_boost' > v3 -> v4: > run 'boost_set_msr_each' for each CPU in the policy rather than > each CPU in the system for 'acpi-cpufreq' > add 'Suggested-by' > > Xiongfeng Wang (2): > cpufreq: change '.set_boost' to act on only one policy > CPPC: add support for SW BOOST > > drivers/cpufreq/acpi-cpufreq.c | 14 ++- > drivers/cpufreq/cppc_cpufreq.c | 39 +++-- > drivers/cpufreq/cpufreq.c | 57 > +++--- > include/linux/cpufreq.h| 2 +- > 4 files changed, 77 insertions(+), 35 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 5/6] vdpa: introduce virtio pci driver
On Fri, May 29, 2020 at 04:03:02PM +0800, Jason Wang wrote: > Note that since virtio specification does not support get/restore > virtqueue state. So we can not use this driver for VM. This can be > addressed by extending the virtio specification. Looks like exactly the kind of hardware limitation VDPA is supposed to paper over within guest. So I suggest we use this as a litmus test, and find ways for VDPA to handle this without spec changes. -- MST
Re: [sched/fair] 0b0695f2b3: phoronix-test-suite.compress-gzip.0.seconds 19.8% regression
On Fri, May 29, 2020 at 07:26:01PM +0200, Vincent Guittot wrote: > On Mon, 25 May 2020 at 10:02, Vincent Guittot > wrote: > > > > On Thu, 21 May 2020 at 10:28, Oliver Sang wrote: > > > > > > On Wed, May 20, 2020 at 03:04:48PM +0200, Vincent Guittot wrote: > > > > On Thu, 14 May 2020 at 19:09, Vincent Guittot > > > > wrote: > > > > > > > > > > Hi Oliver, > > > > > > > > > > On Thu, 14 May 2020 at 16:05, kernel test robot > > > > > wrote: > > > > > > > > > > > > Hi Vincent Guittot, > > > > > > > > > > > > Below report FYI. > > > > > > Last year, we actually reported an improvement "[sched/fair] > > > > > > 0b0695f2b3: > > > > > > vm-scalability.median 3.1% improvement" on link [1]. > > > > > > but now we found the regression on pts.compress-gzip. > > > > > > This seems align with what showed in "[v4,00/10] sched/fair: rework > > > > > > the CFS > > > > > > load balance" (link [2]), where showed the reworked load balance > > > > > > could have > > > > > > both positive and negative effect for different test suites. > > > > > > > > > > We have tried to run all possible use cases but it's impossible to > > > > > covers all so there were a possibility that one that is not covered, > > > > > would regressed. > > > > > > > > > > > And also from link [3], the patch set risks regressions. > > > > > > > > > > > > We also confirmed this regression on another platform > > > > > > (Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G memory), > > > > > > below is the data (lower is better). > > > > > > v5.44.1 > > > > > > fcf0553db6f4c79387864f6e4ab4a891601f395e4.01 > > > > > > 0b0695f2b34a4afa3f6e9aa1ff0e5336d8dad9124.89 > > > > > > v5.55.18 > > > > > > v5.64.62 > > > > > > v5.7-rc24.53 > > > > > > v5.7-rc34.59 > > > > > > > > > > > > It seems there are some recovery on latest kernels, but not fully > > > > > > back. > > > > > > We were just wondering whether you could share some lights the > > > > > > further works > > > > > > on the load balance after patch set [2] which could cause the > > > > > > performance > > > > > > change? > > > > > > And whether you have plan to refine the load balance algorithm > > > > > > further? > > > > > > > > > > I'm going to have a look at your regression to understand what is > > > > > going wrong and how it can be fixed > > > > > > > > I have run the benchmark on my local setups to try to reproduce the > > > > regression and I don't see the regression. But my setups are different > > > > from your so it might be a problem specific to yours > > > > > > Hi Vincent, which OS are you using? We found the regression on Clear OS, > > > but it cannot reproduce on Debian. > > > On > > > https://www.phoronix.com/scan.php?page=article&item=mac-win-linux2018&num=5 > > > it was mentioned that - > > > Gzip compression is much faster out-of-the-box on Clear Linux due to it > > > exploiting > > > multi-threading capabilities compared to the other operating systems Gzip > > > support. > > > > I'm using Debian, I haven't noticed it was only on Clear OS. > > I'm going to look at it. Could you send me traces in the meantime ? > > I run more tests to understand the problem. Even if Clear Linux uses > multithreading, the system is not overloaded and there is a > significant amount of idle time. This means that we use the has_spare > capacity path that spreads tasks on the system. At least that is what > I have seen in the KVM image. Beside this, I think that I have been > able to reproduce the problem on my platform with debian using pigz > instead of gzip for the compress-gzip-1.2.0 test. On my platform, I > can see a difference when I enable all CPU idle states whereas there > is no performance difference when only the shallowest idle state is > enabled. > > The new load balance rework is more efficient at spreading tasks on > the system and one side effect could be that there is more idle time > between tasks wake up on each CPU. As a result, CPUs have to wake up > from a deeper idle state. This could explain the +54% increase of C6 > usage that is reported. Is it possible to get All C-state statistics > ? Hi Vincent, sorry for late. I selected the turbostat while running compress-gzip on Clear OS, as attached. Besides v5.4 and v5.7-rc7, I got the data for v5.5 and v5.7, too. Not sure it's enough since you said "All C-state statistics". Hope it could be useful and if you want more data, please let us know. Again, I collect these data on our "Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G memory" platform. for each release, I ran test twice to assure the results consistent. phoronix-test-suite.compress-gzip.0.seconds release run1run2 v5.44.374.37 v5.55.375.46 v5.7-rc74.824.85 v5.74.864.83 > > Could you run the test after disabling deep idle states like C6 and > above and check what is the difference between v5.7-rc7 and v5.4 ? thanks for suggestion, will collect this data later. > co
Re: [PATCH] hw_breakpoint: Fix build warnings with clang
Le 02/06/2020 à 06:12, Ravi Bangoria a écrit : kbuild test robot reported few build warnings with hw_breakpoint code when compiled with clang[1]. Fix those. [1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/ Reported-by: kbuild test robot Signed-off-by: Ravi Bangoria --- Note: Prepared on top of powerpc/next. arch/powerpc/include/asm/hw_breakpoint.h | 3 --- include/linux/hw_breakpoint.h| 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h index f42a55eb77d2..cb424799da0d 100644 --- a/arch/powerpc/include/asm/hw_breakpoint.h +++ b/arch/powerpc/include/asm/hw_breakpoint.h @@ -70,9 +70,6 @@ extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused, unsigned long val, void *data); int arch_install_hw_breakpoint(struct perf_event *bp); void arch_uninstall_hw_breakpoint(struct perf_event *bp); -int arch_reserve_bp_slot(struct perf_event *bp); -void arch_release_bp_slot(struct perf_event *bp); -void arch_unregister_hw_breakpoint(struct perf_event *bp); void hw_breakpoint_pmu_read(struct perf_event *bp); extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk); diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h index 6058c3844a76..521481f0d320 100644 --- a/include/linux/hw_breakpoint.h +++ b/include/linux/hw_breakpoint.h @@ -80,6 +80,10 @@ extern int dbg_reserve_bp_slot(struct perf_event *bp); extern int dbg_release_bp_slot(struct perf_event *bp); extern int reserve_bp_slot(struct perf_event *bp); extern void release_bp_slot(struct perf_event *bp); +extern int hw_breakpoint_weight(struct perf_event *bp); +extern int arch_reserve_bp_slot(struct perf_event *bp); +extern void arch_release_bp_slot(struct perf_event *bp); +extern void arch_unregister_hw_breakpoint(struct perf_event *bp); Please no new 'extern'. In the old days 'extern' keyword was used, but new code shall not introduce new unnecessary usage of 'extern' keyword. See report from Checkpatch below: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: [1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/ CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #40: FILE: include/linux/hw_breakpoint.h:83: +extern int hw_breakpoint_weight(struct perf_event *bp); CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #41: FILE: include/linux/hw_breakpoint.h:84: +extern int arch_reserve_bp_slot(struct perf_event *bp); CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #42: FILE: include/linux/hw_breakpoint.h:85: +extern void arch_release_bp_slot(struct perf_event *bp); CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #43: FILE: include/linux/hw_breakpoint.h:86: +extern void arch_unregister_hw_breakpoint(struct perf_event *bp); total: 0 errors, 1 warnings, 4 checks, 19 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. the.patch has style problems, please review. NOTE: Ignored message types: ARCH_INCLUDE_LINUX BIT_MACRO COMPARISON_TO_NULL DT_SPLIT_BINDING_PATCH EMAIL_SUBJECT FILE_PATH_CHANGES GLOBAL_INITIALISERS LINE_SPACING MULTIPLE_ASSIGNMENTS NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Christophe
RE: [PATCH] driver core: platform: expose numa_node to users in sysfs
> >
> > Platform devices are NUMA? That's crazy, and feels like a total abuse
> > of platform devices and drivers that really should belong on a "real"
> > bus.
>
> I am not sure if it is an abuse of platform device. But smmu is a platform
> device,
> drivers/iommu/arm-smmu-v3.c is a platform driver.
> In a typical ARM server, there are maybe multiple SMMU devices which can
> support
> IO virtual address and page tables for other devices on PCI-like busses.
> Each different SMMU device might be close to different NUMA node. There is
> really a hardware topology.
>
> If you have multiple CPU packages in a NUMA server, some platform devices
> might
> Belong to CPU0, some other might belong to CPU1.
Those devices are populated by acpi_iort for an ARM server:
drivers/acpi/arm64/iort.c:
static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
.name = "arm-smmu-v3",
.dev_dma_configure = arm_smmu_v3_dma_configure,
.dev_count_resources = arm_smmu_v3_count_resources,
.dev_init_resources = arm_smmu_v3_init_resources,
.dev_set_proximity = arm_smmu_v3_set_proximity,
};
void __init acpi_iort_init(void)
{
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
...
iort_check_id_count_workaround(iort_table);
iort_init_platform_devices();
}
static void __init iort_init_platform_devices(void)
{
...
for (i = 0; i < iort->node_count; i++) {
if (iort_node >= iort_end) {
pr_err("iort node pointer overflows, bad table\n");
return;
}
iort_enable_acs(iort_node);
ops = iort_get_dev_cfg(iort_node);
if (ops) {
fwnode = acpi_alloc_fwnode_static();
if (!fwnode)
return;
iort_set_fwnode(iort_node, fwnode);
ret = iort_add_platform_device(iort_node, ops);
if (ret) {
iort_delete_fwnode(iort_node);
acpi_free_fwnode_static(fwnode);
return;
}
}
...
}
...
}
NUMA node is got from ACPI:
static int __init arm_smmu_v3_set_proximity(struct device *dev,
struct acpi_iort_node *node)
{
struct acpi_iort_smmu_v3 *smmu;
smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
int dev_node = acpi_map_pxm_to_node(smmu->pxm);
...
set_dev_node(dev, dev_node);
...
}
return 0;
}
Barry
Re: [PATCH 5/6] vdpa: introduce virtio pci driver
On Fri, May 29, 2020 at 04:03:02PM +0800, Jason Wang wrote:
> +static void vp_vdpa_set_vq_ready(struct vdpa_device *vdpa,
> + u16 qid, bool ready)
> +{
> + struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa);
> +
> + vp_iowrite16(qid, &vp_vdpa->common->queue_select);
> + vp_iowrite16(ready, &vp_vdpa->common->queue_enable);
> +}
> +
Looks like this needs to check and just skip the write if
ready == 0, right? Of course vdpa core then insists on calling
vp_vdpa_get_vq_ready which will warn. Maybe just drop the
check from core, move it to drivers which need it?
...
> +static const struct pci_device_id vp_vdpa_id_table[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
> + { 0 }
> +};
This looks like it'll create a mess with either virtio pci
or vdpa being loaded at random. Maybe just don't specify
any IDs for now. Down the road we could get a
distinct vendor ID or a range of device IDs for this.
> +MODULE_DEVICE_TABLE(pci, vp_vdpa_id_table);
> +
> +static struct pci_driver vp_vdpa_driver = {
> + .name = "vp-vdpa",
> + .id_table = vp_vdpa_id_table,
> + .probe = vp_vdpa_probe,
> + .remove = vp_vdpa_remove,
> +};
> +
> +module_pci_driver(vp_vdpa_driver);
> +
> +MODULE_AUTHOR("Jason Wang ");
> +MODULE_DESCRIPTION("vp-vdpa");
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION("1");
> --
> 2.20.1
Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers
On Mon, Jun 01, 2020 at 06:25:42PM -0500, Bjorn Helgaas wrote:
> [+cc Greg, linux-kernel for wider exposure]
Thanks for the cc:, missed this...
>
> On Tue, May 26, 2020 at 09:30:08AM -0700, Rajat Jain wrote:
> > On Thu, May 14, 2020 at 7:18 PM Rajat Jain wrote:
> > > On Thu, May 14, 2020 at 12:13 PM Raj, Ashok wrote:
> > > > On Wed, May 13, 2020 at 02:26:18PM -0700, Rajat Jain wrote:
> > > > > On Wed, May 13, 2020 at 8:19 AM Bjorn Helgaas
> > > > > wrote:
> > > > > > On Fri, May 01, 2020 at 04:07:10PM -0700, Rajat Jain wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Currently, the PCI subsystem marks the PCI devices as
> > > > > > > "untrusted", if
> > > > > > > the firmware asks it to:
> > > > > > >
> > > > > > > 617654aae50e ("PCI / ACPI: Identify untrusted PCI devices")
> > > > > > > 9cb30a71acd4 ("PCI: OF: Support "external-facing" property")
> > > > > > >
> > > > > > > An "untrusted" device indicates a (likely external facing) device
> > > > > > > that
> > > > > > > may be malicious, and can trigger DMA attacks on the system. It
> > > > > > > may
> > > > > > > also try to exploit any vulnerabilities exposed by the driver,
> > > > > > > that
> > > > > > > may allow it to read/write unintended addresses in the host (e.g.
> > > > > > > if
> > > > > > > DMA buffers for the device, share memory pages with other driver
> > > > > > > data
> > > > > > > structures or code etc).
> > > > > > >
> > > > > > > High Level proposal
> > > > > > > ===
> > > > > > > Currently, the "untrusted" device property is used as a hint to
> > > > > > > enable
> > > > > > > IOMMU restrictions (on Intel), disable ATS (on ARM) etc. We'd
> > > > > > > like to
> > > > > > > go a step further, and allow the administrator to build a list of
> > > > > > > whitelisted drivers for these "untrusted" devices. This whitelist
> > > > > > > of
> > > > > > > drivers are the ones that he trusts enough to have little or no
> > > > > > > vulnerabilities. (He may have built this list of whitelisted
> > > > > > > drivers
> > > > > > > by a combination of code analysis of drivers, or by extensive
> > > > > > > testing
> > > > > > > using PCIe fuzzing etc). We propose that the administrator be
> > > > > > > allowed
> > > > > > > to specify this list of whitelisted drivers to the kernel, and
> > > > > > > the PCI
> > > > > > > subsystem to impose this behavior:
> > > > > > >
> > > > > > > 1) The "untrusted" devices can bind to only "whitelisted drivers".
> > > > > > > 2) The other devices (i.e. dev->untrusted=0) can bind to any
> > > > > > > driver.
> > > > > > >
> > > > > > > Of course this behavior is to be imposed only if such a whitelist
> > > > > > > is
> > > > > > > provided by the administrator.
> >
> > I haven't heard much on this proposal after the initial inputs (to
> > which I responded). Essentially, I agree that IO-MMU and ACS
> > restrictions need to be put in plcase. But I think we need this
> > additionally. Does this look acceptable to you? I wanted to start
> > spinning out the patches, but wanted to see if there are any pending
> > comments or concerns.
>
> I think it makes sense to code this up and see what it would look
> like. The bare minimum seems like a driver "bind-to-external-devices"
> bit that's visible in sysfs plus something in the driver probe path
> that checks it. Neither is inherently PCI-specific, but maybe the
> right place will become obvious when implementing it.
>
> I'm still not 100% sure the device "external/untrusted" bit is the
> right thing to check. If you don't trust a driver enough to expose it
> to an external device, is it reasonable to trust it for internal
> devices? It seems like one could attack the driver of even an
> internal device like a NIC by controlling the data fed to it.
>
> The existing use of "external/untrusted" for IOMMU protection is
> different. There we're acknowledging that the *device* itself is
> unknown and we need to protect ourselves from malicious DMA.
>
> Here we're concerned about a *driver* that's completely under our
> control. If we don't trust the driver, we could (a) fix the problems
> in the driver, (b) change the driver so it handles external/untrusted
> devices differently, or (c) not ship the driver at all.
>
> I'm also not sure about the administrative details of this. Certain
> versions of the driver may be trusted while others are untrusted.
> That would all have to be managed in userspace, so it's not really our
> problem, but it sounds like a hassle. Putting the information in the
> driver itself would reduce that.
What about taking what we have today for USB devices/drivers where we
have different levels of "authorized"? There's no reason that could not
just move to the driver core and be available for all devices/drivers as
that model has proven to work really well over time.
See the "authorized" sysfs file documentation in
Documentation/ABI/testing/sysfs-bus-usb for some details. Lots of
userspace to
drivers/ptp/ptp_ines.c:837:34: warning: unused variable 'ines_ptp_ctrl_of_match'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f359287765c04711ff54fbd11645271d8e5ff763
commit: bad1eaa6ac312ffd7aa46dd5a4d9843b824aa023 ptp: Add a driver for InES
time stamping IP core.
date: 5 months ago
config: x86_64-randconfig-r036-20200602 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
2388a096e7865c043e83ece4e26654bd3d1a20d5)
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
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout bad1eaa6ac312ffd7aa46dd5a4d9843b824aa023
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/ptp/ptp_ines.c:481:37: warning: format specifies type 'unsigned char'
but the argument has type 'int' [-Wformat]
tag_to_msgtype(ts->tag & 0x7), *msgtype & 0xf);
^~
include/linux/device.h:1784:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:158:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:143:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
include/linux/dynamic_debug.h:125:15: note: expanded from macro
'__dynamic_func_call'
func(&id, ##__VA_ARGS__);
^~~
drivers/ptp/ptp_ines.c:491:19: warning: format specifies type 'unsigned short'
but the argument has type 'int' [-Wformat]
ts->portnum, ntohs(*portn));
^
include/linux/device.h:1784:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:158:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:143:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see
all)
include/linux/byteorder/generic.h:137:21: note: expanded from macro '___ntohs'
#define ___ntohs(x) __be16_to_cpu(x)
^~~~
include/uapi/linux/byteorder/little_endian.h:42:26: note: expanded from macro
'__be16_to_cpu'
#define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
^~~~
include/uapi/linux/swab.h:104:2: note: expanded from macro '__swab16'
(__builtin_constant_p((__u16)(x)) ?
^
drivers/ptp/ptp_ines.c:496:17: warning: format specifies type 'unsigned short'
but the argument has type 'int' [-Wformat]
ts->seqid, ntohs(*seqid));
^
include/linux/device.h:1784:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:158:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:143:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see
all)
include/linux/byteorder/generic.h:137:21: note: expanded from macro '___ntohs'
#define ___ntohs(x) __be16_to_cpu(x)
^~~~
include/uapi/linux/byteorder/little_endian.h:42:26: note: expanded from macro
'__be16_to_cpu'
#define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
^~~~
include/uapi/linux/swab.h:104:2: note: expanded from macro '__swab16'
(__builtin_constant_p((__u16)(x)) ?
^
>> drivers/ptp/ptp_ines.c:837:34: warning: unused variable
>> 'ines_ptp_ctrl_of_match' [-Wunused-const-variable]
static const struct of_device_id ines_ptp_ctrl_of_match[] = {
^
4 warnings generated.
vim +/ines_ptp_ctrl_of_match +837 drivers/ptp/ptp_ines.c
836
> 837 static const struct of_device_id ines_ptp_ctrl_of_match[] = {
838 { .compatible = "ines,ptp-ctrl" },
839 { }
840 };
841
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
memory leak in exfat_parse_param
I report a bug (in linux-5.7.0-rc7) found by syzkaller. kernel config: https://github.com/butterflyhack/syzkaller-fuzz/blob/master/config-v5.7.0-rc7 and can reproduce. A param->string held by exfat_mount_options. BUG: memory leak unreferenced object 0x88801972e090 (size 8): comm "syz-executor.2", pid 16298, jiffies 4295172466 (age 14.060s) hex dump (first 8 bytes): 6b 6f 69 38 2d 75 00 00 koi8-u.. backtrace: [<5bfe35d6>] kstrdup+0x36/0x70 mm/util.c:60 [<18ed3277>] exfat_parse_param+0x160/0x5e0 fs/exfat/super.c:276 [<7680462b>] vfs_parse_fs_param+0x2b4/0x610 fs/fs_context.c:147 [<97c027f2>] vfs_parse_fs_string+0xe6/0x150 fs/fs_context.c:191 [<371bf78f>] generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 [<5ce5eb1b>] do_new_mount fs/namespace.c:2812 [inline] [<5ce5eb1b>] do_mount+0x12bb/0x1b30 fs/namespace.c:3141 [] __do_sys_mount fs/namespace.c:3350 [inline] [ ] __se_sys_mount fs/namespace.c:3327 [inline] [ ] __x64_sys_mount+0x18f/0x230 fs/namespace.c:3327 [<3b024e98>] do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 [ ] entry_SYSCALL_64_after_hwframe+0x49/0xb3
Re: [PATCH 1/6] vhost: allow device that does not depend on vhost worker
On Fri, May 29, 2020 at 04:02:58PM +0800, Jason Wang wrote:
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index d450e16c5c25..70105e045768 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -166,11 +166,16 @@ static int vhost_poll_wakeup(wait_queue_entry_t *wait,
> unsigned mode, int sync,
>void *key)
> {
> struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait);
> + struct vhost_work *work = &poll->work;
>
> if (!(key_to_poll(key) & poll->mask))
> return 0;
>
> - vhost_poll_queue(poll);
> + if (!poll->dev->use_worker)
> + work->fn(work);
> + else
> + vhost_poll_queue(poll);
> +
> return 0;
> }
>
So a wakeup function wakes up eventfd directly.
What if user supplies e.g. the same eventfd as ioeventfd?
Won't this cause infinite loops?
--
MST
Re: iommu: Improve exception handling in iommu_group_alloc()
>> * I suggest to avoid the specification of duplicate function calls. >> Will it be helpful to add a few jump targets? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162#n455 > > I don't think it is helpful or readable to add some jump targets here, > since the exception handling is very simple here. Do you disagree to the application of the Linux coding style then for the recommended exception handling? Regards, Markus
Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message
>>> Please just remove the message instead, it's a tiny allocation that's >>> unlikely to ever fail, and the caller will print an error anyway. >> >> How do you think about to take another look at a previous update suggestion >> like the following? >> >> powerpc/nvram: Delete three error messages for a failed memory allocation >> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/00845261-8528-d011-d3b8-e9355a231...@users.sourceforge.net/ >> https://lore.kernel.org/linuxppc-dev/00845261-8528-d011-d3b8-e9355a231...@users.sourceforge.net/ >> https://lore.kernel.org/patchwork/patch/752720/ >> https://lkml.org/lkml/2017/1/19/537 > > That deleted the messages from nvram_scan_partitions(), but neither of > the callers of nvram_scan_paritions() check its return value or print > anything if it fails. So removing those messages would make those > failures silent which is not what we want. * How do you think about information like the following? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=f359287765c04711ff54fbd11645271d8e5ff763#n883 “… These generic allocation functions all emit a stack dump on failure when used without __GFP_NOWARN so there is no use in emitting an additional failure message when NULL is returned. …” * Would you like to clarify software development concerns around the Linux allocation failure report any more? Regards, Markus
[PATCH v2] kexec: Do not verify the signature without the lockdown or mandatory signature
Signature verification is an important security feature, to protect
system from being attacked with a kernel of unknown origin. Kexec
rebooting is a way to replace the running kernel, hence need be
secured carefully.
In the current code of handling signature verification of kexec kernel,
the logic is very twisted. It mixes signature verification, IMA signature
appraising and kexec lockdown.
If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of
signature, the supported crypto, and key, we don't think this is wrong,
Unless kexec lockdown is executed. IMA is considered as another kind of
signature appraising method.
If kexec kernel image has signature/crypto/key, it has to go through the
signature verification and pass. Otherwise it's seen as verification
failure, and won't be loaded.
Seems kexec kernel image with an unqualified signature is even worse than
those w/o signature at all, this sounds very unreasonable. E.g. If people
get a unsigned kernel to load, or a kernel signed with expired key, which
one is more dangerous?
So, here, let's simplify the logic to improve code readability. If the
KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification
is mandated. Otherwise, we lift the bar for any kernel image.
Signed-off-by: Lianbo Jiang
---
Changes since v1:
[1] Modify the log level(suggested by Jiri Bohac)
kernel/kexec_file.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index faa74d5f6941..fae496958a68 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -181,34 +181,19 @@ void kimage_file_post_load_cleanup(struct kimage *image)
static int
kimage_validate_signature(struct kimage *image)
{
- const char *reason;
int ret;
ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
image->kernel_buf_len);
- switch (ret) {
- case 0:
- break;
+ if (ret) {
- /* Certain verification errors are non-fatal if we're not
-* checking errors, provided we aren't mandating that there
-* must be a valid signature.
-*/
- case -ENODATA:
- reason = "kexec of unsigned image";
- goto decide;
- case -ENOPKG:
- reason = "kexec of image with unsupported crypto";
- goto decide;
- case -ENOKEY:
- reason = "kexec of image with unavailable key";
- decide:
if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
- pr_notice("%s rejected\n", reason);
+ pr_notice("Enforced kernel signature verification
failed (%d).\n", ret);
return ret;
}
- /* If IMA is guaranteed to appraise a signature on the kexec
+ /*
+* If IMA is guaranteed to appraise a signature on the kexec
* image, permit it even if the kernel is otherwise locked
* down.
*/
@@ -216,17 +201,10 @@ kimage_validate_signature(struct kimage *image)
security_locked_down(LOCKDOWN_KEXEC))
return -EPERM;
- return 0;
-
- /* All other errors are fatal, including nomem, unparseable
-* signatures and signature check failures - even if signatures
-* aren't required.
-*/
- default:
- pr_notice("kernel signature verification failed (%d).\n", ret);
+ pr_debug("kernel signature verification failed (%d).\n", ret);
}
- return ret;
+ return 0;
}
#endif
--
2.17.1
Re: linux-sh for-next reactivation
Hi Rich, On Mon, 1 Jun 2020 23:11:39 -0400 Rich Felker wrote: > > Could you reactivate linux-next pull from my arch/sh for-next branch? > It's where it was before, at: > > git://git.libc.org/linux-sh for-next > > and has newly accepted patches ready. I already have an SH tree from git://git.sourceforge.jp/gitroot/uclinux-h8/linux.git#sh-next . Should I do anything with that one? It currently contains: $ git log --oneline origin/master..sh/sh-next a193018e5290 (sh/sh-next) sh: add missing EXPORT_SYMBOL() for __delay 1d5fd6c33b04 sh: add missing DECLARE_EXPORT() for __ashiftrt_r4_xx d70f1e3d5dbd Merge remote-tracking branch 'origin/master' into sh-next baf58858e8b6 sh: prefer __section from compiler_attributes.h 8619b5a9035a sh: Drop -Werror from kernel Makefile 3a3a78124693 sh: kernel: disassemble: Mark expected switch fall-throughs fb8f77490f55 sh: kernel: hw_breakpoint: Fix missing break in switch statement cd10afbc932d sh: remove unneeded uapi asm-generic wrappers cbfc6edb6a4a sh: use __builtin_constant_p() directly instead of IS_IMMEDIATE() -- Cheers, Stephen Rothwell pgpJcDCj71o29.pgp Description: OpenPGP digital signature
[PATCH v2] driver core: platform: need consistent spacing around '-'
Fix the below checkpatch issue: ERROR: need consistent spacing around '-' (ctx:WxV) FILE: drivers/base/platform.c:1008: + len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); ^ Signed-off-by: Barry Song --- -v2: specify a description of the patch in the email body drivers/base/platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index b27d0f6c18c9..ab9408182a0d 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -1005,7 +1005,7 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *a, if (len != -ENODEV) return len; - len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); + len = acpi_device_modalias(dev, buf, PAGE_SIZE - 1); if (len != -ENODEV) return len; -- 2.23.0
Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap
On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote:
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on vhost/linux-next]
> [also build test ERROR on linus/master v5.7 next-20200529]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Jason-Wang/vDPA-doorbell-mapping/20200531-070834
> base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> linux-next
> config: m68k-randconfig-r011-20200601 (attached as .config)
> compiler: m68k-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
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=m68k
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> drivers/vhost/vdpa.c: In function 'vhost_vdpa_fault':
> >> drivers/vhost/vdpa.c:754:22: error: implicit declaration of function
> >> 'pgprot_noncached' [-Werror=implicit-function-declaration]
> 754 | vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> | ^~~~
> >> drivers/vhost/vdpa.c:754:22: error: incompatible types when assigning to
> >> type 'pgprot_t' {aka 'struct '} from type 'int'
> cc1: some warnings being treated as errors
>
> vim +/pgprot_noncached +754 drivers/vhost/vdpa.c
>
>742
>743static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf)
>744{
>745struct vhost_vdpa *v = vmf->vma->vm_file->private_data;
>746struct vdpa_device *vdpa = v->vdpa;
>747const struct vdpa_config_ops *ops = vdpa->config;
>748struct vdpa_notification_area notify;
>749struct vm_area_struct *vma = vmf->vma;
>750u16 index = vma->vm_pgoff;
>751
>752notify = ops->get_vq_notification(vdpa, index);
>753
> > 754vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>755if (remap_pfn_range(vma, vmf->address & PAGE_MASK,
>756notify.addr >> PAGE_SHIFT,
> PAGE_SIZE,
>757vma->vm_page_prot))
>758return VM_FAULT_SIGBUS;
>759
>760return VM_FAULT_NOPAGE;
>761}
>762
Yes well, all this remapping clearly has no chance to work
on systems without CONFIG_MMU.
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] spi: tegra114: missing put on pm_runtime_get_sync failure
the call to pm_runtime_get_sync increments the counter even
in case of failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra114.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 83edabdb41ad..dccd2ac1a975 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -974,6 +974,7 @@ static int tegra_spi_setup(struct spi_device *spi)
dev_err(tspi->dev, "pm runtime failed, e = %d\n", ret);
if (cdata)
tegra_spi_cleanup(spi);
+ pm_runtime_put(tspi->dev);
return ret;
}
@@ -1398,6 +1399,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
+ pm_runtime_put(&pdev->dev);
goto exit_pm_disable;
}
@@ -1479,6 +1481,7 @@ static int tegra_spi_resume(struct device *dev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
dev_err(dev, "pm runtime failed, e = %d\n", ret);
+ pm_runtime_put(dev);
return ret;
}
tegra_spi_writel(tspi, tspi->command1_reg, SPI_COMMAND1);
--
2.17.1
include/linux/compiler.h:199:9: sparse: sparse: context imbalance in 'alua_rtpg' - different lock contexts for basic block
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f359287765c04711ff54fbd11645271d8e5ff763
commit: fb041bb7c0a918b95c6889fc965cdc4a75b4c0ca locking/refcount: Consolidate
implementations of refcount_t
date: 6 months ago
config: ia64-randconfig-s032-20200602 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-243-gc100a7ab-dirty
git checkout fb041bb7c0a918b95c6889fc965cdc4a75b4c0ca
# save the attached .config to linux build tree
make W=1 C=1 ARCH=ia64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> include/linux/compiler.h:199:9: sparse: sparse: context imbalance in
>> 'alua_rtpg' - different lock contexts for basic block
vim +/alua_rtpg +199 include/linux/compiler.h
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 195
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 196 static __always_inline
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 197 void
__read_once_size(const volatile void *p, void *res, int size)
230fa253df6352a Christian Borntraeger 2014-11-25 198 {
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 @199 __READ_ONCE_SIZE;
230fa253df6352a Christian Borntraeger 2014-11-25 200 }
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 201
:: The code at line 199 was first introduced by commit
:: d976441f44bc5d48635d081d277aa76556ffbf8b compiler, atomics, kasan:
Provide READ_ONCE_NOCHECK()
:: TO: Andrey Ryabinin
:: CC: Ingo Molnar
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
linux-next: manual merge of the kvm tree with the tip tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kernel/kvm.c
between commit:
a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")
from the tip tree and commit:
68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info")
from the kvm 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 arch/x86/kernel/kvm.c
index 07dc47359c4f,d6f22a3a1f7d..
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -217,23 -218,23 +217,23 @@@ again
}
EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
- u32 noinstr kvm_read_and_reset_pf_reason(void)
-u32 kvm_read_and_reset_apf_flags(void)
++u32 noinstr kvm_read_and_reset_apf_flags(void)
{
- u32 reason = 0;
+ u32 flags = 0;
if (__this_cpu_read(apf_reason.enabled)) {
- reason = __this_cpu_read(apf_reason.reason);
- __this_cpu_write(apf_reason.reason, 0);
+ flags = __this_cpu_read(apf_reason.flags);
+ __this_cpu_write(apf_reason.flags, 0);
}
- return reason;
+ return flags;
}
- EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
+ EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
-NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
-bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
+noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
{
- u32 reason = kvm_read_and_reset_pf_reason();
+ u32 reason = kvm_read_and_reset_apf_flags();
+ bool rcu_exit;
switch (reason) {
case KVM_PV_REASON_PAGE_NOT_PRESENT:
pgpJaAZeMtAQQ.pgp
Description: OpenPGP digital signature
RE: [PATCH 2/4] firmware: imx: add resource management api
> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api > > > From: Peng Fan > > Sent: Monday, June 1, 2020 8:40 PM > > > > > > > From: Peng Fan > > > > Sent: Friday, April 24, 2020 9:12 AM > > > > > > > > > > > From: Peng Fan > > > > > > Sent: Thursday, April 23, 2020 6:57 PM > > > > > > > > From: Peng Fan > > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM > > > > > > > > > > > > > > > > Add resource management API, when we have multiple > > > > > > > > partition running together, resources not owned to current > > > > > > > > partition should not be > > > > > used. > > > > > > > > > > > > > > > > Reviewed-by: Leonard Crestez > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > Right now I'm still not quite understand if we really need this. > > > > > > > As current resource is bound to power domains, if it's not > > > > > > > owned by one specific SW execution environment, power on > > > > > > > will also > > fail. > > > > > > > Can you clarify if any exceptions? > > > > > > > > > > > > There will be lots of failures when boot Linux domu if no check. > > > > > > > > > > > > > > > > What kind of features did you mean? > > > > > Could you clarify a bit more? I'd like to understand this issue > > > > > better. > > > > > > > > When supporting hypervisor with dual Linux running, 1st Linux and > > > > the 2nd Linux will have their own dedicated resources. > > > > > > > > If no resource check, that means 1st/2nd Linux will register all > > > > the resources, then both will see fail logs when register > > > > resources not owned to > > > itself. > > > > > > > > Same to partitioned m4 case. > > > > > > > > Would it be better without the failure log? > > > > > > > > > > Is it power up failure? > > > If yes, it's expected because we actually use power up to check if > > > resources are owned by this partition. It functions the same as > > > calling resource check API. > > > That's current design. > > > > > > Or it's other failures? Log? > > Sorry for long late reply. > > > > Part of my XEN DomU log, there are lots of failure log. I think better > > not have such logs by add a resource own check. > > Those error logs are intended. > Resource owner check actually behaves the same as power up. If resource is not owned, it will not register the power domain. Without resource own check, it will continue register the power domain and hook it into genpd list. I prefer we not expose the power domain not owned to current partition and keep the err msg for people to easy see where it goes wrong. Regards, Peng. > So not quite necessary to add a double check. > If we're concerning about the error log, we can change it to dev_dbg(). > > BTW, as resource management will be needed by seco drivers later, So I will > continue to review the patch. > > Regards > Aisheng > > > > > [2.034774] imx6q-pcie 5f00.pcie:IO 0x6ff8..0x6ff8 -> > > 0x > > [2.034801] imx6q-pcie 5f00.pcie: MEM 0x6000..0x6fef > -> > > 0x6000 > > [2.035072] sdhc1: failed to power up resource 249 ret -13 > > [2.035619] sdhc2: failed to power up resource 250 ret -13 > > [2.036126] enet0: failed to power up resource 251 ret -13 > > [2.036584] enet1: failed to power up resource 252 ret -13 > > [2.037040] mlb0: failed to power up resource 253 ret -13 > > [2.037495] nand: failed to power up resource 265 ret -13 > > [2.037951] nand: failed to power up resource 265 ret -13 > > [2.038416] pwm0: failed to power up resource 191 ret -13 > > [2.038868] pwm1: failed to power up resource 192 ret -13 > > [2.039320] pwm2: failed to power up resource 193 ret -13 > > [2.039786] pwm3: failed to power up resource 194 ret -13 > > [2.040239] pwm4: failed to power up resource 195 ret -13 > > [2.040692] pwm5: failed to power up resource 196 ret -13 > > [2.041142] pwm6: failed to power up resource 197 ret -13 > > [2.041596] pwm7: failed to power up resource 198 ret -13 > > [2.042073] amix: failed to power up resource 458 ret -13 > > [2.042558] lpspi0: failed to power up resource 53 ret -13 > > [2.043033] lpspi1: failed to power up resource 54 ret -13 > > [2.043501] lpspi2: failed to power up resource 55 ret -13 > > [2.043992] lpspi3: failed to power up resource 56 ret -13 > > [2.044460] lpuart0: failed to power up resource 57 ret -13 > > [2.044935] lpuart2: failed to power up resource 59 ret -13 > > [2.045409] lpuart3: failed to power up resource 60 ret -13 > > [2.055014] sim0: failed to power up resource 62 ret -13 > > [2.055510] adc0: failed to power up resource 101 ret -13 > > [2.056467] lpi2c0: failed to power up resource 96 ret -13 > > [2.056946] lpi2c1: failed to power up resource 97 ret -13 > > [2.057424] lpi2c2: failed to power up resource 98 ret -13 > > [2.057898] lpi2c3: failed to power up resource 99 ret -13 > > [2.058371] can0: failed t
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 2020-06-01 21:20, Anshuman Khandual wrote: ... also important: maybe this patch should also be tracking other causes of THP PMD migration failure, in order to get a truer accounting of the situation. I hope one of the experts here can weigh in on that... Is there any other failure reasons which are only specific to THP migration. Else, adding stats about generic migration failure reasons will just blur the overall understanding about THP migration successes and failure cases that results in splitting. Thinking about that: we do have PGMIGRATE_SUCCESS and PGMIGRATE_FAIL, so I suppose comparing those numbers with the new THP_PMD_MIGRATION_SUCCESS and THP_PMD_MIGRATION_FAILURE events should cover it. However, the fact that this is under discussion hints at the need for a bit of documentation help. What do you think about adding some notes about all of this to, say, Documentation/vm/page_migration.rst ? thanks, -- John Hubbard NVIDIA
RE: [PATCH] driver core: platform: expose numa_node to users in sysfs
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, June 2, 2020 4:24 PM
> To: Song Bao Hua (Barry Song)
> Cc: raf...@kernel.org; io...@lists.linux-foundation.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> ; Zengtao (B) ; Robin
> Murphy
> Subject: Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
>
> On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> > For some platform devices like iommu, particually ARM smmu, users may
> > care about the numa locality. for example, if threads and drivers run
> > near iommu, they may get much better performance on dma_unmap_sg.
> > For other platform devices, users may still want to know the hardware
> > topology.
> >
> > Cc: Prime Zeng
> > Cc: Robin Murphy
> > Signed-off-by: Barry Song
> > ---
> > drivers/base/platform.c | 26 +-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index b27d0f6c18c9..7794b9a38d82 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct
> device *dev,
> > }
> > static DEVICE_ATTR_RW(driver_override);
> >
> > +static ssize_t numa_node_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + return sprintf(buf, "%d\n", dev_to_node(dev));
> > +}
> > +static DEVICE_ATTR_RO(numa_node);
> > +
> > +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> > + int n)
> > +{
> > + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> > +
> > + if (a == &dev_attr_numa_node.attr &&
> > + dev_to_node(dev) == NUMA_NO_NODE)
> > + return 0;
> > +
> > + return a->mode;
> > +}
> >
> > static struct attribute *platform_dev_attrs[] = {
> > &dev_attr_modalias.attr,
> > + &dev_attr_numa_node.attr,
> > &dev_attr_driver_override.attr,
> > NULL,
> > };
> > -ATTRIBUTE_GROUPS(platform_dev);
> > +
> > +static struct attribute_group platform_dev_group = {
> > + .attrs = platform_dev_attrs,
> > + .is_visible = platform_dev_attrs_visible,
> > +};
> > +__ATTRIBUTE_GROUPS(platform_dev);
> >
> > static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> > {
>
> Platform devices are NUMA? That's crazy, and feels like a total abuse
> of platform devices and drivers that really should belong on a "real"
> bus.
I am not sure if it is an abuse of platform device. But smmu is a platform
device,
drivers/iommu/arm-smmu-v3.c is a platform driver.
In a typical ARM server, there are maybe multiple SMMU devices which can support
IO virtual address and page tables for other devices on PCI-like busses.
Each different SMMU device might be close to different NUMA node. There is
really a hardware topology.
If you have multiple CPU packages in a NUMA server, some platform devices might
Belong to CPU0, some other might belong to CPU1.
-barry
>
> What drivers in the kernel today have this issue?
>
> thanks,
>
> greg k-h
linux-next: manual merge of the irqchip tree with the tip tree
Hi all,
Today's linux-next merge of the irqchip tree got a conflict in:
drivers/irqchip/Kconfig
between commit:
d77aeb5d403d ("irqchip: Fix "Loongson HyperTransport Vector support" driver
build on all non-MIPS platforms")
from the tip tree and commit:
4a786cc36028 ("irqchip/loongson-htvec: Don't compile when COMPILE_TEST is
selected")
from the irqchip tree.
I fixed it up (I just used the latter) 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
pgp0N7HCofwOe.pgp
Description: OpenPGP digital signature
[PATCH] spi: tegra20-sflash: call pm_runtime_put in case of pm_runtime_get failure
The counter is incremented via pm_runtime_get even in failure case.
To correct the counter call pm_runtime_put in case of failure, too.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-sflash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index 514429379206..33c34f9c2021 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -552,6 +552,7 @@ static int tegra_sflash_resume(struct device *dev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
+ pm_runtime_put(dev);
dev_err(dev, "pm runtime failed, e = %d\n", ret);
return ret;
}
--
2.17.1
Re: [LKP] Re: 28307d938f ("percpu: make pcpu_alloc() aware of current gfp .."): BUG: kernel reboot-without-warning in boot stage
Hi Filipe, LKP checked blow dmesg as the indicator in this problem [0.144174] RAMDISK: [mem 0x7fa2e000-0x7fff] [0.144559] ACPI: Early table checksum verification disabled [0.144985] ACPI: RSDP 0x000F5850 14 (v00 BOCHS ) [0.145424] ACPI: RSDT 0xBFFE15C9 30 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.146051] ACPI: FACP 0xBFFE149D 74 (v01 BOCHS BXPCFACP 0001 BXPC 0001) BUG: kernel reboot-without-warning in boot stage And i have reproduced it with script in attachment. this issue is gone when i reverted this commit 28307d938f Please note that - i reproduced it with kernel compiled by gcc-5 - i failed to reproduce it in kernel compiled by gcc-7 so far :~/1787$ ./reproduce.sh obj/arch/x86/boot/bzImage qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel obj/arch/x86/boot/bzImage -m 8192 -smp 2 -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::32032-:22 -boot order=nc -no-reboot -watchdog i6300esb -watchdog-action debug -rtc base=localtime -serial stdio -display none -monitor null -append root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw rcuperf.shutdown=0 watchdog_thresh=60 early console in setup code Wrong EFI loader signature. early console in extract_kernel input_data: 0x06f752d8 input_len: 0x0130dd3c output: 0x0100 output_len: 0x07200a48 kernel_total_size: 0x06826000 needed_size: 0x0740 trampoline_32bit: 0x0009d000 Decompressing Linux... Parsing ELF... done. Booting the kernel. [ 0.00] Linux version 5.7.0-rc4-00168-g28307d938fb2 (lizhijian@shao2-debian) (gcc version 5.5.0 20171010 (Debian 5.5.0-12), GNU ld (GNU Binutils for Debian) 2.34) #2 SMP PREEMPT Tue Jun 2 11:23:59 CST 2020 [ 0.00] Command line: root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw rcuperf.shutdown=0 watchdog_thresh=60 [ 0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [ 0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [ 0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [ 0.00] BIOS-e820: [mem 0x0010-0xbffd] usable [ 0.00] BIOS-e820: [mem 0xbffe-0xbfff] reserved [ 0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [ 0.00] BIOS-e820: [mem 0xfffc-0x] reserved [ 0.00] BIOS-e820: [mem 0x0001-0x00023fff] usable [ 0.00] printk: debug: ignoring loglevel setting. [ 0.00] printk: bootconsole [earlyser0] enabled [ 0.00] NX (Execute Disable) protection: active [ 0.00] SMBIOS 2.8 present. [ 0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 0.00] Hypervisor detected: KVM [ 0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [ 0.02] kvm-clock: cpu 0, msr 7601001, primary cpu clock [ 0.02] kvm-clock: using sched offset of 2661499940 cycles [ 0.000603] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.002261] tsc: Detected 3407.998 MHz processor [ 0.005351] e820: update [mem 0x-0x0fff] usable ==> reserved [ 0.005986] e820: remove [mem 0x000a-0x000f] usable [ 0.006535] last_pfn = 0x24 max_arch_pfn = 0x4 [ 0.007091] MTRR default type: write-back [ 0.007477] MTRR fixed ranges enabled: [ 0.007845] 0-9 write-back [ 0.008191] A-B uncachable [ 0.008536] C-F write-protect [ 0.008906] MTRR variable ranges enabled: [ 0.009293] 0 base 00C000 mask FFC000 uncachable [ 0.009818] 1 disabled [ 0.010064] 2 disabled [ 0.010314] 3 disabled [ 0.010561] 4 disabled [ 0.010822] 5 disabled [ 0.011072] 6 disa
[PATCH] spi: spi-ti-qspi: call pm_runtime_put on pm_runtime_get failure
The counter is incremented via pm_runtime_get even in failure case.
To correct the counter call pm_runtime_put in case of failure, too.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-ti-qspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 366a3e5cca6b..dfb811c5ef76 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -174,6 +174,7 @@ static int ti_qspi_setup(struct spi_device *spi)
ret = pm_runtime_get_sync(qspi->dev);
if (ret < 0) {
+ pm_runtime_put_autosuspend(qspi->dev);
dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
return ret;
}
--
2.17.1
Re: [PATCH] media: rkvdec: Fix H264 scaling list order
Hi Jonas,
Thanks a lot for the fix! Indeed it fixes
a few bitstream that had artifacts :)
On Fri, 2020-05-22 at 20:21 +, Jonas Karlman wrote:
> The Rockchip Video Decoder driver is expecting that the values in a
> scaling list are in zig-zag order and applies the inverse scanning process
> to get the values in matrix order.
>
> Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
> scaling_list_4x4/8x8 order") clarified that the values in the scaling list
> should already be in matrix order.
>
> Fix this by removing the reordering and change to use two memcpy.
>
> Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
> Signed-off-by: Jonas Karlman
> ---
> drivers/staging/media/rkvdec/rkvdec-h264.c | 70 +++---
> 1 file changed, 22 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c
> b/drivers/staging/media/rkvdec/rkvdec-h264.c
> index cd4980d06be7..2719f0c66a4a 100644
> --- a/drivers/staging/media/rkvdec/rkvdec-h264.c
> +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
> @@ -18,11 +18,16 @@
> /* Size with u32 units. */
> #define RKV_CABAC_INIT_BUFFER_SIZE (3680 + 128)
> #define RKV_RPS_SIZE ((128 + 128) / 4)
> -#define RKV_SCALING_LIST_SIZE(6 * 16 + 6 * 64 + 128)
> #define RKV_ERROR_INFO_SIZE (256 * 144 * 4)
>
> #define RKVDEC_NUM_REFLIST 3
>
> +struct rkvdec_scaling_matrix {
How about we call this rkvdec_scaling_list
or even rkvdec_h264_scaling_list?
It'll make code more readable and easier to grep.
> + u8 scaling_list_4x4[6][16];
> + u8 scaling_list_8x8[6][64];
> + u8 padding[128];
Oops, something is wrong here, maybe some
mistake when porting code around.
Rockchip MPP defines the scaling list size as:
#define RKV_SCALING_LIST_SIZE (6*16 + 2*64 + 128)
Consistently with the fact that 4:4:4 sampling
is not supported (chroma_format_idc == 3),
only the first two scaling matrices are used.
Moreover, given all these buffers are specified separately
(see below), I bet not even the 128 padding bytes
are needed.
> +};
> +
> struct rkvdec_sps_pps_packet {
> u32 info[8];
> };
> @@ -86,7 +91,7 @@ struct rkvdec_ps_field {
> /* Data structure describing auxiliary buffer format. */
> struct rkvdec_h264_priv_tbl {
> s8 cabac_table[4][464][2];
As can be seen, all these buffers can be allocated
independently, which perhaps could reduce the
pressure on the DMA allocator.
> - u8 scaling_list[RKV_SCALING_LIST_SIZE];
> + struct rkvdec_scaling_matrix scaling_list;
> u32 rps[RKV_RPS_SIZE];
> struct rkvdec_sps_pps_packet param_set[256];
> u8 err_info[RKV_ERROR_INFO_SIZE];
In particular, I wonder if the error info stuff
is really required.
I guess we'll want to merge a simple fix,
so no need to address any of these questions
for now.
With the struct rkvdec_scaling_matrix rename:
Reviewed-by: Ezequiel Garcia
Thanks,
Ezequiel
> @@ -785,56 +790,25 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
> }
> }
>
> -/*
> - * NOTE: The values in a scaling list are in zig-zag order, apply inverse
> - * scanning process to get the values in matrix order.
> - */
> -static const u32 zig_zag_4x4[16] = {
> - 0, 1, 4, 8, 5, 2, 3, 6, 9, 12, 13, 10, 7, 11, 14, 15
> -};
> -
> -static const u32 zig_zag_8x8[64] = {
> - 0, 1, 8, 16, 9, 2, 3, 10, 17, 24, 32, 25, 18, 11, 4, 5,
> - 12, 19, 26, 33, 40, 48, 41, 34, 27, 20, 13, 6, 7, 14, 21, 28,
> - 35, 42, 49, 56, 57, 50, 43, 36, 29, 22, 15, 23, 30, 37, 44, 51,
> - 58, 59, 52, 45, 38, 31, 39, 46, 53, 60, 61, 54, 47, 55, 62, 63
> -};
> -
> -static void reorder_scaling_list(struct rkvdec_ctx *ctx,
> - struct rkvdec_h264_run *run)
> +static void assemble_hw_scaling_list(struct rkvdec_ctx *ctx,
> + struct rkvdec_h264_run *run)
> {
> const struct v4l2_ctrl_h264_scaling_matrix *scaling =
> run->scaling_matrix;
> - const size_t num_list_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4);
> - const size_t list_len_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4[0]);
> - const size_t num_list_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8);
> - const size_t list_len_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8[0]);
> struct rkvdec_h264_ctx *h264_ctx = ctx->priv;
> struct rkvdec_h264_priv_tbl *tbl = h264_ctx->priv_tbl.cpu;
> - u8 *dst = tbl->scaling_list;
> - const u8 *src;
> - int i, j;
> -
> - BUILD_BUG_ON(ARRAY_SIZE(zig_zag_4x4) != list_len_4x4);
> - BUILD_BUG_ON(ARRAY_SIZE(zig_zag_8x8) != list_len_8x8);
> - BUILD_BUG_ON(ARRAY_SIZE(tbl->scaling_list) <
> - num_list_4x4 * list_len_4x4 +
> - num_list_8x8 * list_len_8x8);
> -
> - src = &scaling->scaling_list_4x4[0][0];
> - for (i = 0; i < num_list_4x4; ++i) {
> - for (j = 0; j < list_len_4x4; ++j)
> - dst[zig_zag_4x4[j]] = src[j];
> -
Re: [PATCH] driver core: platform: need consistent spacing around '-'
On Tue, Jun 02, 2020 at 03:47:17PM +1200, Barry Song wrote: > Signed-off-by: Barry Song > --- > drivers/base/platform.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index b27d0f6c18c9..ab9408182a0d 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -1005,7 +1005,7 @@ static ssize_t modalias_show(struct device *dev, struct > device_attribute *a, > if (len != -ENODEV) > return len; > > - len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); > + len = acpi_device_modalias(dev, buf, PAGE_SIZE - 1); > if (len != -ENODEV) > return len; > > -- > 2.23.0 > > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
[PATCH 1/2] perf tools: check libasan and libubsan in Makefile.config
When build perf with ASan or UBSan, if libasan or libubsan can not find, the feature-glibc is 0 and there exists the following error log which is wrong, because we can find gnu/libc-version.h in /usr/include, glibc-devel is also installed. [yangtiezhu@linux perf]$ make DEBUG=1 EXTRA_CFLAGS='-fno-omit-frame-pointer -fsanitize=address' BUILD: Doing 'make -j4' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep :1:0: warning: -fsanitize=address and -fsanitize=kernel-address are not supported for this target :1:0: warning: -fsanitize=address not supported for this target Auto-detecting system features: ... dwarf: [ OFF ] ...dwarf_getlocations: [ OFF ] ... glibc: [ OFF ] ... gtk2: [ OFF ] ... libaudit: [ OFF ] ...libbfd: [ OFF ] ...libcap: [ OFF ] ...libelf: [ OFF ] ... libnuma: [ OFF ] ...numa_num_possible_cpus: [ OFF ] ... libperl: [ OFF ] ... libpython: [ OFF ] ... libcrypto: [ OFF ] ... libunwind: [ OFF ] ...libdw-dwarf-unwind: [ OFF ] ... zlib: [ OFF ] ... lzma: [ OFF ] ... get_cpuid: [ OFF ] ... bpf: [ OFF ] ...libaio: [ OFF ] ... libzstd: [ OFF ] ...disassembler-four-args: [ OFF ] Makefile.config:393: *** No gnu/libc-version.h found, please install glibc-dev[el]. Stop. Makefile.perf:224: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:69: recipe for target 'all' failed make: *** [all] Error 2 [yangtiezhu@linux perf]$ ls /usr/include/gnu/libc-version.h /usr/include/gnu/libc-version.h After install libasan and libubsan, the feature-glibc is 1 and the build process is success, so the cause is related with libasan or libubsan, we should check them and print an error log to reflect the reality. Signed-off-by: Tiezhu Yang --- tools/perf/Makefile.config | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index 12a8204..b699d21 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -387,6 +387,12 @@ else NO_LIBBPF := 1 NO_JVMTI := 1 else + ifneq ($(shell ldconfig -p | grep libasan >/dev/null 2>&1; echo $$?), 0) +msg := $(error No libasan found, please install libasan); + endif + ifneq ($(shell ldconfig -p | grep libubsan >/dev/null 2>&1; echo $$?), 0) +msg := $(error No libubsan found, please install libubsan); + endif ifneq ($(filter s% -static%,$(LDFLAGS),),) msg := $(error No static glibc found, please install glibc-static); else -- 2.1.0
Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform devices, users may still want to know the hardware
> topology.
>
> Cc: Prime Zeng
> Cc: Robin Murphy
> Signed-off-by: Barry Song
> ---
> drivers/base/platform.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b27d0f6c18c9..7794b9a38d82 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device
> *dev,
> }
> static DEVICE_ATTR_RW(driver_override);
>
> +static ssize_t numa_node_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", dev_to_node(dev));
> +}
> +static DEVICE_ATTR_RO(numa_node);
> +
> +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> + int n)
> +{
> + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> +
> + if (a == &dev_attr_numa_node.attr &&
> + dev_to_node(dev) == NUMA_NO_NODE)
> + return 0;
> +
> + return a->mode;
> +}
>
> static struct attribute *platform_dev_attrs[] = {
> &dev_attr_modalias.attr,
> + &dev_attr_numa_node.attr,
> &dev_attr_driver_override.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(platform_dev);
> +
> +static struct attribute_group platform_dev_group = {
> + .attrs = platform_dev_attrs,
> + .is_visible = platform_dev_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(platform_dev);
>
> static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
Also you forgot a new entry in Documentation/ABI/ :(
Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform devices, users may still want to know the hardware
> topology.
>
> Cc: Prime Zeng
> Cc: Robin Murphy
> Signed-off-by: Barry Song
> ---
> drivers/base/platform.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b27d0f6c18c9..7794b9a38d82 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device
> *dev,
> }
> static DEVICE_ATTR_RW(driver_override);
>
> +static ssize_t numa_node_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", dev_to_node(dev));
> +}
> +static DEVICE_ATTR_RO(numa_node);
> +
> +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> + int n)
> +{
> + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> +
> + if (a == &dev_attr_numa_node.attr &&
> + dev_to_node(dev) == NUMA_NO_NODE)
> + return 0;
> +
> + return a->mode;
> +}
>
> static struct attribute *platform_dev_attrs[] = {
> &dev_attr_modalias.attr,
> + &dev_attr_numa_node.attr,
> &dev_attr_driver_override.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(platform_dev);
> +
> +static struct attribute_group platform_dev_group = {
> + .attrs = platform_dev_attrs,
> + .is_visible = platform_dev_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(platform_dev);
>
> static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
Platform devices are NUMA? That's crazy, and feels like a total abuse
of platform devices and drivers that really should belong on a "real"
bus.
What drivers in the kernel today have this issue?
thanks,
greg k-h
