From: "misono.tomohiro@fujitsu.com" <misono.tomohiro@fujitsu.com> To: 'Arnd Bergmann' <arnd@kernel.org> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>, SoC Team <soc@kernel.org>, Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net> Subject: RE: [PATCH 03/10] soc: fujitsu: hwb: Add IOC_BB_ALLOC ioctl Date: Tue, 12 Jan 2021 11:02:27 +0000 [thread overview] Message-ID: <OSBPR01MB458227B345C445CBF342648DE5AA0@OSBPR01MB4582.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <CAK8P3a39ZObFDOdXQCPFyEy_nvoyaE8RBv3W+HMeBs=6OazJ6g@mail.gmail.com> > On Fri, Jan 8, 2021 at 11:52 AM Misono Tomohiro > <misono.tomohiro@jp.fujitsu.com> wrote: > > > +static void write_init_sync_reg(void *args) > > +{ > > + struct init_sync_args *sync_args = (struct init_sync_args *)args; > > + > > + switch (sync_args->bb) { > > + case 0: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB0_EL1); > > + break; > > + case 1: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB1_EL1); > > + break; > > + case 2: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB2_EL1); > > + break; > > + case 3: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB3_EL1); > > + break; > > + case 4: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB4_EL1); > > + break; > > + case 5: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB5_EL1); > > + break; > > + } > > +} > > (minor style comment > > I think this could be simplified into a single write_sysreg_s() with the > register number calculated based on sync_args->bb, rather than duplicating > the same three lines six times. I think msr/mrs instructions needs register names at compile time so it cannot be calculate dynamically. Or am I misunderstood? > > +static int ioc_bb_alloc(struct file *filp, void __user *argp) > > +{ > > + struct hwb_private_data *pdata = (struct hwb_private_data *)filp->private_data; > > A slightly better way to write the ioctl command specific functions > is to just give the argument the correct type (struct > fujitsu_hwb_ioc_bb_ctl __user*) > instead of 'void __user *', to avoid the cast. > > Similarly, as you don't use 'filp' itself, just pass the struct hwb_private_data > pointer as the first argument. thanks, I will follow this advise. > > @@ -164,6 +386,7 @@ static int fujitsu_hwb_dev_open(struct inode *inode, struct file *filp) > > static const struct file_operations fujitsu_hwb_dev_fops = { > > .owner = THIS_MODULE, > > .open = fujitsu_hwb_dev_open, > > + .unlocked_ioctl = fujitsu_hwb_dev_ioctl, > > }; > > All drivers with an ioctl interface should work in compat mode as well, > so please add a > > .compat_ioctl = compat_ptr_ioctl; A64FX does not support 32-bit mode (aarch32 state). So I think unlockd_ioctl is enough or is it better to use compat_ioctl anyway? > > > +#define __FUJITSU_IOCTL_MAGIC 'F' > > It's hard to find a non-conflicting range of ioctl numbers, but > it would be good to note the conflict in > > Documentation/userspace-api/ioctl/ioctl-number.rst > > The 'F' range is also used in framebuffer drivers. I didn't notice this, thanks for pointing out. Again, thanks for all the reviews/comments. Tomohiro > > +/* ioctl definitions for hardware barrier driver */ > > +struct fujitsu_hwb_ioc_bb_ctl { > > + __u8 cmg; > > + __u8 bb; > > + __u8 unused[2]; > > + __u32 size; > > + unsigned long __user *pemask; > > +}; > > However, this structure layout is incompatible with 32-bit user > space because of the indirect pointer. See > Documentation/driver-api/ioctl.rst for how to encode a > pointer in a __u64 member.
WARNING: multiple messages have this Message-ID (diff)
From: "misono.tomohiro@fujitsu.com" <misono.tomohiro@fujitsu.com> To: 'Arnd Bergmann' <arnd@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de>, Catalin Marinas <catalin.marinas@arm.com>, SoC Team <soc@kernel.org>, Olof Johansson <olof@lixom.net>, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: RE: [PATCH 03/10] soc: fujitsu: hwb: Add IOC_BB_ALLOC ioctl Date: Tue, 12 Jan 2021 11:02:27 +0000 [thread overview] Message-ID: <OSBPR01MB458227B345C445CBF342648DE5AA0@OSBPR01MB4582.jpnprd01.prod.outlook.com> (raw) Message-ID: <20210112110227.azt2Sor7ElllwvCzzG-Y2-y4paTLany1UfYGy0yp0DU@z> (raw) In-Reply-To: <CAK8P3a39ZObFDOdXQCPFyEy_nvoyaE8RBv3W+HMeBs=6OazJ6g@mail.gmail.com> > On Fri, Jan 8, 2021 at 11:52 AM Misono Tomohiro > <misono.tomohiro@jp.fujitsu.com> wrote: > > > +static void write_init_sync_reg(void *args) > > +{ > > + struct init_sync_args *sync_args = (struct init_sync_args *)args; > > + > > + switch (sync_args->bb) { > > + case 0: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB0_EL1); > > + break; > > + case 1: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB1_EL1); > > + break; > > + case 2: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB2_EL1); > > + break; > > + case 3: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB3_EL1); > > + break; > > + case 4: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB4_EL1); > > + break; > > + case 5: > > + write_sysreg_s(sync_args->val, FHWB_INIT_SYNC_BB5_EL1); > > + break; > > + } > > +} > > (minor style comment > > I think this could be simplified into a single write_sysreg_s() with the > register number calculated based on sync_args->bb, rather than duplicating > the same three lines six times. I think msr/mrs instructions needs register names at compile time so it cannot be calculate dynamically. Or am I misunderstood? > > +static int ioc_bb_alloc(struct file *filp, void __user *argp) > > +{ > > + struct hwb_private_data *pdata = (struct hwb_private_data *)filp->private_data; > > A slightly better way to write the ioctl command specific functions > is to just give the argument the correct type (struct > fujitsu_hwb_ioc_bb_ctl __user*) > instead of 'void __user *', to avoid the cast. > > Similarly, as you don't use 'filp' itself, just pass the struct hwb_private_data > pointer as the first argument. thanks, I will follow this advise. > > @@ -164,6 +386,7 @@ static int fujitsu_hwb_dev_open(struct inode *inode, struct file *filp) > > static const struct file_operations fujitsu_hwb_dev_fops = { > > .owner = THIS_MODULE, > > .open = fujitsu_hwb_dev_open, > > + .unlocked_ioctl = fujitsu_hwb_dev_ioctl, > > }; > > All drivers with an ioctl interface should work in compat mode as well, > so please add a > > .compat_ioctl = compat_ptr_ioctl; A64FX does not support 32-bit mode (aarch32 state). So I think unlockd_ioctl is enough or is it better to use compat_ioctl anyway? > > > +#define __FUJITSU_IOCTL_MAGIC 'F' > > It's hard to find a non-conflicting range of ioctl numbers, but > it would be good to note the conflict in > > Documentation/userspace-api/ioctl/ioctl-number.rst > > The 'F' range is also used in framebuffer drivers. I didn't notice this, thanks for pointing out. Again, thanks for all the reviews/comments. Tomohiro > > +/* ioctl definitions for hardware barrier driver */ > > +struct fujitsu_hwb_ioc_bb_ctl { > > + __u8 cmg; > > + __u8 bb; > > + __u8 unused[2]; > > + __u32 size; > > + unsigned long __user *pemask; > > +}; > > However, this structure layout is incompatible with 32-bit user > space because of the indirect pointer. See > Documentation/driver-api/ioctl.rst for how to encode a > pointer in a __u64 member. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-12 11:03 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-08 10:52 [RFC PATCH 00/10] Add Fujitsu A64FX soc entry/hardware barrier driver Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 01/10] soc: fujitsu: hwb: Add hardware barrier driver init/exit code Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 02/10] soc: fujtisu: hwb: Add open operation Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 03/10] soc: fujitsu: hwb: Add IOC_BB_ALLOC ioctl Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 13:22 ` Arnd Bergmann 2021-01-08 13:22 ` Arnd Bergmann 2021-01-12 11:02 ` misono.tomohiro [this message] 2021-01-12 11:02 ` misono.tomohiro 2021-01-12 12:34 ` Arnd Bergmann 2021-01-12 12:34 ` Arnd Bergmann 2021-01-08 10:52 ` [PATCH 04/10] soc: fujitsu: hwb: Add IOC_BW_ASSIGN ioctl Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 05/10] soc: fujitsu: hwb: Add IOC_BW_UNASSIGN ioctl Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 06/10] soc: fujitsu: hwb: Add IOC_BB_FREE ioctl Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 07/10] soc: fujitsu: hwb: Add IOC_GET_PE_INFO ioctl Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 10:52 ` [PATCH 08/10] soc: fujitsu: hwb: Add release operation Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 13:25 ` Arnd Bergmann 2021-01-08 13:25 ` Arnd Bergmann 2021-01-12 10:38 ` misono.tomohiro 2021-01-12 10:38 ` misono.tomohiro 2021-01-08 10:52 ` [PATCH 09/10] soc: fujitsu: hwb: Add sysfs entry Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 13:27 ` Arnd Bergmann 2021-01-08 13:27 ` Arnd Bergmann 2021-01-12 10:40 ` misono.tomohiro 2021-01-12 10:40 ` misono.tomohiro 2021-01-08 10:52 ` [PATCH 10/10] soc: fujitsu: hwb: Add Kconfig/Makefile to build fujitsu_hwb driver Misono Tomohiro 2021-01-08 10:52 ` Misono Tomohiro 2021-01-08 12:54 ` [RFC PATCH 00/10] Add Fujitsu A64FX soc entry/hardware barrier driver Mark Rutland 2021-01-08 12:54 ` Mark Rutland 2021-01-08 14:23 ` Arnd Bergmann 2021-01-08 14:23 ` Arnd Bergmann 2021-01-08 15:51 ` Mark Rutland 2021-01-08 15:51 ` Mark Rutland 2021-01-12 10:24 ` misono.tomohiro 2021-01-12 10:24 ` misono.tomohiro 2021-01-12 14:22 ` Arnd Bergmann 2021-01-12 14:22 ` Arnd Bergmann 2021-01-15 11:10 ` misono.tomohiro 2021-01-15 11:10 ` misono.tomohiro 2021-01-15 12:24 ` Arnd Bergmann 2021-01-15 12:24 ` Arnd Bergmann 2021-01-19 5:30 ` misono.tomohiro 2021-01-19 5:30 ` misono.tomohiro 2021-02-18 9:49 ` misono.tomohiro 2021-02-18 9:49 ` misono.tomohiro 2021-03-01 7:53 ` misono.tomohiro 2021-03-01 7:53 ` misono.tomohiro 2021-03-02 11:06 ` Arnd Bergmann 2021-03-02 11:06 ` Arnd Bergmann 2021-03-03 11:20 ` misono.tomohiro 2021-03-03 11:20 ` misono.tomohiro 2021-03-03 13:33 ` Arnd Bergmann 2021-03-03 13:33 ` Arnd Bergmann 2021-03-04 7:03 ` misono.tomohiro 2021-03-04 7:03 ` misono.tomohiro 2021-01-12 10:32 ` misono.tomohiro 2021-01-12 10:32 ` misono.tomohiro -- strict thread matches above, loose matches on Subject: below -- 2021-01-08 10:32 Misono Tomohiro 2021-01-08 10:32 ` [PATCH 03/10] soc: fujitsu: hwb: Add IOC_BB_ALLOC ioctl Misono Tomohiro 2021-01-08 10:32 ` Misono Tomohiro
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=OSBPR01MB458227B345C445CBF342648DE5AA0@OSBPR01MB4582.jpnprd01.prod.outlook.com \ --to=misono.tomohiro@fujitsu.com \ --cc=arnd@arndb.de \ --cc=arnd@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=olof@lixom.net \ --cc=soc@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.