Re: [PATCH] netfilter: use __u8 instead of uint8_t in uapi header
On Sat, Sep 21, 2019 at 10:46:48PM +0900, Masahiro Yamada wrote:
> When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
> make sure they can be included from user-space.
>
> Currently, linux/netfilter_bridge/ebtables.h is excluded from the test
> coverage. To make it join the compile-test, we need to fix the build
> errors attached below.
>
> For a case like this, we decided to use __u{8,16,32,64} variable types
> in this discussion:
>
> https://lkml.org/lkml/2019/6/5/18
>
> Build log:
>
> CC usr/include/linux/netfilter_bridge/ebtables.h.s
> In file included from :32:0:
> ./usr/include/linux/netfilter_bridge/ebtables.h:126:4: error: unknown type
> name ‘uint8_t’
> uint8_t revision;
> ^~~
> ./usr/include/linux/netfilter_bridge/ebtables.h:139:4: error: unknown type
> name ‘uint8_t’
> uint8_t revision;
> ^~~
> ./usr/include/linux/netfilter_bridge/ebtables.h:152:4: error: unknown type
> name ‘uint8_t’
> uint8_t revision;
> ^~~
Applied.
Re: [PATCH] netfilter: use __u8 instead of uint8_t in uapi header
On Sun, Sep 22, 2019 at 09:11:11AM +0200, Pablo Neira Ayuso wrote:
> On Sat, Sep 21, 2019 at 10:46:48PM +0900, Masahiro Yamada wrote:
> > When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
> > make sure they can be included from user-space.
> >
> > Currently, linux/netfilter_bridge/ebtables.h is excluded from the test
> > coverage. To make it join the compile-test, we need to fix the build
> > errors attached below.
> >
> > For a case like this, we decided to use __u{8,16,32,64} variable types
> > in this discussion:
> >
> > https://lkml.org/lkml/2019/6/5/18
> >
> > Build log:
> >
> > CC usr/include/linux/netfilter_bridge/ebtables.h.s
> > In file included from :32:0:
> > ./usr/include/linux/netfilter_bridge/ebtables.h:126:4: error: unknown type
> > name ‘uint8_t’
> > uint8_t revision;
> > ^~~
> > ./usr/include/linux/netfilter_bridge/ebtables.h:139:4: error: unknown type
> > name ‘uint8_t’
> > uint8_t revision;
> > ^~~
> > ./usr/include/linux/netfilter_bridge/ebtables.h:152:4: error: unknown type
> > name ‘uint8_t’
> > uint8_t revision;
> > ^~~
>
> Applied.
Patch does not apply cleanly to nf.git, I have to keep it back, sorry
$ git am /tmp/yamada.masahiro.txt -s
Applying: netfilter: use __u8 instead of uint8_t in uapi header
error: patch failed: usr/include/Makefile:37
error: usr/include/Makefile: patch does not apply
Patch failed at 0001 netfilter: use __u8 instead of uint8_t in uapi header
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
[PATCH] [media] cx88: Fix some error handling path in 'cx8800_initdev()'
A call to 'pci_disable_device()' is missing in the error handling path.
In some cases, a call to 'free_irq()' may also be missing.
Reorder the error handling path, add some new labels and fix the 2 issues
mentionned above.
This way, the error handling path in more in line with 'cx8800_finidev()'
(i.e. the remove function)
Signed-off-by: Christophe JAILLET
---
It is likely that this is still incomplete, but at least it should be
better :)
---
drivers/media/pci/cx88/cx88-video.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-video.c
b/drivers/media/pci/cx88/cx88-video.c
index dcc0f02aeb70..b8abcd550604 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1277,7 +1277,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
core = cx88_core_get(dev->pci);
if (!core) {
err = -EINVAL;
- goto fail_free;
+ goto fail_disable;
}
dev->core = core;
@@ -1323,7 +1323,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
cc->step, cc->default_value);
if (!vc) {
err = core->audio_hdl.error;
- goto fail_core;
+ goto fail_irq;
}
vc->priv = (void *)cc;
}
@@ -1337,7 +1337,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
cc->step, cc->default_value);
if (!vc) {
err = core->video_hdl.error;
- goto fail_core;
+ goto fail_irq;
}
vc->priv = (void *)cc;
if (vc->id == V4L2_CID_CHROMA_AGC)
@@ -1509,11 +1509,14 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
fail_unreg:
cx8800_unregister_video(dev);
- free_irq(pci_dev->irq, dev);
mutex_unlock(&core->lock);
+fail_irq:
+ free_irq(pci_dev->irq, dev);
fail_core:
core->v4ldev = NULL;
cx88_core_put(core, dev->pci);
+fail_disable:
+ pci_disable_device(pci_dev);
fail_free:
kfree(dev);
return err;
--
2.20.1
Re: [PATCH v2] mm: implement write-behind policy for sequential file writes
Hi Konstantin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3 next-20190919] [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/Konstantin-Khlebnikov/mm-implement-write-behind-policy-for-sequential-file-writes/20190920-155606 reproduce: make htmldocs :: branch date: 8 hours ago :: commit date: 8 hours ago If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:1: warning: no structured comments found drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1: warning: no structured comments found drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:1: warning: 'pp_dpm_sclk pp_dpm_mclk pp_dpm_pcie' not found drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:132: warning: Incorrect use of kernel-doc format: Documentation Makefile include scripts source @atomic_obj drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:238: warning: Incorrect use of kernel-doc format: Documentation Makefile include scripts source gpu_info FW provided soc bounding box struct or 0 if not drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'atomic_obj' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'backlight_link' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'backlight_caps' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'freesync_module' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'fw_dmcu' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'dmcu_fw_version' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:243: warning: Function parameter or member 'soc_bounding_box' not described in 'amdgpu_display_manager' drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1: warning: 'register_hpd_handlers' not found drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1: warning: 'dm_crtc_high_irq' not found drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1: warning: 'dm_pflip_high_irq' not found include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/gpio/gpiolib-of.c:92: warning: Excess function parameter 'dev' description in 'of_gpio_need_valid_mask' include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' fs/fs-writeback.c:913: warning: Excess function parameter 'nr_pages' description in 'cgroup_writeback_by_id' fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found kernel/dma/coherent.c:1: warning: no structured comments found include/linux/input/sparse-keymap.h:43: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/skbuff.h:888: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/s
Re: [PATCH] uapi, posix-timers: provide clockid-related macros and functions to UAPI
Hi Eugene, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3 next-20190920] [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/Eugene-Syromiatnikov/uapi-posix-timers-provide-clockid-related-macros-and-functions-to-UAPI/20190921-051356 config: i386-randconfig-a003-201937 (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 :: branch date: 6 hours ago :: commit date: 6 hours ago If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from ./usr/include/linux/timex.h:56:0, from :32: >> ./usr/include/linux/time.h:98:19: error: unknown type name 'clockid_t' static __inline__ clockid_t make_process_cpuclock(const unsigned int pid, ^ ./usr/include/linux/time.h:99:9: error: unknown type name 'clockid_t' const clockid_t clock) ^ ./usr/include/linux/time.h:103:19: error: unknown type name 'clockid_t' static __inline__ clockid_t make_thread_cpuclock(const unsigned int tid, ^ ./usr/include/linux/time.h:104:9: error: unknown type name 'clockid_t' const clockid_t clock) ^ ./usr/include/linux/time.h:109:19: error: unknown type name 'clockid_t' static __inline__ clockid_t fd_to_clockid(const int fd) ^ ./usr/include/linux/time.h:114:43: error: unknown type name 'clockid_t' static __inline__ int clockid_to_fd(const clockid_t clk) ^ --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: .config.gz
Re: [PATCH 5.3 00/21] 5.3.1-stable review
On Fri, Sep 20, 2019 at 05:01:35PM +0100, Jon Hunter wrote: > > On 20/09/2019 15:24, Greg Kroah-Hartman wrote: > > On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote: > >> > >> On 19/09/2019 23:03, Greg Kroah-Hartman wrote: > >>> This is the start of the stable review cycle for the 5.3.1 release. > >>> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC. > >>> 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.3.1-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.3.y > >>> and the diffstat can be found below. > >>> > >>> thanks, > >>> > >>> greg k-h > >> > >> No new regressions* for Tegra ... > >> > >> Test results for stable-v5.3: > >> 12 builds: 12 pass, 0 fail > >> 22 boots: 22 pass, 0 fail > >> 38 tests: 37 pass, 1 fail > >> > >> Linux version: 5.3.1-rc1-g0aa7f3d6baae > >> Boards tested: tegra124-jetson-tk1, tegra186-p2771-, > >> tegra194-p2972-, tegra20-ventana, > >> tegra210-p2371-2180, tegra30-cardhu-a04 > >> > >> * Note we had one regression in v5.3 for a warnings test for Tegra194 > >> causing the above test failure. This has since been fixed by the > >> following commits [0] but given it is just a warning, I have not > >> bothered CC'ing for stable. > >> > >> Cheers > >> Jon > >> > >> [0] https://lkml.org/lkml/2019/8/21/602 > > > > I'll be glad to take this in stable for 5.3.y, what is the git commit > > id? > > OK, that would be great. The IDs are ... > > commit 763719771e84b8c8c2f53af668cdc905faa608de > Author: Jon Hunter > Date: Wed Aug 21 16:02:40 2019 +0100 > > clocksource/drivers/timer-of: Do not warn on deferred probe > > > commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be > Author: Jon Hunter > Date: Wed Aug 21 16:02:41 2019 +0100 > > clocksource/drivers: Do not warn on probe defer > > Now queued up, thanks! greg k-h
Re: [PATCH v8 9/9] leds: Update the lp55xx to use the multi color framework
Hi Dan, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3 next-20190920] [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/Dan-Murphy/leds-multicolor-Add-sysfs-interface-definition/20190921-092827 config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 :: branch date: 5 hours ago :: commit date: 5 hours ago If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "led_classdev_multicolor_register_ext" >> [drivers/leds/leds-lp55xx-common.ko] undefined! >> ERROR: "led_mc_calc_brightness" [drivers/leds/leds-lp55xx-common.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: .config.gz
Re: [PATCH] gen-insn-attr-x86.awk: Fix regexp warnings
Hi Alexander, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3 next-20190920] [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/Alexander-Kapshuk/gen-insn-attr-x86-awk-Fix-regexp-warnings/20190921-194307 config: x86_64-lkp (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 :: branch date: 73 minutes ago :: commit date: 73 minutes ago If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): >> Warning: Kernel ABI header at 'tools/arch/x86/tools/gen-insn-attr-x86.awk' >> differs from latest version at 'arch/x86/tools/gen-insn-attr-x86.awk' 55 real 10 user 5 sys 29.61% cpu make prepare --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: .config.gz
Re: [PATCH 4.19 03/79] RDMA/restrack: Release task struct which was hold by CM_ID object
On Sat, Sep 21, 2019 at 10:22:10PM +0200, Pavel Machek wrote: > Hi! > > > commit ed7a01fd3fd77f40b4ef2562b966a5decd8928d2 upstream. > > > > Tracking CM_ID resource is performed in two stages: creation of cm_id > > and connecting it to the cma_dev. It is needed because rdma-cm protocol > > exports two separate user-visible calls rdma_create_id and > > rdma_accept. > ... > > Mainline says this needs additional fix, fe9bc1644918aa1d, see below. > > > --- a/drivers/infiniband/core/restrack.c > > +++ b/drivers/infiniband/core/restrack.c > > @@ -209,7 +209,7 @@ void rdma_restrack_del(struct rdma_restr > > struct ib_device *dev; > > > > if (!res->valid) > > - return; > > + goto out; > > > > dev = res_to_dev(res); > > if (!dev) > # return; > > This test does return, does it need to go through 'goto out', too? (I > see it should not happen, but...) > > > @@ -222,8 +222,10 @@ void rdma_restrack_del(struct rdma_restr > > down_write(&dev->res.rwsem); > > hash_del(&res->node); > > res->valid = false; > > + up_write(&dev->res.rwsem); > > + > > +out: > > if (res->task) > > put_task_struct(res->task); > > - up_write(&dev->res.rwsem); > > } > > Mainline says res->task = NULL is needed there, see fe9bc1644918aa1d. Good catch, now queued up, thanks! greg k-h
Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
Hi Yu,
I love your patch! Yet something to improve:
[auto build test ERROR on arm/for-next]
[cannot apply to v5.3 next-20190920]
[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/Yu-Chen/arm-export-memblock_reserve-d-regions-via-proc-iomem/20190921-214007
base: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
config: arm-ixp4xx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
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
GCC_VERSION=7.4.0 make.cross ARCH=arm
:: branch date: 3 hours ago
:: commit date: 3 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/arm/kernel/setup.c: In function 'reserve_memblock_reserved_regions':
>> arch/arm/kernel/setup.c:918:18: error: 'num_standard_resources' undeclared
>> (first use in this function); did you mean 'request_standard_resources'?
for (i = 0; i < num_standard_resources; ++i) {
^~
request_standard_resources
arch/arm/kernel/setup.c:918:18: note: each undeclared identifier is reported
only once for each function it appears in
>> arch/arm/kernel/setup.c:919:27: error: 'standard_resources' undeclared
>> (first use in this function); did you mean 'num_standard_resources'?
struct resource *mem = &standard_resources[i];
^~
num_standard_resources
#
https://github.com/0day-ci/linux/commit/4d551f57b6f9f07cdff5690f541f76e78c656c68
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 4d551f57b6f9f07cdff5690f541f76e78c656c68
vim +918 arch/arm/kernel/setup.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 913
4d551f57b6f9f0 Yu Chen2019-09-21 914 static int __init
reserve_memblock_reserved_regions(void)
4d551f57b6f9f0 Yu Chen2019-09-21 915 {
4d551f57b6f9f0 Yu Chen2019-09-21 916 u64 i, j;
4d551f57b6f9f0 Yu Chen2019-09-21 917
4d551f57b6f9f0 Yu Chen2019-09-21 @918 for (i = 0; i <
num_standard_resources; ++i) {
4d551f57b6f9f0 Yu Chen2019-09-21 @919 struct resource *mem =
&standard_resources[i];
4d551f57b6f9f0 Yu Chen2019-09-21 920 phys_addr_t r_start,
r_end, mem_size = resource_size(mem);
4d551f57b6f9f0 Yu Chen2019-09-21 921
4d551f57b6f9f0 Yu Chen2019-09-21 922 if
(!memblock_is_region_reserved(mem->start, mem_size))
4d551f57b6f9f0 Yu Chen2019-09-21 923 continue;
4d551f57b6f9f0 Yu Chen2019-09-21 924
4d551f57b6f9f0 Yu Chen2019-09-21 925
for_each_reserved_mem_region(j, &r_start, &r_end) {
4d551f57b6f9f0 Yu Chen2019-09-21 926 resource_size_t
start, end;
4d551f57b6f9f0 Yu Chen2019-09-21 927
4d551f57b6f9f0 Yu Chen2019-09-21 928 start =
max(PFN_PHYS(PFN_DOWN(r_start)), mem->start);
4d551f57b6f9f0 Yu Chen2019-09-21 929 end =
min(PFN_PHYS(PFN_UP(r_end)) - 1, mem->end);
4d551f57b6f9f0 Yu Chen2019-09-21 930
4d551f57b6f9f0 Yu Chen2019-09-21 931 if (start >
mem->end || end < mem->start)
4d551f57b6f9f0 Yu Chen2019-09-21 932
continue;
4d551f57b6f9f0 Yu Chen2019-09-21 933
4d551f57b6f9f0 Yu Chen2019-09-21 934
reserve_region_with_split(mem, start, end, "reserved");
4d551f57b6f9f0 Yu Chen2019-09-21 935 }
4d551f57b6f9f0 Yu Chen2019-09-21 936 }
4d551f57b6f9f0 Yu Chen2019-09-21 937
4d551f57b6f9f0 Yu Chen2019-09-21 938 return 0;
4d551f57b6f9f0 Yu Chen2019-09-21 939 }
4d551f57b6f9f0 Yu Chen2019-09-21 940
arch_initcall(reserve_memblock_reserved_regions);
4d551f57b6f9f0 Yu Chen2019-09-21 941
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: latest git kernel (v5.3-11506-gf7c3bf8fa7e5) does not compile
On Sun, Sep 22, 2019 at 11:13 AM Anatoly Pugachev wrote:
>
> Hello!
>
> Latest git kernel does not compile for me:
>
> ~/linux-2.6$ git desc
> v5.3-11506-gf7c3bf8fa7e5
>
> ~/linux-2.6$ make
> CALLscripts/checksyscalls.sh
> :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> CALLscripts/atomic/check-atomics.sh
> CHK include/generated/compile.h
> CC arch/sparc/vdso/vdso32/vclock_gettime.o
> unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o
> arch/sparc/vdso/vdso32/vclock_gettime.o: failed
> make[2]: *** [scripts/Makefile.build:266:
> arch/sparc/vdso/vdso32/vclock_gettime.o] Error 1
> make[2]: *** Deleting file 'arch/sparc/vdso/vdso32/vclock_gettime.o'
> make[1]: *** [scripts/Makefile.build:509: arch/sparc/vdso] Error 2
> make: *** [Makefile:1667: arch/sparc] Error
>
> but I was able to compile successfully v5.3-10169-g574cc4539762
>
> Not sure my bisect log is right, but here it is:
>
> $ git bisect good
> 54b8ae66ae1a3454a7645d159a482c31cd89ab33 is the first bad commit
> commit 54b8ae66ae1a3454a7645d159a482c31cd89ab33
> Author: Masahiro Yamada
> Date: Fri Aug 30 13:34:01 2019 +0900
>
> kbuild: change *FLAGS_.o to take the path relative to $(obj)
>
> Kbuild provides per-file compiler flag addition/removal:
>
> CFLAGS_.o
> CFLAGS_REMOVE_.o
> AFLAGS_.o
> AFLAGS_REMOVE_.o
> CPPFLAGS_.lds
> HOSTCFLAGS_.o
> HOSTCXXFLAGS_.o
>
> The is the filename of the target with its directory and
> suffix stripped.
>
> This syntax comes into a trouble when two files with the same basename
> appear in one Makefile, for example:
>
> obj-y += foo.o
> obj-y += dir/foo.o
> CFLAGS_foo.o :=
>
> Here, the applies to both foo.o and dir/foo.o
>
> The real world problem is:
>
> scripts/kconfig/util.c
> scripts/kconfig/lxdialog/util.c
>
> Both files are compiled into scripts/kconfig/mconf, but only the
> latter should be given with the ncurses flags.
>
> It is more sensible to use the relative path to the Makefile, like this:
>
> obj-y += foo.o
> CFLAGS_foo.o :=
> obj-y += dir/foo.o
> CFLAGS_dir/foo.o :=
>
> At first, I attempted to replace $(basetarget) with $*. The $* variable
> is replaced with the stem ('%') part in a pattern rule. This works with
> most of cases, but does not for explicit rules.
>
> For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
> explicit rules, so $* will be empty, resulting in ignoring the per-file
> AFLAGS.
>
> I introduced a new variable, target-stem, which can be used also from
> explicit rules.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Marc Zyngier
>
> arch/arm/kvm/Makefile | 5 +++--
> arch/x86/entry/vdso/Makefile | 3 ++-
> drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 +++---
> drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 2 +-
> drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 +++--
> drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 +++
> drivers/gpu/drm/i915/Makefile | 2 +-
> scripts/Makefile.host | 22 +++---
> scripts/Makefile.lib | 13 -
> scripts/kconfig/Makefile | 8
> 10 files changed, 43 insertions(+), 42 deletions(-)
> mator@ttip:~/linux-2.6$
>
>
> If someone wants to check how kernel compiles on sparc64, could use
> gcc compile farm machine (gcc202) to try on.
and i cannot test compile 54b8ae66ae1a3454a7645d159a482c31cd89ab33 as well :
~/linux-2.6$ git checkout 54b8ae66ae1a3454a7645d159a482c31cd89ab33
HEAD is now at 54b8ae66ae1a kbuild: change *FLAGS_.o to
take the path relative to $(obj)
~/linux-2.6$ make -j clean; make -j olddefconfig && nice make -j24
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACCscripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --olddefconfig Kconfig
#
# No change to .config
#
scripts/kconfig/conf --syncconfig Kconfig
{ command -v gcc; } >/dev/null 2>&1 && echo "n" || echo "y": Cannot
allocate memory
make[2]: *** [scripts/kconfig/Makefile:73: syncconfig] Error 1
make[1]: *** [Makefile:584: syncconfig] Error 2
make: *** [Makefile:695: include/config/auto.conf.cmd] Error 2
~/linux-2.6$
PS: unable to compile kernel makes its bisection impossible =(
[PATCH] dmaengine: at_xdmac: Use devm_platform_ioremap_resource() in at_xdmac_probe()
From: Markus Elfring
Date: Sun, 22 Sep 2019 10:37:31 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/at_xdmac.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index b58ac720d9a1..f71c9f77d405 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1957,21 +1957,16 @@ static int atmel_xdmac_resume(struct device *dev)
static int at_xdmac_probe(struct platform_device *pdev)
{
- struct resource *res;
struct at_xdmac *atxdmac;
int irq, size, nr_channels, i, ret;
void __iomem*base;
u32 reg;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -EINVAL;
-
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
- base = devm_ioremap_resource(&pdev->dev, res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
2.23.0
[PATCH] dmaengine: jz4780: Use devm_platform_ioremap_resource() in jz4780_dma_probe()
From: Markus Elfring
Date: Sun, 22 Sep 2019 11:18:27 +0200
Simplify this function implementation a bit by using
a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/dma-jz4780.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c
index cafb1cc065bb..f42b3ef8e036 100644
--- a/drivers/dma/dma-jz4780.c
+++ b/drivers/dma/dma-jz4780.c
@@ -858,13 +858,7 @@ static int jz4780_dma_probe(struct platform_device *pdev)
jzdma->soc_data = soc_data;
platform_set_drvdata(pdev, jzdma);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "failed to get I/O memory\n");
- return -EINVAL;
- }
-
- jzdma->chn_base = devm_ioremap_resource(dev, res);
+ jzdma->chn_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(jzdma->chn_base))
return PTR_ERR(jzdma->chn_base);
--
2.23.0
[PATCH] dmaengine: k3dma: Use devm_platform_ioremap_resource() in k3_dma_probe()
From: Markus Elfring Date: Sun, 22 Sep 2019 11:36:18 +0200 Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/dma/k3dma.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c index 4b36c8810517..adecea51814f 100644 --- a/drivers/dma/k3dma.c +++ b/drivers/dma/k3dma.c @@ -835,13 +835,8 @@ static int k3_dma_probe(struct platform_device *op) const struct k3dma_soc_data *soc_data; struct k3_dma_dev *d; const struct of_device_id *of_id; - struct resource *iores; int i, ret, irq = 0; - iores = platform_get_resource(op, IORESOURCE_MEM, 0); - if (!iores) - return -EINVAL; - d = devm_kzalloc(&op->dev, sizeof(*d), GFP_KERNEL); if (!d) return -ENOMEM; @@ -850,7 +845,7 @@ static int k3_dma_probe(struct platform_device *op) if (!soc_data) return -EINVAL; - d->base = devm_ioremap_resource(&op->dev, iores); + d->base = devm_platform_ioremap_resource(op, 0); if (IS_ERR(d->base)) return PTR_ERR(d->base); -- 2.23.0
Re: [PATCH v2 2/5] leds: lm3692x: Don't overwrite return value in error path
Hi Dan,
On Fri, Sep 20, 2019 at 06:48:59AM -0500, Dan Murphy wrote:
> Guido
>
> On 9/20/19 12:27 AM, Guido Günther wrote:
> > The driver currently reports successful initialization on every failure
> > as long as it's able to power off the regulator. Don't check the return
> > value of regulator_disable to avoid that.
> >
> > Signed-off-by: Guido Günther
> > ---
> > drivers/leds/leds-lm3692x.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
> > index 487228c2bed2..31115655f97b 100644
> > --- a/drivers/leds/leds-lm3692x.c
> > +++ b/drivers/leds/leds-lm3692x.c
> > @@ -198,7 +198,7 @@ static int lm3692x_brightness_set(struct led_classdev
> > *led_cdev,
> > static int lm3692x_init(struct lm3692x_led *led)
> > {
> > int enable_state;
> > - int ret;
> > + int ret, ret2;
> > if (led->regulator) {
> > ret = regulator_enable(led->regulator);
> > @@ -313,14 +313,15 @@ static int lm3692x_init(struct lm3692x_led *led)
> > gpiod_direction_output(led->enable_gpio, 0);
> > if (led->regulator) {
> > - ret = regulator_disable(led->regulator);
> > - if (ret)
> > + ret2 = regulator_disable(led->regulator);
> > + if (ret2)
> > dev_err(&led->client->dev,
> > "Failed to disable regulator\n");
>
> s/ret2/reg_ret
>
> Like you did in patch 1 log the error code as well.
>
> If regulator_disabled failed you might want to send that error code but
> either error returned is fine.
Changed in v3 - i opted to return the original error code since this is
likely what upper layers care about and only printk the regulator
failure one.
Thanks for the review,
-- Guido
>
> Dan
>
>
> > }
> > return ret;
> > }
> > +
> > static int lm3692x_probe_dt(struct lm3692x_led *led)
> > {
> > struct fwnode_handle *child = NULL;
>
[PATCH v3 1/5] leds: lm3692x: Print error value on dev_err
This gives a way better idea what is going on.
Signed-off-by: Guido Günther
Reviewed-by: Dan Murphy
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3692x.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 3d381f2f73d0..487228c2bed2 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -174,19 +174,20 @@ static int lm3692x_brightness_set(struct led_classdev
*led_cdev,
ret = lm3692x_fault_check(led);
if (ret) {
- dev_err(&led->client->dev, "Cannot read/clear faults\n");
+ dev_err(&led->client->dev, "Cannot read/clear faults: %d\n",
+ ret);
goto out;
}
ret = regmap_write(led->regmap, LM3692X_BRT_MSB, brt_val);
if (ret) {
- dev_err(&led->client->dev, "Cannot write MSB\n");
+ dev_err(&led->client->dev, "Cannot write MSB: %d\n", ret);
goto out;
}
ret = regmap_write(led->regmap, LM3692X_BRT_LSB, led_brightness_lsb);
if (ret) {
- dev_err(&led->client->dev, "Cannot write LSB\n");
+ dev_err(&led->client->dev, "Cannot write LSB: %d\n", ret);
goto out;
}
out:
@@ -203,7 +204,7 @@ static int lm3692x_init(struct lm3692x_led *led)
ret = regulator_enable(led->regulator);
if (ret) {
dev_err(&led->client->dev,
- "Failed to enable regulator\n");
+ "Failed to enable regulator: %d\n", ret);
return ret;
}
}
@@ -213,7 +214,8 @@ static int lm3692x_init(struct lm3692x_led *led)
ret = lm3692x_fault_check(led);
if (ret) {
- dev_err(&led->client->dev, "Cannot read/clear faults\n");
+ dev_err(&led->client->dev, "Cannot read/clear faults: %d\n",
+ ret);
goto out;
}
@@ -409,7 +411,8 @@ static int lm3692x_remove(struct i2c_client *client)
ret = regmap_update_bits(led->regmap, LM3692X_EN, LM3692X_DEVICE_EN, 0);
if (ret) {
- dev_err(&led->client->dev, "Failed to disable regulator\n");
+ dev_err(&led->client->dev, "Failed to disable regulator: %d\n",
+ ret);
return ret;
}
@@ -420,7 +423,7 @@ static int lm3692x_remove(struct i2c_client *client)
ret = regulator_disable(led->regulator);
if (ret)
dev_err(&led->client->dev,
- "Failed to disable regulator\n");
+ "Failed to disable regulator: %d\n", ret);
}
mutex_destroy(&led->lock);
--
2.23.0.rc1
[PATCH v3 4/5] leds: lm3692x: Use flags from LM3692X_BOOST_CTRL
The current setup of LM3692X_BOOST_CTRL uses flags from LM3692X_BRT_CTRL. Use flags from LM3692X_BOOST_CTRL but leave the resulting register value unchanged. Signed-off-by: Guido Günther Reviewed-by: Dan Murphy Acked-by: Pavel Machek --- drivers/leds/leds-lm3692x.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c index 54e9bd2d288b..a57b1571e359 100644 --- a/drivers/leds/leds-lm3692x.c +++ b/drivers/leds/leds-lm3692x.c @@ -250,9 +250,9 @@ static int lm3692x_init(struct lm3692x_led *led) goto out; ret = regmap_write(led->regmap, LM3692X_BOOST_CTRL, - LM3692X_BRHT_MODE_RAMP_MULTI | - LM3692X_BL_ADJ_POL | - LM3692X_RAMP_RATE_250us); + LM3692X_BOOST_SW_1MHZ | + LM3692X_BOOST_SW_NO_SHIFT | + LM3692X_OCP_PROT_1_5A); if (ret) goto out; -- 2.23.0.rc1
[PATCH v3 0/5] leds: lm3692x: Probing and flag fixes
The driver currently returns success on init although probing fails and register setup uses flag values from other registers which is confusing when reading the driver. This series cleans this up. Changes from v2: - Add Acked-by from Pavel Machek, thanks! https://lore.kernel.org/linux-leds/20190920114743.GA21835@amd/ - As per review comment from Dan Murphy https://lore.kernel.org/linux-leds/2bde2870-08a3-38b9-9cd7-fee0e2107...@ti.com/ - rename return value from ret2 to reg_ret - print error code Changes from v1: - Add reviewed by's from Dan Murphy, thanks! https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#mc183f3f65931371fa9f9ca2e0e83e0b85010f24b https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#mb845fac36327a5d5dd03fe7e988eef0eb5626f82 https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#m995bce73dda3e3bd4f0c2e8f98cbd04a39c13832 - As per review comment from Dan Murphy - Don't drop error message when disabling the regulator fails https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#m2ab6dc33b7277b71a197c3747847f1c4d9d9c1d8 - Handle -ENODEV (when the regulator is not set) https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#mf6212c29bbfa37b43200ea2c9744074de4f068ee - Add Acked-by from Pavel Machek, thanks! https://lore.kernel.org/linux-leds/20190919095415.GA29939@amd/ Guido Günther (5): leds: lm3692x: Print error value on dev_err leds: lm3692x: Don't overwrite return value in error path leds: lm3692x: Handle failure to probe the regulator leds: lm3692x: Use flags from LM3692X_BOOST_CTRL leds: lm3692x: Use flags from LM3692X_BRT_CTRL drivers/leds/leds-lm3692x.c | 47 +++-- 1 file changed, 30 insertions(+), 17 deletions(-) -- 2.23.0.rc1
[PATCH v3 3/5] leds: lm3692x: Handle failure to probe the regulator
Instead use devm_regulator_get_optional since the regulator
is optional and check for errors.
Signed-off-by: Guido Günther
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3692x.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index ad76e34455ff..54e9bd2d288b 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -337,9 +337,18 @@ static int lm3692x_probe_dt(struct lm3692x_led *led)
return ret;
}
- led->regulator = devm_regulator_get(&led->client->dev, "vled");
- if (IS_ERR(led->regulator))
+ led->regulator = devm_regulator_get_optional(&led->client->dev, "vled");
+ if (IS_ERR(led->regulator)) {
+ ret = PTR_ERR(led->regulator);
+ if (ret != -ENODEV) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(&led->client->dev,
+ "Failed to get vled regulator: %d\n",
+ ret);
+ return ret;
+ }
led->regulator = NULL;
+ }
child = device_get_next_child_node(&led->client->dev, child);
if (!child) {
--
2.23.0.rc1
[PATCH v3 5/5] leds: lm3692x: Use flags from LM3692X_BRT_CTRL
Use LM3692X_RAMP_EN instead of LM3692X_PWM_HYSTER_4LSB since the later is a flag for the PWM register. The actual register value remains unchanged. Signed-off-by: Guido Günther Reviewed-by: Dan Murphy Acked-by: Pavel Machek --- drivers/leds/leds-lm3692x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c index a57b1571e359..8b408102e138 100644 --- a/drivers/leds/leds-lm3692x.c +++ b/drivers/leds/leds-lm3692x.c @@ -269,7 +269,7 @@ static int lm3692x_init(struct lm3692x_led *led) goto out; ret = regmap_write(led->regmap, LM3692X_BRT_CTRL, - LM3692X_BL_ADJ_POL | LM3692X_PWM_HYSTER_4LSB); + LM3692X_BL_ADJ_POL | LM3692X_RAMP_EN); if (ret) goto out; -- 2.23.0.rc1
[PATCH v3 2/5] leds: lm3692x: Don't overwrite return value in error path
The driver currently reports successful initialization on every failure
as long as it's able to power off the regulator. Don't check the return
value of regulator_disable to avoid that.
Signed-off-by: Guido Günther
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3692x.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 487228c2bed2..ad76e34455ff 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -198,7 +198,7 @@ static int lm3692x_brightness_set(struct led_classdev
*led_cdev,
static int lm3692x_init(struct lm3692x_led *led)
{
int enable_state;
- int ret;
+ int ret, reg_ret;
if (led->regulator) {
ret = regulator_enable(led->regulator);
@@ -313,14 +313,15 @@ static int lm3692x_init(struct lm3692x_led *led)
gpiod_direction_output(led->enable_gpio, 0);
if (led->regulator) {
- ret = regulator_disable(led->regulator);
- if (ret)
+ reg_ret = regulator_disable(led->regulator);
+ if (reg_ret)
dev_err(&led->client->dev,
- "Failed to disable regulator\n");
+ "Failed to disable regulator: %d\n", reg_ret);
}
return ret;
}
+
static int lm3692x_probe_dt(struct lm3692x_led *led)
{
struct fwnode_handle *child = NULL;
--
2.23.0.rc1
Re: [GIT PULL] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo/Thomas, > > Please consider pulling, > > Best regards, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 351a1f5c8afa13ea5cfcdae543f6596ef8ebdbd9: > > Merge tag 'perf-core-for-mingo-5.4-20190920-2' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2019-09-20 18:16:42 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-5.4-20190921 > > for you to fetch changes up to 9f014e3a66bc936412b6614304a4e6c70c70230e: > > perf/core: Fix several typos in comments (2019-09-20 16:05:20 -0300) > > > perf/urgent fixes > > perf tests: > > Jiri Olsa: > > - Fix 'make -C tools/perf build-test' static build entry. > > perf record: > > Jiri Olsa: > > - Fix segfault in cpu_cache_level__read() when reading CPU topology. > > session: > > Mamatha Inamdar: > > - Properly propagate error when reading a perf.data file, it may > not exist or the user may not have permissions, etc. > > perf probe: > > Masami Hiramatsu: > > - Skip same probe address for a given line. > > - Clear tev->nargs in clear_probe_trace_event(), fixing segfault. > > tools headers UAPI: > > Arnaldo Carvalho de Melo: > > - Sync headers, among them prctl.h, that introduces two new options > that are now supported in the 'perf trace' prctl syscall args > beautifiers. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (4): > tools headers uapi: Sync prctl.h with the kernel sources > tools uapi asm-generic: Sync unistd.h with the kernel sources > tools arch x86 uapi: Synch asm/unistd.h with the kernel sources > tools arch x86: Sync asm/cpufeatures.h with the kernel sources > > Jiri Olsa (2): > perf tests: Fix static build test > perf tools: Fix segfault in cpu_cache_level__read() > > Mamatha Inamdar (1): > perf session: Return error code for perf_session__new() function on > failure > > Masami Hiramatsu (2): > perf probe: Skip same probe address for a given line > perf probe: Fix to clear tev->nargs in clear_probe_trace_event() > > Roy Ben Shlomo (1): > perf/core: Fix several typos in comments > > kernel/events/core.c | 6 +++--- > tools/arch/x86/include/asm/cpufeatures.h | 3 +++ > tools/arch/x86/include/uapi/asm/unistd.h | 2 +- > tools/include/uapi/asm-generic/unistd.h | 2 +- > tools/include/uapi/linux/prctl.h | 7 ++- > tools/perf/builtin-annotate.c| 5 +++-- > tools/perf/builtin-buildid-cache.c | 5 +++-- > tools/perf/builtin-buildid-list.c| 5 +++-- > tools/perf/builtin-c2c.c | 6 -- > tools/perf/builtin-diff.c| 9 + > tools/perf/builtin-evlist.c | 5 +++-- > tools/perf/builtin-inject.c | 5 +++-- > tools/perf/builtin-kmem.c| 5 +++-- > tools/perf/builtin-kvm.c | 9 + > tools/perf/builtin-lock.c| 5 +++-- > tools/perf/builtin-mem.c | 5 +++-- > tools/perf/builtin-record.c | 5 +++-- > tools/perf/builtin-report.c | 4 ++-- > tools/perf/builtin-sched.c | 11 ++- > tools/perf/builtin-script.c | 9 + > tools/perf/builtin-stat.c| 11 ++- > tools/perf/builtin-timechart.c | 5 +++-- > tools/perf/builtin-top.c | 5 +++-- > tools/perf/builtin-trace.c | 4 ++-- > tools/perf/tests/make| 2 +- > tools/perf/tests/topology.c | 5 +++-- > tools/perf/util/data-convert-bt.c| 5 - > tools/perf/util/header.c | 2 +- > tools/perf/util/probe-event.c| 1 + > tools/perf/util/probe-finder.c | 19 +++ > tools/perf/util/session.c| 15 +++ > 31 files changed, 122 insertions(+), 65 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
[tip: perf/urgent] tools arch x86: Sync asm/cpufeatures.h with the kernel sources
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 40f1c039c7c6de913ee04eac585102e2fce7f6f7
Gitweb:
https://git.kernel.org/tip/40f1c039c7c6de913ee04eac585102e2fce7f6f7
Author:Arnaldo Carvalho de Melo
AuthorDate:Fri, 20 Sep 2019 15:00:49 -03:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 15:00:49 -03:00
tools arch x86: Sync asm/cpufeatures.h with the kernel sources
To pick up the changes from:
b4dd4f6e3648 ("x86/vmware: Add a header file for hypercall definitions")
f36cf386e3fe ("x86/speculation/swapgs: Exclude ATOMs from speculation through
SWAPGS")
be261ffce6f1 ("x86: Remove X86_FEATURE_MFENCE_RDTSC")
018ebca8bd70 ("x86/cpufeatures: Enable a new AVX512 CPU feature")
These don't cause any changes in tooling, just silences this perf build
warning:
Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h'
differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
diff -u tools/arch/x86/include/asm/cpufeatures.h
arch/x86/include/asm/cpufeatures.h
To clarify, updating those files cause these bits of tools/perf to rebuild:
CC /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
CC /tmp/build/perf/bench/mem-memset-x86-64-asm.o
INSTALL GTK UI
LD /tmp/build/perf/bench/perf-in.o
Those use just:
$ grep FEATURE tools/arch/x86/lib/mem*.S
tools/arch/x86/lib/memcpy_64.S: ALTERNATIVE_2 "jmp memcpy_orig", "",
X86_FEATURE_REP_GOOD, \
tools/arch/x86/lib/memcpy_64.S: "jmp memcpy_erms",
X86_FEATURE_ERMS
tools/arch/x86/lib/memset_64.S: ALTERNATIVE_2 "jmp memset_orig", "",
X86_FEATURE_REP_GOOD, \
tools/arch/x86/lib/memset_64.S: "jmp memset_erms",
X86_FEATURE_ERMS
$
I.e. none of the feature defines added/removed by the patches above.
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Gayatri Kammela
Cc: Jiri Olsa
Cc: Josh Poimboeuf
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Thomas Hellstrom
Link: https://lkml.kernel.org/n/tip-pq63abgknsaeov23p80d8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/x86/include/asm/cpufeatures.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/arch/x86/include/asm/cpufeatures.h
b/tools/arch/x86/include/asm/cpufeatures.h
index 5171b9c..0652d3e 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -231,6 +231,8 @@
#define X86_FEATURE_VMMCALL( 8*32+15) /* Prefer VMMCALL to VMCALL
*/
#define X86_FEATURE_XENPV ( 8*32+16) /* "" Xen paravirtual guest
*/
#define X86_FEATURE_EPT_AD ( 8*32+17) /* Intel Extended Page Table
access-dirty bit */
+#define X86_FEATURE_VMCALL ( 8*32+18) /* "" Hypervisor supports
the VMCALL instruction */
+#define X86_FEATURE_VMW_VMMCALL( 8*32+19) /* "" VMware prefers
VMMCALL hypercall instruction */
/* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
#define X86_FEATURE_FSGSBASE ( 9*32+ 0) /* RDFSBASE, WRFSBASE,
RDGSBASE, WRGSBASE instructions*/
@@ -354,6 +356,7 @@
/* Intel-defined CPU features, CPUID level 0x0007:0 (EDX), word 18 */
#define X86_FEATURE_AVX512_4VNNIW (18*32+ 2) /* AVX-512 Neural Network
Instructions */
#define X86_FEATURE_AVX512_4FMAPS (18*32+ 3) /* AVX-512 Multiply
Accumulation Single precision */
+#define X86_FEATURE_AVX512_VP2INTERSECT (18*32+ 8) /* AVX-512 Intersect for
D/Q */
#define X86_FEATURE_MD_CLEAR (18*32+10) /* VERW clears CPU buffers */
#define X86_FEATURE_TSX_FORCE_ABORT(18*32+13) /* "" TSX_FORCE_ABORT */
#define X86_FEATURE_PCONFIG(18*32+18) /* Intel PCONFIG */
[tip: perf/urgent] perf probe: Skip same probe address for a given line
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 1a375ae7659ab740d4c885ea98c1659b8a6e2071
Gitweb:
https://git.kernel.org/tip/1a375ae7659ab740d4c885ea98c1659b8a6e2071
Author:Masami Hiramatsu
AuthorDate:Thu, 19 Sep 2019 12:41:10 +09:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 15:22:00 -03:00
perf probe: Skip same probe address for a given line
Fix to skip making a same probe address on given line.
Since a DWARF line info contains several entries for one line with
different column, perf probe will make a different probe on same address
if user specifies a probe point by "function:line" or "file:line".
e.g.
$ perf probe -D kernel_read:8
p:probe/kernel_read_L8 kernel_read+39
p:probe/kernel_read_L8_1 kernel_read+39
This skips such duplicated probe addresses.
Committer testing:
# uname -a
Linux quaco 5.3.0+ #2 SMP Thu Sep 19 16:13:22 -03 2019 x86_64 x86_64 x86_64
GNU/Linux
#
Before:
# perf probe -D kernel_read:8
p:probe/kernel_read _text+3115191
p:probe/kernel_read_1 _text+3115191
#
After:
# perf probe -D kernel_read:8
p:probe/kernel_read _text+3115191
#
Signed-off-by: Masami Hiramatsu
Tested-by: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link:
http://lore.kernel.org/lkml/156886447061.10772.4261569305869149178.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-finder.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 505905f..cd9f95e 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1245,6 +1245,17 @@ static int expand_probe_args(Dwarf_Die *sc_die, struct
probe_finder *pf,
return n;
}
+static bool trace_event_finder_overlap(struct trace_event_finder *tf)
+{
+ int i;
+
+ for (i = 0; i < tf->ntevs; i++) {
+ if (tf->pf.addr == tf->tevs[i].point.address)
+ return true;
+ }
+ return false;
+}
+
/* Add a found probe point into trace event list */
static int add_probe_trace_event(Dwarf_Die *sc_die, struct probe_finder *pf)
{
@@ -1255,6 +1266,14 @@ static int add_probe_trace_event(Dwarf_Die *sc_die,
struct probe_finder *pf)
struct perf_probe_arg *args = NULL;
int ret, i;
+ /*
+* For some reason (e.g. different column assigned to same address)
+* This callback can be called with the address which already passed.
+* Ignore it first.
+*/
+ if (trace_event_finder_overlap(tf))
+ return 0;
+
/* Check number of tevs */
if (tf->ntevs == tf->max_tevs) {
pr_warning("Too many( > %d) probe point found.\n",
[tip: perf/urgent] tools uapi asm-generic: Sync unistd.h with the kernel sources
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 9846f1366489e1a30d871a5c3198b14394365be7
Gitweb:
https://git.kernel.org/tip/9846f1366489e1a30d871a5c3198b14394365be7
Author:Arnaldo Carvalho de Melo
AuthorDate:Fri, 20 Sep 2019 14:52:24 -03:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 14:59:28 -03:00
tools uapi asm-generic: Sync unistd.h with the kernel sources
To pick the change from:
78e05972c5e6 ("ipc: fix semtimedop for generic 32-bit architectures")
Which doesn't trigger any change in tooling and silences this perf build
warning:
Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/unistd.h'
differs from latest version at 'include/uapi/asm-generic/unistd.h'
diff -u tools/include/uapi/asm-generic/unistd.h
include/uapi/asm-generic/unistd.h
Cc: Adrian Hunter
Cc: Arnd Bergmann
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: https://lkml.kernel.org/n/tip-hpnjuyjzoudltqe7dvbok...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/include/uapi/asm-generic/unistd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/uapi/asm-generic/unistd.h
b/tools/include/uapi/asm-generic/unistd.h
index 1be0e79..1fc8faa 100644
--- a/tools/include/uapi/asm-generic/unistd.h
+++ b/tools/include/uapi/asm-generic/unistd.h
@@ -569,7 +569,7 @@ __SYSCALL(__NR_semget, sys_semget)
__SC_COMP(__NR_semctl, sys_semctl, compat_sys_semctl)
#if defined(__ARCH_WANT_TIME32_SYSCALLS) || __BITS_PER_LONG != 32
#define __NR_semtimedop 192
-__SC_COMP(__NR_semtimedop, sys_semtimedop, sys_semtimedop_time32)
+__SC_3264(__NR_semtimedop, sys_semtimedop_time32, sys_semtimedop)
#endif
#define __NR_semop 193
__SYSCALL(__NR_semop, sys_semop)
[tip: perf/urgent] perf/core: Fix several typos in comments
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 9f014e3a66bc936412b6614304a4e6c70c70230e
Gitweb:
https://git.kernel.org/tip/9f014e3a66bc936412b6614304a4e6c70c70230e
Author:Roy Ben Shlomo
AuthorDate:Fri, 20 Sep 2019 20:12:53 +03:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 16:05:20 -03:00
perf/core: Fix several typos in comments
Fix typos in a few functions' documentation comments.
Signed-off-by: Roy Ben Shlomo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: r...@sentinelone.com
Link: http://lore.kernel.org/lkml/20190920171254.31373-1-r...@sentinelone.com
Signed-off-by: Arnaldo Carvalho de Melo
---
kernel/events/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4f08b17..275eae0 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2239,7 +2239,7 @@ static void __perf_event_disable(struct perf_event *event,
*
* If event->ctx is a cloned context, callers must make sure that
* every task struct that event->ctx->task could possibly point to
- * remains valid. This condition is satisifed when called through
+ * remains valid. This condition is satisfied when called through
* perf_event_for_each_child or perf_event_for_each because they
* hold the top-level event's child_mutex, so any descendant that
* goes to exit will block in perf_event_exit_event().
@@ -6054,7 +6054,7 @@ static void perf_sample_regs_intr(struct perf_regs
*regs_intr,
* Get remaining task size from user stack pointer.
*
* It'd be better to take stack vma map and limit this more
- * precisly, but there's no way to get it safely under interrupt,
+ * precisely, but there's no way to get it safely under interrupt,
* so using TASK_SIZE as limit.
*/
static u64 perf_ustack_task_size(struct pt_regs *regs)
@@ -6616,7 +6616,7 @@ void perf_prepare_sample(struct perf_event_header *header,
if (sample_type & PERF_SAMPLE_STACK_USER) {
/*
-* Either we need PERF_SAMPLE_STACK_USER bit to be allways
+* Either we need PERF_SAMPLE_STACK_USER bit to be always
* processed as the last one or have additional check added
* in case new sample type is added, because we could eat
* up the rest of the sample size.
[tip: perf/urgent] perf session: Return error code for perf_session__new() function on failure
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 6ef81c55a2b6584cb642917f5fdf3632ef44b670
Gitweb:
https://git.kernel.org/tip/6ef81c55a2b6584cb642917f5fdf3632ef44b670
Author:Mamatha Inamdar
AuthorDate:Thu, 22 Aug 2019 12:50:49 +05:30
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 15:58:11 -03:00
perf session: Return error code for perf_session__new() function on failure
This patch is to return error code of perf_new_session function on
failure instead of NULL.
Test Results:
Before Fix:
$ perf c2c report -input
failed to open nput: No such file or directory
$ echo $?
0
$
After Fix:
$ perf c2c report -input
failed to open nput: No such file or directory
$ echo $?
254
$
Committer notes:
Fix 'perf tests topology' case, where we use that TEST_ASSERT_VAL(...,
session), i.e. we need to pass zero in case of failure, which was the
case before when NULL was returned by perf_session__new() for failure,
but now we need to negate the result of IS_ERR(session) to respect that
TEST_ASSERT_VAL) expectation of zero meaning failure.
Reported-by: Nageswara R Sastry
Signed-off-by: Mamatha Inamdar
Tested-by: Arnaldo Carvalho de Melo
Tested-by: Nageswara R Sastry
Acked-by: Ravi Bangoria
Reviewed-by: Jiri Olsa
Reviewed-by: Mukesh Ojha
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: Alexey Budankov
Cc: Greg Kroah-Hartman
Cc: Jeremie Galarneau
Cc: Kate Stewart
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Shawn Landden
Cc: Song Liu
Cc: Thomas Gleixner
Cc: Tzvetomir Stoyanov
Link:
http://lore.kernel.org/lkml/20190822071223.17892.45782.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-annotate.c | 5 +++--
tools/perf/builtin-buildid-cache.c | 5 +++--
tools/perf/builtin-buildid-list.c | 5 +++--
tools/perf/builtin-c2c.c | 6 --
tools/perf/builtin-diff.c | 9 +
tools/perf/builtin-evlist.c| 5 +++--
tools/perf/builtin-inject.c| 5 +++--
tools/perf/builtin-kmem.c | 5 +++--
tools/perf/builtin-kvm.c | 9 +
tools/perf/builtin-lock.c | 5 +++--
tools/perf/builtin-mem.c | 5 +++--
tools/perf/builtin-record.c| 5 +++--
tools/perf/builtin-report.c| 4 ++--
tools/perf/builtin-sched.c | 11 ++-
tools/perf/builtin-script.c| 9 +
tools/perf/builtin-stat.c | 11 ++-
tools/perf/builtin-timechart.c | 5 +++--
tools/perf/builtin-top.c | 5 +++--
tools/perf/builtin-trace.c | 4 ++--
tools/perf/tests/topology.c| 5 +++--
tools/perf/util/data-convert-bt.c | 5 -
tools/perf/util/session.c | 15 +++
22 files changed, 86 insertions(+), 57 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 553c651..8db8fc9 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
struct perf_annotate {
struct perf_tool tool;
@@ -584,8 +585,8 @@ int cmd_annotate(int argc, const char **argv)
data.path = input_name;
annotate.session = perf_session__new(&data, false, &annotate.tool);
- if (annotate.session == NULL)
- return -1;
+ if (IS_ERR(annotate.session))
+ return PTR_ERR(annotate.session);
annotate.has_br_stack = perf_header__has_feat(&annotate.session->header,
HEADER_BRANCH_STACK);
diff --git a/tools/perf/builtin-buildid-cache.c
b/tools/perf/builtin-buildid-cache.c
index 1a69eb5..39efa51 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -28,6 +28,7 @@
#include "util/util.h"
#include "util/probe-file.h"
#include
+#include
static int build_id_cache__kcore_buildid(const char *proc_dir, char *sbuildid)
{
@@ -422,8 +423,8 @@ int cmd_buildid_cache(int argc, const char **argv)
data.force = force;
session = perf_session__new(&data, false, NULL);
- if (session == NULL)
- return -1;
+ if (IS_ERR(session))
+ return PTR_ERR(session);
}
if (symbol__init(session ? &session->header.env : NULL) < 0)
diff --git a/tools/perf/builtin-buildid-list.c
b/tools/perf/builtin-buildid-list.c
index 5a0d8b3..e3ef755 100644
--- a/tools/perf/builtin-buildid-list.c
+++ b/tools/perf/builtin-buildid-list.c
@@ -18,6 +18,7 @@
#include "util/symbol.h"
#include "util/data.h"
#include
+#include
static int sysfs__fprintf_build_id(FILE *fp)
{
@@ -65,8 +66,8 @@ static int perf_session__list_build_ids(bool force, bool
with_hits)
goto out;
session = perf_session__new(&data, false, &build_id__mark_dso_hit_ops);
- if (session == NULL)
-
[tip: perf/urgent] tools arch x86 uapi: Synch asm/unistd.h with the kernel sources
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 761830a03c5c99fc0a7142e16cf0811cb68bd7af
Gitweb:
https://git.kernel.org/tip/761830a03c5c99fc0a7142e16cf0811cb68bd7af
Author:Arnaldo Carvalho de Melo
AuthorDate:Fri, 20 Sep 2019 14:56:47 -03:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 14:59:28 -03:00
tools arch x86 uapi: Synch asm/unistd.h with the kernel sources
To pick up the change in:
45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long")
That doesn't trigger any changes in tooling and silences this perf build
warning:
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/unistd.h'
differs from latest version at 'arch/x86/include/uapi/asm/unistd.h'
diff -u tools/arch/x86/include/uapi/asm/unistd.h
arch/x86/include/uapi/asm/unistd.h
Cc: Adrian Hunter
Cc: Andy Lutomirski
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/x86/include/uapi/asm/unistd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/arch/x86/include/uapi/asm/unistd.h
b/tools/arch/x86/include/uapi/asm/unistd.h
index 30d7d04..196fdd0 100644
--- a/tools/arch/x86/include/uapi/asm/unistd.h
+++ b/tools/arch/x86/include/uapi/asm/unistd.h
@@ -3,7 +3,7 @@
#define _UAPI_ASM_X86_UNISTD_H
/* x32 syscall flag bit */
-#define __X32_SYSCALL_BIT 0x4000
+#define __X32_SYSCALL_BIT 0x4000UL
#ifndef __KERNEL__
# ifdef __i386__
[tip: perf/urgent] perf probe: Fix to clear tev->nargs in clear_probe_trace_event()
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 9e6124d9d635957b56717f85219a88701617253f
Gitweb:
https://git.kernel.org/tip/9e6124d9d635957b56717f85219a88701617253f
Author:Masami Hiramatsu
AuthorDate:Mon, 16 Sep 2019 01:44:40 +09:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 15:30:09 -03:00
perf probe: Fix to clear tev->nargs in clear_probe_trace_event()
Since add_probe_trace_event() can reuse tf->tevs[i] after calling
clear_probe_trace_event(), this can make perf-probe crash if the 1st
attempt of probe event finding fails to find an event argument, and the
2nd attempt fails to find probe point.
E.g.
$ perf probe -D "task_pid_nr tsk"
Failed to find 'tsk' in this function.
Failed to get entry address of warn_bad_vsyscall
Segmentation fault (core dumped)
Committer testing:
After the patch:
$ perf probe -D "task_pid_nr tsk"
Failed to find 'tsk' in this function.
Failed to get entry address of warn_bad_vsyscall
Failed to get entry address of signal_fault
Failed to get entry address of show_signal
Failed to get entry address of umip_printk
Failed to get entry address of __bad_area_nosemaphore
Failed to get entry address of sock_set_timeout
Failed to get entry address of tcp_recvmsg
Probe point 'task_pid_nr' not found.
Error: Failed to add events.
$
Fixes: 092b1f0b5f9f ("perf probe: Clear probe_trace_event when
add_probe_trace_event() fails")
Signed-off-by: Masami Hiramatsu
Tested-by: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link:
http://lore.kernel.org/lkml/156856587999.25775.5145779959474477595.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-event.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b8e0967..91cab5f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2331,6 +2331,7 @@ void clear_probe_trace_event(struct probe_trace_event
*tev)
}
}
zfree(&tev->args);
+ tev->nargs = 0;
}
struct kprobe_blacklist_node {
[PATCH] dmaengine: mediatek: Use devm_platform_ioremap_resource() in mtk_cqdma_probe()
From: Markus Elfring
Date: Sun, 22 Sep 2019 12:52:25 +0200
Simplify this function implementation a bit by using
a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/mediatek/mtk-cqdma.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
index 723b11c190b3..6bf838e63be1 100644
--- a/drivers/dma/mediatek/mtk-cqdma.c
+++ b/drivers/dma/mediatek/mtk-cqdma.c
@@ -819,15 +819,7 @@ static int mtk_cqdma_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&cqdma->pc[i]->queue);
spin_lock_init(&cqdma->pc[i]->lock);
refcount_set(&cqdma->pc[i]->refcnt, 0);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, i);
- if (!res) {
- dev_err(&pdev->dev, "No mem resource for %s\n",
- dev_name(&pdev->dev));
- return -EINVAL;
- }
-
- cqdma->pc[i]->base = devm_ioremap_resource(&pdev->dev, res);
+ cqdma->pc[i]->base = devm_platform_ioremap_resource(pdev, i);
if (IS_ERR(cqdma->pc[i]->base))
return PTR_ERR(cqdma->pc[i]->base);
--
2.23.0
[PATCH] dmaengine: mediatek: Use devm_platform_ioremap_resource() in mtk_uart_apdma_probe()
From: Markus Elfring
Date: Sun, 22 Sep 2019 13:07:41 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/mediatek/mtk-uart-apdma.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/dma/mediatek/mtk-uart-apdma.c
b/drivers/dma/mediatek/mtk-uart-apdma.c
index f40051d6aecb..c20e6bd4e298 100644
--- a/drivers/dma/mediatek/mtk-uart-apdma.c
+++ b/drivers/dma/mediatek/mtk-uart-apdma.c
@@ -475,7 +475,6 @@ static int mtk_uart_apdma_probe(struct platform_device
*pdev)
struct device_node *np = pdev->dev.of_node;
struct mtk_uart_apdmadev *mtkd;
int bit_mask = 32, rc;
- struct resource *res;
struct mtk_chan *c;
unsigned int i;
@@ -532,13 +531,7 @@ static int mtk_uart_apdma_probe(struct platform_device
*pdev)
goto err_no_dma;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, i);
- if (!res) {
- rc = -ENODEV;
- goto err_no_dma;
- }
-
- c->base = devm_ioremap_resource(&pdev->dev, res);
+ c->base = devm_platform_ioremap_resource(pdev, i);
if (IS_ERR(c->base)) {
rc = PTR_ERR(c->base);
goto err_no_dma;
--
2.23.0
[GIT PULL] RTC for 5.4
Hello Linus, Here is the pull-request for the RTC subsystem for 5.4. Two new drivers and the new pcf2127 feature make the bulk of the additions. The rest are the usual fixes and new features. The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-5.4 for you to fetch changes up to b99a3120f9a30e1429d8d634e18da8dff93340c6: rtc: meson: mark PM functions as __maybe_unused (2019-09-10 16:14:15 +0200) RTC for 5.4 Subsystem: - add debug message when registration fails New drivers: - Amlogic Virtual Wake - Freescale FlexTimer Module alarm Drivers: - remove superfluous error messages - convert to i2c_new_dummy_device and devm_i2c_new_dummy_device - Remove dev_err() usage after platform_get_irq() - Set RTC range for: pcf2123, pcf8563, snvs. - pcf2127: tamper detection and watchdog support - pcf85363: fix regmap issue - sun6i: H6 support - remove w90x900/nuc900 driver Alejandro González (1): rtc: sun6i: Allow using as wakeup source from suspend Alexandre Belloni (19): rtc: pcf2123: don't use weekday alarm rtc; pcf2123: fix possible alarm race condition rtc: pcf2123: implement .alarm_irq_enable rtc: pcf2123: stop using dev.platform_data rtc: pcf2123: rename struct and variables rtc: pcf2123: remove useless error path goto rtc: pcf2123: convert to devm_rtc_allocate_device rtc: pcf2123: let the core handle range offsetting rtc: pcf2123: add proper compatible string rtc: class: add debug message when registration fails rtc: remove superfluous error message rtc: ds1672: remove unnecessary check rtc: snvs: set range rtc: snvs: switch to rtc_time64_to_tm/rtc_tm_to_time64 rtc: pcf8563: add Epson RTC8564 compatible rtc: pcf8563: add Microcrystal RV8564 compatible rtc: pcf8563: convert to devm_rtc_allocate_device rtc: pcf8563: remove useless indirection rtc: pcf8563: let the core handle range offsetting Anson Huang (3): rtc: mxc_v2: use devm_platform_ioremap_resource() to simplify code rtc: imxdi: use devm_platform_ioremap_resource() to simplify code rtc: snvs: fix possible race condition Arnd Bergmann (2): rtc: remove w90x900/nuc900 driver rtc: meson: mark PM functions as __maybe_unused Baolin Wang (1): rtc: sc27xx: Remove clearing SPRD_RTC_POWEROFF_ALM_FLAG flag Bastian Krause (1): dt-bindings: rtc: ds1307: add rx8130 compatible Biwen Li (3): dt-bindings: rtc: add bindings for FlexTimer Module rtc: fsl-ftm-alarm: add FTM alarm driver rtc: pcf85363/pcf85263: fix regmap error in set_time Bruno Thomsen (6): rtc: pcf2127: convert to devm_rtc_allocate_device rtc: pcf2127: cleanup register and bit defines rtc: pcf2127: bugfix: read rtc disables watchdog rtc: pcf2127: add watchdog feature support rtc: pcf2127: add tamper detection support rtc: pcf2127: bugfix: watchdog build dependency Dan Carpenter (1): rtc: rv3029: revert error handling patch to rv3029_eeprom_write() Fuqian Huang (1): rtc: mxc: use spin_lock_irqsave instead of spin_lock_irq in IRQ context Kevin Hilman (1): dt-bindings: rtc: new binding for Amlogic VRTC Matti Vaittinen (1): rtc: bd70528: fix driver dependencies Maxime Ripard (1): dt-bindings: rtc: Remove the PCF8563 from the trivial RTCs Neil Armstrong (1): rtc: Add Amlogic Virtual Wake RTC Ondrej Jirman (2): dt-bindings: rtc: sun6i: Add compatible for H6 RTC rtc: sun6i: Add support for H6 RTC Stephen Boyd (1): rtc: Remove dev_err() usage after platform_get_irq() Wolfram Sang (6): rtc: isl12026: convert to i2c_new_dummy_device rtc: max77686: convert to i2c_new_dummy_device rtc: s35390a: convert to i2c_new_dummy_device rtc: s5m: convert to i2c_new_dummy_device rtc: max77686: convert to devm_i2c_new_dummy_device() rtc: s35390a: convert to devm_i2c_new_dummy_device() .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 13 + .../devicetree/bindings/rtc/nxp,rtc-2123.txt | 4 +- Documentation/devicetree/bindings/rtc/pcf8563.txt | 4 +- .../devicetree/bindings/rtc/rtc-ds1307.txt | 1 + .../devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt | 36 ++ .../devicetree/bindings/rtc/rtc-meson-vrtc.txt | 22 ++ .../devicetree/bindings/rtc/trivial-rtc.yaml | 2 - MAINTAINERS| 1 + drivers/rtc/Kconfig| 42 ++- drivers/rtc/Makefile | 3 +- drivers/rtc/class.c| 4 +- drivers/rtc/rtc-88pm80x.c
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
* Linus Torvalds wrote: > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > wrote: > > > > Sorry about that. I am surprised that none of the other reviewers > > brought this up. > > I think I'm "special". > > There was some other similar change a few years ago, which I > absolutely hated because of how it broke autocomplete for me. Very few > other people seemed to react to it. FWIW, I am obsessively sensitive to autocomplete and overall source code file hieararchy and nomenclature details as well, so it's not just you. Beyond the muscle memory aspect, nonsensical naming and inanely flat file hierarchies annoy kernel developers and makes it harder for newbies to understand the kernel source as well. The less clutter, the more organization, the better - and there's very few valid technical reasons to add any new files or directories to the top level directory - we should probably *remove* quite a few. For example 'firmware/' was recently moved to drivers/firmware/, and in a similar fashion about a third of the remaining 22 directories should probably be moved too: drwxr-xr-xarch drwxr-xr-xblock drwxr-xr-xcerts # move to build/certs/ dir drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ drwxr-xr-xDocumentation drwxr-xr-xdrivers drwxr-xr-xfs drwxr-xr-xinclude drwxr-xr-xinit drwxr-xr-xipc # move to kernel/ipc/ drwxr-xr-xkernel drwxr-xr-xlib drwxr-xr-xLICENSES drwxr-xr-xmm drwxr-xr-xnet drwxr-xr-xsamples # move to Documentation/samples/ drwxr-xr-xscripts # move to build/scripts/ drwxr-xr-xsecurity drwxr-xr-xsound # move to drivers/sound/ drwxr-xr-xtools drwxr-xr-xusr # move to build/usr/ drwxr-xr-xvirt# move to the already existing drivers/virt/ -rw-r--r--COPYING -rw-r--r--CREDITS -rw-r--r--Kbuild -rw-r--r--Kconfig -rw-r--r--MAINTAINERS -rw-r--r--Makefile -rw-r--r--README There's a few borderline ones: - 'block' could in principle move to drivers/block/core/ but it's fine at the top level too I think. - 'init' could in principle be moved to kernel/init/ - but it's not wrong at the top level either. The remaining top level hierarchy would look pretty sweet and short: drwxr-xr-xarch drwxr-xr-xblock drwxr-xr-xbuild # new drwxr-xr-xDocumentation drwxr-xr-xdrivers drwxr-xr-xfs drwxr-xr-xinclude drwxr-xr-xinit drwxr-xr-xkernel drwxr-xr-xlib drwxr-xr-xLICENSES drwxr-xr-xmm drwxr-xr-xnet drwxr-xr-xsecurity drwxr-xr-xtools -rw-r--r--COPYING -rw-r--r--CREDITS -rw-r--r--Kbuild -rw-r--r--Kconfig -rw-r--r--MAINTAINERS -rw-r--r--Makefile -rw-r--r--README I'm volunteering to do this (in a scripted, repeatable, reviewable, tweakable and "easy to execute in a quiet moment" fashion), although I also expect you to balk at the churn. :-) Thanks, Ingo
[PATCH] dmaengine: owl: Use devm_platform_ioremap_resource() in owl_dma_probe()
From: Markus Elfring
Date: Sun, 22 Sep 2019 13:23:54 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/owl-dma.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index 90bbcef99ef8..023f951189a7 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -1045,18 +1045,13 @@ static int owl_dma_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct owl_dma *od;
- struct resource *res;
int ret, i, nr_channels, nr_requests;
od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
if (!od)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -EINVAL;
-
- od->base = devm_ioremap_resource(&pdev->dev, res);
+ od->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(od->base))
return PTR_ERR(od->base);
--
2.23.0
[PATCH] sparc: vdso: fix build error of vdso32
Since commit 54b8ae66ae1a ("kbuild: change *FLAGS_.o to
take the path relative to $(obj)"), sparc allmodconfig fails to build
as follows:
CC arch/sparc/vdso/vdso32/vclock_gettime.o
unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o
arch/sparc/vdso/vdso32/vclock_gettime.o: failed
The cause of the breakage is that -pg flag not being dropped.
The vdso32 files are located in the vdso32/ subdirectory, but I missed
to update the Makefile.
Fixes: 54b8ae66ae1a ("kbuild: change *FLAGS_.o to take the path
relative to $(obj)")
Reported-by: Anatoly Pugachev
Signed-off-by: Masahiro Yamada
---
arch/sparc/vdso/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
index 324a23947585..399bc22b1cf8 100644
--- a/arch/sparc/vdso/Makefile
+++ b/arch/sparc/vdso/Makefile
@@ -67,12 +67,14 @@ $(vobjs): KBUILD_CFLAGS := $(filter-out
$(GCC_PLUGINS_CFLAGS) $(SPARC_REG_CFLAGS
#
CFLAGS_REMOVE_vdso-note.o = -pg
CFLAGS_REMOVE_vclock_gettime.o = -pg
+CFLAGS_REMOVE_vdso32/vdso-note.o = -pg
+CFLAGS_REMOVE_vdso32/vclock_gettime.o = -pg
$(obj)/%.so: OBJCOPYFLAGS := -S
$(obj)/%.so: $(obj)/%.so.dbg FORCE
$(call if_changed,objcopy)
-CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
+CPPFLAGS_vdso32/vdso32.lds = $(CPPFLAGS_vdso.lds)
VDSO_LDFLAGS_vdso32.lds = -m elf32_sparc -soname linux-gate.so.1
#This makes sure the $(obj) subdirectory exists even though vdso32/
--
2.17.1
Re: latest git kernel (v5.3-11506-gf7c3bf8fa7e5) does not compile
Hi Anatoly,
On Sun, Sep 22, 2019 at 5:33 PM Anatoly Pugachev wrote:
>
> On Sun, Sep 22, 2019 at 11:13 AM Anatoly Pugachev wrote:
> >
> > Hello!
> >
> > Latest git kernel does not compile for me:
> >
> > ~/linux-2.6$ git desc
> > v5.3-11506-gf7c3bf8fa7e5
> >
> > ~/linux-2.6$ make
> > CALLscripts/checksyscalls.sh
> > :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> > CALLscripts/atomic/check-atomics.sh
> > CHK include/generated/compile.h
> > CC arch/sparc/vdso/vdso32/vclock_gettime.o
> > unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o
> > arch/sparc/vdso/vdso32/vclock_gettime.o: failed
> > make[2]: *** [scripts/Makefile.build:266:
> > arch/sparc/vdso/vdso32/vclock_gettime.o] Error 1
> > make[2]: *** Deleting file 'arch/sparc/vdso/vdso32/vclock_gettime.o'
> > make[1]: *** [scripts/Makefile.build:509: arch/sparc/vdso] Error 2
> > make: *** [Makefile:1667: arch/sparc] Error
> >
> > but I was able to compile successfully v5.3-10169-g574cc4539762
Thanks for the report, and apology for the breakage.
Please check this patch.
https://lore.kernel.org/patchwork/patch/1130469/
I hope it will fix the build error.
Thanks.
> >
> > Not sure my bisect log is right, but here it is:
> >
> > $ git bisect good
> > 54b8ae66ae1a3454a7645d159a482c31cd89ab33 is the first bad commit
> > commit 54b8ae66ae1a3454a7645d159a482c31cd89ab33
> > Author: Masahiro Yamada
> > Date: Fri Aug 30 13:34:01 2019 +0900
> >
> > kbuild: change *FLAGS_.o to take the path relative to $(obj)
> >
> > Kbuild provides per-file compiler flag addition/removal:
> >
> > CFLAGS_.o
> > CFLAGS_REMOVE_.o
> > AFLAGS_.o
> > AFLAGS_REMOVE_.o
> > CPPFLAGS_.lds
> > HOSTCFLAGS_.o
> > HOSTCXXFLAGS_.o
> >
> > The is the filename of the target with its directory and
> > suffix stripped.
> >
> > This syntax comes into a trouble when two files with the same basename
> > appear in one Makefile, for example:
> >
> > obj-y += foo.o
> > obj-y += dir/foo.o
> > CFLAGS_foo.o :=
> >
> > Here, the applies to both foo.o and dir/foo.o
> >
> > The real world problem is:
> >
> > scripts/kconfig/util.c
> > scripts/kconfig/lxdialog/util.c
> >
> > Both files are compiled into scripts/kconfig/mconf, but only the
> > latter should be given with the ncurses flags.
> >
> > It is more sensible to use the relative path to the Makefile, like this:
> >
> > obj-y += foo.o
> > CFLAGS_foo.o :=
> > obj-y += dir/foo.o
> > CFLAGS_dir/foo.o :=
> >
> > At first, I attempted to replace $(basetarget) with $*. The $* variable
> > is replaced with the stem ('%') part in a pattern rule. This works with
> > most of cases, but does not for explicit rules.
> >
> > For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
> > explicit rules, so $* will be empty, resulting in ignoring the per-file
> > AFLAGS.
> >
> > I introduced a new variable, target-stem, which can be used also from
> > explicit rules.
> >
> > Signed-off-by: Masahiro Yamada
> > Acked-by: Marc Zyngier
> >
> > arch/arm/kvm/Makefile | 5 +++--
> > arch/x86/entry/vdso/Makefile | 3 ++-
> > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 +++---
> > drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 2 +-
> > drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 +++--
> > drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 +++
> > drivers/gpu/drm/i915/Makefile | 2 +-
> > scripts/Makefile.host | 22 +++---
> > scripts/Makefile.lib | 13 -
> > scripts/kconfig/Makefile | 8
> > 10 files changed, 43 insertions(+), 42 deletions(-)
> > mator@ttip:~/linux-2.6$
> >
> >
> > If someone wants to check how kernel compiles on sparc64, could use
> > gcc compile farm machine (gcc202) to try on.
>
> and i cannot test compile 54b8ae66ae1a3454a7645d159a482c31cd89ab33 as well :
>
> ~/linux-2.6$ git checkout 54b8ae66ae1a3454a7645d159a482c31cd89ab33
> HEAD is now at 54b8ae66ae1a kbuild: change *FLAGS_.o to
> take the path relative to $(obj)
>
> ~/linux-2.6$ make -j clean; make -j olddefconfig && nice make -j24
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> HOSTCC scripts/kconfig/confdata.o
> HOSTCC scripts/kconfig/expr.o
> LEX scripts/kconfig/lexer.lex.c
> YACCscripts/kconfig/parser.tab.[ch]
> HOSTCC scripts/kconfig/preprocess.o
> HOSTCC scripts/kconfig/symbol.o
> HOSTCC scripts/kconfig/lexer.lex.o
> HOSTCC scripts/kconfig/parser.tab.o
> HOSTLD scripts/kconfig/conf
> scripts/kconfig/conf --olddefconfig Kconfig
> #
> # No change to .config
> #
> scripts/kconfig/conf --syncconfig Kconfig
> { command -v gcc; } >/dev/null 2>&1 && echo "n" || echo "y": Cannot
> allocate m
[PATCH] atm: he: clean up an indentation issue
From: Colin Ian King
There is a statement that is indented one level too many, remove
the extraneous tab.
Signed-off-by: Colin Ian King
---
drivers/atm/he.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 70b00ae4ec38..8af793f5e811 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1690,7 +1690,7 @@ he_service_rbrq(struct he_dev *he_dev, int group)
if (RBRQ_HBUF_ERR(he_dev->rbrq_head)) {
hprintk("HBUF_ERR! (cid 0x%x)\n", cid);
- atomic_inc(&vcc->stats->rx_drop);
+ atomic_inc(&vcc->stats->rx_drop);
goto return_host_buffers;
}
--
2.20.1
[PATCH] memstick: jmb38x_ms: clean up indentation issue
From: Colin Ian King
There is a hunk of code that is indented one level too deep, fix
this by removing the extraneous tabs.
Signed-off-by: Colin Ian King
---
drivers/memstick/host/jmb38x_ms.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/memstick/host/jmb38x_ms.c
b/drivers/memstick/host/jmb38x_ms.c
index 32747425297d..3394164a7968 100644
--- a/drivers/memstick/host/jmb38x_ms.c
+++ b/drivers/memstick/host/jmb38x_ms.c
@@ -433,13 +433,13 @@ static int jmb38x_ms_issue_cmd(struct memstick_host *msh)
writel(((1 << 16) & BLOCK_COUNT_MASK)
| (data_len & BLOCK_SIZE_MASK),
host->addr + BLOCK);
- t_val = readl(host->addr + INT_STATUS_ENABLE);
- t_val |= host->req->data_dir == READ
-? INT_STATUS_FIFO_RRDY
-: INT_STATUS_FIFO_WRDY;
+ t_val = readl(host->addr + INT_STATUS_ENABLE);
+ t_val |= host->req->data_dir == READ
+? INT_STATUS_FIFO_RRDY
+: INT_STATUS_FIFO_WRDY;
- writel(t_val, host->addr + INT_STATUS_ENABLE);
- writel(t_val, host->addr + INT_SIGNAL_ENABLE);
+ writel(t_val, host->addr + INT_STATUS_ENABLE);
+ writel(t_val, host->addr + INT_SIGNAL_ENABLE);
} else {
cmd &= ~(TPC_DATA_SEL | 0xf);
host->cmd_flags |= REG_DATA;
--
2.20.1
Re: latest git kernel (v5.3-11506-gf7c3bf8fa7e5) does not compile
On Sun, Sep 22, 2019 at 5:33 PM Anatoly Pugachev wrote:
>
> On Sun, Sep 22, 2019 at 11:13 AM Anatoly Pugachev wrote:
> >
> > Hello!
> >
> > Latest git kernel does not compile for me:
> >
> > ~/linux-2.6$ git desc
> > v5.3-11506-gf7c3bf8fa7e5
> >
> > ~/linux-2.6$ make
> > CALLscripts/checksyscalls.sh
> > :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> > CALLscripts/atomic/check-atomics.sh
> > CHK include/generated/compile.h
> > CC arch/sparc/vdso/vdso32/vclock_gettime.o
> > unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o
> > arch/sparc/vdso/vdso32/vclock_gettime.o: failed
> > make[2]: *** [scripts/Makefile.build:266:
> > arch/sparc/vdso/vdso32/vclock_gettime.o] Error 1
> > make[2]: *** Deleting file 'arch/sparc/vdso/vdso32/vclock_gettime.o'
> > make[1]: *** [scripts/Makefile.build:509: arch/sparc/vdso] Error 2
> > make: *** [Makefile:1667: arch/sparc] Error
> >
> > but I was able to compile successfully v5.3-10169-g574cc4539762
> >
> > Not sure my bisect log is right, but here it is:
> >
> > $ git bisect good
> > 54b8ae66ae1a3454a7645d159a482c31cd89ab33 is the first bad commit
> > commit 54b8ae66ae1a3454a7645d159a482c31cd89ab33
> > Author: Masahiro Yamada
> > Date: Fri Aug 30 13:34:01 2019 +0900
> >
> > kbuild: change *FLAGS_.o to take the path relative to $(obj)
> >
> > Kbuild provides per-file compiler flag addition/removal:
> >
> > CFLAGS_.o
> > CFLAGS_REMOVE_.o
> > AFLAGS_.o
> > AFLAGS_REMOVE_.o
> > CPPFLAGS_.lds
> > HOSTCFLAGS_.o
> > HOSTCXXFLAGS_.o
> >
> > The is the filename of the target with its directory and
> > suffix stripped.
> >
> > This syntax comes into a trouble when two files with the same basename
> > appear in one Makefile, for example:
> >
> > obj-y += foo.o
> > obj-y += dir/foo.o
> > CFLAGS_foo.o :=
> >
> > Here, the applies to both foo.o and dir/foo.o
> >
> > The real world problem is:
> >
> > scripts/kconfig/util.c
> > scripts/kconfig/lxdialog/util.c
> >
> > Both files are compiled into scripts/kconfig/mconf, but only the
> > latter should be given with the ncurses flags.
> >
> > It is more sensible to use the relative path to the Makefile, like this:
> >
> > obj-y += foo.o
> > CFLAGS_foo.o :=
> > obj-y += dir/foo.o
> > CFLAGS_dir/foo.o :=
> >
> > At first, I attempted to replace $(basetarget) with $*. The $* variable
> > is replaced with the stem ('%') part in a pattern rule. This works with
> > most of cases, but does not for explicit rules.
> >
> > For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
> > explicit rules, so $* will be empty, resulting in ignoring the per-file
> > AFLAGS.
> >
> > I introduced a new variable, target-stem, which can be used also from
> > explicit rules.
> >
> > Signed-off-by: Masahiro Yamada
> > Acked-by: Marc Zyngier
> >
> > arch/arm/kvm/Makefile | 5 +++--
> > arch/x86/entry/vdso/Makefile | 3 ++-
> > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 +++---
> > drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 2 +-
> > drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 +++--
> > drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 +++
> > drivers/gpu/drm/i915/Makefile | 2 +-
> > scripts/Makefile.host | 22 +++---
> > scripts/Makefile.lib | 13 -
> > scripts/kconfig/Makefile | 8
> > 10 files changed, 43 insertions(+), 42 deletions(-)
> > mator@ttip:~/linux-2.6$
> >
> >
> > If someone wants to check how kernel compiles on sparc64, could use
> > gcc compile farm machine (gcc202) to try on.
>
> and i cannot test compile 54b8ae66ae1a3454a7645d159a482c31cd89ab33 as well :
>
> ~/linux-2.6$ git checkout 54b8ae66ae1a3454a7645d159a482c31cd89ab33
> HEAD is now at 54b8ae66ae1a kbuild: change *FLAGS_.o to
> take the path relative to $(obj)
>
> ~/linux-2.6$ make -j clean; make -j olddefconfig && nice make -j24
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> HOSTCC scripts/kconfig/confdata.o
> HOSTCC scripts/kconfig/expr.o
> LEX scripts/kconfig/lexer.lex.c
> YACCscripts/kconfig/parser.tab.[ch]
> HOSTCC scripts/kconfig/preprocess.o
> HOSTCC scripts/kconfig/symbol.o
> HOSTCC scripts/kconfig/lexer.lex.o
> HOSTCC scripts/kconfig/parser.tab.o
> HOSTLD scripts/kconfig/conf
> scripts/kconfig/conf --olddefconfig Kconfig
> #
> # No change to .config
> #
> scripts/kconfig/conf --syncconfig Kconfig
> { command -v gcc; } >/dev/null 2>&1 && echo "n" || echo "y": Cannot
> allocate memory
> make[2]: *** [scripts/kconfig/Makefile:73: syncconfig] Error 1
> make[1]: *** [Makefile:584: syncconfig] Error 2
> make: *** [Makefile:695: include/config/auto.conf.cmd] Error 2
> ~/linux
Re: [PATCH] netfilter: use __u8 instead of uint8_t in uapi header
Hi Pablo,
On Sun, Sep 22, 2019 at 4:13 PM Pablo Neira Ayuso wrote:
>
> On Sun, Sep 22, 2019 at 09:11:11AM +0200, Pablo Neira Ayuso wrote:
> > On Sat, Sep 21, 2019 at 10:46:48PM +0900, Masahiro Yamada wrote:
> > > When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
> > > make sure they can be included from user-space.
> > >
> > > Currently, linux/netfilter_bridge/ebtables.h is excluded from the test
> > > coverage. To make it join the compile-test, we need to fix the build
> > > errors attached below.
> > >
> > > For a case like this, we decided to use __u{8,16,32,64} variable types
> > > in this discussion:
> > >
> > > https://lkml.org/lkml/2019/6/5/18
> > >
> > > Build log:
> > >
> > > CC usr/include/linux/netfilter_bridge/ebtables.h.s
> > > In file included from :32:0:
> > > ./usr/include/linux/netfilter_bridge/ebtables.h:126:4: error: unknown
> > > type name ‘uint8_t’
> > > uint8_t revision;
> > > ^~~
> > > ./usr/include/linux/netfilter_bridge/ebtables.h:139:4: error: unknown
> > > type name ‘uint8_t’
> > > uint8_t revision;
> > > ^~~
> > > ./usr/include/linux/netfilter_bridge/ebtables.h:152:4: error: unknown
> > > type name ‘uint8_t’
> > > uint8_t revision;
> > > ^~~
> >
> > Applied.
>
> Patch does not apply cleanly to nf.git, I have to keep it back, sorry
Perhaps, reducing the context (git am -C) might help.
Shall I rebase and resend it?
Thanks.
> $ git am /tmp/yamada.masahiro.txt -s
> Applying: netfilter: use __u8 instead of uint8_t in uapi header
> error: patch failed: usr/include/Makefile:37
> error: usr/include/Makefile: patch does not apply
> Patch failed at 0001 netfilter: use __u8 instead of uint8_t in uapi header
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
--
Best Regards
Masahiro Yamada
[PATCH] HID: core: clean up indentation issue
From: Colin Ian King
There is an if statement that is indented by one extra space,
fix this by removing the extraneous space.
Signed-off-by: Colin Ian King
---
drivers/hid/hid-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 3eaee2c37931..9469c382a182 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2329,10 +2329,10 @@ int hid_add_device(struct hid_device *hdev)
/*
* Check for the mandatory transport channel.
*/
-if (!hdev->ll_driver->raw_request) {
+ if (!hdev->ll_driver->raw_request) {
hid_err(hdev, "transport driver missing .raw_request()\n");
return -EINVAL;
-}
+ }
/*
* Read the device report descriptor once and use as template
--
2.20.1
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins > > wrote: > > > > > > Sorry about that. I am surprised that none of the other reviewers > > > brought this up. > > > > I think I'm "special". > > > > There was some other similar change a few years ago, which I > > absolutely hated because of how it broke autocomplete for me. Very few > > other people seemed to react to it. > > FWIW, I am obsessively sensitive to autocomplete and overall source code > file hieararchy and nomenclature details as well, so it's not just you. > > Beyond the muscle memory aspect, nonsensical naming and inanely flat file > hierarchies annoy kernel developers and makes it harder for newbies to > understand the kernel source as well. > > The less clutter, the more organization, the better - and there's very > few valid technical reasons to add any new files or directories to the > top level directory - we should probably *remove* quite a few. > > For example 'firmware/' was recently moved to drivers/firmware/, and in a > similar fashion about a third of the remaining 22 directories should > probably be moved too: > > drwxr-xr-xarch > drwxr-xr-xblock > drwxr-xr-xcerts # move to build/certs/ dir > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xipc # move to kernel/ipc/ > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsamples # move to Documentation/samples/ > drwxr-xr-xscripts # move to build/scripts/ > drwxr-xr-xsecurity > drwxr-xr-xsound # move to drivers/sound/ > drwxr-xr-xtools > drwxr-xr-xusr # move to build/usr/ > drwxr-xr-xvirt# move to the already existing drivers/virt/ > > -rw-r--r--COPYING > -rw-r--r--CREDITS > -rw-r--r--Kbuild > -rw-r--r--Kconfig > -rw-r--r--MAINTAINERS > -rw-r--r--Makefile > -rw-r--r--README > > There's a few borderline ones: > > - 'block' could in principle move to drivers/block/core/ but it's fine >at the top level too I think. > > - 'init' could in principle be moved to kernel/init/ - but it's not >wrong at the top level either. > > The remaining top level hierarchy would look pretty sweet and short: > > drwxr-xr-xarch > drwxr-xr-xblock > drwxr-xr-xbuild # new > drwxr-xr-xDocumentation > drwxr-xr-xdrivers > drwxr-xr-xfs > drwxr-xr-xinclude > drwxr-xr-xinit > drwxr-xr-xkernel > drwxr-xr-xlib > drwxr-xr-xLICENSES > drwxr-xr-xmm > drwxr-xr-xnet > drwxr-xr-xsecurity > drwxr-xr-xtools > > -rw-r--r--COPYING > -rw-r--r--CREDITS > -rw-r--r--Kbuild > -rw-r--r--Kconfig > -rw-r--r--MAINTAINERS > -rw-r--r--Makefile > -rw-r--r--README > > I'm volunteering to do this (in a scripted, repeatable, reviewable, > tweakable and "easy to execute in a quiet moment" fashion), although > I also expect you to balk at the churn. :-) I for one would love the above changes. And I'm the one that has to deal with all of the backporting issues that arise with stable backports :) thanks, greg k-h
[PATCH] mmc: dw_mmc: fix indentation issue
From: Colin Ian King There are a couple of statements that are indented by an extra space, clean this up by remove the extraneous spaces. Signed-off-by: Colin Ian King --- drivers/mmc/host/dw_mmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 79c55c7b4afd..bf0048ebbda3 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -3441,8 +3441,8 @@ int dw_mci_runtime_resume(struct device *dev) * Restore the initial value at FIFOTH register * And Invalidate the prev_blksz with zero */ -mci_writel(host, FIFOTH, host->fifoth_val); -host->prev_blksz = 0; + mci_writel(host, FIFOTH, host->fifoth_val); + host->prev_blksz = 0; /* Put in max timeout */ mci_writel(host, TMOUT, 0x); -- 2.20.1
Re: "Pick the right alignment default when creating dax devices" failed to build on powerpc
On 21 September 2019 4:31:16 am AEST, Dan Williams wrote: >On Fri, Sep 20, 2019 at 11:18 AM Qian Cai wrote: >> >> On Fri, 2019-09-20 at 19:55 +0530, Aneesh Kumar K.V wrote: >> > Qian Cai writes: >> > >> > > The linux-next commit "libnvdimm/dax: Pick the right alignment >default when >> > > creating dax devices" causes powerpc failed to build with this >config. Reverted >> > > it fixed the issue. >> > > >> > > ERROR: "hash__has_transparent_hugepage" >[drivers/nvdimm/libnvdimm.ko] undefined! >> > > ERROR: "radix__has_transparent_hugepage" >[drivers/nvdimm/libnvdimm.ko] >> > > undefined! >> > > make[1]: *** [scripts/Makefile.modpost:93: __modpost] Error 1 >> > > make: *** [Makefile:1305: modules] Error 2 >> > > >> > > [1] https://patchwork.kernel.org/patch/11133445/ >> > > [2] >https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config >> > >> > Sorry for breaking the build. How about? >> >> It works fine. > >Thanks, but let's delay "libnvdimm/dax: Pick the right alignment >default when creating dax devices" until after -rc1 to allow Michael >time to ack/nak this new export. Thanks Dan. It looks fine to me: Acked-by: Michael Ellerman cheers -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: latest git kernel (v5.3-11506-gf7c3bf8fa7e5) does not compile
On Sun, Sep 22, 2019 at 2:38 PM Masahiro Yamada wrote: > > Hi Anatoly, > > On Sun, Sep 22, 2019 at 5:33 PM Anatoly Pugachev wrote: > > > > On Sun, Sep 22, 2019 at 11:13 AM Anatoly Pugachev > > wrote: > > > > > > Hello! > > > > > > Latest git kernel does not compile for me: > > > > > > ~/linux-2.6$ git desc > > > v5.3-11506-gf7c3bf8fa7e5 > > > > > > ~/linux-2.6$ make > > > CALLscripts/checksyscalls.sh > > > :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp] > > > CALLscripts/atomic/check-atomics.sh > > > CHK include/generated/compile.h > > > CC arch/sparc/vdso/vdso32/vclock_gettime.o > > > unrecognized e_machine 18 arch/sparc/vdso/vdso32/vclock_gettime.o > > > arch/sparc/vdso/vdso32/vclock_gettime.o: failed > > > make[2]: *** [scripts/Makefile.build:266: > > > arch/sparc/vdso/vdso32/vclock_gettime.o] Error 1 > > > make[2]: *** Deleting file 'arch/sparc/vdso/vdso32/vclock_gettime.o' > > > make[1]: *** [scripts/Makefile.build:509: arch/sparc/vdso] Error 2 > > > make: *** [Makefile:1667: arch/sparc] Error > > > > > > but I was able to compile successfully v5.3-10169-g574cc4539762 > > > Thanks for the report, and apology for the breakage. > > Please check this patch. > https://lore.kernel.org/patchwork/patch/1130469/ > > I hope it will fix the build error. It does. Thanks Masahiro!
Re: [PATCH] netfilter: use __u8 instead of uint8_t in uapi header
On Sun, Sep 22, 2019 at 08:49:11PM +0900, Masahiro Yamada wrote:
> Hi Pablo,
>
> On Sun, Sep 22, 2019 at 4:13 PM Pablo Neira Ayuso wrote:
> >
> > On Sun, Sep 22, 2019 at 09:11:11AM +0200, Pablo Neira Ayuso wrote:
> > > On Sat, Sep 21, 2019 at 10:46:48PM +0900, Masahiro Yamada wrote:
> > > > When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
> > > > make sure they can be included from user-space.
> > > >
> > > > Currently, linux/netfilter_bridge/ebtables.h is excluded from the test
> > > > coverage. To make it join the compile-test, we need to fix the build
> > > > errors attached below.
> > > >
> > > > For a case like this, we decided to use __u{8,16,32,64} variable types
> > > > in this discussion:
> > > >
> > > > https://lkml.org/lkml/2019/6/5/18
> > > >
> > > > Build log:
> > > >
> > > > CC usr/include/linux/netfilter_bridge/ebtables.h.s
> > > > In file included from :32:0:
> > > > ./usr/include/linux/netfilter_bridge/ebtables.h:126:4: error: unknown
> > > > type name ‘uint8_t’
> > > > uint8_t revision;
> > > > ^~~
> > > > ./usr/include/linux/netfilter_bridge/ebtables.h:139:4: error: unknown
> > > > type name ‘uint8_t’
> > > > uint8_t revision;
> > > > ^~~
> > > > ./usr/include/linux/netfilter_bridge/ebtables.h:152:4: error: unknown
> > > > type name ‘uint8_t’
> > > > uint8_t revision;
> > > > ^~~
> > >
> > > Applied.
> >
> > Patch does not apply cleanly to nf.git, I have to keep it back, sorry
>
> Perhaps, reducing the context (git am -C) might help.
Not working for me.
> Shall I rebase and resend it?
Please do. Thanks.
Re: [GIT PULL] Kselftest update for Linux 5.4-rc1
> Beyond the muscle memory aspect, nonsensical naming and inanely flat file > hierarchies annoy kernel developers Flat(ish) file hierarchies are good -- less typing. If you're copy-pasting then it doesn't matter much (it still matters a little because long filename occupy more space on the screen and in logs). > makes it harder for newbies to understand the kernel source as well. That's fine too. > drwxr-xr-xcrypto # move to kernel/crypto/ or security/crypto/ No, crypto/ is fine. If everything arch independent should live at kernel/ then why should kernel/ exist at all? It should be trimmed and everything moved to the top level directory (OK, I'm not really suggesting that). > drwxr-xr-xipc # move to kernel/ipc/ No, same reason. It was there since time immemorial. > drwxr-xr-xsamples # move to Documentation/samples/ Just delete it. Best API usage samples are in modern parts of main tree, actively maintained/updated. > drwxr-xr-xscripts # move to build/scripts/ eh > drwxr-xr-xsound # move to drivers/sound/ NO! it has hw independent part and pretty big one. > drwxr-xr-xtools If tools/ people could somewhow stop duplicating large parts of include/linux and arch/x86/include/asm it will be very much appreciated. > - 'block' could in principle move to drivers/block/core/ but it's fine >at the top level too I think. It is fine indeed. Short name, top level dir, arch and hw independent code -- it is perfect. > I'm volunteering to do this (in a scripted, repeatable, reviewable, > tweakable and "easy to execute in a quiet moment" fashion), although > I also expect you to balk at the churn. :-) Can I pay you $100 to not do this ever? In Russia we say "what has grown has grown" and it is not like Linux is perfect example of intelligent design.
Re: [PATCH v2 1/5] irqchip/irq-bcm7038-l1: Add PM support
On Fri, 13 Sep 2019 12:15:38 -0700
Florian Fainelli wrote:
> From: Justin Chen
>
> The current l1 controller does not mask any interrupts when dropping
> into suspend. This mean we can receive unexpected wake up sources.
> Modified MIPS l1 controller to mask the all non-wake interrupts before
> dropping into suspend.
>
> Signed-off-by: Justin Chen
> Signed-off-by: Florian Fainelli
> ---
> drivers/irqchip/irq-bcm7038-l1.c | 98
> 1 file changed, 98 insertions(+)
>
> diff --git a/drivers/irqchip/irq-bcm7038-l1.c
> b/drivers/irqchip/irq-bcm7038-l1.c
> index fc75c61233aa..f5e4ff5251ab 100644
> --- a/drivers/irqchip/irq-bcm7038-l1.c
> +++ b/drivers/irqchip/irq-bcm7038-l1.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> #define IRQS_PER_WORD32
> #define REG_BYTES_PER_IRQ_WORD (sizeof(u32) * 4)
> @@ -39,6 +40,10 @@ struct bcm7038_l1_chip {
> unsigned intn_words;
> struct irq_domain *domain;
> struct bcm7038_l1_cpu *cpus[NR_CPUS];
> +#ifdef CONFIG_PM_SLEEP
> + struct list_headlist;
> + u32 wake_mask[MAX_WORDS];
> +#endif
> u8 affinity[MAX_WORDS * IRQS_PER_WORD];
> };
>
> @@ -47,6 +52,17 @@ struct bcm7038_l1_cpu {
> u32 mask_cache[0];
> };
>
> +/*
> + * We keep a list of bcm7038_l1_chip used for suspend/resume. This hack is
> + * used because the struct chip_type suspend/resume hooks are not called
> + * unless chip_type is hooked onto a generic_chip. Since this driver does
> + * not use generic_chip, we need to manually hook our resume/suspend to
> + * syscore_ops.
> + */
> +#ifdef CONFIG_PM_SLEEP
> +static LIST_HEAD(bcm7038_l1_intcs_list);
> +#endif
nit: this could be moved down to be close to the rest of the PM_SLEEP
ifdefery.
> +
> /*
> * STATUS/MASK_STATUS/MASK_SET/MASK_CLEAR are packed one right after another:
> *
> @@ -287,6 +303,77 @@ static int __init bcm7038_l1_init_one(struct device_node
> *dn,
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int bcm7038_l1_suspend(void)
> +{
> + struct bcm7038_l1_chip *intc;
> + unsigned long flags;
> + int boot_cpu, word;
> +
> + /* Wakeup interrupt should only come from the boot cpu */
> + boot_cpu = cpu_logical_map(smp_processor_id());
What guarantees that you're actually running on the boot CPU at this
point? If that's actually the case, why isn't cpu_logical_map(0) enough?
> +
> + list_for_each_entry(intc, &bcm7038_l1_intcs_list, list) {
> + raw_spin_lock_irqsave(&intc->lock, flags);
And if this can only run on a single CPU, what's the purpose of this
lock?
> + for (word = 0; word < intc->n_words; word++) {
> + l1_writel(~intc->wake_mask[word],
> + intc->cpus[boot_cpu]->map_base +
> + reg_mask_set(intc, word));
> + l1_writel(intc->wake_mask[word],
> + intc->cpus[boot_cpu]->map_base +
> + reg_mask_clr(intc, word));
nit: Please don't split the write address across two lines, it makes it
harder to read.
> + }
> + raw_spin_unlock_irqrestore(&intc->lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static void bcm7038_l1_resume(void)
> +{
> + struct bcm7038_l1_chip *intc;
> + unsigned long flags;
> + int boot_cpu, word;
> +
> + boot_cpu = cpu_logical_map(smp_processor_id());
> +
> + list_for_each_entry(intc, &bcm7038_l1_intcs_list, list) {
> + raw_spin_lock_irqsave(&intc->lock, flags);
> + for (word = 0; word < intc->n_words; word++) {
> + l1_writel(intc->cpus[boot_cpu]->mask_cache[word],
> + intc->cpus[boot_cpu]->map_base +
> + reg_mask_set(intc, word));
> + l1_writel(~intc->cpus[boot_cpu]->mask_cache[word],
> + intc->cpus[boot_cpu]->map_base +
> + reg_mask_clr(intc, word));
> + }
> + raw_spin_unlock_irqrestore(&intc->lock, flags);
> + }
> +}
> +
> +static struct syscore_ops bcm7038_l1_syscore_ops = {
> + .suspend= bcm7038_l1_suspend,
> + .resume = bcm7038_l1_resume,
> +};
> +
> +static int bcm7038_l1_set_wake(struct irq_data *d, unsigned int on)
> +{
> + struct bcm7038_l1_chip *intc = irq_data_get_irq_chip_data(d);
> + unsigned long flags;
> + u32 word = d->hwirq / IRQS_PER_WORD;
> + u32 mask = BIT(d->hwirq % IRQS_PER_WORD);
> +
> + raw_spin_lock_irqsave(&intc->lock, flags);
> + if (on)
> + intc->wake_mask[word] |= mask;
> + else
> + intc->wake_mask[word] &= ~mask;
> + raw_spin_unlock_irqrestore(&intc->lock, flags);
> +
> + return 0;
> +}
> +#endif
> +
> static struct irq_chip bcm7038
Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
> Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
> to fallback to tun_automq_select_queue() for tx queue selection.
>
> Compilation of this exact patch was tested.
>
> For functional testing 3 additional printk()s were added.
>
> Functional testing results (on 2 txq tap device):
>
> [Fri Sep 20 18:33:27 2019] == tun no prog ==
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> [Fri Sep 20 18:33:27 2019] == tun prog -1 ==
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '-1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> [Fri Sep 20 18:33:27 2019] == tun prog 0 ==
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '0'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> [Fri Sep 20 18:33:27 2019] == tun prog 1 ==
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '1'
> [Fri Sep 20 18:33:27 2019] == tun prog 2 ==
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '2'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
>
> Signed-off-by: Matthew Cover
Could you add a bit more motivation data here?
1. why is this a good idea
2. how do we know existing userspace does not rely on existing behaviour
3. why doesn't userspace need a way to figure out whether it runs on a kernel
with and
without this patch
thanks,
MST
> ---
> drivers/net/tun.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index aab0be4..173d159 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -583,35 +583,37 @@ static u16 tun_automq_select_queue(struct tun_struct
> *tun, struct sk_buff *skb)
> return txq;
> }
>
> -static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> +static int tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> {
> struct tun_prog *prog;
> u32 numqueues;
> - u16 ret = 0;
> + int ret = -1;
>
> numqueues = READ_ONCE(tun->numqueues);
> if (!numqueues)
> return 0;
>
> + rcu_read_lock();
> prog = rcu_dereference(tun->steering_prog);
> if (prog)
> ret = bpf_prog_run_clear_cb(prog->prog, skb);
> + rcu_read_unlock();
>
> - return ret % numqueues;
> + if (ret >= 0)
> + ret %= numqueues;
> +
> + return ret;
> }
>
> static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
> struct net_device *sb_dev)
> {
> struct tun_struct *tun = netdev_priv(dev);
> - u16 ret;
> + int ret;
>
> - rcu_read_lock();
> - if (rcu_dereference(tun->steering_prog))
> - ret = tun_ebpf_select_queue(tun, skb);
> - else
> + ret = tun_ebpf_select_queue(tun, skb);
> + if (ret < 0)
> ret = tun_automq_select_queue(tun, skb);
> - rcu_read_unlock();
>
> return ret;
> }
> --
> 1.8.3.1
Re: [PATCH v2 5/5] irqchip/irq-bcm7038-l1: Support brcm,int-fwd-mask
On Fri, 13 Sep 2019 12:15:42 -0700
Florian Fainelli wrote:
> On some specific chips like 7211 we need to leave some interrupts
> untouched/forwarded to the VPU which is another agent in the system
> making use of that interrupt controller hardware (goes to both ARM GIC
> and VPU L1 interrupt controller). Make that possible by using the
> existing brcm,int-fwd-mask property.
>
> Signed-off-by: Florian Fainelli
> ---
> drivers/irqchip/irq-bcm7038-l1.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-bcm7038-l1.c
> b/drivers/irqchip/irq-bcm7038-l1.c
> index 0673a44bbdc2..811a34201dd4 100644
> --- a/drivers/irqchip/irq-bcm7038-l1.c
> +++ b/drivers/irqchip/irq-bcm7038-l1.c
> @@ -44,6 +44,7 @@ struct bcm7038_l1_chip {
> struct list_headlist;
> u32 wake_mask[MAX_WORDS];
> #endif
> + u32 irq_fwd_mask[MAX_WORDS];
> u8 affinity[MAX_WORDS * IRQS_PER_WORD];
> };
>
> @@ -265,6 +266,7 @@ static int __init bcm7038_l1_init_one(struct device_node
> *dn,
> resource_size_t sz;
> struct bcm7038_l1_cpu *cpu;
> unsigned int i, n_words, parent_irq;
> + int ret;
>
> if (of_address_to_resource(dn, idx, &res))
> return -EINVAL;
> @@ -278,6 +280,14 @@ static int __init bcm7038_l1_init_one(struct device_node
> *dn,
> else if (intc->n_words != n_words)
> return -EINVAL;
>
> + ret = of_property_read_u32_array(dn , "brcm,int-fwd-mask",
What is the exact meaning of "fwd"? Forward? FirmWare Dementia?
> + intc->irq_fwd_mask, n_words);
> + if (ret != 0 && ret != -EINVAL) {
> + /* property exists but has the wrong number of words */
> + pr_err("invalid brcm,int-fwd-mask property\n");
> + return -EINVAL;
> + }
> +
> cpu = intc->cpus[idx] = kzalloc(sizeof(*cpu) + n_words * sizeof(u32),
> GFP_KERNEL);
> if (!cpu)
> @@ -288,8 +298,9 @@ static int __init bcm7038_l1_init_one(struct device_node
> *dn,
> return -ENOMEM;
>
> for (i = 0; i < n_words; i++) {
> - l1_writel(0x, cpu->map_base + reg_mask_set(intc, i));
> - cpu->mask_cache[i] = 0x;
> + l1_writel(0x & ~intc->irq_fwd_mask[i],
> + cpu->map_base + reg_mask_set(intc, i));
> + cpu->mask_cache[i] = 0x & ~intc->irq_fwd_mask[i];
I seem to remember that (0x & whatever) == whatever, as long as
'whatever' is a 32bit quantity. So what it this for?
M.
--
Without deviation from the norm, progress is not possible.
[PATCH] dmaengine: zx: Use devm_platform_ioremap_resource() in zx_dma_probe()
From: Markus Elfring
Date: Sun, 22 Sep 2019 14:32:12 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/zx_dma.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/dma/zx_dma.c b/drivers/dma/zx_dma.c
index 9f4436f7c914..6b457e683e70 100644
--- a/drivers/dma/zx_dma.c
+++ b/drivers/dma/zx_dma.c
@@ -754,18 +754,13 @@ static struct dma_chan *zx_of_dma_simple_xlate(struct
of_phandle_args *dma_spec,
static int zx_dma_probe(struct platform_device *op)
{
struct zx_dma_dev *d;
- struct resource *iores;
int i, ret = 0;
- iores = platform_get_resource(op, IORESOURCE_MEM, 0);
- if (!iores)
- return -EINVAL;
-
d = devm_kzalloc(&op->dev, sizeof(*d), GFP_KERNEL);
if (!d)
return -ENOMEM;
- d->base = devm_ioremap_resource(&op->dev, iores);
+ d->base = devm_platform_ioremap_resource(op, 0);
if (IS_ERR(d->base))
return PTR_ERR(d->base);
--
2.23.0
[PATCH] FUSE: fix beyond-end-of-page access in fuse_parse_cache()
With DEBUG_PAGEALLOC on, the following triggers.
BUG: unable to handle page fault for address: 88859367c000
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 3001067 P4D 3001067 PUD 406d3a8067 PMD 406d30c067 PTE 800a6c983060
Oops: [#1] SMP DEBUG_PAGEALLOC
CPU: 38 PID: 3110657 Comm: python2.7
RIP: 0010:fuse_readdir+0x88f/0xe7a [fuse]
Code: 49 8b 4d 08 49 39 4e 60 0f 84 44 04 00 00 48 8b 43 08 43 8d 1c 3c 4d 01
7e 68 49 89 dc 48 03 5c 24 38 49 89 46 60 8b 44 24 30 <8b> 4b 10 44 29 e0 48 89
ca 48 83 c1 1f 48 83 e1 f8 83 f8 17 49 89
RSP: 0018:c90035edbde0 EFLAGS: 00010286
RAX: 1000 RBX: 88859367bff0 RCX:
RDX: RSI: 88859367bfed RDI: 00920907
RBP: c90035edbe90 R08: 014b R09: 0004
R10: 88859367b000 R11: R12: 0ff0
R13: c90035edbee0 R14: 889fb8546180 R15: 0020
FS: 7f80b5f4a740() GS:889fffa0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 88859367c000 CR3: 001c170c2001 CR4: 003606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
iterate_dir+0x122/0x180
__x64_sys_getdents+0xa6/0x140
do_syscall_64+0x42/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
faddr2line says
fuse_readdir+0x88f/0x38fc9b:
fuse_parse_cache at
/builddir/build/BUILD/kernel-5.2.9-1992_g2c63931edbb0/fs/fuse/readdir.c:375
(inlined by) fuse_readdir_cached at
/builddir/build/BUILD/kernel-5.2.9-1992_g2c63931edbb0/fs/fuse/readdir.c:524
(inlined by) fuse_readdir at
/builddir/build/BUILD/kernel-5.2.9-1992_g2c63931edbb0/fs/fuse/readdir.c:562
It's in fuse_parse_cache(). %rbx (88859367bff0) is fuse_dirent
pointer - addr + offset. FUSE_DIRENT_SIZE() is trying to dereference
namelen off of it but that derefs into the next page which is disabled
by pagealloc debug causing a PF.
This is caused by dirent->namelen being accessed before ensuring that
there's enough bytes in the page for the dirent. Fix it by pushing
down reclen calculation.
Signed-off-by: Tejun Heo
Fixes: 5d7bc7e8680c ("fuse: allow using readdir cache")
Cc: sta...@vger.kernel.org # v4.20+
---
fs/fuse/readdir.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c
index 574d03f8a573..b2da3de6a78e 100644
--- a/fs/fuse/readdir.c
+++ b/fs/fuse/readdir.c
@@ -372,11 +372,13 @@ static enum fuse_parse_result fuse_parse_cache(struct
fuse_file *ff,
for (;;) {
struct fuse_dirent *dirent = addr + offset;
unsigned int nbytes = size - offset;
- size_t reclen = FUSE_DIRENT_SIZE(dirent);
+ size_t reclen;
if (nbytes < FUSE_NAME_OFFSET || !dirent->namelen)
break;
+ reclen = FUSE_DIRENT_SIZE(dirent); /* derefs ->namelen */
+
if (WARN_ON(dirent->namelen > FUSE_NAME_MAX))
return FOUND_ERR;
if (WARN_ON(reclen > nbytes))
[PATCH] kheaders: making headers archive reproducible
From: Dmitry Goldin
In commit 43d8ce9d65a5 ("Provide in-kernel headers to make
extending kernel easier") a new mechanism was introduced, for kernels
>=5.2, which embeds the kernel headers in the kernel image or a module
and exposed them in procfs for use by userland tools.
The archive containing the header files has nondeterminism through the
header files metadata. This patch normalizes the metadata and utilizes
KBUILD_BUILD_TIMESTAMP if provided and otherwise falls back to the
default behaviour.
In commit f7b101d33046 ("kheaders: Move from proc to sysfs") it was
modified to use sysfs and the script for generation of the archive was
renamed to what is being patched.
Signed-off-by: Dmitry Goldin
---
kernel/gen_kheaders.sh | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh
index 9ff449888d9c..2e154741e3b2 100755
--- a/kernel/gen_kheaders.sh
+++ b/kernel/gen_kheaders.sh
@@ -71,7 +71,10 @@ done | cpio --quiet -pd $cpio_dir >/dev/null 2>&1
find $cpio_dir -type f -print0 |
xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;};
s/\/\*((?!SPDX).)*?\*\///smg;'
-tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null
+# Create archive and try to normalized metadata for reproducibility
+tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \
+--owner=0 --group=0 --sort=name --numeric-owner \
+-Jcf $tarfile -C $cpio_dir/ . > /dev/null
echo "$src_files_md5" > kernel/kheaders.md5
echo "$obj_files_md5" >> kernel/kheaders.md5
--
2.19.2
Re: [PATCH] platform/x86: dell-laptop: fix phantom kbd backlight on Inspiron 10xx
On Wednesday 18 September 2019 17:29:15 Pacien TRAN-GIRARD wrote: > Quoting Pali Rohár (2019-09-12 09:33:58) > > On Thursday 12 September 2019 01:14:48 Pacien TRAN-GIRARD wrote: > > > This patch registers a quirk disabling keyboard backlight support > > > for the Dell Inspiron 1012 and 1018. > > > > > > Those models wrongly report supporting the KBD_LED_OFF_TOKEN and > > > KBD_LED_ON_TOKEN SMBIOS tokens, exposing keyboard brightness controls > > > through sysfs which freeze the system when used. > > > > > > The associated SMBIOS calls never return and cause the system to > > > hang, notably at boot when systemd-backlight tries to restore > > > previous brightness settings. > > > > Hi! This sounds like a firmware bug. Have you already reported it to Dell? > > Yes, the issue has been reported to Dell's technical support, which didn't > provide a satisfying answer. There were already some firmware problems with keyboard backlight and Mario posted this comment about Linux support: https://github.com/dell/libsmbios/issues/48#issuecomment-391328501 Can you try to use libsmbios tools and if they do not work too, report problem also there? > I'm not familiar with Dell's policy, but I doubt that they would issue a > BIOS update for discontinued models from 2010. We need to wait what Mario wrote about this particular problem. > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107651 > > > Signed-off-by: Pacien TRAN-GIRARD > > > > -- > > Pali Rohr > > pali.ro...@gmail.com > > -- > Pacien TRAN-GIRARD -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
[PATCH] ata: libahci_platform: Use common error handling code in ahci_platform_get_resources()
From: Markus Elfring
Date: Sun, 22 Sep 2019 15:42:46 +0200
Convert the call of the function “of_node_put” to another jump target
so that it can be better reused at three places in this function.
Signed-off-by: Markus Elfring
---
drivers/ata/libahci_platform.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index e742780950de..7b2e364f3bd5 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -497,8 +497,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct
platform_device *pdev,
if (of_property_read_u32(child, "reg", &port)) {
rc = -EINVAL;
- of_node_put(child);
- goto err_out;
+ goto err_put_node;
}
if (port >= hpriv->nports) {
@@ -515,18 +514,14 @@ struct ahci_host_priv *ahci_platform_get_resources(struct
platform_device *pdev,
if (port_dev) {
rc = ahci_platform_get_regulator(hpriv, port,
&port_dev->dev);
- if (rc == -EPROBE_DEFER) {
- of_node_put(child);
- goto err_out;
- }
+ if (rc == -EPROBE_DEFER)
+ goto err_put_node;
}
#endif
rc = ahci_platform_get_phy(hpriv, port, dev, child);
- if (rc) {
- of_node_put(child);
- goto err_out;
- }
+ if (rc)
+ goto err_put_node;
enabled_ports++;
}
@@ -558,6 +553,8 @@ struct ahci_host_priv *ahci_platform_get_resources(struct
platform_device *pdev,
devres_remove_group(dev, NULL);
return hpriv;
+err_put_node:
+ of_node_put(child);
err_out:
devres_release_group(dev, NULL);
return ERR_PTR(rc);
--
2.23.0
[tip: perf/urgent] tools headers uapi: Sync prctl.h with the kernel sources
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 7b678ccdf5f608c408e1368e525ed191ca456bcf
Gitweb:
https://git.kernel.org/tip/7b678ccdf5f608c408e1368e525ed191ca456bcf
Author:Arnaldo Carvalho de Melo
AuthorDate:Fri, 20 Sep 2019 14:40:30 -03:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Fri, 20 Sep 2019 14:59:05 -03:00
tools headers uapi: Sync prctl.h with the kernel sources
To get the changes in:
63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user
addresses ABI")
that introduces prctl options that then automagically gets catched by
the prctl cmd table generator, and thus supported in the 'perf trace'
prctl beautifier for the 'option' argument:
$ tools/perf/trace/beauty/prctl_option.sh > after
$ diff -u before after
--- before2019-09-20 14:38:41.386720870 -0300
+++ after 2019-09-20 14:40:02.583990802 -0300
@@ -49,6 +49,8 @@
[52] = "GET_SPECULATION_CTRL",
[53] = "SET_SPECULATION_CTRL",
[54] = "PAC_RESET_KEYS",
+ [55] = "SET_TAGGED_ADDR_CTRL",
+ [56] = "GET_TAGGED_ADDR_CTRL",
};
static const char *prctl_set_mm_options[] = {
[1] = "START_CODE",
$
For now just the translation of 55 and 56 to the respecting strings are
done, more work needed to allow for filters to be used using strings.
This, for instance, already works:
# perf record -e syscalls:sys_enter_close --filter="fd==4"
# perf script | head -5
gpm 1018 [006] 21327.171436: syscalls:sys_enter_close: fd:
0x0004
gpm 1018 [006] 21329.171583: syscalls:sys_enter_close: fd:
0x0004
bash 4882 [002] 21330.785496: syscalls:sys_enter_close: fd:
0x0004
bash 20672 [001] 21330.785719: syscalls:sys_enter_close: fd:
0x0004
find 20672 [001] 21330.789082: syscalls:sys_enter_close: fd:
0x0004
# perf record -e syscalls:sys_enter_close --filter="fd>=4"
^C[ perf record: Woken up 1 times to write data ]
# perf script | head -5
gpm 1018 [005] 21401.178501: syscalls:sys_enter_close: fd:
0x0004
gsd-housekeepin 2287 [006] 21402.225365: syscalls:sys_enter_close: fd:
0x000b
gsd-housekeepin 2287 [006] 21402.226234: syscalls:sys_enter_close: fd:
0x000b
gsd-housekeepin 2287 [006] 21402.227255: syscalls:sys_enter_close: fd:
0x000b
gsd-housekeepin 2287 [006] 21402.228088: syscalls:sys_enter_close: fd:
0x000b
#
Being able to pass something like:
# perf record -e syscalls:sys_enter_prctl --filter="option=*TAGGED_ADDR*"
Should be easy enough, first using tracepoint filters, then via the
augmented_raw_syscalls.c BPF method.
This addresses this perf build warning:
Warning: Kernel ABI header at 'tools/include/uapi/linux/prctl.h' differs from
latest version at 'include/uapi/linux/prctl.h'
diff -u tools/include/uapi/linux/prctl.h include/uapi/linux/prctl.h
Cc: Adrian Hunter
Cc: Brendan Gregg
Cc: Catalin Marinas
Cc: Jiri Olsa
Cc: Luis Cláudio Gonçalves
Cc: Namhyung Kim
Cc: Will Deacon
Link: https://lkml.kernel.org/n/tip-y8u8kvflooyo9x0if1g3j...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/include/uapi/linux/prctl.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/prctl.h b/tools/include/uapi/linux/prctl.h
index 094bb03..7da1b37 100644
--- a/tools/include/uapi/linux/prctl.h
+++ b/tools/include/uapi/linux/prctl.h
@@ -181,7 +181,7 @@ struct prctl_mm_map {
#define PR_GET_THP_DISABLE 42
/*
- * Tell the kernel to start/stop helping userspace manage bounds tables.
+ * No longer implemented, but left here to ensure the numbers stay reserved:
*/
#define PR_MPX_ENABLE_MANAGEMENT 43
#define PR_MPX_DISABLE_MANAGEMENT 44
@@ -229,4 +229,9 @@ struct prctl_mm_map {
# define PR_PAC_APDBKEY(1UL << 3)
# define PR_PAC_APGAKEY(1UL << 4)
+/* Tagged user address controls for arm64 */
+#define PR_SET_TAGGED_ADDR_CTRL55
+#define PR_GET_TAGGED_ADDR_CTRL56
+# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
+
#endif /* _LINUX_PRCTL_H */
[tip: perf/urgent] perf tests: Fix static build test
The following commit has been merged into the perf/urgent branch of tip: Commit-ID: b117b9b48b24cbb090dd3844b563b464d60a6278 Gitweb: https://git.kernel.org/tip/b117b9b48b24cbb090dd3844b563b464d60a6278 Author:Jiri Olsa AuthorDate:Thu, 05 Sep 2019 11:09:24 +02:00 Committer: Arnaldo Carvalho de Melo CommitterDate: Fri, 20 Sep 2019 14:37:28 -03:00 perf tests: Fix static build test Disable the potentional shared library features, which breaks static build if they are enabled and detected: jvmti and vdso libraries. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20190905090924.GA1949@krava Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/tests/make | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/tests/make b/tools/perf/tests/make index 6b3afed..c850d16 100644 --- a/tools/perf/tests/make +++ b/tools/perf/tests/make @@ -100,7 +100,7 @@ make_install_info := install-info make_install_pdf:= install-pdf make_install_prefix := install prefix=/tmp/krava make_install_prefix_slash := install prefix=/tmp/krava/ -make_static := LDFLAGS=-static +make_static := LDFLAGS=-static NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 NO_JVMTI=1 # all the NO_* variable combined make_minimal:= NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1
Re: [PATCH v2] dt-bindings: iio: accel: add binding documentation for ADIS16240
Hi,
Could anyone with some experience in devicetree give us a hint on what
to do here?
I have built a binding doc using the same spi-cpha property.
https://github.com/analogdevicesinc/linux/commit/bb2945e489dfdf2faa0255dd2cf09ae4ee77d826
On 09/13, Ardelean, Alexandru wrote:
> On Thu, 2019-09-12 at 18:39 -0300, Rodrigo Carvalho wrote:
> > This patch add device tree binding documentation for ADIS16240.
> >
> > Signed-off-by: Rodrigo Ribeiro Carvalho
> > ---
> > V2:
> > - Remove true constant for spi-cpha and spi-cpol
> > - Add description field for spi-cpha and spi-cpol
> > - Add maxItems field for spi-cpha and spi-cpol
> >
> > .../bindings/iio/accel/adi,adis16240.yaml | 61 +++
> > 1 file changed, 61 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > new file mode 100644
> > index ..4b1bd2419604
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > @@ -0,0 +1,61 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> > +
> > +maintainers:
> > + - Alexandru Ardelean
> > +
> > +description: |
> > + ADIS16240 Programmable Impact Sensor and Recorder driver that supports
> > + SPI interface.
> > +https://www.analog.com/en/products/adis16240.html
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - adi,adis16240
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + spi-cpha:
> > +description: |
> > + See Documentation/devicetree/bindings/spi/spi-controller.yaml
> > +maxItems: 1
>
> Description for standard properties is not required.
>
> For spi-cpha/cpol just "true" seems sufficient.
>
> So
>
> spi-cpha: true
>
> spi-cpol: true
>
I'm not Rob, but I think it is not necessary to explicitly say the
property is true. In this case, it should be enough if it is present. If
needed to know whether some property is "true" or not, one can use the
of_property_read_bool function. For the AD7292 driver on it was enough
to just add the property names. The spi-chpa did not need any further
care. Without the spi-cpha property, the AD7292 vendor ID came as 0x0C
(one bit shifted to the right).
Rodrigo is participating at FLUSP students group. It would be good if we
could test whether these properties are really needed. However, I don't
think we have the ADIS16240 part. Would anyone test it?
> > +
> > + spi-cpol: |
> > +description: |
> > + See Documentation/devicetree/bindings/spi/spi-controller.yaml
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
>
> If spi-cpha & spi-cpol are true, they should typically be also required.
> Though, I think Rob would answer things better here.
>
Some feedback about the need (or not) to link to the spi-controller doc
would also be appreciated.
> > +examples:
> > + - |
> > +#include
> > +#include
> > +spi0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +/* Example for a SPI device node */
> > +accelerometer@0 {
> > +compatible = "adi,adis16240";
> > +reg = <0>;
> > +spi-max-frequency = <250>;
> > +spi-cpol;
> > +spi-cpha;
> > +interrupt-parent = <&gpio0>;
> > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +};
> > +};
Thanks,
Marcelo
Re: [RFC 00/73] libperf: Add sampling interface
On Fri, Sep 13, 2019 at 03:22:42PM +0200, Jiri Olsa wrote:
> hi,
> sending changes for exporting basic sampling interface
> in libperf. It's now possible to use following code in
> applications via libperf:
>
> --- (example is without error checks for simplicity)
>
> struct perf_event_attr attr = {
> .type = PERF_TYPE_TRACEPOINT,
> .sample_period= 1,
> .wakeup_watermark = 1,
> .disabled = 1,
> };
> /* ... setup attr */
>
> cpus = perf_cpu_map__new(NULL);
>
> evlist = perf_evlist__new();
> evsel = perf_evsel__new(&attr);
> perf_evlist__add(evlist, evsel);
>
> perf_evlist__set_maps(evlist, cpus, NULL);
>
> err = perf_evlist__open(evlist);
> err = perf_evlist__mmap(evlist, 4);
>
> err = perf_evlist__enable(evlist);
>
> /* ... monitored area, plus all the other cpus */
>
> err = perf_evlist__disable(evlist);
>
> perf_evlist__for_each_mmap(evlist, map) {
> if (perf_mmap__read_init(map) < 0)
> continue;
>
> while ((event = perf_mmap__read_event(map)) != NULL) {
> perf_mmap__consume(map);
> }
>
> perf_mmap__read_done(map);
> }
>
> perf_evlist__delete(evlist);
> perf_cpu_map__put(cpus);
>
> --- (end)
>
> Nothing is carved in stone so far, the interface is exported
> as is available in perf now and we can change it as we want.
>
> New tests are added in test-evlist.c to do thread and cpu based
> sampling.
>
> All the functionality should not change, however there's considerable
> mmap code rewrite, so would be great if guys could run your usual
> workloads to see if all is fine.. so far so good in my tests ;-)
>
> It's also available in here:
> git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> perf/lib
hi,
I rebased the branch to latest Arnaldo's perf/core branch
jirka
[PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings
This patch fixes the regexp warnings shown below:
GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c
awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape
sequence `\:' is not a known regexp operator
awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350:
(FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape
sequence `\&' is not a known regexp operator
The ':' and '&' characters need not escaping when used in string constants
as part of regular expressions.
[Test-run]
awk -f arch/x86/tools/gen-insn-attr-x86.awk \
arch/x86/lib/x86-opcode-map.txt >../tmp/inat-tables.c
diff arch/x86/lib/inat-tables.c ~/tmp/inat-tables.c; echo $?
0
awk -f tools/arch/x86/tools/gen-insn-attr-x86.awk \
tools/arch/x86/lib/x86-opcode-map.txt >../tmp/inat-tables.c
diff tools/objtool/arch/x86/lib/inat-tables.c ~/tmp/inat-tables.c; echo $?
0
[Debugging output]
DBG:ext:(66&F2)
DBG:match(ext, ...):(66&F2)
DBG:match(..., lprefix3_expr):\((F2|!F3|66&F2)\)
Signed-off-by: Alexander Kapshuk
Reported-by: kbuild test robot
---
arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
tools/arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/tools/arch/x86/tools/gen-insn-attr-x86.awk
b/tools/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\&F2)\\)"
+ lprefix3_expr = "\\((F2|!F3|66&F2)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
--
2.23.0
Re: [PATCH] ata: libahci_platform: Add of_node_put() before loop exit
How do you think about to add the tag “Fixes” for this software correction? Regards, Markus
[GIT PULL] Modules updates for v5.4
Hi Linus,
The main bulk of this pull request introduces a new exported symbol
namespaces feature. The number of exported symbols is increasingly growing
with each release (we're at about 31k exports as of 5.3-rc7) and we
currently have no way of visualizing how these symbols are "clustered" or
making sense of this huge export surface. Namespacing exported symbols
allows kernel developers to more explicitly partition and categorize
exported symbols, as well as more easily limiting the availability of
namespaced symbols to other parts of the kernel. For starters, we have
introduced the USB_STORAGE namespace to demonstrate the API's usage. I have
briefly summarized the feature and its main motivations in the tag below.
Disclaimer: linux-next releases were originally planned to be paused from
Sept 5 to Sept 30, then from Sept 15, Mark Brown picked up the work and
resumed doing -next releases. Since the patchset landed in modules-next
during the week of -rc8, it has unfortunately not gotten linux-next time. I
would understand if you'd prefer to defer to the next release.
Also note that there is a conflict with the kbuild tree. Many thanks to
Matthias Maennich for quickly providing the conflict resolution (diff
below). Only include/linux/export.h and scripts/Makefile.modpost had hard
conflicts. In the inline diff below, I've provided the result of the
conflict resolution from merging modules-next into your master branch.
Please let me know if you run into any trouble.
Thanks,
Jessica
->8-
diff --cc .gitignore
index ce2c6348d372,9ee63aa2a3fb..70580bdd352c
--- a/.gitignore
+++ b/.gitignore
@@@ -32,8 -32,10 +32,9 @@@
*.lzo
*.mod
*.mod.c
+ *.ns_deps
*.o
*.o.*
-*.order
*.patch
*.s
*.so
diff --cc include/linux/export.h
index 7d8c112a8b61,ef5d015d754a..6ecb04014558
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@@ -18,6 -18,11 +18,8 @@@ extern struct module __this_module
#define THIS_MODULE ((struct module *)0)
#endif
-#ifdef CONFIG_MODULES
-
+ #define NS_SEPARATOR "."
+
-#if defined(__KERNEL__) && !defined(__GENKSYMS__)
#ifdef CONFIG_MODVERSIONS
/* Mark the CRC weak since genksyms apparently decides not to
* generate a checksums for some symbols */
@@@ -71,24 -98,26 +95,35 @@@ struct kernel_symbol
};
#endif
+#ifdef __GENKSYMS__
+
+#define ___EXPORT_SYMBOL(sym, sec) __GENKSYMS_EXPORT_SYMBOL(sym)
++#define ___EXPORT_SYMBOL_NS(sym, sec, ns) __GENKSYMS_EXPORT_SYMBOL(sym)
+
+#else
+
- /* For every exported symbol, place a struct in the __ksymtab section */
- #define ___EXPORT_SYMBOL(sym, sec)\
+ #define ___export_symbol_common(sym, sec) \
extern typeof(sym) sym; \
- __CRC_SYMBOL(sym, sec) \
+ __CRC_SYMBOL(sym, sec); \
static const char __kstrtab_##sym[] \
__attribute__((section("__ksymtab_strings"), used, aligned(1))) \
- = #sym; \
+ = #sym \
+
+ /* For every exported symbol, place a struct in the __ksymtab section */
+ #define ___EXPORT_SYMBOL_NS(sym, sec, ns) \
+ ___export_symbol_common(sym, sec); \
+ static const char __kstrtab_ns_##sym[] \
+ __attribute__((section("__ksymtab_strings"), used, aligned(1))) \
+ = #ns; \
+ __KSYMTAB_ENTRY_NS(sym, sec, ns)
+
+ #define ___EXPORT_SYMBOL(sym, sec) \
+ ___export_symbol_common(sym, sec); \
__KSYMTAB_ENTRY(sym, sec)
-#if defined(__DISABLE_EXPORTS)
+#endif
+
+#if !defined(CONFIG_MODULES) || defined(__DISABLE_EXPORTS)
/*
* Allow symbol exports to be disabled completely so that C code may
@@@ -121,18 -151,36 +157,37 @@@
#define __cond_export_sym_1(sym, sec) ___EXPORT_SYMBOL(sym, sec)
#define __cond_export_sym_0(sym, sec) /* nothing */
+ #define __EXPORT_SYMBOL_NS(sym, sec, ns)\
+ __ksym_marker(sym); \
+ __cond_export_ns_sym(sym, sec, ns, __is_defined(__KSYM_##sym))
+ #define __cond_export_ns_sym(sym, sec, ns, conf) \
+ ___cond_export_ns_sym(sym, sec, ns, conf)
+ #define ___cond_export_ns_sym(sym, sec, ns, enabled) \
+ __cond_export_ns_sym_##enabled(sym, sec, ns)
+ #define __cond_export_ns_sym_1(sym, sec, ns) ___EXPORT_SYMBOL_NS(sym, sec, ns)
+ #define __cond_export_ns_sym_0(sym, sec, ns) /* nothing */
+
#else
-#define __EXPORT_SYMBOL_NS ___EXPORT_SYMBOL_NS
+
- #define __EXPORT_SYMBOL(sym, sec) ___EXPORT_SYMBOL(sym, sec)
+ #define __EXPORT_SYMBOL ___EXPORT_SYMBOL
-#endif
++#define __EXPORT_SYMBOL_NS _
Re: threads-max observe limits
On 9/22/19 8:58 AM, Michal Hocko wrote:
> On Thu 19-09-19 14:33:24, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>>> On Tue 17-09-19 12:26:18, Eric W. Biederman wrote:
> [...]
Michal is it a very small effect your customers are seeing?
Is it another bug somewhere else?
>>>
>>> I am still trying to get more information. Reportedly they see a
>>> different auto tuned limit between two kernel versions which results in
>>> an applicaton complaining. As already mentioned this might be a side
>>> effect of something else and this is not yet fully analyzed. My main
>>> point for bringing up this discussion is ...
>>
>> Please this sounds like the kind of issue that will reveal something
>> deeper about what is going on.
>
> Yes, I have pushed for that information even before starting discussion
> here. I haven't heard from the customer yet unfortunatelly.
>
b) Not being able to bump threads_max to the physical limit of
the machine is very clearly a regression.
>>>
>>> ... exactly this part. The changelog of the respective patch doesn't
>>> really exaplain why it is needed except of "it sounds like a good idea
>>> to be consistent".
>>
>> I suggest doing a partial revert to just:
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 7a74ade4e7d6..de8264ea34a7 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -2943,7 +2943,7 @@ int sysctl_max_threads(struct ctl_table *table, int
>> write,
>> if (ret || !write)
>> return ret;
>>
>> -set_max_threads(threads);
>> +max_threads = threads;
>>
>> return 0;
>> }
>>
>> proc_dointvec_minmax limiting the values to MIN_THREADS and MAX_THREADS
>> is justifiable. Those are the minimum and maximum values the kernel can
>> function with.
>
> MAX_THREADS limit makes perfect sense because crossing it reflects a
> real constrain for correctness. MIN_THREADS, on the other hand, is only
> the low gate for auto tuning to not come with an unbootable system. I do
> not think we should jump into the admin call on the lower bound. There
> might be a good reason to restrict the number of threads to 1. So here
> is what I would like to go with.
Did this patch when applied to the customer's kernel solve any problem?
WebSphere MQ is a messaging application. If it hits the current limits
of threads-max, there is a bug in the software or in the way that it has
been set up at the customer. Instead of messing around with the kernel
the application should be fixed.
With this patch you allow administrators to set values that will crash
their system. And they will not even have a way to find out the limits
which he should adhere to. So expect a lot of systems to be downed this way.
Best regards
Heinrich
>
>>From 711000fdc243b6bc68a92f9ef0017ae495086d39 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Sun, 22 Sep 2019 08:45:28 +0200
> Subject: [PATCH] kernel/sysctl.c: do not override max_threads provided by
> userspace
>
> Partially revert 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
> because the patch is causing a regression to any workload which needs to
> override the auto-tuning of the limit provided by kernel.
>
> set_max_threads is implementing a boot time guesstimate to provide a
> sensible limit of the concurrently running threads so that runaways will
> not deplete all the memory. This is a good thing in general but there
> are workloads which might need to increase this limit for an application
> to run (reportedly WebSpher MQ is affected) and that is simply not
> possible after the mentioned change. It is also very dubious to override
> an admin decision by an estimation that doesn't have any direct relation
> to correctness of the kernel operation.
>
> Fix this by dropping set_max_threads from sysctl_max_threads so any
> value is accepted as long as it fits into MAX_THREADS which is important
> to check because allowing more threads could break internal robust futex
> restriction. While at it, do not use MIN_THREADS as the lower boundary
> because it is also only a heuristic for automatic estimation and admin
> might have a good reason to stop new threads to be created even when
> below this limit.
>
> Fixes: 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
> Cc: stable
> Signed-off-by: Michal Hocko
> ---
> kernel/fork.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 2852d0e76ea3..ef865be37e98 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2929,7 +2929,7 @@ int sysctl_max_threads(struct ctl_table *table, int
> write,
> struct ctl_table t;
> int ret;
> int threads = max_threads;
> - int min = MIN_THREADS;
> + int min = 1;
> int max = MAX_THREADS;
>
> t = *table;
> @@ -2941,7 +2941,7 @@ int sysctl_max_threads(struct ctl_table *table, int
> write,
> if (ret || !write)
> return ret;
>
> - set_max_threads(threads);
> + max_threads =
[GIT PULL] hsi changes for hsi-5.4
Hi Linus, The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git tags/hsi-for-5.4 for you to fetch changes up to c1030cd456198a2c58f718c3c4b215698d635553: HSI: Remove dev_err() usage after platform_get_irq() (2019-07-30 22:40:03 +0200) HSI changes for the 5.4 series * misc. cleanups Gustavo A. R. Silva (1): HSI: ssi_protocol: Mark expected switch fall-throughs Stephen Boyd (1): HSI: Remove dev_err() usage after platform_get_irq() drivers/hsi/clients/ssi_protocol.c | 7 --- drivers/hsi/controllers/omap_ssi_core.c | 4 +--- drivers/hsi/controllers/omap_ssi_port.c | 4 +--- 3 files changed, 6 insertions(+), 9 deletions(-) signature.asc Description: PGP signature
[GIT PULL] power-supply changes for 5.4
Hi Linus, The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v5.4 for you to fetch changes up to 7f7378618b4103c083db7de5017df958f8ada070: power: supply: cpcap-charger: Enable vbus boost voltage (2019-09-02 23:08:07 +0200) power supply and reset changes for the v5.4 series Core: * Ensure HWMON devices are registered with valid names * Fix device wakeup code Drivers: * bq25890_charger: Add BQ25895 support * axp288_fuel_gauge: Add Minix Neo Z83-4 to blacklist * sc27xx: improve battery calibration * misc. small fixes all over drivers Angus Ainslie (Purism) (1): power: supply: bq25890_charger: Add the BQ25895 part Bartosz Golaszewski (1): power: supply: max77650: add MODULE_ALIAS() Christophe JAILLET (1): power: supply: max17042_battery: Fix a typo in function names Colin Ian King (1): power: supply: isp1704: remove redundant assignment to variable ret Denis Efremov (1): MAINTAINERS: N900: Remove isp1704_charger.h record Fuqian Huang (2): power: supply: sc27xx: Introduce local variable 'struct device *dev' power: supply: sc27xx: Replace devm_add_action() followed by failure action with devm_add_action_or_reset() Gustavo A. R. Silva (1): power: supply: ab8500_charger: Mark expected switch fall-through Hans de Goede (2): power: supply: axp288_fuel_gauge: Sort the DMI blacklist alphabetically power: supply: axp288_fuel_gauge: Add Minix Neo Z83-4 to the blacklist Matwey V. Kornilov (1): power: reset: reboot-mode: Fix author email format Michael Nosthoff (2): power: supply: sbs-battery: use correct flags field power: supply: sbs-battery: only return health when battery present Michal Simek (1): power: reset: gpio-restart: Fix typo when gpio reset is not found Romain Izard (1): power: supply: register HWMON devices with valid names Stephen Boyd (1): power: supply: Init device wakeup after device_add() Tony Lindgren (1): power: supply: cpcap-charger: Enable vbus boost voltage Yuanjiang Yu (6): power: supply: sc27xx: Add POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN attribute power: supply: sc27xx: Fix conditon to enable the FGU interrupt power: supply: sc27xx: Fix the the accuracy issue of coulomb calculation power: supply: sc27xx: Make sure the alarm capacity is larger than 0 power: supply: sc27xx: Optimize the battery capacity calibration power: supply: sc27xx: Add POWER_SUPPLY_PROP_CALIBRATE attribute YueHaibing (1): power: supply: ab8500: remove set but not used variables 'vbup33_vrtcn' and 'bup_vch_range' MAINTAINERS | 1 - drivers/phy/motorola/phy-cpcap-usb.c | 8 +- drivers/power/reset/gpio-restart.c| 2 +- drivers/power/reset/reboot-mode.c | 2 +- drivers/power/supply/ab8500_charger.c | 8 +- drivers/power/supply/axp288_fuel_gauge.c | 14 +- drivers/power/supply/bq25890_charger.c| 12 +- drivers/power/supply/cpcap-charger.c | 23 ++- drivers/power/supply/isp1704_charger.c| 2 +- drivers/power/supply/max17042_battery.c | 8 +- drivers/power/supply/max77650-charger.c | 1 + drivers/power/supply/power_supply_core.c | 10 +- drivers/power/supply/power_supply_hwmon.c | 15 +- drivers/power/supply/sbs-battery.c| 27 ++-- drivers/power/supply/sc27xx_fuel_gauge.c | 223 -- 15 files changed, 237 insertions(+), 119 deletions(-) signature.asc Description: PGP signature
Re: [PATCH] mm: slub: print_hex_dump() with DUMP_PREFIX_OFFSET
On Sat, 2019-09-21 at 02:08 -0700, David Rientjes wrote:
> On Fri, 20 Sep 2019, Miles Chen wrote:
>
> > Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
> > The use DUMP_PREFIX_OFFSET instead of DUMP_PREFIX_ADDRESS with
> > print_hex_dump() can generate more useful messages.
> >
> > In the following example, it's easier get the offset of incorrect poison
> > value with DUMP_PREFIX_OFFSET.
> >
> > Before:
> > Object e817b73b: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 816f4601: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 169d2bb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object f4c38716: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 917e3491: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object c0e33738: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 1755ddd1: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > After:
> > Object : 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 0010: 63 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 0020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > Object 0030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
> >
> > I think it might be worth to convert all DUMP_PREFIX_ADDRESS to
> > DUMP_PREFIX_OFFSET for the whole Linux kernel.
> >
>
> I agree it looks nicer for poisoning, I'm not sure that every caller of
> print_section() is the same, however. For example trace() seems better
> off as DUMP_PREFIX_ADDRESS since it already specifies the address of the
> object being allocated or freed and offset here wouldn't really be useful,
> no?
Thanks for the reply. I agree not all caller of print_section() is the
same case. Converting all of them is not a good idea.
For mm/slub.c, let me explain with the following example.
The offset is useful for use-after-free debugging. I often trace the
"free track" and find the data structure used and compare the data
structure with the offset of the incorrect poison value and see if the
incorrect poison value matches some member of that data structure.
Assume we have a data structure "something" and it has a member called
"m", offset = 780.
struct something *p; // sizeof(struct something) is 1024
p = kmalloc(sizeof(struct something), GFP_KERNEL);
kfree(p);
(p->m) = 'c'; // assume p->member is at offset=780
When we see the log: (using DUMP_PREFIX_ADDRESS)
We have to "count" the offset.
INFO: Slab 0x(ptrval) objects=21 used=21 fp=0x(ptrval)
flags=0x10200
INFO: Object 0x(ptrval) @offset=7808 fp=0x(ptrval)
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Redzone ptrval: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
...
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 63 6b 6b 6b
ckkk
Object ptrval: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
k
Re: [PATCH v2 1/2] rtc: wilco-ec: Remove yday and wday calculations
On Mon 2019-09-16 12:12:15, Nick Crews wrote: > The tm_yday and tm_wday fields are not used by userspace, > so since they aren't needed within the driver, don't > bother calculating them. This is especially needed since > the rtc_year_days() call was crashing if the HW returned > an invalid time. > > Signed-off-by: Nick Crews > --- > drivers/rtc/rtc-wilco-ec.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/rtc/rtc-wilco-ec.c b/drivers/rtc/rtc-wilco-ec.c > index 8ad4c4e6d557..e84faa268caf 100644 > --- a/drivers/rtc/rtc-wilco-ec.c > +++ b/drivers/rtc/rtc-wilco-ec.c > @@ -110,10 +110,6 @@ static int wilco_ec_rtc_read(struct device *dev, struct > rtc_time *tm) > tm->tm_mday = rtc.day; > tm->tm_mon = rtc.month - 1; > tm->tm_year = rtc.year + (rtc.century * 100) - 1900; > - tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year); > - > - /* Don't compute day of week, we don't need it. */ > - tm->tm_wday = -1; > > return 0; Are you sure? It would be bad to pass unititialized memory to userspace... If userspace does not need those fields, why are they there? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
Hi! > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as > system controller, the system controller is in charge of system > power, clock and power key event etc. management, Linux kernel > has to communicate with system controller via MU (message unit) > IPC to get power key event, add binding doc for i.MX system > controller power key driver. > > Signed-off-by: Anson Huang > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > @@ -157,6 +157,15 @@ Required properties: > Optional properties: > - timeout-sec: contains the watchdog timeout in seconds. > > +Power key bindings based on SCU Message Protocol > + > + > +Required properties: > +- compatible: should be: > + "fsl,imx8qxp-sc-pwrkey" > + followed by "fsl,imx-sc-pwrkey"; > +- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt Actually there's no reason for having "linux,keycodes" property when it is always a power button. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support
Hi! > >>Why is it global struct? It seems to be flexible configurable over > >>devicetree. > >>So I would assume it should be able to handle more then one button. Please > >>remove global variables, make it allocatable per OF node. > > > >There is ONLY one button available for SC key, but yes, I think I can make > >the structure > >private and get all necessary data from the structure using container_of. > > And we will never need more then 640 kB RAM ;) > https://en.wikiquote.org/wiki/Talk:Bill_Gates Right question is "is it worth complicating kernel now (and making it slower/bigger) for future flexibility?". And I believe answer is "no", but it is not a big deal either way. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
On Tue 2019-09-03 10:03:40, Anson Huang wrote: > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as > system controller, the system controller is in charge of system > power, clock and power key event etc. management, Linux kernel > has to communicate with system controller via MU (message unit) > IPC to get power key event, add binding doc for i.MX system > controller power key driver. > > Signed-off-by: Anson Huang > --- > Changes since V1: > - remove "wakeup-source" property, as it is NOT needed for SCU > interrupt; > - remove "status" in example. > --- > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 > ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > index c149fad..f93e2e4 100644 > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt > @@ -157,6 +157,15 @@ Required properties: > Optional properties: > - timeout-sec: contains the watchdog timeout in seconds. > > +Power key bindings based on SCU Message Protocol > + > + > +Required properties: > +- compatible: should be: > + "fsl,imx8qxp-sc-pwrkey" > + followed by "fsl,imx-sc-pwrkey"; > +- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt Note you have keycode_s_ here, but keycode in the example and in the dts patch. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
Hi!
> > > + ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> > > + if (ret) {
> > > + dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> > > + return;
> > > + }
> > > +
> > > + state = (bool)msg.state;
> > > +
> > > + if (!state && !priv->keystate)
> > > + state = true;
> >
> > This needs an explanation please.
>
> This is to handle the quick press of button, e.g., when button is pressed and
> released very quickly,
> when the delay work is scheduled, the button state read from SCU FW is
> actually a release state (0),
> the press state is (1), so the quick press/release will be ignored.
>
> However, after double check and test, I think this should be handled by
> debounce time, if the button is pressed/release
> very quickly, the event should be ignored, I will remove it and reduce the
> debounce time to 30mS, previous 100mS
> is too long, using 30mS as debounce time, I did NOT see similar issue no
> matter how quick I press/release the button.
Are you sure this is expected behaviour?
AFAIK microswitches can bounce when the button is pressed and released, but
will not generate
glitches when the button was not pressed, so even short presses are real and
should be
propagated...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 3.16 000/132] 3.16.74-rc1 review
On Fri, 2019-09-20 at 18:35 -0700, Guenter Roeck wrote: > On 9/20/19 2:16 PM, Ben Hutchings wrote: > > On Fri, 2019-09-20 at 13:04 -0700, Guenter Roeck wrote: > > > On Fri, Sep 20, 2019 at 03:23:34PM +0100, Ben Hutchings wrote: > > > > This is the start of the stable review cycle for the 3.16.74 release. > > > > There are 132 patches in this series, which will be posted as responses > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Mon Sep 23 20:00:00 UTC 2019. > > > > Anything received after that time might be too late. > > > > > > > > > > Build results: > > > total: 136 pass: 135 fail: 1 > > > Failed builds: > > > arm:allmodconfig > > > Qemu test results: > > > total: 229 pass: 229 fail: 0 > > > > > > Build errors in arm:allmodconfig are along the line of > > > > > > In file included from include/linux/printk.h:5, > > > from include/linux/kernel.h:13, > > > from include/linux/clk.h:16, > > > from drivers/gpu/drm/tilcdc/tilcdc_drv.h:21, > > > from drivers/gpu/drm/tilcdc/tilcdc_drv.c:20: > > > include/linux/init.h:343:7: error: 'cleanup_module' > > > specifies less restrictive attribute than its target 'tilcdc_drm_fini': > > > 'cold' > > > > > > In addition to a few errors like that, there are literally thousands > > > of similar warnings. > > > > It looks like this is triggered by you switching arm builds from gcc 8 > > to 9, rather than by any code change. > > > > After reverting to gcc 8.3.0 for arm, I get: > > Build results: > total: 136 pass: 136 fail: 0 > Qemu test results: > total: 229 pass: 229 fail: 0 > > Sorry for the noise. Great, thanks for checking. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] MIPS changes
The pull request you sent on Sat, 21 Sep 2019 23:10:24 +: > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5c6bd5de3c2e5bc8a17451e281ed2613375a7fd5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mmc: host: atmel-mci: assign false/true to bool variable
On Wed, Sep 18, 2019 at 08:01:12PM +0200, Alexandre Belloni wrote: > More useful than information than info on semantic patching, it would be > good to have info on why you feel this is necessary. Sure, will update the changelog and resend.
[PATCH] perf: save RAM when filtering events
The code mentioned wanting to use an implementation of log10() in the dvb
drivers. I am not aware why that specific implementation is mentioned.
I used the implementation found in `math.h`.
I tested this patch passing 200 syscalls to filter on a `perf trace -e
${syscalls} ls`
call. You can see the commands used and a snipped of the valgrind results here:
https://termbin.com/k4of
Before: 61,910,110 bytes allocated
After: 61,907,045 bytes allocated
perf used to allocate space in excess to build the filtering expressions.
now perf only allocates the space necessary and not more.
Signed-off-by: Alex Diaz
---
tools/perf/util/string.c | 25 -
tools/perf/util/string2.h | 2 ++
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
index 52603876c548..4c3913a9e7e7 100644
--- a/tools/perf/util/string.c
+++ b/tools/perf/util/string.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include
@@ -209,15 +210,29 @@ int strtailcmp(const char *s1, const char *s2)
return 0;
}
-char *asprintf_expr_inout_ints(const char *var, bool in, size_t nints, int
*ints)
+size_t calc_expr_buffer_size(const char *var, size_t nints, int *ints)
{
/*
-* FIXME: replace this with an expression using log10() when we
-* find a suitable implementation, maybe the one in the dvb drivers...
+* Calculate the buffer for the expression:
*
-* "%s == %d || " = log10(MAXINT) * 2 + 8 chars for the operators
+* "%s == %d || "
+* length: strlen(var) + strlen(" == ") + log10(n) + strlen(" || ") + 1
*/
- size_t size = nints * 28 + 1; /* \0 */
+ size_t size = 0;
+ size_t num_len = 0;
+ const size_t var_len = strlen(var);
+
+ for (size_t i = 0; i < nints; ++i) {
+ num_len = (ints[i] == 0) ? 1 : log10(ints[i]);
+ size += var_len + num_len + 9;
+ }
+
+ return size;
+}
+
+char *asprintf_expr_inout_ints(const char *var, bool in, size_t nints, int
*ints)
+{
+ size_t size = calc_expr_buffer_size(var, nints, ints);
size_t i, printed = 0;
char *expr = malloc(size);
diff --git a/tools/perf/util/string2.h b/tools/perf/util/string2.h
index 708805f5573e..28fbc782ad54 100644
--- a/tools/perf/util/string2.h
+++ b/tools/perf/util/string2.h
@@ -20,6 +20,8 @@ static inline bool strisglob(const char *str)
}
int strtailcmp(const char *s1, const char *s2);
+size_t calc_expr_buffer_size(const char *var, size_t nints, int *ints);
+
char *asprintf_expr_inout_ints(const char *var, bool in, size_t nints, int
*ints);
static inline char *asprintf_expr_in_ints(const char *var, size_t nints, int
*ints)
--
2.21.0
Re: [PATCH] mm: slub: print_hex_dump() with DUMP_PREFIX_OFFSET
On Sat, 2019-09-21 at 09:00 -0700, Matthew Wilcox wrote:
> On Sat, Sep 21, 2019 at 02:08:59AM -0700, David Rientjes wrote:
> > On Fri, 20 Sep 2019, Miles Chen wrote:
> >
> > > Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
> > > The use DUMP_PREFIX_OFFSET instead of DUMP_PREFIX_ADDRESS with
> > > print_hex_dump() can generate more useful messages.
> > >
> > > In the following example, it's easier get the offset of incorrect poison
> > > value with DUMP_PREFIX_OFFSET.
> > >
> > > Before:
> > > Object e817b73b: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 816f4601: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 169d2bb8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object f4c38716: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 917e3491: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object c0e33738: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 1755ddd1: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > >
> > > After:
> > > Object : 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 0010: 63 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 0020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> > > Object 0030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
> >
> > I agree it looks nicer for poisoning, I'm not sure that every caller of
> > print_section() is the same, however. For example trace() seems better
> > off as DUMP_PREFIX_ADDRESS since it already specifies the address of the
> > object being allocated or freed and offset here wouldn't really be useful,
> > no?
>
> While it looks nicer, it might be less useful for debugging. The point of
> obfuscated %p is that you can compare two "pointer" values for equality.
> So if you know that you freed object e817b73b from an earlier
> printk, then you can match it up to this dump. It's obviously not
> perfect since we're only getting the pointers at addresses that are
> multiples of 16, but it's a help.
Thanks for the reply.
The value of e817b73b dump and the value earlier printk should
be the same, Otherwise we have a serious problem because:
printf("%p", bad_ptr);
print_hex_dump(bad_ptr);
and we see a different hashed address of bad_ptr in print_hex_dump().
I think it's a rare case but we still have a chance to see that case.
DUMP_PREFIX_ADDRESS is useful for that case.
On the other hand, DUMP_PREFIX_OFFSET is useful for finding the offset
of incorrect poison value easier.
Maybe I can print the offset of the bad poison value in
check_bytes_and_report(). e.g.,
@@ -736,6 +736,7 @@ static int check_bytes_and_report(struct kmem_cache
*s, struct page *page,
{
u8 *fault;
u8 *end;
+ u8 *addr = page_address(page);
metadata_access_enable();
fault = memchr_inv(start, value, bytes);
@@ -748,8 +749,9 @@ static int check_bytes_and_report(struct kmem_cache
*s, struct page *page,
end--;
slab_bug(s, "%s overwritten", what);
- pr_err("INFO: 0x%p-0x%p. First byte 0x%x instead of 0x%x\n",
- fault, end - 1, fault[0],
value);
+ pr_err("INFO: 0x%p-0x%p. First byte 0x%x instead of 0x%x,
offset=%tu\n",
+ fault, end - 1, fault[0], value,
fault -
+ addr);
and we can see the offset printed out:
=
BUG kmalloc-1k (Tainted: GB): Poison overwritten
-
INFO: 0x(ptrval)-0x(ptrval). First byte 0x63 instead of
0x6b, offset=7052
INFO: Object 0x(ptrval) @offset=6272 fp=0x(ptrval)
and we can get the offset by: 7052 - 6272 = 780.
Re: [v2 0/3] Fix issues reported by Coccinelle
On Tue, Sep 17, 2019 at 08:14:23PM +0200, Wolfram Sang wrote: > On Tue, Sep 17, 2019 at 08:10:45PM +0200, Markus Elfring wrote: > > > Using cocciecheck to ensure there are no semantic issues in > > > i2c-qup driver. > > > > * This wording contains a typo. > > Doesn't matter to me for a cover letter as long as we can understand it. > > > * I would prefer to refer to a desired reduction of a few > > source code quality concerns. > > Not needed. I understand what is going on here. Markus - By "ensure", I mean there are no further cocciecheck issues at this point in time. And further, what changed is covered in individual patch changelog. So, I think this information is fine in cover. > > Can such a prefix be omitted? Can be, but I like to keep it. Thanks for review. -Saiyam
kexec broken with STACKLEAK enabled
Hi, since commit b059f801a937 (x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS) kexec is broken if GCC_PLUGIN_STACKLEAK is enabled, as the purgatory contains undefined references to stackleak_track_stack. Attempting to load a kexec kernel results in an error: kexec: Undefined symbol: stackleak_track_stack kexec-bzImage64: Loading purgatory failed Adding $(DISABLE_STACKLEAK_PLUGIN) to PURGATORY_CFLAGS in arch/x86/purgatory/Makefile fixes this. Not sure if that's the best fix or if other architectures also require a similar one. Thanks.
Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin wrote:
>
> On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
> > Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
> > to fallback to tun_automq_select_queue() for tx queue selection.
> >
> > Compilation of this exact patch was tested.
> >
> > For functional testing 3 additional printk()s were added.
> >
> > Functional testing results (on 2 txq tap device):
> >
> > [Fri Sep 20 18:33:27 2019] == tun no prog ==
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> > [Fri Sep 20 18:33:27 2019] == tun prog -1 ==
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '-1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> > [Fri Sep 20 18:33:27 2019] == tun prog 0 ==
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '0'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> > [Fri Sep 20 18:33:27 2019] == tun prog 1 ==
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '1'
> > [Fri Sep 20 18:33:27 2019] == tun prog 2 ==
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '2'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> >
> > Signed-off-by: Matthew Cover
>
>
> Could you add a bit more motivation data here?
Thank you for these questions Michael.
I'll plan on adding the below information to the
commit message and submitting a v2 of this patch
when net-next reopens. In the meantime, it would
be very helpful to know if these answers address
some of your concerns.
> 1. why is this a good idea
This change allows TUNSETSTEERINGEBPF progs to
do any of the following.
1. implement queue selection for a subset of
traffic (e.g. special queue selection logic
for ipv4, but return negative and use the
default automq logic for ipv6)
2. determine there isn't sufficient information
to do proper queue selection; return
negative and use the default automq logic
for the unknown
3. implement a noop prog (e.g. do
bpf_trace_printk() then return negative and
use the default automq logic for everything)
> 2. how do we know existing userspace does not rely on existing behaviour
Prior to this change a negative return from a
TUNSETSTEERINGEBPF prog would have been cast
into a u16 and traversed netdev_cap_txqueue().
In most cases netdev_cap_txqueue() would have
found this value to exceed real_num_tx_queues
and queue_index would be updated to 0.
It is possible that a TUNSETSTEERINGEBPF prog
return a negative value which when cast into a
u16 results in a positive queue_index less than
real_num_tx_queues. For example, on x86_64, a
return value of -65535 results in a queue_index
of 1; which is a valid queue for any multiqueue
device.
It seems unlikely, however as stated above is
unfortunately possible, that existing
TUNSETSTEERINGEBPF programs would choose to
return a negative value rather than return the
positive value which holds the same meaning.
It seems more likely that future
TUNSETSTEERINGEBPF programs would leverage a
negative return and potentially be loaded into
a kernel with the old behavior.
> 3. why doesn't userspace need a way to figure out whether it runs on a kernel
> with and
>without this patch
There may be some value in exposing this fact
to the ebpf prog loader. What is the standard
practice here, a define?
>
>
> thanks,
> MST
>
> > ---
> > drivers/net/tun.c | 20 +++-
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index aab0be4..173d159 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -583,35 +583,37 @@ static u16 tun_automq_select_queue(struct tun_struct
> > *tun, struct sk_buff *skb)
> > return txq;
> > }
> >
> > -static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff
> > *skb)
> > +static int tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff
> > *skb)
> > {
> > struct tun_prog *prog;
> > u32 numqueues;
> > - u16 ret = 0;
> > + int ret = -1;
> >
> > numqueues = READ_ONCE(tun->numqueues);
> > if (!numqueues)
> > return 0;
> >
> > + rcu_read_lock();
> > prog = rcu_dereference(tun->steering_prog);
> > if (prog)
> > ret = bpf_prog_run_clear_cb(prog->prog, skb);
> > + rcu_read_unlock();
> >
> > - return ret % numqueues;
> > + if (ret >= 0)
> > + ret %= numqueues;
> > +
> > + return ret;
> > }
> >
> > static u16 tun_select_queue(struct net
[RFC] VSOCK: add support for MSG_PEEK
This patch adds support for MSG_PEEK. In such a case, packets are not
removed from the rx_queue and credit updates are not sent.
Signed-off-by: Matias Ezequiel Vara Larsen
---
net/vmw_vsock/virtio_transport_common.c | 59 +++--
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c
b/net/vmw_vsock/virtio_transport_common.c
index 94cc0fa..830e890 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -264,6 +264,59 @@ static int virtio_transport_send_credit_update(struct
vsock_sock *vsk,
}
static ssize_t
+virtio_transport_stream_do_peek(struct vsock_sock *vsk,
+ struct msghdr *msg,
+ size_t len)
+{
+ struct virtio_vsock_sock *vvs = vsk->trans;
+ struct virtio_vsock_pkt *pkt;
+ size_t bytes, off = 0, total = 0;
+ int err = -EFAULT;
+
+ spin_lock_bh(&vvs->rx_lock);
+
+ if (list_empty(&vvs->rx_queue)) {
+ spin_unlock_bh(&vvs->rx_lock);
+ return 0;
+ }
+
+ pkt = list_first_entry(&vvs->rx_queue,
+ struct virtio_vsock_pkt, list);
+ do {
+ bytes = len - total;
+ if (bytes > pkt->len - off)
+ bytes = pkt->len - off;
+
+ /* sk_lock is held by caller so no one else can dequeue.
+* Unlock rx_lock since memcpy_to_msg() may sleep.
+*/
+ spin_unlock_bh(&vvs->rx_lock);
+
+ err = memcpy_to_msg(msg, pkt->buf + off, bytes);
+ if (err)
+ goto out;
+
+ spin_lock_bh(&vvs->rx_lock);
+
+ total += bytes;
+ off += bytes;
+ if (off == pkt->len) {
+ pkt = list_next_entry(pkt, list);
+ off = 0;
+ }
+ } while ((total < len) && !list_is_first(&pkt->list, &vvs->rx_queue));
+
+ spin_unlock_bh(&vvs->rx_lock);
+
+ return total;
+
+out:
+ if (total)
+ err = total;
+ return err;
+}
+
+static ssize_t
virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
struct msghdr *msg,
size_t len)
@@ -330,9 +383,9 @@ virtio_transport_stream_dequeue(struct vsock_sock *vsk,
size_t len, int flags)
{
if (flags & MSG_PEEK)
- return -EOPNOTSUPP;
-
- return virtio_transport_stream_do_dequeue(vsk, msg, len);
+ return virtio_transport_stream_do_peek(vsk, msg, len);
+ else
+ return virtio_transport_stream_do_dequeue(vsk, msg, len);
}
EXPORT_SYMBOL_GPL(virtio_transport_stream_dequeue);
--
2.7.4
[PATCH 04/13] platform: chrome: cros-ec: record event timestamp in the hard irq
To improve sensor timestamp precision, given EC and AP are in
different time domains, the AP needs to try to record the exact
moment an event was signalled to the AP by the EC as soon as
possible after it happens.
First thing in the hard irq is the best place for this.
Signed-off-by: Gwendal Grignou
---
drivers/platform/chrome/cros_ec.c | 18 +-
drivers/platform/chrome/cros_ec_lpc.c | 2 ++
include/linux/platform_data/cros_ec_proto.h | 15 +++
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec.c
b/drivers/platform/chrome/cros_ec.c
index fd77e6fa74c2..f49eb1d1e3cd 100644
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -31,6 +31,21 @@ static struct cros_ec_platform pd_p = {
.cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_PD_INDEX),
};
+s64 cros_ec_get_time_ns(void)
+{
+ return ktime_get_boottime_ns();
+}
+EXPORT_SYMBOL(cros_ec_get_time_ns);
+
+static irqreturn_t ec_irq_handler(int irq, void *data)
+{
+ struct cros_ec_device *ec_dev = data;
+
+ ec_dev->last_event_time = cros_ec_get_time_ns();
+
+ return IRQ_WAKE_THREAD;
+}
+
static irqreturn_t ec_irq_thread(int irq, void *data)
{
struct cros_ec_device *ec_dev = data;
@@ -132,7 +147,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
}
if (ec_dev->irq) {
- err = devm_request_threaded_irq(dev, ec_dev->irq, NULL,
+ err = devm_request_threaded_irq(
+ dev, ec_dev->irq, ec_irq_handler,
ec_irq_thread, IRQF_TRIGGER_LOW | IRQF_ONESHOT,
"chromeos-ec", ec_dev);
if (err) {
diff --git a/drivers/platform/chrome/cros_ec_lpc.c
b/drivers/platform/chrome/cros_ec_lpc.c
index 7d10d909435f..3c77496e164d 100644
--- a/drivers/platform/chrome/cros_ec_lpc.c
+++ b/drivers/platform/chrome/cros_ec_lpc.c
@@ -313,6 +313,8 @@ static void cros_ec_lpc_acpi_notify(acpi_handle device, u32
value, void *data)
{
struct cros_ec_device *ec_dev = data;
+ ec_dev->last_event_time = cros_ec_get_time_ns();
+
if (ec_dev->mkbp_event_supported &&
cros_ec_get_next_event(ec_dev, NULL) > 0)
blocking_notifier_call_chain(&ec_dev->event_notifier, 0,
diff --git a/include/linux/platform_data/cros_ec_proto.h
b/include/linux/platform_data/cros_ec_proto.h
index e91e3fcb0348..ab12e28f2107 100644
--- a/include/linux/platform_data/cros_ec_proto.h
+++ b/include/linux/platform_data/cros_ec_proto.h
@@ -121,6 +121,8 @@ struct cros_ec_command {
* @event_data: Raw payload transferred with the MKBP event.
* @event_size: Size in bytes of the event data.
* @host_event_wake_mask: Mask of host events that cause wake from suspend.
+ * @last_event_time: exact time from the hard irq when we got notified of
+ * a new event.
* @ec: The platform_device used by the mfd driver to interface with the
* main EC.
* @pd: The platform_device used by the mfd driver to interface with the
@@ -161,6 +163,7 @@ struct cros_ec_device {
int event_size;
u32 host_event_wake_mask;
u32 last_resume_result;
+ s64 last_event_time;
/* The platform devices used by the mfd driver */
struct platform_device *ec;
@@ -308,4 +311,16 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev,
bool *wake_event);
*/
u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
+/**
+ * cros_ec_get_time_ns - Return time in ns.
+ *
+ * This is the function used to record the time for last_event_time in struct
+ * cros_ec_device during the hard irq.
+ *
+ * This function is probably implemented using ktime_get_boot_ns(), but it's
+ * exposed here to make sure all cros_ec drivers use the same code path to get
+ * the time.
+ */
+s64 cros_ec_get_time_ns(void);
+
#endif /* __LINUX_CROS_EC_PROTO_H */
--
2.23.0.351.gc4317032e6-goog
[PATCH 00/13] cros_ec: Add sensorhub driver and FIFO processing
This patchset adds a sensorhub driver for spreading sensor events coming from the Embedded controller sensor FIFO: +---+ +--+ + | cros_ec_accel | | cros_ec_gyro | | ... +---+ +--+ + id:0 \id:1 | / id:.. +--+ | cros_ec_sensorhub | +--+ | cros_ec_dev| +--+ | cros_ec_i2c, cros_ec_lpc, .. | +--+ | EC When new sensors events are present, the EC raises and interrupt, sensorhub reads the FIFO and uses the 'id' field to spread the event to the proper IIO sensors. This stack is similar to the HID sensor input stack. The first 3 patches add a primitive cros_ec_sensorhub. MFD just have to register this driver if at least one sensor is presented by the EC. cros_ec_sensorhub retrieves more information from the EC to find out which sensors are actually present: mfd: cros_ec: Add sensor_count and make check_features public platform: cros_ec: Add cros_ec_sensor_hub driver platform/mfd:iio: cros_ec: Register sensor through sensorhub The next 3 patches prepare for FIFO support: platform: chrome: cros-ec: record event timestamp in the hard irq platform: chrome: cros_ec: Do not attempt to register a non-positive platform: chrome: cros_ec: handle MKBP more events flag The next 4 patches add FIFO support. An interface is added to connect the IIO sensors with cros_ec_sensorhub, and filters are needed to spread the timestamp when the EC send batches of events and deal with variation in interrupt delay. platform: chrome: sensorhub: Add FIFO support platform: chrome: sensorhub: Add code to spread timestmap platform: chrome: sensorhub: Add median filter iio: cros_ec: Use triggered buffer only when EC does not support FIFO Finally, the last 3 patches present sensor information following the IIO ABI: - Configurable EC timeout to allow batch mode in buffer/hwfifo_timeout, in seconds. - Hard coded EC FIFO size in buffer/hwfifo_watermark_max - Sensor sampling frequency in hertz at sampling_frequency: iio: cros_ec: Expose hwfifo_timeout iio: cros_ec: Report hwfifo_watermark_max iio: cros_ec: Use Hertz as unit for sampling frequency For testing, libiio test tools can be used: A iio device link looks like: iio:device1 -> ...09:00/GOOG0004:00/cros-ec-dev.6.auto/cros-ec-sensorhub.7.auto/ cros-ec-accel.15.auto/iio:device1 When FIFO is available, no trigger are presented. Once sampling_freqeuncy and hwfifo_timeout are set, sensor events flow when listening to /dev/iio:device1: echo 12 > sampling_frequency # Set ODR to at least 12Hz echo .100 > buffer/hwfifo_timeout # do not wait more than 100ms to # to send samples iio_readdev -b 2 -T 1000 -s 2 iio:device1 2>/dev/null| od -x 000 ffd0 2e20 d990 8630 b56c 07ea 020 ffc0 2e10 d970 877e b56c 07ea 040` When FIFO is not supported by the EC, a trigger is present in the directory. After registering a trigger, setting sampling_frequency, the latest data collected by the sensor will be retrieved by the host when the trigger expires. When cros_ec_accel_legacy driver is used, no FIFO is supported and the sampling frequency for the accelerometers is hard coded at 10Hz. This set is built upon the master branch of git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Enrico Granata (2): platform: chrome: cros_ec: Do not attempt to register a non-positive IRQ number platform: chrome: cros_ec: handle MKBP more events flag Gwendal Grignou (11): mfd: cros_ec: Add sensor_count and make check_features public platform: cros_ec: Add cros_ec_sensor_hub driver platform/mfd:iio: cros_ec: Register sensor through sensorhub platform: chrome: cros-ec: record event timestamp in the hard irq platform: chrome: sensorhub: Add FIFO support platform: chrome: sensorhub: Add code to spread timestmap platform: chrome: sensorhub: Add median filter iio: cros_ec: Use triggered buffer only when EC does not support FIFO iio: cros_ec: Expose hwfifo_timeout iio: cros_ec: Report hwfifo_watermark_max iio: cros_ec: Use Hertz as unit for sampling frequency drivers/iio/accel/cros_ec_accel_legacy.c | 13 +- drivers/iio/common/cros_ec_sensors/Kconfig| 2 +- .../cros_ec_sensors/cros_ec_lid_angle.c | 2 +- .../common/cros_ec_sensors/cros_ec_sensors.c | 14 +- .../cros_ec_sensors/cros_ec_sensors_core.c| 251 - drivers/iio/light/cros_ec_light_prox.c| 18 +- drivers/iio/pressure/cros_ec_baro.c | 12 +- drivers/mfd/cros_ec_dev.c | 208 +--- drivers/platform/chrome/Kconfig
[PATCH 07/13] platform: chrome: sensorhub: Add FIFO support
cros_ec_sensorhub registers a listener and query motion sense FIFO,
spread to iio sensors registers.
To test, we can use libiio:
iiod&
iio_readdev -u ip:localhost -T 1 -s 25 -b 16 cros-ec-gyro | od -x
Signed-off-by: Gwendal Grignou
---
drivers/iio/accel/cros_ec_accel_legacy.c | 1 +
.../common/cros_ec_sensors/cros_ec_sensors.c | 1 +
.../cros_ec_sensors/cros_ec_sensors_core.c| 13 +
drivers/iio/light/cros_ec_light_prox.c| 1 +
drivers/iio/pressure/cros_ec_baro.c | 1 +
drivers/platform/chrome/Makefile | 3 +-
drivers/platform/chrome/cros_ec_sensorhub.c | 130 --
.../platform/chrome/cros_ec_sensorhub_ring.c | 374 ++
.../linux/iio/common/cros_ec_sensors_core.h | 3 +
.../linux/platform_data/cros_ec_sensorhub.h | 79
10 files changed, 569 insertions(+), 37 deletions(-)
create mode 100644 drivers/platform/chrome/cros_ec_sensorhub_ring.c
diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
b/drivers/iio/accel/cros_ec_accel_legacy.c
index c9af6fa0670d..591c0d962c44 100644
--- a/drivers/iio/accel/cros_ec_accel_legacy.c
+++ b/drivers/iio/accel/cros_ec_accel_legacy.c
@@ -212,6 +212,7 @@ static struct platform_driver cros_ec_accel_platform_driver
= {
.name = DRV_NAME,
},
.probe = cros_ec_accel_legacy_probe,
+ .remove = cros_ec_sensors_core_clean,
};
module_platform_driver(cros_ec_accel_platform_driver);
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
index 5bd6f54afc42..a88dd8deade9 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
@@ -329,6 +329,7 @@ static struct platform_driver
cros_ec_sensors_platform_driver = {
.pm = &cros_ec_sensors_pm_ops,
},
.probe = cros_ec_sensors_probe,
+ .remove = cros_ec_sensors_core_clean,
.id_table = cros_ec_sensors_ids,
};
module_platform_driver(cros_ec_sensors_platform_driver);
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index 81a7f692de2f..43eb1d42820e 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -160,6 +160,19 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
}
EXPORT_SYMBOL_GPL(cros_ec_sensors_core_init);
+int cros_ec_sensors_core_clean(struct platform_device *pdev)
+{
+ struct cros_ec_sensorhub *sensor_hub =
+ dev_get_drvdata(pdev->dev.parent);
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
+ u8 sensor_num = st->param.info.sensor_num;
+
+ cros_ec_sensorhub_unregister_push_data(sensor_hub, sensor_num);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cros_ec_sensors_core_clean);
+
int cros_ec_motion_send_host_cmd(struct cros_ec_sensors_core_state *state,
u16 opt_length)
{
diff --git a/drivers/iio/light/cros_ec_light_prox.c
b/drivers/iio/light/cros_ec_light_prox.c
index 205effc1f404..c431e4d1482d 100644
--- a/drivers/iio/light/cros_ec_light_prox.c
+++ b/drivers/iio/light/cros_ec_light_prox.c
@@ -270,6 +270,7 @@ static struct platform_driver
cros_ec_light_prox_platform_driver = {
.pm = &cros_ec_sensors_pm_ops,
},
.probe = cros_ec_light_prox_probe,
+ .remove = cros_ec_sensors_core_clean,
.id_table = cros_ec_light_prox_ids,
};
module_platform_driver(cros_ec_light_prox_platform_driver);
diff --git a/drivers/iio/pressure/cros_ec_baro.c
b/drivers/iio/pressure/cros_ec_baro.c
index 2354302375de..2f4d6d3ab41d 100644
--- a/drivers/iio/pressure/cros_ec_baro.c
+++ b/drivers/iio/pressure/cros_ec_baro.c
@@ -201,6 +201,7 @@ static struct platform_driver cros_ec_baro_platform_driver
= {
.name = "cros-ec-baro",
},
.probe = cros_ec_baro_probe,
+ .remove = cros_ec_sensors_core_clean,
.id_table = cros_ec_baro_ids,
};
module_platform_driver(cros_ec_baro_platform_driver);
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index a164c40dc099..cb709048c003 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -17,7 +17,8 @@ obj-$(CONFIG_CROS_EC_PROTO) += cros_ec_proto.o
cros_ec_trace.o
obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_chardev.o
obj-$(CONFIG_CROS_EC_LIGHTBAR) += cros_ec_lightbar.o
-obj-$(CONFIG_CROS_EC_SENSORHUB)+= cros_ec_sensorhub.o
+cros_ec_sensorsupport-objs := cros_ec_sensorhub_ring.o
cros_ec_sensorhub.o
+obj-$(CONFIG_CROS_EC_SENSORH
[PATCH 09/13] platform: chrome: sensorhub: Add median filter
Events are timestamped in EC time space, their timestamps need to be
converted in host time space.
The assumption is the time delta between when the interrupt is sent
by the EC and when it is receive by the host is a [small] constant.
This is not always true, even with hard-wired interrupt. To mitigate
worst offenders, add a median filter to weed out bigger than expected
delays.
Signed-off-by: Gwendal Grignou
---
.../platform/chrome/cros_ec_sensorhub_ring.c | 485 +-
.../linux/platform_data/cros_ec_sensorhub.h | 65 +++
2 files changed, 533 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_sensorhub_ring.c
b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
index 48327e80a5a3..9955c80d0907 100644
--- a/drivers/platform/chrome/cros_ec_sensorhub_ring.c
+++ b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
@@ -69,9 +69,11 @@ int cros_ec_sensorhub_ring_fifo_toggle(
struct cros_ec_sensorhub *sensorhub,
bool on)
{
- int ret;
+ int ret, i;
mutex_lock(&sensorhub->cmd_lock);
+ for (i = 0; i < CROS_EC_SENSOR_MAX; i++)
+ sensorhub->last_batch_len[i] = 0;
sensorhub->params->cmd = MOTIONSENSE_CMD_FIFO_INT_ENABLE;
sensorhub->params->fifo_int_enable.enable = on;
@@ -86,6 +88,227 @@ int cros_ec_sensorhub_ring_fifo_toggle(
return ret;
}
+static int cros_ec_ring_median_cmp(const void *pv1, const void *pv2)
+{
+ s64 v1 = *(s64 *)pv1;
+ s64 v2 = *(s64 *)pv2;
+
+ if (v1 > v2)
+ return 1;
+ else if (v1 < v2)
+ return -1;
+ else
+ return 0;
+}
+
+/*
+ * cros_ec_ring_median: Gets median of an array of numbers
+ *
+ * For now it's implemented using an inefficient > O(n) sort then return
+ * the middle element. A more optimal method would be something like
+ * quickselect, but given that n = 64 we can probably live with it in the
+ * name of clarity.
+ *
+ * Warning: the input array gets modified (sorted)!
+ */
+static s64 cros_ec_ring_median(s64 *array, size_t length)
+{
+ sort(array, length, sizeof(s64), cros_ec_ring_median_cmp, NULL);
+ return array[length / 2];
+}
+
+/*
+ * IRQ Timestamp Filtering
+ *
+ * Lower down in cros_ec_ring_process_event(), for each sensor event we have to
+ * calculate it's timestamp in the AP timebase. There are 3 time points:
+ * a - EC timebase, sensor event
+ * b - EC timebase, IRQ
+ * c - AP timebase, IRQ
+ * a' - what we want: sensor even in AP timebase
+ *
+ * While a and b are recorded at accurate times (due to the EC real time
+ * nature); c is pretty untrustworthy, even though it's recorded the
+ * first thing in ec_irq_handler(). There is a very good change we'll get
+ * added lantency due to:
+ * other irqs
+ * ddrfreq
+ * cpuidle
+ *
+ * Normally a' = c - b + a, but if we do that naive math any jitter in c
+ * will get coupled in a', which we don't want. We want a function
+ * a' = cros_ec_ring_ts_filter(a) which will filter out outliers in c.
+ *
+ * Think of a graph of AP time(b) on the y axis vs EC time(c) on the x axis.
+ * The slope of the line won't be exactly 1, there will be some clock drift
+ * between the 2 chips for various reasons (mechanical stress, temperature,
+ * voltage). We need to extrapolate values for a future x, without trusting
+ * recent y values too much.
+ *
+ * We use a median filter for the slope, then another median filter for the
+ * y-intercept to calculate this function:
+ * dx[n] = x[n-1] - x[n]
+ * dy[n] = x[n-1] - x[n]
+ * m[n] = dy[n] / dx[n]
+ * median_m = median(m[n-k:n])
+ * error[i] = y[n-i] - median_m * x[n-i]
+ * median_error = median(error[:k])
+ * predicted_y = median_m * x + median_error
+ *
+ * Implementation differences from above:
+ * - Redefined y to be actually c - b, this gives us a lot more precision
+ * to do the math. (c-b)/b variations are more obvious than c/b variations.
+ * - Since we don't have floating point, any operations involving slope are
+ * done using fixed point math (*M_PRECISION)
+ * - Since x and y grow with time, we keep zeroing the graph (relative to
+ * the last sample), this way math involving *x[n-i] will not overflow
+ * - EC timestamps are kept in us, it improves the slope calculation precision
+ */
+
+/*
+ * cros_ec_ring_ts_filter_update: Given a new IRQ timestamp pair (EC and
+ * AP timebases), add it to the filter history.
+ *
+ * @b IRQ timestamp, EC timebase (us)
+ * @c IRQ timestamp, AP timebase (ns)
+ */
+static void cros_ec_ring_ts_filter_update(
+ struct cros_ec_sensors_ts_filter_state *state,
+ s64 b, s64 c)
+{
+ s64 x, y;
+ s64 dx, dy;
+ s64 m; /* stored as *M_PRECISION */
+ s64 *m_history_copy = state->temp_buf;
+ s64 *error = state->temp_buf;
+ int i;
+
+ /* we trust b the most, that'll be our independent variable */
+ x = b;
+ /* y is the of
[PATCH 02/13] platform: cros_ec: Add cros_ec_sensor_hub driver
Similar to HID sensor stack, the new driver sits between cros_ec_dev
and the iio device drivers:
EC based iio device topology would be:
iio:device1 ->
...0/:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/
cros-ec-sensorhub.7.auto/
cros-ec-accel.15.auto/
iio:device1
It will be expanded to control EC sensor FIFO.
Signed-off-by: Gwendal Grignou
---
drivers/iio/common/cros_ec_sensors/Kconfig| 2 +-
drivers/platform/chrome/Kconfig | 18 +-
drivers/platform/chrome/Makefile | 1 +
drivers/platform/chrome/cros_ec_sensorhub.c | 211 ++
.../linux/platform_data/cros_ec_sensorhub.h | 21 ++
5 files changed, 249 insertions(+), 4 deletions(-)
create mode 100644 drivers/platform/chrome/cros_ec_sensorhub.c
create mode 100644 include/linux/platform_data/cros_ec_sensorhub.h
diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig
b/drivers/iio/common/cros_ec_sensors/Kconfig
index cdbb29cfb907..fefad9572790 100644
--- a/drivers/iio/common/cros_ec_sensors/Kconfig
+++ b/drivers/iio/common/cros_ec_sensors/Kconfig
@@ -4,7 +4,7 @@
#
config IIO_CROS_EC_SENSORS_CORE
tristate "ChromeOS EC Sensors Core"
- depends on SYSFS && CROS_EC
+ depends on SYSFS && CROS_EC_SENSORHUB
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index ee5f08ea57b6..add967236cfb 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -132,9 +132,9 @@ config CROS_EC_LPC
module will be called cros_ec_lpcs.
config CROS_EC_PROTO
-bool
-help
- ChromeOS EC communication protocol helpers.
+ bool
+ help
+ ChromeOS EC communication protocol helpers.
config CROS_KBD_LED_BACKLIGHT
tristate "Backlight LED support for Chrome OS keyboards"
@@ -190,6 +190,18 @@ config CROS_EC_DEBUGFS
To compile this driver as a module, choose M here: the
module will be called cros_ec_debugfs.
+config CROS_EC_SENSORHUB
+ tristate "ChromeOS EC MEMS Senosr Hub"
+ depends on CROS_EC && IIO
+ help
+ Allow loading IIO sensors. This driver is loaded by MFD and will in
+ turn query the EC and register the sensors.
+ It also spreads the sensor data coming from the EC to the IIO sensorr
+ object.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_sensorhub.
+
config CROS_EC_SYSFS
tristate "ChromeOS EC control and information through sysfs"
depends on MFD_CROS_EC_DEV && SYSFS
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index 477ec3d1d1c9..a164c40dc099 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CROS_EC_PROTO) += cros_ec_proto.o
cros_ec_trace.o
obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_chardev.o
obj-$(CONFIG_CROS_EC_LIGHTBAR) += cros_ec_lightbar.o
+obj-$(CONFIG_CROS_EC_SENSORHUB)+= cros_ec_sensorhub.o
obj-$(CONFIG_CROS_EC_VBC) += cros_ec_vbc.o
obj-$(CONFIG_CROS_EC_DEBUGFS) += cros_ec_debugfs.o
obj-$(CONFIG_CROS_EC_SYSFS)+= cros_ec_sysfs.o
diff --git a/drivers/platform/chrome/cros_ec_sensorhub.c
b/drivers/platform/chrome/cros_ec_sensorhub.c
new file mode 100644
index ..80688018ef66
--- /dev/null
+++ b/drivers/platform/chrome/cros_ec_sensorhub.c
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SensorHub: driver that discover sensors behind
+ * a ChromeOS Embedded controller.
+ *
+ * Copyright 2019 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define DRV_NAME "cros-ec-sensorhub"
+
+static int cros_ec_sensors_register(struct device *dev,
+ struct cros_ec_dev *ec)
+{
+ int ret, i, id, sensor_num;
+ struct mfd_cell *sensor_cells;
+ struct cros_ec_sensor_platform *sensor_platforms;
+ int sensor_type[MOTIONSENSE_TYPE_MAX] = { 0 };
+ struct ec_params_motion_sense *params;
+ struct ec_response_motion_sense *resp;
+ struct cros_ec_command *msg;
+
+ sensor_num = cros_ec_get_sensor_count(ec);
+ if (sensor_num < 0) {
+ dev_err(dev,
+ "Unable to retrieve sensor information (err:%d)\n",
+ sensor_num);
+ return sensor_num;
+ }
+
+ if (sensor_num == 0) {
+ dev_err(dev, "Zero sensors reported.\n");
+ return -EINVAL;
+ }
+
+ /*
+* Build
[PATCH 08/13] platform: chrome: sensorhub: Add code to spread timestmap
EC FIFO can send sensor events in batch. Spread them based on
previous (TSa) and currnet timestamp (TSb)
EC FIFO iio events
+---+
| TSa |
+---+ +---+
| event 1 | | event 1 | TSb - (TSb - TSa)/n * (n-1) |
+---+ +---+
| event 2 | | event 2 | TSb - (TSb - TSa)/n * (n-2) |
+---+ +---+
| ... | -->| | |
+---+ +---+
| event n-1 | | event 2 | TSb - (TSb - TSa)/n |
+---+ +---+
| event n | | event 2 | TSb |
+---+ +---+
| TSb |
+---+
Signed-off-by: Gwendal Grignou
---
.../platform/chrome/cros_ec_sensorhub_ring.c | 99 ++-
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_sensorhub_ring.c
b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
index 8cd533d5542e..48327e80a5a3 100644
--- a/drivers/platform/chrome/cros_ec_sensorhub_ring.c
+++ b/drivers/platform/chrome/cros_ec_sensorhub_ring.c
@@ -160,6 +160,97 @@ static bool cros_ec_ring_process_event(
return true;
}
+/*
+ * cros_ec_ring_spread_add: Calculate proper timestamps then
+ * add to ringbuffer (legacy).
+ *
+ * If there is a sample with a proper timestamp
+ *timestamp | count
+ * older_unprocess_out --> TS1 | 1
+ * TS1 | 2
+ * out --> TS1 | 3
+ * next_out -->TS2 |
+ * We spread time for the samples [older_unprocess_out .. out]
+ * between TS1 and TS2: [TS1+1/4, TS1+2/4, TS1+3/4, TS2].
+ *
+ * If we reach the end of the samples, we compare with the
+ * current timestamp:
+ *
+ * older_unprocess_out --> TS1 | 1
+ * TS1 | 2
+ * out --> TS1 | 3
+ * We know have [TS1+1/3, TS1+2/3, current timestamp]
+ */
+static void cros_ec_ring_spread_add(
+ struct cros_ec_sensorhub *sensorhub,
+ unsigned long sensor_mask,
+ s64 current_timestamp,
+ struct cros_ec_sensors_ring_sample *last_out)
+{
+ struct cros_ec_sensors_ring_sample *out;
+ int i;
+
+ for_each_set_bit(i, &sensor_mask, BITS_PER_LONG) {
+ s64 older_timestamp;
+ s64 timestamp;
+ struct cros_ec_sensors_ring_sample *older_unprocess_out =
+ sensorhub->ring;
+ struct cros_ec_sensors_ring_sample *next_out;
+ int count = 1;
+
+ for (out = sensorhub->ring; out < last_out; out = next_out) {
+ s64 time_period;
+
+ next_out = out + 1;
+ if (out->sensor_id != i)
+ continue;
+
+ /* Timestamp to start with */
+ older_timestamp = out->timestamp;
+
+ /* find next sample */
+ while (next_out < last_out && next_out->sensor_id != i)
+ next_out++;
+
+ if (next_out >= last_out) {
+ timestamp = current_timestamp;
+ } else {
+ timestamp = next_out->timestamp;
+ if (timestamp == older_timestamp) {
+ count++;
+ continue;
+ }
+ }
+
+ /*
+* The next sample has a new timestamp,
+* spread the unprocessed samples.
+*/
+ if (next_out < last_out)
+ count++;
+ time_period = div_s64(timestamp - older_timestamp,
+ count);
+
+ for (; older_unprocess_out <= out;
+ older_unprocess_out++) {
+ if (older_unprocess_out->sensor_id != i)
+ continue;
+ older_timestamp += time_period;
+ older_unprocess_out->timestamp =
+ older_timestamp;
+ }
+ count = 1;
+ /* The next_out sample has a valid timestamp, skip. */
+ next_out++;
+ older_unprocess_out = next_out;
+ }
[PATCH 01/13] mfd: cros_ec: Add sensor_count and make check_features public
Add a new function to return the number of MEMS sensors available in a
ChromeOS Embedded Controller.
It uses MOTIONSENSE_CMD_DUMP if available or a specific memory map ACPI
registers to find out.
Also, make check_features public as it can be useful for other drivers
to know whant the Embedded Controller supports.
Signed-off-by: Gwendal Grignou
---
drivers/mfd/cros_ec_dev.c | 61 -
include/linux/mfd/cros_ec.h | 17 +++
2 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 6e6dfd6c1871..3be80183ccaa 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -112,7 +112,7 @@ static const struct mfd_cell cros_ec_vbc_cells[] = {
{ .name = "cros-ec-vbc", }
};
-static int cros_ec_check_features(struct cros_ec_dev *ec, int feature)
+int cros_ec_check_features(struct cros_ec_dev *ec, int feature)
{
struct cros_ec_command *msg;
int ret;
@@ -143,12 +143,71 @@ static int cros_ec_check_features(struct cros_ec_dev *ec,
int feature)
return ec->features[feature / 32] & EC_FEATURE_MASK_0(feature);
}
+EXPORT_SYMBOL_GPL(cros_ec_check_features);
static void cros_ec_class_release(struct device *dev)
{
kfree(to_cros_ec_dev(dev));
}
+int cros_ec_get_sensor_count(struct cros_ec_dev *ec)
+{
+ /*
+* Issue a command to get the number of sensor reported.
+* If not supported, check for legacy mode.
+*/
+ int ret, sensor_count;
+ struct ec_params_motion_sense *params;
+ struct ec_response_motion_sense *resp;
+ struct cros_ec_command *msg;
+ struct cros_ec_device *ec_dev = ec->ec_dev;
+ u8 status;
+
+ msg = kzalloc(sizeof(struct cros_ec_command) +
+ max(sizeof(*params), sizeof(*resp)), GFP_KERNEL);
+ if (msg == NULL)
+ return -ENOMEM;
+
+ msg->version = 1;
+ msg->command = EC_CMD_MOTION_SENSE_CMD + ec->cmd_offset;
+ msg->outsize = sizeof(*params);
+ msg->insize = sizeof(*resp);
+
+ params = (struct ec_params_motion_sense *)msg->data;
+ params->cmd = MOTIONSENSE_CMD_DUMP;
+
+ ret = cros_ec_cmd_xfer(ec->ec_dev, msg);
+ if (ret < 0) {
+ sensor_count = ret;
+ } else if (msg->result != EC_RES_SUCCESS) {
+ sensor_count = -EPROTO;
+ } else {
+ resp = (struct ec_response_motion_sense *)msg->data;
+ sensor_count = resp->dump.sensor_count;
+ }
+ kfree(msg);
+
+ /*
+* Check legacy mode: Let's find out if sensors are accessible
+* via LPC interface.
+*/
+ if (sensor_count == -EPROTO &&
+ ec->cmd_offset == 0 &&
+ ec_dev->cmd_readmem) {
+ ret = ec_dev->cmd_readmem(ec_dev, EC_MEMMAP_ACC_STATUS,
+ 1, &status);
+ if ((ret >= 0) &&
+ (status & EC_MEMMAP_ACC_STATUS_PRESENCE_BIT)) {
+ /*
+* We have 2 sensors, one in the lid, one in the base.
+*/
+ sensor_count = 2;
+ }
+ }
+ return sensor_count;
+}
+EXPORT_SYMBOL_GPL(cros_ec_get_sensor_count);
+
static void cros_ec_sensors_register(struct cros_ec_dev *ec)
{
/*
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 61c2875c2a40..578e0bbcafdc 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -32,4 +32,21 @@ struct cros_ec_dev {
#define to_cros_ec_dev(dev) container_of(dev, struct cros_ec_dev, class_dev)
+/**
+ * cros_ec_check_features - Test for the presence of EC features
+ *
+ * Call this function to test whether the ChromeOS EC supports a feature.
+ *
+ * @ec_dev: EC device
+ * @msg: One of ec_feature_code values
+ * @return: 1 if supported, 0 if not
+ */
+int cros_ec_check_features(struct cros_ec_dev *ec, int feature);
+
+/*
+ * Return the number of MEMS sensors supported.
+ * Return < 0 in case of error.
+ */
+int cros_ec_get_sensor_count(struct cros_ec_dev *ec);
+
#endif /* __LINUX_MFD_CROS_EC_H */
--
2.23.0.351.gc4317032e6-goog
[PATCH 12/13] iio: cros_ec: Report hwfifo_watermark_max
Report the maximum amount of sample the EC can hold.
This is not tunable, but can be useful for application to find out the
maximum amount of time it can sleep when hwfifo_timeout is set to a
large number.
Signed-off-by: Gwendal Grignou
---
.../cros_ec_sensors/cros_ec_sensors_core.c| 35 +--
.../linux/iio/common/cros_ec_sensors_core.h | 4 ++-
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index a31a761e3a81..a32260c9bc09 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -23,6 +23,12 @@
#include
#include
+/*
+ * Hard coded to the first device to support sensor fifo. The EC has a 2048
+ * byte fifo and will trigger an interrupt when fifo is 2/3 full.
+ */
+#define CROS_EC_FIFO_SIZE (2048 * 2 / 3)
+
static char *cros_ec_loc[] = {
[MOTIONSENSE_LOC_BASE] = "base",
[MOTIONSENSE_LOC_LID] = "lid",
@@ -56,8 +62,15 @@ static int cros_ec_get_host_cmd_version_mask(struct
cros_ec_device *ec_dev,
static void get_default_min_max_freq(enum motionsensor_type type,
u32 *min_freq,
-u32 *max_freq)
+u32 *max_freq,
+u32 *max_fifo_events)
{
+ /*
+* We don't know fifo size, set to size previously used by older
+* hardware.
+*/
+ *max_fifo_events = CROS_EC_FIFO_SIZE;
+
switch (type) {
case MOTIONSENSE_TYPE_ACCEL:
case MOTIONSENSE_TYPE_GYRO:
@@ -122,6 +135,7 @@ static ssize_t cros_ec_sensor_set_report_latency(struct
device *dev,
return len;
}
+
static ssize_t cros_ec_sensor_get_report_latency(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -149,8 +163,22 @@ static IIO_DEVICE_ATTR(hwfifo_timeout, 0644,
cros_ec_sensor_get_report_latency,
cros_ec_sensor_set_report_latency, 0);
+static ssize_t hwfifo_watermark_max_show(
+ struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
+
+ return sprintf(buf, "%d\n", st->fifo_max_event_count);
+}
+
+static IIO_DEVICE_ATTR_RO(hwfifo_watermark_max, 0);
+
static const struct attribute *cros_ec_sensor_fifo_attributes[] = {
&iio_dev_attr_hwfifo_timeout.dev_attr.attr,
+ &iio_dev_attr_hwfifo_watermark_max.dev_attr.attr,
NULL,
};
@@ -251,12 +279,15 @@ int cros_ec_sensors_core_init(struct platform_device
*pdev,
if (state->msg->version < 3) {
get_default_min_max_freq(state->resp->info.type,
&state->frequencies[1],
-&state->frequencies[2]);
+&state->frequencies[2],
+&state->fifo_max_event_count);
} else {
state->frequencies[1] =
state->resp->info_3.min_frequency;
state->frequencies[2] =
state->resp->info_3.max_frequency;
+ state->fifo_max_event_count =
+ state->resp->info_3.fifo_max_event_count;
}
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE_FIFO)) {
diff --git a/include/linux/iio/common/cros_ec_sensors_core.h
b/include/linux/iio/common/cros_ec_sensors_core.h
index 60f78f0e4884..2c6acbde0d02 100644
--- a/include/linux/iio/common/cros_ec_sensors_core.h
+++ b/include/linux/iio/common/cros_ec_sensors_core.h
@@ -54,7 +54,8 @@ typedef irqreturn_t (*cros_ec_sensors_capture_t)(int irq,
void *p);
* the timestamp. The timestamp is always last and
* is always 8-byte aligned.
* @read_ec_sensors_data: function used for accessing sensors values
- * @cuur_sampl_freq: current sampling period
+ * @curr_sampl_freq: current sampling period
+ * @fifo_max_event_count: Size of the EC sensor FIFO
*/
struct cros_ec_sensors_core_state {
struct cros_ec_device *ec;
@@ -78,6 +79,7 @@ struct cros_ec_sensors_core_state {
unsigned long scan_mask, s16 *data);
int curr_sampl_freq;
+ u32 fifo_max_event_count;
/* Table of known available frequencies : 0, Min and Max in mHz */
int frequencies[3];
--
2.23.0.351.gc4317032e6-goog
[PATCH 03/13] platform/mfd:iio: cros_ec: Register sensor through sensorhub
- Add sensorhub include file
- Remove duplicate code in mfd, since mfd just register
cros_ec_sensorhub if at least one sensor is present
- Change iio cros_ec driver to get the pointer to the cros_ec_dev
through cros_ec_sensorhub.
Signed-off-by: Gwendal Grignou
---
drivers/iio/accel/cros_ec_accel_legacy.c | 4 +-
.../common/cros_ec_sensors/cros_ec_sensors.c | 4 +-
.../cros_ec_sensors/cros_ec_sensors_core.c| 4 +-
drivers/iio/light/cros_ec_light_prox.c| 6 +-
drivers/mfd/cros_ec_dev.c | 203 ++
drivers/platform/chrome/cros_ec_sensorhub.c | 2 +-
include/linux/platform_data/cros_ec_proto.h | 8 -
.../linux/platform_data/cros_ec_sensorhub.h | 8 +
8 files changed, 34 insertions(+), 205 deletions(-)
diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
b/drivers/iio/accel/cros_ec_accel_legacy.c
index fcc3f999e482..c9af6fa0670d 100644
--- a/drivers/iio/accel/cros_ec_accel_legacy.c
+++ b/drivers/iio/accel/cros_ec_accel_legacy.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#define DRV_NAME "cros-ec-accel-legacy"
@@ -163,7 +164,8 @@ static const struct iio_chan_spec
cros_ec_accel_legacy_channels[] = {
static int cros_ec_accel_legacy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct cros_ec_dev *ec = dev_get_drvdata(dev->parent);
+ struct cros_ec_sensorhub *sensor_hub = dev_get_drvdata(dev->parent);
+ struct cros_ec_dev *ec = sensor_hub->ec;
struct iio_dev *indio_dev;
struct cros_ec_sensors_core_state *state;
int ret;
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
index a6987726eeb8..5bd6f54afc42 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -222,7 +223,8 @@ static const struct iio_info ec_sensors_info = {
static int cros_ec_sensors_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
+ struct cros_ec_sensorhub *sensor_hub = dev_get_drvdata(dev->parent);
+ struct cros_ec_dev *ec_dev = sensor_hub->ec;
struct iio_dev *indio_dev;
struct cros_ec_sensors_state *state;
struct iio_chan_spec *channel;
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index d2609e6feda4..81a7f692de2f 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
static char *cros_ec_loc[] = {
@@ -88,7 +89,8 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
{
struct device *dev = &pdev->dev;
struct cros_ec_sensors_core_state *state = iio_priv(indio_dev);
- struct cros_ec_dev *ec = dev_get_drvdata(pdev->dev.parent);
+ struct cros_ec_sensorhub *sensor_hub = dev_get_drvdata(dev->parent);
+ struct cros_ec_dev *ec = sensor_hub->ec;
struct cros_ec_sensor_platform *sensor_platform = dev_get_platdata(dev);
u32 ver_mask;
int ret, i;
diff --git a/drivers/iio/light/cros_ec_light_prox.c
b/drivers/iio/light/cros_ec_light_prox.c
index c5263b563fc1..205effc1f404 100644
--- a/drivers/iio/light/cros_ec_light_prox.c
+++ b/drivers/iio/light/cros_ec_light_prox.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -169,13 +170,14 @@ static const struct iio_info cros_ec_light_prox_info = {
static int cros_ec_light_prox_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct cros_ec_dev *ec_dev = dev_get_drvdata(dev->parent);
+ struct cros_ec_sensorhub *sensor_hub = dev_get_drvdata(dev->parent);
+ struct cros_ec_dev *ec = sensor_hub->ec;
struct iio_dev *indio_dev;
struct cros_ec_light_prox_state *state;
struct iio_chan_spec *channel;
int ret;
- if (!ec_dev || !ec_dev->ec_dev) {
+ if (!ec || !ec->ec_dev) {
dev_warn(dev, "No CROS EC device found.\n");
return -EINVAL;
}
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 3be80183ccaa..3a583d3503ca 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -78,6 +78,10 @@ static const struct mfd_cell cros_ec_rtc_cells[] = {
{ .name = "cros-ec-rtc", },
};
+static const struct mfd_cell cros_ec_sensorhub_cells[] = {
+ { .name = "cros-ec-sensorhub", },
+};
+
static const struct mfd_cell cros_usbpd_charger_cells[] = {
{ .name = "cros-usbpd-charger", },
{ .name = "cros-usbpd-logger", },
@@ -208,192 +212,6 @@ int cros_ec_
[PATCH 06/13] platform: chrome: cros_ec: handle MKBP more events flag
From: Enrico Granata
The ChromeOS EC has support for signaling to the host that
a single IRQ can serve multiple MKBP events.
Doing this serves an optimization purpose, as it minimizes the
number of round-trips into the interrupt handling machinery, and
it proves beneficial to sensor timestamping as it keeps the desired
synchronization of event times between the two processors.
This patch adds kernel support for this EC feature, allowing the
ec_irq to loop until all events have been served.
Signed-off-by: Enrico Granata
Signed-off-by: Gwendal Grignou
---
drivers/platform/chrome/cros_ec.c | 33 +
drivers/platform/chrome/cros_ec_proto.c | 51 -
include/linux/platform_data/cros_ec_proto.h | 7 ++-
3 files changed, 57 insertions(+), 34 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec.c
b/drivers/platform/chrome/cros_ec.c
index 9c8dc7cdb2b7..4adc007c357c 100644
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -46,25 +46,38 @@ static irqreturn_t ec_irq_handler(int irq, void *data)
return IRQ_WAKE_THREAD;
}
-static irqreturn_t ec_irq_thread(int irq, void *data)
+static bool ec_handle_event(struct cros_ec_device *ec_dev)
{
- struct cros_ec_device *ec_dev = data;
bool wake_event = true;
- int ret;
+ bool ec_has_more_events = false;
+ int ret = cros_ec_get_next_event(ec_dev, &wake_event);
- ret = cros_ec_get_next_event(ec_dev, &wake_event);
+ if (ec_dev->mkbp_event_supported) {
+ ec_has_more_events = (ret > 0) &&
+ (ec_dev->event_data.event_type &
+ EC_MKBP_HAS_MORE_EVENTS);
+ }
- /*
-* Signal only if wake host events or any interrupt if
-* cros_ec_get_next_event() returned an error (default value for
-* wake_event is true)
-*/
- if (wake_event && device_may_wakeup(ec_dev->dev))
+ if (device_may_wakeup(ec_dev->dev) && wake_event)
pm_wakeup_event(ec_dev->dev, 0);
if (ret > 0)
blocking_notifier_call_chain(&ec_dev->event_notifier,
0, ec_dev);
+
+ return ec_has_more_events;
+
+}
+
+static irqreturn_t ec_irq_thread(int irq, void *data)
+{
+ struct cros_ec_device *ec_dev = data;
+ bool ec_has_more_events;
+
+ do {
+ ec_has_more_events = ec_handle_event(ec_dev);
+ } while (ec_has_more_events);
+
return IRQ_HANDLED;
}
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index f659f96bda12..70e6d6c93b8d 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -425,10 +425,14 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev)
ret = cros_ec_get_host_command_version_mask(ec_dev,
EC_CMD_GET_NEXT_EVENT,
&ver_mask);
- if (ret < 0 || ver_mask == 0)
+ if (ret < 0 || ver_mask == 0) {
ec_dev->mkbp_event_supported = 0;
- else
- ec_dev->mkbp_event_supported = 1;
+ dev_info(ec_dev->dev, "MKBP not supported\n");
+ } else {
+ ec_dev->mkbp_event_supported = fls(ver_mask);
+ dev_info(ec_dev->dev, "MKBP support version %u\n",
+ ec_dev->mkbp_event_supported - 1);
+ }
/* Probe if host sleep v1 is supported for S0ix failure detection. */
ret = cros_ec_get_host_command_version_mask(ec_dev,
@@ -519,6 +523,7 @@ EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
static int get_next_event_xfer(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg,
+ struct ec_response_get_next_event_v1 *event,
int version, uint32_t size)
{
int ret;
@@ -531,7 +536,7 @@ static int get_next_event_xfer(struct cros_ec_device
*ec_dev,
ret = cros_ec_cmd_xfer(ec_dev, msg);
if (ret > 0) {
ec_dev->event_size = ret - 1;
- memcpy(&ec_dev->event_data, msg->data, ret);
+ ec_dev->event_data = *event;
}
return ret;
@@ -539,30 +544,29 @@ static int get_next_event_xfer(struct cros_ec_device
*ec_dev,
static int get_next_event(struct cros_ec_device *ec_dev)
{
- u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
- struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
- static int cmd_version = 1;
- int ret;
+ struct {
+ struct cros_ec_command msg;
+ struct ec_response_get_next_event_v1 event;
+ } __packed buf;
+ struct cros_ec_command *msg = &buf.msg;
+ struct ec_response_get_next_event_v1 *event = &buf.event;
+ const int cmd_version = ec_dev-
[PATCH 11/13] iio: cros_ec: Expose hwfifo_timeout
Expose EC sampling rate through buffer/hwfifo_timeout.
Rename frequency to sampling_frequency to match IIO ABI.
Signed-off-by: Gwendal Grignou
---
.../common/cros_ec_sensors/cros_ec_sensors.c | 1 -
.../cros_ec_sensors/cros_ec_sensors_core.c| 110 +-
drivers/iio/light/cros_ec_light_prox.c| 3 +-
drivers/iio/pressure/cros_ec_baro.c | 3 +-
4 files changed, 81 insertions(+), 36 deletions(-)
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
index b78a942ac8e5..95a4b4cf8f87 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
@@ -255,7 +255,6 @@ static int cros_ec_sensors_probe(struct platform_device
*pdev)
BIT(IIO_CHAN_INFO_CALIBSCALE);
channel->info_mask_shared_by_all =
BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_FREQUENCY) |
BIT(IIO_CHAN_INFO_SAMP_FREQ);
channel->info_mask_shared_by_all_available =
BIT(IIO_CHAN_INFO_SAMP_FREQ);
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index c4c37c6df301..a31a761e3a81 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -84,6 +85,75 @@ static void get_default_min_max_freq(enum motionsensor_type
type,
}
}
+static int cros_ec_sensor_set_ec_rate(struct cros_ec_sensors_core_state *st,
+ int rate)
+{
+ int ret;
+
+ mutex_lock(&st->cmd_lock);
+ st->param.cmd = MOTIONSENSE_CMD_EC_RATE;
+ st->param.ec_rate.data = rate;
+ ret = cros_ec_motion_send_host_cmd(st, 0);
+ if (ret == 0)
+ st->curr_sampl_freq = rate;
+ mutex_unlock(&st->cmd_lock);
+ return ret;
+}
+
+static ssize_t cros_ec_sensor_set_report_latency(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
+ int integer, fract, ret;
+ int latency;
+
+ ret = iio_str_to_fixpoint(buf, 10, &integer, &fract);
+ if (ret)
+ return ret;
+
+ /* EC rate is in ms. */
+ latency = integer * 1000 + fract / 1000;
+ ret = cros_ec_sensor_set_ec_rate(st, latency);
+ if (ret < 0)
+ return ret;
+
+ return len;
+}
+
+static ssize_t cros_ec_sensor_get_report_latency(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
+ int latency, ret;
+
+ mutex_lock(&st->cmd_lock);
+ st->param.cmd = MOTIONSENSE_CMD_EC_RATE;
+ st->param.ec_rate.data = EC_MOTION_SENSE_NO_VALUE;
+
+ ret = cros_ec_motion_send_host_cmd(st, 0);
+ latency = st->resp->ec_rate.ret;
+ mutex_unlock(&st->cmd_lock);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%d.%06u\n",
+ latency / 1000,
+ (latency % 1000) * 1000);
+}
+
+static IIO_DEVICE_ATTR(hwfifo_timeout, 0644,
+ cros_ec_sensor_get_report_latency,
+ cros_ec_sensor_set_report_latency, 0);
+
+static const struct attribute *cros_ec_sensor_fifo_attributes[] = {
+ &iio_dev_attr_hwfifo_timeout.dev_attr.attr,
+ NULL,
+};
+
int cros_ec_sensors_push_data(
struct iio_dev *indio_dev,
s16 *data,
@@ -194,6 +264,9 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
if (!buffer)
return -ENOMEM;
+ iio_buffer_set_attrs(buffer,
+cros_ec_sensor_fifo_attributes);
+
iio_device_attach_buffer(indio_dev, buffer);
indio_dev->modes = INDIO_BUFFER_SOFTWARE;
ret = cros_ec_sensorhub_register_push_data(
@@ -553,18 +626,6 @@ int cros_ec_sensors_core_read(struct
cros_ec_sensors_core_state *st,
switch (mask) {
case IIO_CHAN_INFO_SAMP_FREQ:
- st->param.cmd = MOTIONSENSE_CMD_EC_RATE;
- st->param.ec_rate.data =
- EC_MOTION_SENSE_NO_VALUE;
-
- ret = cros_ec_motion_send_host_cmd(st, 0);
- if (ret)
-
[PATCH 13/13] iio: cros_ec: Use Hertz as unit for sampling frequency
To be compliant with other sensors, set and get sensor sampling
frequency in Hz, not mHz.
Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose
cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou
---
.../cros_ec_sensors/cros_ec_sensors_core.c| 32 +++
.../linux/iio/common/cros_ec_sensors_core.h | 6 ++--
2 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index a32260c9bc09..f7e6827bd4cb 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -227,6 +227,7 @@ int cros_ec_sensors_core_init(struct platform_device *pdev,
struct cros_ec_sensor_platform *sensor_platform = dev_get_platdata(dev);
struct iio_buffer *buffer;
u32 ver_mask;
+ int frequencies[ARRAY_SIZE(state->frequencies) / 2] = { 0 };
int ret, i;
platform_set_drvdata(pdev, indio_dev);
@@ -275,20 +276,22 @@ int cros_ec_sensors_core_init(struct platform_device
*pdev,
state->calib[i].scale = MOTION_SENSE_DEFAULT_SCALE;
/* 0 is a correct value used to stop the device */
- state->frequencies[0] = 0;
if (state->msg->version < 3) {
get_default_min_max_freq(state->resp->info.type,
-&state->frequencies[1],
-&state->frequencies[2],
+&frequencies[1],
+&frequencies[2],
&state->fifo_max_event_count);
} else {
- state->frequencies[1] =
- state->resp->info_3.min_frequency;
- state->frequencies[2] =
- state->resp->info_3.max_frequency;
+ frequencies[1] = state->resp->info_3.min_frequency;
+ frequencies[2] = state->resp->info_3.max_frequency;
state->fifo_max_event_count =
state->resp->info_3.fifo_max_event_count;
}
+ for (i = 0; i < ARRAY_SIZE(frequencies); i++) {
+ state->frequencies[2 * i] = frequencies[i] / 1000;
+ state->frequencies[2 * i + 1] =
+ (frequencies[i] % 1000) * 1000;
+ }
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE_FIFO)) {
buffer = devm_iio_kfifo_allocate(dev);
@@ -653,7 +656,7 @@ int cros_ec_sensors_core_read(struct
cros_ec_sensors_core_state *st,
struct iio_chan_spec const *chan,
int *val, int *val2, long mask)
{
- int ret;
+ int ret, frequency;
switch (mask) {
case IIO_CHAN_INFO_SAMP_FREQ:
@@ -665,8 +668,10 @@ int cros_ec_sensors_core_read(struct
cros_ec_sensors_core_state *st,
if (ret)
break;
- *val = st->resp->sensor_odr.ret;
- ret = IIO_VAL_INT;
+ frequency = st->resp->sensor_odr.ret;
+ *val = frequency / 1000;
+ *val2 = (frequency % 1000) * 1000;
+ ret = IIO_VAL_INT_PLUS_MICRO;
break;
default:
ret = -EINVAL;
@@ -690,7 +695,7 @@ int cros_ec_sensors_core_read_avail(struct iio_dev
*indio_dev,
case IIO_CHAN_INFO_SAMP_FREQ:
*length = ARRAY_SIZE(state->frequencies);
*vals = (const int *)&state->frequencies;
- *type = IIO_VAL_INT;
+ *type = IIO_VAL_INT_PLUS_MICRO;
return IIO_AVAIL_LIST;
}
@@ -702,12 +707,13 @@ int cros_ec_sensors_core_write(struct
cros_ec_sensors_core_state *st,
struct iio_chan_spec const *chan,
int val, int val2, long mask)
{
- int ret;
+ int ret, frequency;
switch (mask) {
case IIO_CHAN_INFO_SAMP_FREQ:
+ frequency = val * 1000 + val2 / 1000;
st->param.cmd = MOTIONSENSE_CMD_SENSOR_ODR;
- st->param.sensor_odr.data = val;
+ st->param.sensor_odr.data = frequency;
/* Always roundup, so caller gets at least what it asks for. */
st->param.sensor_odr.roundup = 1;
diff --git a/include/linux/iio/common/cros_ec_sensors_core.h
b/include/linux/iio/common/cros_ec_sensors_core.h
index 2c6acbde0d02..46d5110b2fe4 100644
--- a/include/linux/iio/common/cros_ec_sensors_core.h
+++ b/include/linux/iio/common/cros_ec_sensors_core.h
@@ -56,6 +56,8 @@ typedef irqreturn_t (*cros_ec_sensors_capture_t)(int irq,
void *
[PATCH 05/13] platform: chrome: cros_ec: Do not attempt to register a non-positive IRQ number
From: Enrico Granata
Add a layer of sanity checking to cros_ec_register against attempting to
register IRQ values that are not strictly greater than 0.
Signed-off-by: Enrico Granata
Signed-off-by: Enrico Granata
Signed-off-by: Gwendal Grignou
---
drivers/platform/chrome/cros_ec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec.c
b/drivers/platform/chrome/cros_ec.c
index f49eb1d1e3cd..9c8dc7cdb2b7 100644
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -146,7 +146,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return err;
}
- if (ec_dev->irq) {
+ if (ec_dev->irq > 0) {
err = devm_request_threaded_irq(
dev, ec_dev->irq, ec_irq_handler,
ec_irq_thread, IRQF_TRIGGER_LOW | IRQF_ONESHOT,
--
2.23.0.351.gc4317032e6-goog
[PATCH 10/13] iio: cros_ec: Use triggered buffer only when EC does not support FIFO
When EC supports FIFO, the samples will flow from the kernel by
themselves.
When no FIFO, the user space app needs to call trigger_new, or better
register a high precision timer.
Signed-off-by: Gwendal Grignou
---
drivers/iio/accel/cros_ec_accel_legacy.c | 8 +--
.../cros_ec_sensors/cros_ec_lid_angle.c | 2 +-
.../common/cros_ec_sensors/cros_ec_sensors.c | 8 +--
.../cros_ec_sensors/cros_ec_sensors_core.c| 61 +--
drivers/iio/light/cros_ec_light_prox.c| 8 +--
drivers/iio/pressure/cros_ec_baro.c | 8 +--
.../linux/iio/common/cros_ec_sensors_core.h | 16 -
7 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
b/drivers/iio/accel/cros_ec_accel_legacy.c
index 591c0d962c44..d607fbc52c95 100644
--- a/drivers/iio/accel/cros_ec_accel_legacy.c
+++ b/drivers/iio/accel/cros_ec_accel_legacy.c
@@ -179,7 +179,8 @@ static int cros_ec_accel_legacy_probe(struct
platform_device *pdev)
if (!indio_dev)
return -ENOMEM;
- ret = cros_ec_sensors_core_init(pdev, indio_dev, true);
+ ret = cros_ec_sensors_core_init(pdev, indio_dev, true,
+ cros_ec_sensors_capture, cros_ec_sensors_push_data);
if (ret)
return ret;
@@ -199,11 +200,6 @@ static int cros_ec_accel_legacy_probe(struct
platform_device *pdev)
state->sign[CROS_EC_SENSOR_Z] = -1;
}
- ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
- cros_ec_sensors_capture, NULL);
- if (ret)
- return ret;
-
return devm_iio_device_register(dev, indio_dev);
}
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
index 1dcc2a16ab2d..e30a59fcf0f9 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
@@ -97,7 +97,7 @@ static int cros_ec_lid_angle_probe(struct platform_device
*pdev)
if (!indio_dev)
return -ENOMEM;
- ret = cros_ec_sensors_core_init(pdev, indio_dev, false);
+ ret = cros_ec_sensors_core_init(pdev, indio_dev, false, NULL, NULL);
if (ret)
return ret;
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
index a88dd8deade9..b78a942ac8e5 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
@@ -239,7 +239,8 @@ static int cros_ec_sensors_probe(struct platform_device
*pdev)
if (!indio_dev)
return -ENOMEM;
- ret = cros_ec_sensors_core_init(pdev, indio_dev, true);
+ ret = cros_ec_sensors_core_init(pdev, indio_dev, true,
+ cros_ec_sensors_capture, cros_ec_sensors_push_data);
if (ret)
return ret;
@@ -301,11 +302,6 @@ static int cros_ec_sensors_probe(struct platform_device
*pdev)
else
state->core.read_ec_sensors_data = cros_ec_sensors_read_cmd;
- ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
- cros_ec_sensors_capture, NULL);
- if (ret)
- return ret;
-
return devm_iio_device_register(dev, indio_dev);
}
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index 43eb1d42820e..c4c37c6df301 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -83,15 +84,50 @@ static void get_default_min_max_freq(enum motionsensor_type
type,
}
}
+int cros_ec_sensors_push_data(
+ struct iio_dev *indio_dev,
+ s16 *data,
+ s64 timestamp)
+{
+ struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
+ s16 *out;
+ unsigned int i;
+
+ /*
+* It can happen if we get a samples before the iio device is fully
+* registered.
+*/
+ if (!st)
+ return 0;
+
+ /* Ignore samples if the buffer is not set. */
+ if (!indio_dev->active_scan_mask)
+ return 0;
+
+ out = (s16 *)st->samples;
+ for_each_set_bit(i,
+indio_dev->active_scan_mask,
+indio_dev->masklength) {
+ *out = data[i];
+ out++;
+ }
+ iio_push_to_buffers_with_timestamp(indio_dev, st->samples, timestamp);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data);
+
int cros_ec_sensors_core_init(struct platform_device *pdev,
struct iio_dev *indio_dev,
- bool physical_device)
+
Re: [GIT PULL] Modules updates for v5.4
The pull request you sent on Sun, 22 Sep 2019 17:28:09 +0200: > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git > tags/modules-for-v5.4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e0703556644a531e50b5dc61b9f6ea83af5f6604 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] ARM: at91: Documentation: update the sama5d3 and armv7m datasheets
On 19/08/2019 17:12:19+0200, Nicolas Ferre wrote: > Update SAMA5D3 and SAM E70/S70/V70/V71 Family SoC Datasheets. URL are > updated in Microchip documentation. > > Signed-off-by: Nicolas Ferre > --- > Documentation/arm/microchip.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Applied, thanks. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [Patch v3 00/13] media: am437x-vpfe: overdue maintenance
On Fri, Sep 20, 2019 at 6:03 PM Benoit Parrot wrote: > > This patch series is a collection of patches we have been carrying for a > while. > > A few patches do fix actual bug and v4l2-compliance errors/warnings. > Other are drivers re-work to simplify/clarify the code for easier > maintenance. > > We also include the SPDX Licensing update which seemed to have been > missed by the global script thus far. > > Changes since v2: > - Rename VPFE_MAX_ACTIVE_FMT to VPFE_NUM_FORMATS and corrected the > comments > - Move the "Remove print_fourcc helper" patch to the end of the series > and rebase it on the pending v4l2_fourcc_conv macros patches > > Changes since v1: > - Address review comment from Joe, Hans and Prabhakar > - Cleaned-up the function entry debug log > - Split off the pcr change into its own patch > - Rework/combine two patches but remove code churn > - fix miscellaneous typos > > = > > v4l2-compliance SHA: 5b168dc8473911227890526bad26553d9e8ff81b, 32 bits > > Compliance test for vpfe device /dev/video0: > > Driver Info: > Driver name : vpfe > Card type: TI AM437x VPFE > Bus info : platform:vpfe 48326000.vpfe > Driver version : 5.3.0 > Capabilities : 0x8521 > Vide o Capture > Read/Write > Streaming > Extended Pix Format > D evice Capabilities > Device Caps : 0x0521 > Video Capt ure > Read/Write > Streaming > Extended Pix Format > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second /dev/video0 open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > test for unlimited opens: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Control ioctls (Input 0): > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 3 Private Controls: 0 > > Format ioctls (Input 0): > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > fail: v4l2-test-formats.cpp(1419): > node->frmsizes_count[pixfmt] > 1 > test Cropping: FAIL > test Composing: OK (Not Supported) > test Scaling: OK (Not Supported) > > Codec ioctls (Input 0): > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls (Input 0): > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK > test Requests: OK (Not Supported) > > Test input 0: > > Streaming ioctls: > test read/write: OK > test blocking wait: OK > test MMAP (no poll): OK > test MMAP (select): OK > test MMAP (epoll): OK > test USERPTR (no poll): OK (Not Supported) > test USERPTR (select): OK (Not Supported) > test DMABUF: Cannot test, specify --expbuf-device > > Total for vpfe device /dev/video0: 51, Succeeded: 50, Failed: 1, Warnings: 0 > > > Benoit Parrot (12): > media: am437x-vpfe: Fix missing first line > media: am437x-vpfe: Rework ISR routine for clarity > media: am437x-vpfe: Wait for end of frame before tear-down > media: am437x-vpfe: fix start streaming error path > media: am437x-vpfe: Streamlined vb2 buffer
Re: [GIT PULL] Modules updates for v5.4
On Sun, Sep 22, 2019 at 8:28 AM Jessica Yu wrote: > > The main bulk of this pull request introduces a new exported symbol > namespaces feature. Hmm. So I merged this, and felt that I tested my merge resolution fairly well, and then pushed it out. But during more extensive testing for special cases, I notice that MODULE_IMPORT_NS() does not work at all when modules are disabled. In particular, it causes errors like this: drivers/usb/storage/uas.c:1222:1: warning: data definition has no type or storage class 1222 | MODULE_IMPORT_NS(USB_STORAGE); | ^~~~ because without modules, MODULE_IMPORT_NS() doesn't get #define'd at all. This is not a merge error - it's an error in the original. Tssk. I hate finding stupid bugs like this myself. Particularly when I find them quickly from a simple "what if" test. Yes, some of it goes to just bad luck with linux-next, but some of this is simply people not thinking about different cases. Tssk tssk. Linus
Re: [GIT PULL] MIPS changes
On Sat, Sep 21, 2019 at 4:10 PM Paul Burton wrote:
>
> Here are the main MIPS changes for v5.4; please pull.
Hmm. I pulled and because initial tests didn't show any issues, I
already pushed out.
But some unrelated further testing then shows that this:
> Florian Fainelli (2):
> firmware: bcm47xx_nvram: Correct size_t printf format
> firmware: bcm47xx_nvram: Allow COMPILE_TEST
causes problems, and commit feb4eb060c3a ("firmware: bcm47xx_nvram:
Correct size_t printf format") is buggy:
drivers/firmware/broadcom/bcm47xx_nvram.c: In function ‘nvram_init’:
drivers/firmware/broadcom/bcm47xx_nvram.c:151: warning: format ‘%zu’
expects argument of type ‘size_t’, but argument 2 has type ‘u32’ {aka
‘unsigned int’} [-Wformat=]
and the change to use %zu was completely wrong.
It prints out 'header.len', which is an u32, not nvram_len which is a size_t.
Tssk tssk.
I've fixed it in my tree, but this should have shown up in linux-next,
or in MIPS testing. The process clearly failed.
Linus
[PATCH AUTOSEL 5.3 003/203] cpufreq: ap806: Add NULL check after kcalloc
From: Hariprasad Kelam [ Upstream commit 3355c91b79394593ebbb197c8e930a91826f4ff3 ] Add NULL check after kcalloc. Fix below issue reported by coccicheck ./drivers/cpufreq/armada-8k-cpufreq.c:138:1-12: alloc with no test, possible model on line 151 Signed-off-by: Hariprasad Kelam Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/armada-8k-cpufreq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpufreq/armada-8k-cpufreq.c b/drivers/cpufreq/armada-8k-cpufreq.c index 988ebc326bdbb..39e34f5066d3d 100644 --- a/drivers/cpufreq/armada-8k-cpufreq.c +++ b/drivers/cpufreq/armada-8k-cpufreq.c @@ -136,6 +136,8 @@ static int __init armada_8k_cpufreq_init(void) nb_cpus = num_possible_cpus(); freq_tables = kcalloc(nb_cpus, sizeof(*freq_tables), GFP_KERNEL); + if (!freq_tables) + return -ENOMEM; cpumask_copy(&cpus, cpu_possible_mask); /* -- 2.20.1
