Re: [PATCH 4/5] kbuild: disable KBUILD_MODNAME when building for mod.a
2018-06-18 13:55 GMT+09:00 NeilBrown : > When building an object to be included in mod.a we > cannot know the name of the module. So don't define > KBUILD_MODNAME. This will ensure attempt to use > that macro when the module name isn't know will > trigger an error. Honestly, I hate KBUILD_MODNAME. If KBUILD_MODNAME is undefined, you cannot call pr_debug() in the sub-directory for example. CONFIG_DYNAMIC_DEBUG requires KBUILD_MODNAME, but people often miss to notice that, then cause build errors. > Signed-off-by: NeilBrown > --- > scripts/Makefile.lib |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index c84167169a59..d09246474f2e 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -96,7 +96,7 @@ subdir-ym := $(addprefix $(obj)/,$(subdir-ym)) > # Finds the multi-part object the current object will be linked into. > # If the object belongs to two or more multi-part objects, all of them are > # concatenated with a colon separator. > -modname-multi = $(subst $(space),:,$(sort $(foreach m,$(multi-used),\ > +modname-multi = $(subst $(space),:,$(sort $(foreach m,$(multi-used) > modobj.o,\ > $(if $(filter $*.o, $($(m:.o=-objs)) $($(m:.o=-y)) > $($(m:.o=-m))),$(m:.o=) > > modname = $(if $(modname-multi),$(modname-multi),$(basetarget)) > @@ -106,7 +106,7 @@ modname = $(if > $(modname-multi),$(modname-multi),$(basetarget)) > # end up in (or would, if it gets compiled in) > name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst > -,_,$1))$(quote)$(squote) > basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) > -modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) > +modname_flags = $(if $(filter-out > modobj,$(modname)),-DKBUILD_MODNAME=$(call name-fix,$(modname))) > > orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) \ > $(ccflags-y) $(CFLAGS_$(basetarget).o) > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH 4/5] kbuild: disable KBUILD_MODNAME when building for mod.a
2018-06-18 13:55 GMT+09:00 NeilBrown : > When building an object to be included in mod.a we > cannot know the name of the module. So don't define > KBUILD_MODNAME. This will ensure attempt to use > that macro when the module name isn't know will > trigger an error. Honestly, I hate KBUILD_MODNAME. If KBUILD_MODNAME is undefined, you cannot call pr_debug() in the sub-directory for example. CONFIG_DYNAMIC_DEBUG requires KBUILD_MODNAME, but people often miss to notice that, then cause build errors. > Signed-off-by: NeilBrown > --- > scripts/Makefile.lib |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index c84167169a59..d09246474f2e 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -96,7 +96,7 @@ subdir-ym := $(addprefix $(obj)/,$(subdir-ym)) > # Finds the multi-part object the current object will be linked into. > # If the object belongs to two or more multi-part objects, all of them are > # concatenated with a colon separator. > -modname-multi = $(subst $(space),:,$(sort $(foreach m,$(multi-used),\ > +modname-multi = $(subst $(space),:,$(sort $(foreach m,$(multi-used) > modobj.o,\ > $(if $(filter $*.o, $($(m:.o=-objs)) $($(m:.o=-y)) > $($(m:.o=-m))),$(m:.o=) > > modname = $(if $(modname-multi),$(modname-multi),$(basetarget)) > @@ -106,7 +106,7 @@ modname = $(if > $(modname-multi),$(modname-multi),$(basetarget)) > # end up in (or would, if it gets compiled in) > name-fix = $(squote)$(quote)$(subst $(comma),_,$(subst > -,_,$1))$(quote)$(squote) > basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) > -modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) > +modname_flags = $(if $(filter-out > modobj,$(modname)),-DKBUILD_MODNAME=$(call name-fix,$(modname))) > > orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) \ > $(ccflags-y) $(CFLAGS_$(basetarget).o) > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg
On Tue, Jun 26, 2018 at 11:05 PM, Shakeel Butt wrote:
> On Tue, Jun 26, 2018 at 12:03 PM Johannes Weiner wrote:
>>
>> On Mon, Jun 25, 2018 at 04:06:58PM -0700, Shakeel Butt wrote:
>> > @@ -140,8 +141,9 @@ struct fanotify_event_info
>> > *fanotify_alloc_event(struct fsnotify_group *group,
>> >struct inode *inode, u32
>> > mask,
>> >const struct path *path)
>> > {
>> > - struct fanotify_event_info *event;
>> > + struct fanotify_event_info *event = NULL;
>> > gfp_t gfp = GFP_KERNEL;
>> > + struct mem_cgroup *old_memcg = NULL;
>> >
>> > /*
>> >* For queues with unlimited length lost events are not expected and
>> > @@ -151,19 +153,25 @@ struct fanotify_event_info
>> > *fanotify_alloc_event(struct fsnotify_group *group,
>> > if (group->max_events == UINT_MAX)
>> > gfp |= __GFP_NOFAIL;
>> >
>> > + /* Whoever is interested in the event, pays for the allocation. */
>> > + if (group->memcg) {
>> > + gfp |= __GFP_ACCOUNT;
>> > + old_memcg = memalloc_use_memcg(group->memcg);
>> > + }
>>
>> group->memcg is only NULL when memcg is disabled or there is some
>> offlining race. Can you make memalloc_use_memcg(NULL) mean that it
>> should charge root_mem_cgroup instead of current->mm->memcg? That way
>> we can make this site unconditional while retaining the behavior:
>>
>> gfp_t gfp = GFP_KERNEL | __GFP_ACCOUNT;
>>
>> memalloc_use_memcg(group->memcg);
>> kmem_cache_alloc(..., gfp);
>> out:
>> memalloc_unuse_memcg();
>>
>> (dropping old_memcg and the unuse parameter as per the other mail)
>>
>
> group->memcg is only NULL when memcg is disabled (i.e.
> get_mem_cgroup_from_mm() returns root_mem_cgroup for offlined
> mm->memcg). Though group->memcg can point to an offlined memcg.
>
> If I understand you correctly this is what we want:
>
> 1. If group->memcg is NULL then __GFP_ACCOUNT is a noop i.e. memcg is
> disabled.
> 2. If group->memcg is root_mem_cgroup, then __GFP_ACCOUNT again is a
> kind of noop (charges to root_mem_cgroups are bypassed).
> 3. If group->memcg is offlined memcg, then make __GFP_ACCOUNT noop by
> returning root_mem_cgroup from get_mem_cgroup_from_current().
> 4. Else charge group->memcg.
>
> This seems reasonable. After your Ack and Amir's or Jan's answer to
> the nesting query, I will resend the next version of this patch
> series.
>
> In future if we find any use-cases of memalloc_use_memcg nesting then
> we can make it work for nesting.
>
For the fsnotify use case memalloc_use_memcg() certainly doesn't
need to nest, but I wonder, if that facility becomes popular among different
subsystems, how exactly do you intend to monitor that it doesn't grow
nested use cases? I would suggest that you at least leave a
WARN_ON_ONCE if memalloc_use_memcg() is called and
active_memcg is already set.
Thanks,
Amir.
Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg
On Tue, Jun 26, 2018 at 11:05 PM, Shakeel Butt wrote:
> On Tue, Jun 26, 2018 at 12:03 PM Johannes Weiner wrote:
>>
>> On Mon, Jun 25, 2018 at 04:06:58PM -0700, Shakeel Butt wrote:
>> > @@ -140,8 +141,9 @@ struct fanotify_event_info
>> > *fanotify_alloc_event(struct fsnotify_group *group,
>> >struct inode *inode, u32
>> > mask,
>> >const struct path *path)
>> > {
>> > - struct fanotify_event_info *event;
>> > + struct fanotify_event_info *event = NULL;
>> > gfp_t gfp = GFP_KERNEL;
>> > + struct mem_cgroup *old_memcg = NULL;
>> >
>> > /*
>> >* For queues with unlimited length lost events are not expected and
>> > @@ -151,19 +153,25 @@ struct fanotify_event_info
>> > *fanotify_alloc_event(struct fsnotify_group *group,
>> > if (group->max_events == UINT_MAX)
>> > gfp |= __GFP_NOFAIL;
>> >
>> > + /* Whoever is interested in the event, pays for the allocation. */
>> > + if (group->memcg) {
>> > + gfp |= __GFP_ACCOUNT;
>> > + old_memcg = memalloc_use_memcg(group->memcg);
>> > + }
>>
>> group->memcg is only NULL when memcg is disabled or there is some
>> offlining race. Can you make memalloc_use_memcg(NULL) mean that it
>> should charge root_mem_cgroup instead of current->mm->memcg? That way
>> we can make this site unconditional while retaining the behavior:
>>
>> gfp_t gfp = GFP_KERNEL | __GFP_ACCOUNT;
>>
>> memalloc_use_memcg(group->memcg);
>> kmem_cache_alloc(..., gfp);
>> out:
>> memalloc_unuse_memcg();
>>
>> (dropping old_memcg and the unuse parameter as per the other mail)
>>
>
> group->memcg is only NULL when memcg is disabled (i.e.
> get_mem_cgroup_from_mm() returns root_mem_cgroup for offlined
> mm->memcg). Though group->memcg can point to an offlined memcg.
>
> If I understand you correctly this is what we want:
>
> 1. If group->memcg is NULL then __GFP_ACCOUNT is a noop i.e. memcg is
> disabled.
> 2. If group->memcg is root_mem_cgroup, then __GFP_ACCOUNT again is a
> kind of noop (charges to root_mem_cgroups are bypassed).
> 3. If group->memcg is offlined memcg, then make __GFP_ACCOUNT noop by
> returning root_mem_cgroup from get_mem_cgroup_from_current().
> 4. Else charge group->memcg.
>
> This seems reasonable. After your Ack and Amir's or Jan's answer to
> the nesting query, I will resend the next version of this patch
> series.
>
> In future if we find any use-cases of memalloc_use_memcg nesting then
> we can make it work for nesting.
>
For the fsnotify use case memalloc_use_memcg() certainly doesn't
need to nest, but I wonder, if that facility becomes popular among different
subsystems, how exactly do you intend to monitor that it doesn't grow
nested use cases? I would suggest that you at least leave a
WARN_ON_ONCE if memalloc_use_memcg() is called and
active_memcg is already set.
Thanks,
Amir.
Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
On Wed, Jun 27, 2018 at 10:07:26AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
> 940efcc8889f ("RDMA/uverbs: Protect from attempts to create flows on
> unsupported QP")
>
> from the rdma-fixes tree and commit:
>
> e99028ad76e7 ("RDMA/uverbs: Check existence of create_flow callback")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/infiniband/core/uverbs_cmd.c
> index 87ffeebc0b28,5fc14fde274c..
> --- a/drivers/infiniband/core/uverbs_cmd.c
> +++ b/drivers/infiniband/core/uverbs_cmd.c
> @@@ -3559,11 -3554,11 +3554,16 @@@ int ib_uverbs_ex_create_flow(struct ib_
> goto err_uobj;
> }
>
> +if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) {
> +err = -EINVAL;
> +goto err_put;
> +}
> +
> + if (!qp->device->create_flow) {
> + err = -EOPNOTSUPP;
> + goto err_put;
> + }
> +
Thanks Stephen, looks good.
> flow_attr = kzalloc(struct_size(flow_attr, flows,
> cmd.flow_attr.num_of_specs), GFP_KERNEL);
> if (!flow_attr) {
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the rdma tree with the rdma-fixes tree
On Wed, Jun 27, 2018 at 10:07:26AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
> 940efcc8889f ("RDMA/uverbs: Protect from attempts to create flows on
> unsupported QP")
>
> from the rdma-fixes tree and commit:
>
> e99028ad76e7 ("RDMA/uverbs: Check existence of create_flow callback")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/infiniband/core/uverbs_cmd.c
> index 87ffeebc0b28,5fc14fde274c..
> --- a/drivers/infiniband/core/uverbs_cmd.c
> +++ b/drivers/infiniband/core/uverbs_cmd.c
> @@@ -3559,11 -3554,11 +3554,16 @@@ int ib_uverbs_ex_create_flow(struct ib_
> goto err_uobj;
> }
>
> +if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) {
> +err = -EINVAL;
> +goto err_put;
> +}
> +
> + if (!qp->device->create_flow) {
> + err = -EOPNOTSUPP;
> + goto err_put;
> + }
> +
Thanks Stephen, looks good.
> flow_attr = kzalloc(struct_size(flow_attr, flows,
> cmd.flow_attr.num_of_specs), GFP_KERNEL);
> if (!flow_attr) {
signature.asc
Description: PGP signature
[PATCH v3 0/2] Add a property in at24.c
From: Alan Chiang In at24.c, it uses 8-bit addressing by default. In this patch, add a property address-width that provides a flexible method to pass the information to the driver. Alan Chiang (2): dt-bindings: at24: Add address-width property eeprom: at24: Add support for address-width property Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++ drivers/misc/eeprom/at24.c| 18 ++ 2 files changed, 20 insertions(+) -- 2.7.4
[PATCH v3 1/2] dt-bindings: at24: Add address-width property
From: Alan Chiang
The AT24 series chips use 8-bit address by default. If some
chips would like to support more than 8 bits, the at24 driver
should be added the compatible field for specfic chips.
Provide a flexible way to determine the addressing bits through
address-width in this patch.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
since v1:
-- Remove the address-width field in the example.
since v2:
-- Remove redundant space.
---
Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt
b/Documentation/devicetree/bindings/eeprom/at24.txt
index 61d833a..aededdb 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -72,6 +72,8 @@ Optional properties:
- wp-gpios: GPIO to which the write-protect pin of the chip is connected.
+ - address-width: number of address bits (one of 8, 16).
+
Example:
eeprom@52 {
--
2.7.4
[PATCH v3 2/2] eeprom: at24: Add support for address-width property
From: Alan Chiang
Provide a flexible way to determine the addressing bits of eeprom.
Pass the addressing bits to driver through address-width property.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
since v1
-- Add a warn message for 8-bit addressing.
since v2
-- Modify the warning message for clear.
-- Move the clearing bit operation outside of a statement.
---
drivers/misc/eeprom/at24.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 0c125f2..d606f3b 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -478,6 +478,24 @@ static void at24_properties_to_pdata(struct device *dev,
if (device_property_present(dev, "no-read-rollover"))
chip->flags |= AT24_FLAG_NO_RDROL;
+ err = device_property_read_u32(dev, "address-width", );
+ if (!err) {
+ switch (val) {
+ case 8:
+ if (chip->flags & AT24_FLAG_ADDR16)
+ dev_warn(dev, "Override address width to be 8,"
+"while default is 16\n");
+ chip->flags &= ~AT24_FLAG_ADDR16;
+ break;
+ case 16:
+ chip->flags |= AT24_FLAG_ADDR16;
+ break;
+ default:
+ dev_warn(dev, "Bad \"address-width\" property: %u\n",
+val);
+ }
+ }
+
err = device_property_read_u32(dev, "size", );
if (!err)
chip->byte_len = val;
--
2.7.4
[PATCH v3 0/2] Add a property in at24.c
From: Alan Chiang In at24.c, it uses 8-bit addressing by default. In this patch, add a property address-width that provides a flexible method to pass the information to the driver. Alan Chiang (2): dt-bindings: at24: Add address-width property eeprom: at24: Add support for address-width property Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++ drivers/misc/eeprom/at24.c| 18 ++ 2 files changed, 20 insertions(+) -- 2.7.4
[PATCH v3 1/2] dt-bindings: at24: Add address-width property
From: Alan Chiang
The AT24 series chips use 8-bit address by default. If some
chips would like to support more than 8 bits, the at24 driver
should be added the compatible field for specfic chips.
Provide a flexible way to determine the addressing bits through
address-width in this patch.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
since v1:
-- Remove the address-width field in the example.
since v2:
-- Remove redundant space.
---
Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt
b/Documentation/devicetree/bindings/eeprom/at24.txt
index 61d833a..aededdb 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -72,6 +72,8 @@ Optional properties:
- wp-gpios: GPIO to which the write-protect pin of the chip is connected.
+ - address-width: number of address bits (one of 8, 16).
+
Example:
eeprom@52 {
--
2.7.4
[PATCH v3 2/2] eeprom: at24: Add support for address-width property
From: Alan Chiang
Provide a flexible way to determine the addressing bits of eeprom.
Pass the addressing bits to driver through address-width property.
Signed-off-by: Alan Chiang
Signed-off-by: Andy Yeh
---
since v1
-- Add a warn message for 8-bit addressing.
since v2
-- Modify the warning message for clear.
-- Move the clearing bit operation outside of a statement.
---
drivers/misc/eeprom/at24.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 0c125f2..d606f3b 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -478,6 +478,24 @@ static void at24_properties_to_pdata(struct device *dev,
if (device_property_present(dev, "no-read-rollover"))
chip->flags |= AT24_FLAG_NO_RDROL;
+ err = device_property_read_u32(dev, "address-width", );
+ if (!err) {
+ switch (val) {
+ case 8:
+ if (chip->flags & AT24_FLAG_ADDR16)
+ dev_warn(dev, "Override address width to be 8,"
+"while default is 16\n");
+ chip->flags &= ~AT24_FLAG_ADDR16;
+ break;
+ case 16:
+ chip->flags |= AT24_FLAG_ADDR16;
+ break;
+ default:
+ dev_warn(dev, "Bad \"address-width\" property: %u\n",
+val);
+ }
+ }
+
err = device_property_read_u32(dev, "size", );
if (!err)
chip->byte_len = val;
--
2.7.4
[PATCH] x86/entry/64/compat: Fix "x86/entry/64/compat: Preserve r8-r11 in int $0x80"
Commit 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int
$0x80") was busted. My original patch had a minor conflict with
some of the nospec changes. git apply is very clever and silently
accepted the patch by making the same changes to a different
function in the same file. There was obviously a huge offset, but
git apply for some reason doesn't feel any need to say so.
Move the changes to the correct function. Now the
test_syscall_vdso_32 selftests passes.
If anyone cares to observe the original problem, try applying the
patch at
https://lore.kernel.org/lkml/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.l...@kernel.org/raw
to the kernel at 316d097c4cd4e7f2ef50c40cff2db266593c4ec4. git am and
git apply accept the patch without any complaints at all. patch -p1
at least prints out a message about the huge offset.
Reported-by: zhijianx...@intel.com
Fixes: 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int $0x80")
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_64_compat.S | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 9de7f1e1dede..7d0df78db727 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -84,13 +84,13 @@ ENTRY(entry_SYSENTER_compat)
pushq %rdx/* pt_regs->dx */
pushq %rcx/* pt_regs->cx */
pushq $-ENOSYS/* pt_regs->ax */
- pushq %r8 /* pt_regs->r8 */
+ pushq $0 /* pt_regs->r8 = 0 */
xorl%r8d, %r8d /* nospec r8 */
- pushq %r9 /* pt_regs->r9 */
+ pushq $0 /* pt_regs->r9 = 0 */
xorl%r9d, %r9d /* nospec r9 */
- pushq %r10/* pt_regs->r10 */
+ pushq $0 /* pt_regs->r10 = 0 */
xorl%r10d, %r10d/* nospec r10 */
- pushq %r11/* pt_regs->r11 */
+ pushq $0 /* pt_regs->r11 = 0 */
xorl%r11d, %r11d/* nospec r11 */
pushq %rbx/* pt_regs->rbx */
xorl%ebx, %ebx /* nospec rbx */
@@ -374,13 +374,13 @@ ENTRY(entry_INT80_compat)
pushq %rcx/* pt_regs->cx */
xorl%ecx, %ecx /* nospec cx */
pushq $-ENOSYS/* pt_regs->ax */
- pushq $0 /* pt_regs->r8 = 0 */
+ pushq %r8 /* pt_regs->r8 */
xorl%r8d, %r8d /* nospec r8 */
- pushq $0 /* pt_regs->r9 = 0 */
+ pushq %r9 /* pt_regs->r9 */
xorl%r9d, %r9d /* nospec r9 */
- pushq $0 /* pt_regs->r10 = 0 */
+ pushq %r10/* pt_regs->r10*/
xorl%r10d, %r10d/* nospec r10 */
- pushq $0 /* pt_regs->r11 = 0 */
+ pushq %r11/* pt_regs->r11 */
xorl%r11d, %r11d/* nospec r11 */
pushq %rbx/* pt_regs->rbx */
xorl%ebx, %ebx /* nospec rbx */
--
2.17.1
[PATCH] x86/entry/64/compat: Fix "x86/entry/64/compat: Preserve r8-r11 in int $0x80"
Commit 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int
$0x80") was busted. My original patch had a minor conflict with
some of the nospec changes. git apply is very clever and silently
accepted the patch by making the same changes to a different
function in the same file. There was obviously a huge offset, but
git apply for some reason doesn't feel any need to say so.
Move the changes to the correct function. Now the
test_syscall_vdso_32 selftests passes.
If anyone cares to observe the original problem, try applying the
patch at
https://lore.kernel.org/lkml/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.l...@kernel.org/raw
to the kernel at 316d097c4cd4e7f2ef50c40cff2db266593c4ec4. git am and
git apply accept the patch without any complaints at all. patch -p1
at least prints out a message about the huge offset.
Reported-by: zhijianx...@intel.com
Fixes: 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int $0x80")
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_64_compat.S | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 9de7f1e1dede..7d0df78db727 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -84,13 +84,13 @@ ENTRY(entry_SYSENTER_compat)
pushq %rdx/* pt_regs->dx */
pushq %rcx/* pt_regs->cx */
pushq $-ENOSYS/* pt_regs->ax */
- pushq %r8 /* pt_regs->r8 */
+ pushq $0 /* pt_regs->r8 = 0 */
xorl%r8d, %r8d /* nospec r8 */
- pushq %r9 /* pt_regs->r9 */
+ pushq $0 /* pt_regs->r9 = 0 */
xorl%r9d, %r9d /* nospec r9 */
- pushq %r10/* pt_regs->r10 */
+ pushq $0 /* pt_regs->r10 = 0 */
xorl%r10d, %r10d/* nospec r10 */
- pushq %r11/* pt_regs->r11 */
+ pushq $0 /* pt_regs->r11 = 0 */
xorl%r11d, %r11d/* nospec r11 */
pushq %rbx/* pt_regs->rbx */
xorl%ebx, %ebx /* nospec rbx */
@@ -374,13 +374,13 @@ ENTRY(entry_INT80_compat)
pushq %rcx/* pt_regs->cx */
xorl%ecx, %ecx /* nospec cx */
pushq $-ENOSYS/* pt_regs->ax */
- pushq $0 /* pt_regs->r8 = 0 */
+ pushq %r8 /* pt_regs->r8 */
xorl%r8d, %r8d /* nospec r8 */
- pushq $0 /* pt_regs->r9 = 0 */
+ pushq %r9 /* pt_regs->r9 */
xorl%r9d, %r9d /* nospec r9 */
- pushq $0 /* pt_regs->r10 = 0 */
+ pushq %r10/* pt_regs->r10*/
xorl%r10d, %r10d/* nospec r10 */
- pushq $0 /* pt_regs->r11 = 0 */
+ pushq %r11/* pt_regs->r11 */
xorl%r11d, %r11d/* nospec r11 */
pushq %rbx/* pt_regs->rbx */
xorl%ebx, %ebx /* nospec rbx */
--
2.17.1
[PATCH v4 5/7] Bluetooth: Extend btuart driver for join more vendor devices
From: Sean Wang
Adding an independent btuart.h header allows these essential definitions
can be reused in vendor driver. Also, struct btuart_vnd is extended with
additional callbacks such as .init initializing vendor data, .shtudown,
.recv and .send supporting SoC specific framing for that btuart can
simply adapt to various Bluetooth uart-based devices.
Signed-off-by: Sean Wang
---
drivers/bluetooth/btuart.c | 73 --
drivers/bluetooth/btuart.h | 30 +++
2 files changed, 68 insertions(+), 35 deletions(-)
create mode 100644 drivers/bluetooth/btuart.h
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
index 03e980f..ab7f836 100644
--- a/drivers/bluetooth/btuart.c
+++ b/drivers/bluetooth/btuart.c
@@ -33,35 +33,11 @@
#include
#include "h4_recv.h"
+#include "btuart.h"
#include "btbcm.h"
#define VERSION "1.0"
-struct btuart_vnd {
- const struct h4_recv_pkt *recv_pkts;
- int recv_pkts_cnt;
- unsigned int manufacturer;
- int (*open)(struct hci_dev *hdev);
- int (*close)(struct hci_dev *hdev);
- int (*setup)(struct hci_dev *hdev);
-};
-
-struct btuart_dev {
- struct hci_dev *hdev;
- struct serdev_device *serdev;
-
- struct work_struct tx_work;
- unsigned long tx_state;
- struct sk_buff_head txq;
-
- struct sk_buff *rx_skb;
-
- const struct btuart_vnd *vnd;
-};
-
-#define BTUART_TX_STATE_ACTIVE 1
-#define BTUART_TX_STATE_WAKEUP 2
-
static void btuart_tx_work(struct work_struct *work)
{
struct btuart_dev *bdev = container_of(work, struct btuart_dev,
@@ -187,13 +163,27 @@ static int btuart_setup(struct hci_dev *hdev)
return 0;
}
+static int btuart_shutdown(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ if (bdev->vnd->shutdown)
+ return bdev->vnd->shutdown(hdev);
+
+ return 0;
+}
+
static int btuart_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
struct btuart_dev *bdev = hci_get_drvdata(hdev);
- /* Prepend skb with frame type */
- memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
- skb_queue_tail(>txq, skb);
+ if (bdev->vnd->send) {
+ bdev->vnd->send(hdev, skb);
+ } else {
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
+ skb_queue_tail(>txq, skb);
+ }
btuart_tx_wakeup(bdev);
return 0;
@@ -204,14 +194,23 @@ static int btuart_receive_buf(struct serdev_device
*serdev, const u8 *data,
{
struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
const struct btuart_vnd *vnd = bdev->vnd;
+ int err;
- bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb, data, count,
- vnd->recv_pkts, vnd->recv_pkts_cnt);
- if (IS_ERR(bdev->rx_skb)) {
- int err = PTR_ERR(bdev->rx_skb);
- bt_dev_err(bdev->hdev, "Frame reassembly failed (%d)", err);
- bdev->rx_skb = NULL;
- return err;
+ if (bdev->vnd->recv) {
+ err = bdev->vnd->recv(bdev->hdev, data, count);
+ if (err < 0)
+ return err;
+ } else {
+ bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb,
+ data, count, vnd->recv_pkts,
+ vnd->recv_pkts_cnt);
+ if (IS_ERR(bdev->rx_skb)) {
+ err = PTR_ERR(bdev->rx_skb);
+ bt_dev_err(bdev->hdev,
+ "Frame reassembly failed (%d)", err);
+ bdev->rx_skb = NULL;
+ return err;
+ }
}
bdev->hdev->stat.byte_rx += count;
@@ -429,6 +428,9 @@ static int btuart_probe(struct serdev_device *serdev)
if (!bdev->vnd)
bdev->vnd = _vnd;
+ if (bdev->vnd->init)
+ bdev->data = bdev->vnd->init(>dev);
+
bdev->serdev = serdev;
serdev_device_set_drvdata(serdev, bdev);
@@ -460,6 +462,7 @@ static int btuart_probe(struct serdev_device *serdev)
hdev->close = btuart_close;
hdev->flush = btuart_flush;
hdev->setup = btuart_setup;
+ hdev->shutdown = btuart_shutdown;
hdev->send = btuart_send_frame;
SET_HCIDEV_DEV(hdev, >dev);
diff --git a/drivers/bluetooth/btuart.h b/drivers/bluetooth/btuart.h
new file mode 100644
index 000..6c1fe31
--- /dev/null
+++ b/drivers/bluetooth/btuart.h
@@ -0,0 +1,30 @@
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ void *(*init)(struct device *dev);
+
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+ int
[PATCH v4 7/7] MAINTAINERS: add an entry for MediaTek Bluetooth driver
From: Sean Wang Add an entry for the MediaTek Bluetooth driver. Signed-off-by: Sean Wang --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff..b06e38d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8987,6 +8987,14 @@ F: include/uapi/linux/meye.h F: include/uapi/linux/ivtv* F: include/uapi/linux/uvcvideo.h +MEDIATEK BLUETOOTH DRIVER +M: Sean Wang +L: linux-blueto...@vger.kernel.org +L: linux-media...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: Documentation/devicetree/bindings/net/mediatek-bluetooth.txt +F: drivers/bluetooth/btmtkuart.c + MEDIATEK CIR DRIVER M: Sean Wang S: Maintained -- 2.7.4
[PATCH v4 5/7] Bluetooth: Extend btuart driver for join more vendor devices
From: Sean Wang
Adding an independent btuart.h header allows these essential definitions
can be reused in vendor driver. Also, struct btuart_vnd is extended with
additional callbacks such as .init initializing vendor data, .shtudown,
.recv and .send supporting SoC specific framing for that btuart can
simply adapt to various Bluetooth uart-based devices.
Signed-off-by: Sean Wang
---
drivers/bluetooth/btuart.c | 73 --
drivers/bluetooth/btuart.h | 30 +++
2 files changed, 68 insertions(+), 35 deletions(-)
create mode 100644 drivers/bluetooth/btuart.h
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
index 03e980f..ab7f836 100644
--- a/drivers/bluetooth/btuart.c
+++ b/drivers/bluetooth/btuart.c
@@ -33,35 +33,11 @@
#include
#include "h4_recv.h"
+#include "btuart.h"
#include "btbcm.h"
#define VERSION "1.0"
-struct btuart_vnd {
- const struct h4_recv_pkt *recv_pkts;
- int recv_pkts_cnt;
- unsigned int manufacturer;
- int (*open)(struct hci_dev *hdev);
- int (*close)(struct hci_dev *hdev);
- int (*setup)(struct hci_dev *hdev);
-};
-
-struct btuart_dev {
- struct hci_dev *hdev;
- struct serdev_device *serdev;
-
- struct work_struct tx_work;
- unsigned long tx_state;
- struct sk_buff_head txq;
-
- struct sk_buff *rx_skb;
-
- const struct btuart_vnd *vnd;
-};
-
-#define BTUART_TX_STATE_ACTIVE 1
-#define BTUART_TX_STATE_WAKEUP 2
-
static void btuart_tx_work(struct work_struct *work)
{
struct btuart_dev *bdev = container_of(work, struct btuart_dev,
@@ -187,13 +163,27 @@ static int btuart_setup(struct hci_dev *hdev)
return 0;
}
+static int btuart_shutdown(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ if (bdev->vnd->shutdown)
+ return bdev->vnd->shutdown(hdev);
+
+ return 0;
+}
+
static int btuart_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
struct btuart_dev *bdev = hci_get_drvdata(hdev);
- /* Prepend skb with frame type */
- memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
- skb_queue_tail(>txq, skb);
+ if (bdev->vnd->send) {
+ bdev->vnd->send(hdev, skb);
+ } else {
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
+ skb_queue_tail(>txq, skb);
+ }
btuart_tx_wakeup(bdev);
return 0;
@@ -204,14 +194,23 @@ static int btuart_receive_buf(struct serdev_device
*serdev, const u8 *data,
{
struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
const struct btuart_vnd *vnd = bdev->vnd;
+ int err;
- bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb, data, count,
- vnd->recv_pkts, vnd->recv_pkts_cnt);
- if (IS_ERR(bdev->rx_skb)) {
- int err = PTR_ERR(bdev->rx_skb);
- bt_dev_err(bdev->hdev, "Frame reassembly failed (%d)", err);
- bdev->rx_skb = NULL;
- return err;
+ if (bdev->vnd->recv) {
+ err = bdev->vnd->recv(bdev->hdev, data, count);
+ if (err < 0)
+ return err;
+ } else {
+ bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb,
+ data, count, vnd->recv_pkts,
+ vnd->recv_pkts_cnt);
+ if (IS_ERR(bdev->rx_skb)) {
+ err = PTR_ERR(bdev->rx_skb);
+ bt_dev_err(bdev->hdev,
+ "Frame reassembly failed (%d)", err);
+ bdev->rx_skb = NULL;
+ return err;
+ }
}
bdev->hdev->stat.byte_rx += count;
@@ -429,6 +428,9 @@ static int btuart_probe(struct serdev_device *serdev)
if (!bdev->vnd)
bdev->vnd = _vnd;
+ if (bdev->vnd->init)
+ bdev->data = bdev->vnd->init(>dev);
+
bdev->serdev = serdev;
serdev_device_set_drvdata(serdev, bdev);
@@ -460,6 +462,7 @@ static int btuart_probe(struct serdev_device *serdev)
hdev->close = btuart_close;
hdev->flush = btuart_flush;
hdev->setup = btuart_setup;
+ hdev->shutdown = btuart_shutdown;
hdev->send = btuart_send_frame;
SET_HCIDEV_DEV(hdev, >dev);
diff --git a/drivers/bluetooth/btuart.h b/drivers/bluetooth/btuart.h
new file mode 100644
index 000..6c1fe31
--- /dev/null
+++ b/drivers/bluetooth/btuart.h
@@ -0,0 +1,30 @@
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ void *(*init)(struct device *dev);
+
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+ int
[PATCH v4 7/7] MAINTAINERS: add an entry for MediaTek Bluetooth driver
From: Sean Wang Add an entry for the MediaTek Bluetooth driver. Signed-off-by: Sean Wang --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff..b06e38d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8987,6 +8987,14 @@ F: include/uapi/linux/meye.h F: include/uapi/linux/ivtv* F: include/uapi/linux/uvcvideo.h +MEDIATEK BLUETOOTH DRIVER +M: Sean Wang +L: linux-blueto...@vger.kernel.org +L: linux-media...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: Documentation/devicetree/bindings/net/mediatek-bluetooth.txt +F: drivers/bluetooth/btmtkuart.c + MEDIATEK CIR DRIVER M: Sean Wang S: Maintained -- 2.7.4
[PATCH v4 3/7] Bluetooth: Add new serdev based driver for UART attached controllers
From: Marcel Holtmann
This is a from scratch written driver to run H:4 on serdev based system
with a Bluetooth controller attached via an UART. It is currently tested
on RPi3 and it has Broadcom integration. It is DT only and is missing
GPIO and runtime power management integration. Also Apple or ACPI
support is currently not added.
To integrate with controllers from Intel and Qualcomm, similar handling
like with btusb.c has to be done. A simple abstraction for that has been
provided to make it similar to hci_uart.
The goal is to run individual drivers on serdev capable systems so that
we can retire hci_uart on these system and continue with a lot simpler
and easier to maintain driver. It seems that hci_uart has too many race
conditions due to handling TTY and line disciplines. And fixes for that
are not really related to serdev based drivers. In a serdev only world
it makes sense to remove any of the complex code.
Signed-off-by: Marcel Holtmann
---
drivers/bluetooth/Kconfig | 11 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btuart.c | 506 +
3 files changed, 518 insertions(+)
create mode 100644 drivers/bluetooth/btuart.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index f3c643a..00fdf5f 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -74,6 +74,17 @@ config BT_HCIBTSDIO
Say Y here to compile support for Bluetooth SDIO devices into the
kernel or say M to compile it as module (btsdio).
+config BT_HCIBTUART
+ tristate "HCI UART driver"
+ depends on SERIAL_DEV_BUS
+ help
+ Bluetooth HCI UART driver.
+ This driver is required if you want to use Bluetooth device with
+ UART interface.
+
+ Say Y here to compile support for Bluetooth UART devices into the
+ kernel or say M to compile it as module (btuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index ec16c55..60a19cb 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_BT_HCIBLUECARD) += bluecard_cs.o
obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
+obj-$(CONFIG_BT_HCIBTUART) += btuart.o
obj-$(CONFIG_BT_INTEL) += btintel.o
obj-$(CONFIG_BT_ATH3K) += ath3k.o
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
new file mode 100644
index 000..03e980f
--- /dev/null
+++ b/drivers/bluetooth/btuart.c
@@ -0,0 +1,506 @@
+/*
+ *
+ * Generic Bluetooth HCI UART driver
+ *
+ * Copyright (C) 2015-2018 Intel Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "h4_recv.h"
+#include "btbcm.h"
+
+#define VERSION "1.0"
+
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+};
+
+struct btuart_dev {
+ struct hci_dev *hdev;
+ struct serdev_device *serdev;
+
+ struct work_struct tx_work;
+ unsigned long tx_state;
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+
+ const struct btuart_vnd *vnd;
+};
+
+#define BTUART_TX_STATE_ACTIVE 1
+#define BTUART_TX_STATE_WAKEUP 2
+
+static void btuart_tx_work(struct work_struct *work)
+{
+ struct btuart_dev *bdev = container_of(work, struct btuart_dev,
+ tx_work);
+ struct serdev_device *serdev = bdev->serdev;
+ struct hci_dev *hdev = bdev->hdev;
+
+ while (1) {
+ clear_bit(BTUART_TX_STATE_WAKEUP, >tx_state);
+
+ while (1) {
+ struct sk_buff *skb = skb_dequeue(>txq);
+ int len;
+
+ if (!skb)
+ break;
+
+ len = serdev_device_write_buf(serdev, skb->data,
+
[PATCH v4 3/7] Bluetooth: Add new serdev based driver for UART attached controllers
From: Marcel Holtmann
This is a from scratch written driver to run H:4 on serdev based system
with a Bluetooth controller attached via an UART. It is currently tested
on RPi3 and it has Broadcom integration. It is DT only and is missing
GPIO and runtime power management integration. Also Apple or ACPI
support is currently not added.
To integrate with controllers from Intel and Qualcomm, similar handling
like with btusb.c has to be done. A simple abstraction for that has been
provided to make it similar to hci_uart.
The goal is to run individual drivers on serdev capable systems so that
we can retire hci_uart on these system and continue with a lot simpler
and easier to maintain driver. It seems that hci_uart has too many race
conditions due to handling TTY and line disciplines. And fixes for that
are not really related to serdev based drivers. In a serdev only world
it makes sense to remove any of the complex code.
Signed-off-by: Marcel Holtmann
---
drivers/bluetooth/Kconfig | 11 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btuart.c | 506 +
3 files changed, 518 insertions(+)
create mode 100644 drivers/bluetooth/btuart.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index f3c643a..00fdf5f 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -74,6 +74,17 @@ config BT_HCIBTSDIO
Say Y here to compile support for Bluetooth SDIO devices into the
kernel or say M to compile it as module (btsdio).
+config BT_HCIBTUART
+ tristate "HCI UART driver"
+ depends on SERIAL_DEV_BUS
+ help
+ Bluetooth HCI UART driver.
+ This driver is required if you want to use Bluetooth device with
+ UART interface.
+
+ Say Y here to compile support for Bluetooth UART devices into the
+ kernel or say M to compile it as module (btuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index ec16c55..60a19cb 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_BT_HCIBLUECARD) += bluecard_cs.o
obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
+obj-$(CONFIG_BT_HCIBTUART) += btuart.o
obj-$(CONFIG_BT_INTEL) += btintel.o
obj-$(CONFIG_BT_ATH3K) += ath3k.o
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
new file mode 100644
index 000..03e980f
--- /dev/null
+++ b/drivers/bluetooth/btuart.c
@@ -0,0 +1,506 @@
+/*
+ *
+ * Generic Bluetooth HCI UART driver
+ *
+ * Copyright (C) 2015-2018 Intel Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "h4_recv.h"
+#include "btbcm.h"
+
+#define VERSION "1.0"
+
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+};
+
+struct btuart_dev {
+ struct hci_dev *hdev;
+ struct serdev_device *serdev;
+
+ struct work_struct tx_work;
+ unsigned long tx_state;
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+
+ const struct btuart_vnd *vnd;
+};
+
+#define BTUART_TX_STATE_ACTIVE 1
+#define BTUART_TX_STATE_WAKEUP 2
+
+static void btuart_tx_work(struct work_struct *work)
+{
+ struct btuart_dev *bdev = container_of(work, struct btuart_dev,
+ tx_work);
+ struct serdev_device *serdev = bdev->serdev;
+ struct hci_dev *hdev = bdev->hdev;
+
+ while (1) {
+ clear_bit(BTUART_TX_STATE_WAKEUP, >tx_state);
+
+ while (1) {
+ struct sk_buff *skb = skb_dequeue(>txq);
+ int len;
+
+ if (!skb)
+ break;
+
+ len = serdev_device_write_buf(serdev, skb->data,
+
[PATCH v4 0/7] add support for Bluetooth on MT7622 SoC
From: Sean Wang v4 and changes since v3: - refine patch 2 based on commit 919b7308fcc4 to allow that dev_pm_domain_attach() will return better error codes. v3 and changes since v2 * all changes happen on patch 6 - fix up SPDX license style for btmtkuart.h. - change firmware download from in ACL data to in HCI commands and then remove unused mtk_acl_wmt_sync and related code. - add a workaround replacing bad vendor event id 0xe4 with 0xff every vendor should use. - add a sanity check for mtk_hci_wmt_sync to verifying if input parameters are valid. - add an atomic_inc(>hdev->cmd_cnt) for __hci_cmd_sync_ev. - be changed to use firmware with a header called mt7622pr2h.bin. v2 and changes since v1 - Dropped patches already being applied - Rewirte the whole driver using btuart [1], and add slight extension of btuart to fit into btmtkuart driver. Beware that [1] is also pulled into one part of the series for avoiding any breakage when the patchset is being compiled. [1] btuart https://www.spinics.net/lists/linux-bluetooth/msg74918.html v1: Hi, This patchset introduces built-in Bluetooth support on MT7622 SoC. And, it should be simple to make an extension to support other MediaTek SoCs with adjusting a few of changes on the initialization sequence of the device. Before the main driver is being introduced, a few of things about power-domain management should be re-worked for serdev core and MediaTek SCPSYS to allow the Bluetooth to properly power up. Patch 2: add a generic way attaching power domain to serdev Patch 3 and 4: add cleanups with reuse APIs from Linux core Patch 5: fix a limitation about power enablement Bluetooth depends on Patch 1, 6 and 7: the major part of adding Bluetooth support to MT7622 Sean Marcel Holtmann (1): Bluetooth: Add new serdev based driver for UART attached controllers Sean Wang (6): dt-bindings: net: bluetooth: Add mediatek-bluetooth serdev: add dev_pm_domain_attach|detach() Bluetooth: Add new quirk for non-persistent setup settings Bluetooth: Extend btuart driver for join more vendor devices Bluetooth: mediatek: Add protocol support for MediaTek serial devices MAINTAINERS: add an entry for MediaTek Bluetooth driver .../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++ MAINTAINERS| 8 + drivers/bluetooth/Kconfig | 23 + drivers/bluetooth/Makefile | 3 + drivers/bluetooth/btmtkuart.c | 355 ++ drivers/bluetooth/btmtkuart.h | 119 + drivers/bluetooth/btuart.c | 527 + drivers/bluetooth/btuart.h | 30 ++ drivers/tty/serdev/core.c | 15 +- include/net/bluetooth/hci.h| 9 + net/bluetooth/hci_core.c | 3 +- 11 files changed, 1125 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt create mode 100644 drivers/bluetooth/btmtkuart.c create mode 100644 drivers/bluetooth/btmtkuart.h create mode 100644 drivers/bluetooth/btuart.c create mode 100644 drivers/bluetooth/btuart.h -- 2.7.4
[PATCH v4 0/7] add support for Bluetooth on MT7622 SoC
From: Sean Wang v4 and changes since v3: - refine patch 2 based on commit 919b7308fcc4 to allow that dev_pm_domain_attach() will return better error codes. v3 and changes since v2 * all changes happen on patch 6 - fix up SPDX license style for btmtkuart.h. - change firmware download from in ACL data to in HCI commands and then remove unused mtk_acl_wmt_sync and related code. - add a workaround replacing bad vendor event id 0xe4 with 0xff every vendor should use. - add a sanity check for mtk_hci_wmt_sync to verifying if input parameters are valid. - add an atomic_inc(>hdev->cmd_cnt) for __hci_cmd_sync_ev. - be changed to use firmware with a header called mt7622pr2h.bin. v2 and changes since v1 - Dropped patches already being applied - Rewirte the whole driver using btuart [1], and add slight extension of btuart to fit into btmtkuart driver. Beware that [1] is also pulled into one part of the series for avoiding any breakage when the patchset is being compiled. [1] btuart https://www.spinics.net/lists/linux-bluetooth/msg74918.html v1: Hi, This patchset introduces built-in Bluetooth support on MT7622 SoC. And, it should be simple to make an extension to support other MediaTek SoCs with adjusting a few of changes on the initialization sequence of the device. Before the main driver is being introduced, a few of things about power-domain management should be re-worked for serdev core and MediaTek SCPSYS to allow the Bluetooth to properly power up. Patch 2: add a generic way attaching power domain to serdev Patch 3 and 4: add cleanups with reuse APIs from Linux core Patch 5: fix a limitation about power enablement Bluetooth depends on Patch 1, 6 and 7: the major part of adding Bluetooth support to MT7622 Sean Marcel Holtmann (1): Bluetooth: Add new serdev based driver for UART attached controllers Sean Wang (6): dt-bindings: net: bluetooth: Add mediatek-bluetooth serdev: add dev_pm_domain_attach|detach() Bluetooth: Add new quirk for non-persistent setup settings Bluetooth: Extend btuart driver for join more vendor devices Bluetooth: mediatek: Add protocol support for MediaTek serial devices MAINTAINERS: add an entry for MediaTek Bluetooth driver .../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++ MAINTAINERS| 8 + drivers/bluetooth/Kconfig | 23 + drivers/bluetooth/Makefile | 3 + drivers/bluetooth/btmtkuart.c | 355 ++ drivers/bluetooth/btmtkuart.h | 119 + drivers/bluetooth/btuart.c | 527 + drivers/bluetooth/btuart.h | 30 ++ drivers/tty/serdev/core.c | 15 +- include/net/bluetooth/hci.h| 9 + net/bluetooth/hci_core.c | 3 +- 11 files changed, 1125 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt create mode 100644 drivers/bluetooth/btmtkuart.c create mode 100644 drivers/bluetooth/btmtkuart.h create mode 100644 drivers/bluetooth/btuart.c create mode 100644 drivers/bluetooth/btuart.h -- 2.7.4
[PATCH v4 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang
This adds a driver to run on the top of btuart driver for the MediaTek
serial protocol based on running H:4, which can enable the built-in
Bluetooth device inside MT7622 SoC.
Signed-off-by: Sean Wang
---
drivers/bluetooth/Kconfig | 12 ++
drivers/bluetooth/Makefile| 2 +
drivers/bluetooth/btmtkuart.c | 355 ++
drivers/bluetooth/btmtkuart.h | 119 ++
drivers/bluetooth/btuart.c| 18 +++
5 files changed, 506 insertions(+)
create mode 100644 drivers/bluetooth/btmtkuart.c
create mode 100644 drivers/bluetooth/btmtkuart.h
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 00fdf5f..1a44afd 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -85,6 +85,18 @@ config BT_HCIBTUART
Say Y here to compile support for Bluetooth UART devices into the
kernel or say M to compile it as module (btuart).
+config BT_HCIBTUART_MTK
+ tristate "MediaTek HCI UART driver"
+ depends on BT_HCIBTUART
+ default y
+ help
+ MediaTek Bluetooth HCI UART driver.
+ This driver is required if you want to use MediaTek Bluetooth
+ with serial interface.
+
+ Say Y here to compile support for MediaTek Bluetooth UART devices
+ into the kernel or say M to compile it as module (btmtkuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 60a19cb..c9a8926 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_BT_BCM) += btbcm.o
obj-$(CONFIG_BT_RTL) += btrtl.o
obj-$(CONFIG_BT_QCA) += btqca.o
+obj-$(CONFIG_BT_HCIBTUART_MTK) += btmtkuart.o
+
obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
obj-$(CONFIG_BT_HCIRSI)+= btrsi.o
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
new file mode 100644
index 000..3118f61
--- /dev/null
+++ b/drivers/bluetooth/btmtkuart.c
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 MediaTek Inc.
+
+/*
+ * Bluetooth support for MediaTek serial devices
+ *
+ * Author: Sean Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "h4_recv.h"
+#include "btuart.h"
+#include "btmtkuart.h"
+
+static void mtk_stp_reset(struct mtk_stp_splitter *sp)
+{
+ sp->cursor = 2;
+ sp->dlen = 0;
+}
+
+static const unsigned char *
+mtk_stp_split(struct btuart_dev *bdev, struct mtk_stp_splitter *sp,
+ const unsigned char *data, int count, int *sz_h4)
+{
+ struct mtk_stp_hdr *shdr;
+
+ /* The cursor is reset when all the data of STP is consumed out. */
+ if (!sp->dlen && sp->cursor >= 6)
+ sp->cursor = 0;
+
+ /* Filling pad until all STP info is obtained. */
+ while (sp->cursor < 6 && count > 0) {
+ sp->pad[sp->cursor] = *data;
+ sp->cursor++;
+ data++;
+ count--;
+ }
+
+ /* Retrieve STP info and have a sanity check. */
+ if (!sp->dlen && sp->cursor >= 6) {
+ shdr = (struct mtk_stp_hdr *)>pad[2];
+ sp->dlen = shdr->dlen1 << 8 | shdr->dlen2;
+
+ /* Resync STP when unexpected data is being read. */
+ if (shdr->prefix != 0x80 || sp->dlen > 2048) {
+ bt_dev_err(bdev->hdev, "stp format unexpect (%d, %d)",
+ shdr->prefix, sp->dlen);
+ mtk_stp_reset(sp);
+ }
+ }
+
+ /* Directly quit when there's no data found for H4 can process. */
+ if (count <= 0)
+ return NULL;
+
+ /* Tranlate to how much the size of data H4 can handle so far. */
+ *sz_h4 = min_t(int, count, sp->dlen);
+ /* Update the remaining size of STP packet. */
+ sp->dlen -= *sz_h4;
+
+ /* Data points to STP payload which can be handled by H4. */
+ return data;
+}
+
+static int mtk_stp_send(struct btuart_dev *bdev, struct sk_buff *skb)
+{
+ struct mtk_stp_hdr *shdr;
+ struct sk_buff *new_skb;
+ int dlen;
+
+ memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
+ dlen = skb->len;
+
+ /* Make sure of STP header at least has 4-bytes free space to fill. */
+ if (unlikely(skb_headroom(skb) < MTK_STP_HDR_SIZE)) {
+ new_skb = skb_realloc_headroom(skb, MTK_STP_HDR_SIZE);
+ kfree_skb(skb);
+ skb = new_skb;
+ }
+
+ /* Build for STP packet format. */
+ shdr = skb_push(skb, MTK_STP_HDR_SIZE);
+ mtk_make_stp_hdr(shdr, 0, dlen);
+ skb_put_zero(skb, MTK_STP_TLR_SIZE);
+
+ skb_queue_tail(>txq, skb);
+
+ return 0;
+}
+
+static int mtk_hci_wmt_sync(struct btuart_dev *bdev,
[PATCH v4 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang
This adds a driver to run on the top of btuart driver for the MediaTek
serial protocol based on running H:4, which can enable the built-in
Bluetooth device inside MT7622 SoC.
Signed-off-by: Sean Wang
---
drivers/bluetooth/Kconfig | 12 ++
drivers/bluetooth/Makefile| 2 +
drivers/bluetooth/btmtkuart.c | 355 ++
drivers/bluetooth/btmtkuart.h | 119 ++
drivers/bluetooth/btuart.c| 18 +++
5 files changed, 506 insertions(+)
create mode 100644 drivers/bluetooth/btmtkuart.c
create mode 100644 drivers/bluetooth/btmtkuart.h
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 00fdf5f..1a44afd 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -85,6 +85,18 @@ config BT_HCIBTUART
Say Y here to compile support for Bluetooth UART devices into the
kernel or say M to compile it as module (btuart).
+config BT_HCIBTUART_MTK
+ tristate "MediaTek HCI UART driver"
+ depends on BT_HCIBTUART
+ default y
+ help
+ MediaTek Bluetooth HCI UART driver.
+ This driver is required if you want to use MediaTek Bluetooth
+ with serial interface.
+
+ Say Y here to compile support for MediaTek Bluetooth UART devices
+ into the kernel or say M to compile it as module (btmtkuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 60a19cb..c9a8926 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_BT_BCM) += btbcm.o
obj-$(CONFIG_BT_RTL) += btrtl.o
obj-$(CONFIG_BT_QCA) += btqca.o
+obj-$(CONFIG_BT_HCIBTUART_MTK) += btmtkuart.o
+
obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
obj-$(CONFIG_BT_HCIRSI)+= btrsi.o
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
new file mode 100644
index 000..3118f61
--- /dev/null
+++ b/drivers/bluetooth/btmtkuart.c
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 MediaTek Inc.
+
+/*
+ * Bluetooth support for MediaTek serial devices
+ *
+ * Author: Sean Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "h4_recv.h"
+#include "btuart.h"
+#include "btmtkuart.h"
+
+static void mtk_stp_reset(struct mtk_stp_splitter *sp)
+{
+ sp->cursor = 2;
+ sp->dlen = 0;
+}
+
+static const unsigned char *
+mtk_stp_split(struct btuart_dev *bdev, struct mtk_stp_splitter *sp,
+ const unsigned char *data, int count, int *sz_h4)
+{
+ struct mtk_stp_hdr *shdr;
+
+ /* The cursor is reset when all the data of STP is consumed out. */
+ if (!sp->dlen && sp->cursor >= 6)
+ sp->cursor = 0;
+
+ /* Filling pad until all STP info is obtained. */
+ while (sp->cursor < 6 && count > 0) {
+ sp->pad[sp->cursor] = *data;
+ sp->cursor++;
+ data++;
+ count--;
+ }
+
+ /* Retrieve STP info and have a sanity check. */
+ if (!sp->dlen && sp->cursor >= 6) {
+ shdr = (struct mtk_stp_hdr *)>pad[2];
+ sp->dlen = shdr->dlen1 << 8 | shdr->dlen2;
+
+ /* Resync STP when unexpected data is being read. */
+ if (shdr->prefix != 0x80 || sp->dlen > 2048) {
+ bt_dev_err(bdev->hdev, "stp format unexpect (%d, %d)",
+ shdr->prefix, sp->dlen);
+ mtk_stp_reset(sp);
+ }
+ }
+
+ /* Directly quit when there's no data found for H4 can process. */
+ if (count <= 0)
+ return NULL;
+
+ /* Tranlate to how much the size of data H4 can handle so far. */
+ *sz_h4 = min_t(int, count, sp->dlen);
+ /* Update the remaining size of STP packet. */
+ sp->dlen -= *sz_h4;
+
+ /* Data points to STP payload which can be handled by H4. */
+ return data;
+}
+
+static int mtk_stp_send(struct btuart_dev *bdev, struct sk_buff *skb)
+{
+ struct mtk_stp_hdr *shdr;
+ struct sk_buff *new_skb;
+ int dlen;
+
+ memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
+ dlen = skb->len;
+
+ /* Make sure of STP header at least has 4-bytes free space to fill. */
+ if (unlikely(skb_headroom(skb) < MTK_STP_HDR_SIZE)) {
+ new_skb = skb_realloc_headroom(skb, MTK_STP_HDR_SIZE);
+ kfree_skb(skb);
+ skb = new_skb;
+ }
+
+ /* Build for STP packet format. */
+ shdr = skb_push(skb, MTK_STP_HDR_SIZE);
+ mtk_make_stp_hdr(shdr, 0, dlen);
+ skb_put_zero(skb, MTK_STP_TLR_SIZE);
+
+ skb_queue_tail(>txq, skb);
+
+ return 0;
+}
+
+static int mtk_hci_wmt_sync(struct btuart_dev *bdev,
[PATCH v4 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth
From: Sean Wang
Add binding document for a SoC built-in device using MediaTek protocol.
Which could be found on MT7622 SoC or other similar MediaTek SoCs.
Signed-off-by: Sean Wang
Reviewed-by: Rob Herring
---
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
new file mode 100644
index 000..1335429
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
@@ -0,0 +1,35 @@
+MediaTek SoC built-in Bluetooth Devices
+==
+
+This device is a serial attached device to BTIF device and thus it must be a
+child node of the serial node with BTIF. The dt-bindings details for BTIF
+device can be known via Documentation/devicetree/bindings/serial/8250.txt.
+
+Required properties:
+
+- compatible: Must be one of
+ "mediatek,mt7622-bluetooth"": for MT7622 SoC
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "ref" entries.
+- power-domains: Phandle to the power domain that the device is part of
+
+Example:
+
+ btif: serial@1100c000 {
+ compatible = "mediatek,mt7622-btif",
+"mediatek,mtk-btif";
+ reg = <0 0x1100c000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_PERI_BTIF_PD>;
+ clock-names = "main";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = < MT7622_POWER_DOMAIN_WB>;
+ clocks = <>;
+ clock-names = "ref";
+ };
+ };
--
2.7.4
[PATCH v4 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth
From: Sean Wang
Add binding document for a SoC built-in device using MediaTek protocol.
Which could be found on MT7622 SoC or other similar MediaTek SoCs.
Signed-off-by: Sean Wang
Reviewed-by: Rob Herring
---
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
new file mode 100644
index 000..1335429
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
@@ -0,0 +1,35 @@
+MediaTek SoC built-in Bluetooth Devices
+==
+
+This device is a serial attached device to BTIF device and thus it must be a
+child node of the serial node with BTIF. The dt-bindings details for BTIF
+device can be known via Documentation/devicetree/bindings/serial/8250.txt.
+
+Required properties:
+
+- compatible: Must be one of
+ "mediatek,mt7622-bluetooth"": for MT7622 SoC
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "ref" entries.
+- power-domains: Phandle to the power domain that the device is part of
+
+Example:
+
+ btif: serial@1100c000 {
+ compatible = "mediatek,mt7622-btif",
+"mediatek,mtk-btif";
+ reg = <0 0x1100c000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_PERI_BTIF_PD>;
+ clock-names = "main";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = < MT7622_POWER_DOMAIN_WB>;
+ clocks = <>;
+ clock-names = "ref";
+ };
+ };
--
2.7.4
[PATCH v4 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang
Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
runs setup() after every open() and not just after the first open().
Signed-off-by: Sean Wang
---
include/net/bluetooth/hci.h | 9 +
net/bluetooth/hci_core.c| 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 1668211..b37d973 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -183,6 +183,15 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_NON_PERSISTENT_DIAG,
+
+ /* When this quirk is set, setup() would be run after every
+* open() and not just after the first open().
+*
+* This quirk can be set before hci_register_dev is called or
+* during the hdev->setup vendor callback.
+*
+*/
+ HCI_QUIRK_NON_PERSISTENT_SETUP,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index ee8ef12..f2bf0c6 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1368,7 +1368,8 @@ static int hci_dev_do_open(struct hci_dev *hdev)
atomic_set(>cmd_cnt, 1);
set_bit(HCI_INIT, >flags);
- if (hci_dev_test_flag(hdev, HCI_SETUP)) {
+ if (hci_dev_test_flag(hdev, HCI_SETUP) ||
+ test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks)) {
hci_sock_dev_event(hdev, HCI_DEV_SETUP);
if (hdev->setup)
--
2.7.4
[PATCH v4 2/7] serdev: add dev_pm_domain_attach|detach()
From: Sean Wang
In order to open up the required power gate before any operation can be
effectively performed over the serial bus between CPU and serdev, it's
clearly essential to add common attach functions for PM domains to serdev
at the probe phase.
Similarly, the relevant dettach function for the PM domains should be
properly and reversely added at the remove phase.
Signed-off-by: Sean Wang
Cc: Rob Herring
Cc: Ulf Hansson
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
---
drivers/tty/serdev/core.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index df93b72..8096138 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -330,8 +331,17 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
static int serdev_drv_probe(struct device *dev)
{
const struct serdev_device_driver *sdrv =
to_serdev_device_driver(dev->driver);
+ int ret;
- return sdrv->probe(to_serdev_device(dev));
+ ret = dev_pm_domain_attach(dev, true);
+ if (ret)
+ return ret;
+
+ ret = sdrv->probe(to_serdev_device(dev));
+ if (ret)
+ dev_pm_domain_detach(dev, true);
+
+ return ret;
}
static int serdev_drv_remove(struct device *dev)
@@ -339,6 +349,9 @@ static int serdev_drv_remove(struct device *dev)
const struct serdev_device_driver *sdrv =
to_serdev_device_driver(dev->driver);
if (sdrv->remove)
sdrv->remove(to_serdev_device(dev));
+
+ dev_pm_domain_detach(dev, true);
+
return 0;
}
--
2.7.4
[PATCH v4 2/7] serdev: add dev_pm_domain_attach|detach()
From: Sean Wang
In order to open up the required power gate before any operation can be
effectively performed over the serial bus between CPU and serdev, it's
clearly essential to add common attach functions for PM domains to serdev
at the probe phase.
Similarly, the relevant dettach function for the PM domains should be
properly and reversely added at the remove phase.
Signed-off-by: Sean Wang
Cc: Rob Herring
Cc: Ulf Hansson
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
---
drivers/tty/serdev/core.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index df93b72..8096138 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -330,8 +331,17 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
static int serdev_drv_probe(struct device *dev)
{
const struct serdev_device_driver *sdrv =
to_serdev_device_driver(dev->driver);
+ int ret;
- return sdrv->probe(to_serdev_device(dev));
+ ret = dev_pm_domain_attach(dev, true);
+ if (ret)
+ return ret;
+
+ ret = sdrv->probe(to_serdev_device(dev));
+ if (ret)
+ dev_pm_domain_detach(dev, true);
+
+ return ret;
}
static int serdev_drv_remove(struct device *dev)
@@ -339,6 +349,9 @@ static int serdev_drv_remove(struct device *dev)
const struct serdev_device_driver *sdrv =
to_serdev_device_driver(dev->driver);
if (sdrv->remove)
sdrv->remove(to_serdev_device(dev));
+
+ dev_pm_domain_detach(dev, true);
+
return 0;
}
--
2.7.4
[PATCH v4 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang
Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
runs setup() after every open() and not just after the first open().
Signed-off-by: Sean Wang
---
include/net/bluetooth/hci.h | 9 +
net/bluetooth/hci_core.c| 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 1668211..b37d973 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -183,6 +183,15 @@ enum {
* during the hdev->setup vendor callback.
*/
HCI_QUIRK_NON_PERSISTENT_DIAG,
+
+ /* When this quirk is set, setup() would be run after every
+* open() and not just after the first open().
+*
+* This quirk can be set before hci_register_dev is called or
+* during the hdev->setup vendor callback.
+*
+*/
+ HCI_QUIRK_NON_PERSISTENT_SETUP,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index ee8ef12..f2bf0c6 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1368,7 +1368,8 @@ static int hci_dev_do_open(struct hci_dev *hdev)
atomic_set(>cmd_cnt, 1);
set_bit(HCI_INIT, >flags);
- if (hci_dev_test_flag(hdev, HCI_SETUP)) {
+ if (hci_dev_test_flag(hdev, HCI_SETUP) ||
+ test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks)) {
hci_sock_dev_event(hdev, HCI_DEV_SETUP);
if (hdev->setup)
--
2.7.4
[PATCH] linux-firmware: mediatek: add MT7622 Bluetooth firmwares and license file
From: Sean Wang
Add MT7622 Bluetooth firmware files, along with the corresponding MediaTek
license file.
Signed-off-by: Sean Wang
---
LICENCE.mediatek| 9 +
WHENCE | 9 +
mediatek/mt7622pr2h.bin | Bin 0 -> 78158 bytes
3 files changed, 18 insertions(+)
create mode 100644 LICENCE.mediatek
create mode 100755 mediatek/mt7622pr2h.bin
diff --git a/LICENCE.mediatek b/LICENCE.mediatek
new file mode 100644
index 000..6886c61
--- /dev/null
+++ b/LICENCE.mediatek
@@ -0,0 +1,9 @@
+MediaTek Inc. grants permission to use and redistribute aforementioned firmware
+files for the use with devices containing MediaTek chipsets, but not as part of
+the Linux kernel or in any other form which would require these files
themselves
+to be covered by the terms of the GNU General Public License or the GNU Lesser
+General Public License.
+
+These firmware files are distributed in the hope that they will be useful, but
+are provided WITHOUT ANY WARRANTY, INCLUDING BUT NOT LIMITED TO IMPLIED
WARRANTY
+OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
diff --git a/WHENCE b/WHENCE
index ca3f30c..7c3172b 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3795,6 +3795,15 @@ OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--
+Driver: btmtk - MediaTek Bluetooth Driver
+
+File: mediatek/mt7622pr2h.bin
+Version: 20180621204904
+
+Licence: Redistributable. See LICENCE.mediatek for details.
+
+--
+
Driver: rk3399-dptx - ROCKCHIP rk3399 dptx firmware
File: rockchip/dptx.bin
diff --git a/mediatek/mt7622pr2h.bin b/mediatek/mt7622pr2h.bin
new file mode 100755
index
..06bae379be2f9cd45074076bc5100725e1076a82
GIT binary patch
literal 78158
zcmceFk*B9q6Sb0K?DhoIHSX9
zQfSbqA;eCD0b3_F(ZPrsGv2wpb1T4T2N%$>?}h=jpX!95b3eSF
zUi_u&)LEXhJ?Gg^S&)}sn0IYKenH;M>+)uAyX8sgNr@05~ke{+#^*M&
zRi4bO;mN_nggjbdCN*P3@>z$K)ZS<%2c07MKsJ+u|7|7eOp#3ZFEd#^RU}`1YbE}x
z%;Z3)g}9SMv=vA%XC@7=SxLp0W*4UB{>PKqLTuZ<$fp90pk
zQDig5@c-98XKWTJmdNWB5)C+~XVvMZmpWhVILY@7cI`!3opbt>O{%Q(uNEP1sB5ny
z%_9~QnbhV~5F)n~wJSm%RbJY@dv|?Nah^la$ubXcplv_>+_rBR}SBOGH!Kh`%s>bLs>O8byX;HVRMXWW_!uzHQl1E1B
z@ycjDo?KB+0n7~g6PTPlT9?S9bvXjKbvmz-$lCi4=Fa?kX(Po9!@io*Jd#E;opZ=~HwnQ%hGyajH~VzKSTxg!G#&|KyDV^-G6&*?^a)3kE_?x)YP`M!j(YUx9;^`
znM0)Zt(~!DMO12QF0<3*iY3pI_GVU>#G!7awa8i*mmMdHD_OV!~Q@;D#q;gQDys*E!xw9B=t+f3|K;LW5EL1;Hc)*iV1Y1tMkG}7`q8ZP_(
zTP9hai$^{vH<1|4N-cB>Eup`}ZroB9PlbS&?L)Fm3j$m5J0nny-Jb~Xr0r-Udy6()h$jP{Vec)gtb*#VkFOE4=KBAU#O2duEyD}YVQ;uPe?Q{Y9
z%RygnA?GhF2hUH~6D^JN2z<%f_pMSX+kB+)0PsK7DeU{!k#_B0N+n`N*#$ZY?LW*-
z-gjXHkA^;qU`IXiQD3rVb{CXM3aRDG^9g_0>MjaUC9jTGNQ{6S;jpN7T#q8#w2|b_AZw}BsWyWA$bq!>
zd^8p%_6owG#3hB0!=4}DnJb*Jg`!xyKv9JhAT33@$#XH+F|w}LuYdL6H(%x6-FM0N
zS>x)n>Ol25Z)5kj+p6iiydHnn)G3AH-4bEAl~|ldS}XEvK2WPY7Z(nyrV_$Ua;&>y
z7S^Lu8HZZmm2RLDsnwlGi09&?ud3wdE$QQE*-b5IX;Up|WgTv1(yh+>`#vQ*iDhv;
z8FLv%?y@2s2l`A3SbiZ(x^KoUA@Y}imtspQ-pgtELne8Q^6u?L@#?AU%
zD_}IKJYf78^lPAWgJL7UBXQd@o-UH`)MrMB*@1<8aM{ZJ9=Hg3h4DsDkkpv(D7hc}aga|f0d^H-IenE*^Q
z&)%<|L7zA)$|ZOanjT$u-)crI-@98ECUDa;=?%}tYab2%Kl>btT^9RI
zid_=0{~5(4a<`Hvi^_|2q{HO0KPtZKB=d-ELAR-2aVcW(A;qrg-DW!Se%zi
z6zL0b-%LfSMVTNRLD}8nz8UPfTHIH_p7)FU^4W8PxbIr_+$8SHW6#YZ;70`?R-2z|
zZaknU>Nv%vj#pNu3VIY>^U|{71>t^0s^i;MG00>mCHtJoFHkFYigGF6P)qRoel_@;
zv)hiCDpnD0-(2I#lX+A$QX;>Tnn^Xa73Zb*D-D{cG+>OXj9zJsq6P%z?o>A3Rd=(T
zSe9DNQdul@KTBn^6olt_G>)Y+a4{OPsHJmB41S${76w
zz+Y9$#+SxYWh^z3rHpx`vs8t6PUyD)UTT{vV8_hgP_vSN9Vi2SEm4K@D#kCD%_0+&
zCC!3zQ>Dnp=v~gntSqS$%qJ*mubS-`^{5{S~*2sBb
zGBBWZ`v`ce2q`sr*IR8pp77A}dJ?j=6}$5w-z5QKq#B`p(x`llb9UZGRWjghteJo4
z)#IK^4?GCj=?8jdaxj=h*V4c9hpA_H_1{s8t`|bGR=C9NmGle(8Z#ptP4Bs3;~J
z(W9vqxyHNky9l|8BmPTG<<7)J#u?$Qo{Qr@t|ucr)yO-~WE14S-jBLh@LEW+L{wIQ
zUh?3!c0Hyz2jXx(DOL!u9vnZJBgOheNDNDrtGLoolhR
zM0+k~zCJSgVR_-aTBKHj;(cG1POYsW&&8%Pat*bXbA)OI&>I+6(LBmBw(vt
zZYS~J-%D`5@>h$B)W9nVDr7zPUH##;F883+yBiuHD~Rn1>#I#+JuvFmuDEXkWJR$j^NeP-D+W}
zLHRWdChG;Vg@|(m_#%%qZNFkq7`~`4sFhClz8|Eyl*jX1JgxY%;LnUd0e>d<3hM`K
zEz}~cinD7HG_Z6E%>-|ru1T~TZzkid1aEREk=#U0^=cWv<*bi5=V#s3liq7qIj1?R
zQjd0~;8#S;>3F|OEpldORW7b3_Z|CX=e>YqHsCnOv(+Yaq&@
zu6!Z7+)Yf13priD9Kn?!MweGnrCgvUW#a@vSrx-}XR*s36YWx^Xr+oG549T=b%Mxn
zQK8sEXLn5{2hd@-BclMZF8hg
zxeC(s#9{*8N5o!3w%)FCU3SQIm4ZYnT+$Crm#P5XPDjn{stILA>+_{R+~1a6
zyA9=dq}rh$%EqqE_guWiR!@qFNSK`Gh`sjHax~X%#W{ok#@OK;May%>8B4M
z{a8dV!x=e(6PYc@M5FTAY9`AMz)~<^I;^Sjv+JgtOc5Mg~-rn9n|5Vdu!e
zwqj{R<$|9!H7wYz;I+Vc>~k=|EsWJi8qw;y?{bY-gXWu-n9e?Zr}m_dwLy
zr%)0z@FYs2&(>DhV`B!MDo)6^55$~(8YR*|?Lcg`hF+wBrw6zN9S^QZ#`xSsv<;ZN
zceeAzJKlJ4z}zo*qd+?zJbPlm+HavDq?6t50b9RFgY634HW1w(MelA0rB
zKQbp*G;B|;sCs%ryOMH@Y)gKQJf6IXJdvElDanc6qU1!*m7L(6cLv%9lkM7+_M(8d
zWqV+2%aeiXmZt)0OKrg163f=knU>wG66c#`y!+x$Y7%z;t-Yvzg<9Iu
zS({VJZ8;0<9^US1~AhPD;XMUywRSB_ehTD-6(@ms#_+8d$k5#8Ba$XeiRbo`9>
zTpBIUZbtbVqvZw`-_7hueup~`7LF2MU9p1m=d$JKqF6~d-)dz>jH$37hP>eE{6WdD
zfm~cjV#sZT9AnlRv=mr-!$wuvX;L|T!oEZ5OO2P*j-XeWH(|WuY8vM*Bj0>tsy*;G
[PATCH] linux-firmware: mediatek: add MT7622 Bluetooth firmwares and license file
From: Sean Wang
Add MT7622 Bluetooth firmware files, along with the corresponding MediaTek
license file.
Signed-off-by: Sean Wang
---
LICENCE.mediatek| 9 +
WHENCE | 9 +
mediatek/mt7622pr2h.bin | Bin 0 -> 78158 bytes
3 files changed, 18 insertions(+)
create mode 100644 LICENCE.mediatek
create mode 100755 mediatek/mt7622pr2h.bin
diff --git a/LICENCE.mediatek b/LICENCE.mediatek
new file mode 100644
index 000..6886c61
--- /dev/null
+++ b/LICENCE.mediatek
@@ -0,0 +1,9 @@
+MediaTek Inc. grants permission to use and redistribute aforementioned firmware
+files for the use with devices containing MediaTek chipsets, but not as part of
+the Linux kernel or in any other form which would require these files
themselves
+to be covered by the terms of the GNU General Public License or the GNU Lesser
+General Public License.
+
+These firmware files are distributed in the hope that they will be useful, but
+are provided WITHOUT ANY WARRANTY, INCLUDING BUT NOT LIMITED TO IMPLIED
WARRANTY
+OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
diff --git a/WHENCE b/WHENCE
index ca3f30c..7c3172b 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3795,6 +3795,15 @@ OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--
+Driver: btmtk - MediaTek Bluetooth Driver
+
+File: mediatek/mt7622pr2h.bin
+Version: 20180621204904
+
+Licence: Redistributable. See LICENCE.mediatek for details.
+
+--
+
Driver: rk3399-dptx - ROCKCHIP rk3399 dptx firmware
File: rockchip/dptx.bin
diff --git a/mediatek/mt7622pr2h.bin b/mediatek/mt7622pr2h.bin
new file mode 100755
index
..06bae379be2f9cd45074076bc5100725e1076a82
GIT binary patch
literal 78158
zcmceFk*B9q6Sb0K?DhoIHSX9
zQfSbqA;eCD0b3_F(ZPrsGv2wpb1T4T2N%$>?}h=jpX!95b3eSF
zUi_u&)LEXhJ?Gg^S&)}sn0IYKenH;M>+)uAyX8sgNr@05~ke{+#^*M&
zRi4bO;mN_nggjbdCN*P3@>z$K)ZS<%2c07MKsJ+u|7|7eOp#3ZFEd#^RU}`1YbE}x
z%;Z3)g}9SMv=vA%XC@7=SxLp0W*4UB{>PKqLTuZ<$fp90pk
zQDig5@c-98XKWTJmdNWB5)C+~XVvMZmpWhVILY@7cI`!3opbt>O{%Q(uNEP1sB5ny
z%_9~QnbhV~5F)n~wJSm%RbJY@dv|?Nah^la$ubXcplv_>+_rBR}SBOGH!Kh`%s>bLs>O8byX;HVRMXWW_!uzHQl1E1B
z@ycjDo?KB+0n7~g6PTPlT9?S9bvXjKbvmz-$lCi4=Fa?kX(Po9!@io*Jd#E;opZ=~HwnQ%hGyajH~VzKSTxg!G#&|KyDV^-G6&*?^a)3kE_?x)YP`M!j(YUx9;^`
znM0)Zt(~!DMO12QF0<3*iY3pI_GVU>#G!7awa8i*mmMdHD_OV!~Q@;D#q;gQDys*E!xw9B=t+f3|K;LW5EL1;Hc)*iV1Y1tMkG}7`q8ZP_(
zTP9hai$^{vH<1|4N-cB>Eup`}ZroB9PlbS&?L)Fm3j$m5J0nny-Jb~Xr0r-Udy6()h$jP{Vec)gtb*#VkFOE4=KBAU#O2duEyD}YVQ;uPe?Q{Y9
z%RygnA?GhF2hUH~6D^JN2z<%f_pMSX+kB+)0PsK7DeU{!k#_B0N+n`N*#$ZY?LW*-
z-gjXHkA^;qU`IXiQD3rVb{CXM3aRDG^9g_0>MjaUC9jTGNQ{6S;jpN7T#q8#w2|b_AZw}BsWyWA$bq!>
zd^8p%_6owG#3hB0!=4}DnJb*Jg`!xyKv9JhAT33@$#XH+F|w}LuYdL6H(%x6-FM0N
zS>x)n>Ol25Z)5kj+p6iiydHnn)G3AH-4bEAl~|ldS}XEvK2WPY7Z(nyrV_$Ua;&>y
z7S^Lu8HZZmm2RLDsnwlGi09&?ud3wdE$QQE*-b5IX;Up|WgTv1(yh+>`#vQ*iDhv;
z8FLv%?y@2s2l`A3SbiZ(x^KoUA@Y}imtspQ-pgtELne8Q^6u?L@#?AU%
zD_}IKJYf78^lPAWgJL7UBXQd@o-UH`)MrMB*@1<8aM{ZJ9=Hg3h4DsDkkpv(D7hc}aga|f0d^H-IenE*^Q
z&)%<|L7zA)$|ZOanjT$u-)crI-@98ECUDa;=?%}tYab2%Kl>btT^9RI
zid_=0{~5(4a<`Hvi^_|2q{HO0KPtZKB=d-ELAR-2aVcW(A;qrg-DW!Se%zi
z6zL0b-%LfSMVTNRLD}8nz8UPfTHIH_p7)FU^4W8PxbIr_+$8SHW6#YZ;70`?R-2z|
zZaknU>Nv%vj#pNu3VIY>^U|{71>t^0s^i;MG00>mCHtJoFHkFYigGF6P)qRoel_@;
zv)hiCDpnD0-(2I#lX+A$QX;>Tnn^Xa73Zb*D-D{cG+>OXj9zJsq6P%z?o>A3Rd=(T
zSe9DNQdul@KTBn^6olt_G>)Y+a4{OPsHJmB41S${76w
zz+Y9$#+SxYWh^z3rHpx`vs8t6PUyD)UTT{vV8_hgP_vSN9Vi2SEm4K@D#kCD%_0+&
zCC!3zQ>Dnp=v~gntSqS$%qJ*mubS-`^{5{S~*2sBb
zGBBWZ`v`ce2q`sr*IR8pp77A}dJ?j=6}$5w-z5QKq#B`p(x`llb9UZGRWjghteJo4
z)#IK^4?GCj=?8jdaxj=h*V4c9hpA_H_1{s8t`|bGR=C9NmGle(8Z#ptP4Bs3;~J
z(W9vqxyHNky9l|8BmPTG<<7)J#u?$Qo{Qr@t|ucr)yO-~WE14S-jBLh@LEW+L{wIQ
zUh?3!c0Hyz2jXx(DOL!u9vnZJBgOheNDNDrtGLoolhR
zM0+k~zCJSgVR_-aTBKHj;(cG1POYsW&&8%Pat*bXbA)OI&>I+6(LBmBw(vt
zZYS~J-%D`5@>h$B)W9nVDr7zPUH##;F883+yBiuHD~Rn1>#I#+JuvFmuDEXkWJR$j^NeP-D+W}
zLHRWdChG;Vg@|(m_#%%qZNFkq7`~`4sFhClz8|Eyl*jX1JgxY%;LnUd0e>d<3hM`K
zEz}~cinD7HG_Z6E%>-|ru1T~TZzkid1aEREk=#U0^=cWv<*bi5=V#s3liq7qIj1?R
zQjd0~;8#S;>3F|OEpldORW7b3_Z|CX=e>YqHsCnOv(+Yaq&@
zu6!Z7+)Yf13priD9Kn?!MweGnrCgvUW#a@vSrx-}XR*s36YWx^Xr+oG549T=b%Mxn
zQK8sEXLn5{2hd@-BclMZF8hg
zxeC(s#9{*8N5o!3w%)FCU3SQIm4ZYnT+$Crm#P5XPDjn{stILA>+_{R+~1a6
zyA9=dq}rh$%EqqE_guWiR!@qFNSK`Gh`sjHax~X%#W{ok#@OK;May%>8B4M
z{a8dV!x=e(6PYc@M5FTAY9`AMz)~<^I;^Sjv+JgtOc5Mg~-rn9n|5Vdu!e
zwqj{R<$|9!H7wYz;I+Vc>~k=|EsWJi8qw;y?{bY-gXWu-n9e?Zr}m_dwLy
zr%)0z@FYs2&(>DhV`B!MDo)6^55$~(8YR*|?Lcg`hF+wBrw6zN9S^QZ#`xSsv<;ZN
zceeAzJKlJ4z}zo*qd+?zJbPlm+HavDq?6t50b9RFgY634HW1w(MelA0rB
zKQbp*G;B|;sCs%ryOMH@Y)gKQJf6IXJdvElDanc6qU1!*m7L(6cLv%9lkM7+_M(8d
zWqV+2%aeiXmZt)0OKrg163f=knU>wG66c#`y!+x$Y7%z;t-Yvzg<9Iu
zS({VJZ8;0<9^US1~AhPD;XMUywRSB_ehTD-6(@ms#_+8d$k5#8Ba$XeiRbo`9>
zTpBIUZbtbVqvZw`-_7hueup~`7LF2MU9p1m=d$JKqF6~d-)dz>jH$37hP>eE{6WdD
zfm~cjV#sZT9AnlRv=mr-!$wuvX;L|T!oEZ5OO2P*j-XeWH(|WuY8vM*Bj0>tsy*;G
[GIT PULL] arch/microblaze patches for 4.18-rc3
Hi Linus, please pull the following patches to your tree. Thanks, Michal The following changes since commit f0dc7f9c6dd99891611fca5849cbc4c6965b690e: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-06-10 19:25:23 -0700) are available in the git repository at: git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v4.18-rc3 for you to fetch changes up to 45df561a7ae2ca5080708cc2cf84a236f4d930ef: microblaze: consolidate GPIO reset handling (2018-06-21 13:57:39 +0200) Microblaze patches for 4.18-rc3 - Fix architecture gpio heart beat code - Add new syscalls - Remove unused xlnx,compound handling - Remove platform.c Michal Simek (2): microblaze: Remove architecture heart beat code microblaze: Add new syscalls io_pgetevents and rseq Rob Herring (3): microblaze: heartbeat: fix missing prom.h include microblaze: remove unecessary of_platform_bus_probe call microblaze: consolidate GPIO reset handling arch/microblaze/Kconfig.debug | 7 --- arch/microblaze/include/asm/setup.h | 5 - arch/microblaze/include/asm/unistd.h | 2 +- arch/microblaze/include/uapi/asm/unistd.h | 2 ++ arch/microblaze/kernel/Makefile | 4 +--- arch/microblaze/kernel/heartbeat.c| 72 arch/microblaze/kernel/platform.c | 29 - arch/microblaze/kernel/reset.c| 11 ++- arch/microblaze/kernel/syscall_table.S| 2 ++ arch/microblaze/kernel/timer.c| 7 --- 10 files changed, 12 insertions(+), 129 deletions(-) delete mode 100644 arch/microblaze/kernel/heartbeat.c delete mode 100644 arch/microblaze/kernel/platform.c -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature
[GIT PULL] arch/microblaze patches for 4.18-rc3
Hi Linus, please pull the following patches to your tree. Thanks, Michal The following changes since commit f0dc7f9c6dd99891611fca5849cbc4c6965b690e: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-06-10 19:25:23 -0700) are available in the git repository at: git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v4.18-rc3 for you to fetch changes up to 45df561a7ae2ca5080708cc2cf84a236f4d930ef: microblaze: consolidate GPIO reset handling (2018-06-21 13:57:39 +0200) Microblaze patches for 4.18-rc3 - Fix architecture gpio heart beat code - Add new syscalls - Remove unused xlnx,compound handling - Remove platform.c Michal Simek (2): microblaze: Remove architecture heart beat code microblaze: Add new syscalls io_pgetevents and rseq Rob Herring (3): microblaze: heartbeat: fix missing prom.h include microblaze: remove unecessary of_platform_bus_probe call microblaze: consolidate GPIO reset handling arch/microblaze/Kconfig.debug | 7 --- arch/microblaze/include/asm/setup.h | 5 - arch/microblaze/include/asm/unistd.h | 2 +- arch/microblaze/include/uapi/asm/unistd.h | 2 ++ arch/microblaze/kernel/Makefile | 4 +--- arch/microblaze/kernel/heartbeat.c| 72 arch/microblaze/kernel/platform.c | 29 - arch/microblaze/kernel/reset.c| 11 ++- arch/microblaze/kernel/syscall_table.S| 2 ++ arch/microblaze/kernel/timer.c| 7 --- 10 files changed, 12 insertions(+), 129 deletions(-) delete mode 100644 arch/microblaze/kernel/heartbeat.c delete mode 100644 arch/microblaze/kernel/platform.c -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature
[PATCH 0/2] A fix and a cleanup to the x86 sigreturn selftests
The sigreturn_64 selftest has always failed on AMD CPUs. Fix it and clean it up a bit. Andy Lutomirski (2): selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs selftests/x86/sigreturn: Minor cleanups tools/testing/selftests/x86/sigreturn.c | 59 +++-- 1 file changed, 36 insertions(+), 23 deletions(-) -- 2.17.1
[PATCH 2/2] selftests/x86/sigreturn: Minor cleanups
We have short names for the requested and resulting register values.
Use them instead of spelling out the whole register entry for each
case.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/sigreturn.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/x86/sigreturn.c
b/tools/testing/selftests/x86/sigreturn.c
index 2559e2c01793..4d9dc3f2fd70 100644
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -610,6 +610,7 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
*/
for (int i = 0; i < NGREG; i++) {
greg_t req = requested_regs[i], res = resulting_regs[i];
+
if (i == REG_TRAPNO || i == REG_IP)
continue; /* don't care */
@@ -673,18 +674,18 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
#endif
/* Sanity check on the kernel */
- if (i == REG_CX && requested_regs[i] != resulting_regs[i]) {
+ if (i == REG_CX && req != res) {
printf("[FAIL]\tCX (saved SP) mismatch: requested
0x%llx; got 0x%llx\n",
- (unsigned long long)requested_regs[i],
- (unsigned long long)resulting_regs[i]);
+ (unsigned long long)req,
+ (unsigned long long)res);
nerrs++;
continue;
}
- if (requested_regs[i] != resulting_regs[i] && !ignore_reg) {
+ if (req != res && !ignore_reg) {
printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got
0x%llx\n",
- i, (unsigned long long)requested_regs[i],
- (unsigned long long)resulting_regs[i]);
+ i, (unsigned long long)req,
+ (unsigned long long)res);
nerrs++;
}
}
--
2.17.1
[PATCH 1/2] selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs
When I wrote the sigreturn test, I didn't realize that AMD's busted
IRET behavior was different from Intel's busted IRET behavior. On
AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer
to certain userspace contexts. Gee, thanks. There's very little
the kernel can do about it. Modify the test so it passes.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/sigreturn.c | 46 -
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/tools/testing/selftests/x86/sigreturn.c
b/tools/testing/selftests/x86/sigreturn.c
index 246145b84a12..2559e2c01793 100644
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -612,19 +612,38 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
greg_t req = requested_regs[i], res = resulting_regs[i];
if (i == REG_TRAPNO || i == REG_IP)
continue; /* don't care */
- if (i == REG_SP) {
- printf("\tSP: %llx -> %llx\n", (unsigned long long)req,
- (unsigned long long)res);
+ if (i == REG_SP) {
/*
-* In many circumstances, the high 32 bits of rsp
-* are zeroed. For example, we could be a real
-* 32-bit program, or we could hit any of a number
-* of poorly-documented IRET or segmented ESP
-* oddities. If this happens, it's okay.
+* If we were using a 16-bit stack segment, then
+* the kernel is a bit stuck: IRET only restores
+* the low 16 bits of ESP/RSP if SS is 16-bit.
+* The kernel uses a hack to restore bits 31:16,
+* but that hack doesn't help with bits 63:32.
+* On Intel CPUs, bits 63:32 end up zeroed, and, on
+* AMD CPUs, they leak the high bits of the kernel
+* espfix64 stack pointer. There's very little that
+* the kernel can do about it.
+*
+* Similarly, if we are returning to a 32-bit context,
+* the CPU will often lose the high 32 bits of RSP.
*/
- if (res == (req & 0x))
- continue; /* OK; not expected to work */
+
+ if (res == req)
+ continue;
+
+ if (cs_bits != 64 && ((res ^ req) & 0x) == 0) {
+ printf("[NOTE]\tSP: %llx -> %llx\n",
+ (unsigned long long)req,
+ (unsigned long long)res);
+ continue;
+ }
+
+ printf("[FAIL]\tSP mismatch: requested 0x%llx; got
0x%llx\n",
+ (unsigned long long)requested_regs[i],
+ (unsigned long long)resulting_regs[i]);
+ nerrs++;
+ continue;
}
bool ignore_reg = false;
@@ -663,13 +682,6 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
}
if (requested_regs[i] != resulting_regs[i] && !ignore_reg) {
- /*
-* SP is particularly interesting here. The
-* usual cause of failures is that we hit the
-* nasty IRET case of returning to a 16-bit SS,
-* in which case bits 16:31 of the *kernel*
-* stack pointer persist in ESP.
-*/
printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got
0x%llx\n",
i, (unsigned long long)requested_regs[i],
(unsigned long long)resulting_regs[i]);
--
2.17.1
[PATCH 0/2] A fix and a cleanup to the x86 sigreturn selftests
The sigreturn_64 selftest has always failed on AMD CPUs. Fix it and clean it up a bit. Andy Lutomirski (2): selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs selftests/x86/sigreturn: Minor cleanups tools/testing/selftests/x86/sigreturn.c | 59 +++-- 1 file changed, 36 insertions(+), 23 deletions(-) -- 2.17.1
[PATCH 2/2] selftests/x86/sigreturn: Minor cleanups
We have short names for the requested and resulting register values.
Use them instead of spelling out the whole register entry for each
case.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/sigreturn.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/x86/sigreturn.c
b/tools/testing/selftests/x86/sigreturn.c
index 2559e2c01793..4d9dc3f2fd70 100644
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -610,6 +610,7 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
*/
for (int i = 0; i < NGREG; i++) {
greg_t req = requested_regs[i], res = resulting_regs[i];
+
if (i == REG_TRAPNO || i == REG_IP)
continue; /* don't care */
@@ -673,18 +674,18 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
#endif
/* Sanity check on the kernel */
- if (i == REG_CX && requested_regs[i] != resulting_regs[i]) {
+ if (i == REG_CX && req != res) {
printf("[FAIL]\tCX (saved SP) mismatch: requested
0x%llx; got 0x%llx\n",
- (unsigned long long)requested_regs[i],
- (unsigned long long)resulting_regs[i]);
+ (unsigned long long)req,
+ (unsigned long long)res);
nerrs++;
continue;
}
- if (requested_regs[i] != resulting_regs[i] && !ignore_reg) {
+ if (req != res && !ignore_reg) {
printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got
0x%llx\n",
- i, (unsigned long long)requested_regs[i],
- (unsigned long long)resulting_regs[i]);
+ i, (unsigned long long)req,
+ (unsigned long long)res);
nerrs++;
}
}
--
2.17.1
[PATCH 1/2] selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs
When I wrote the sigreturn test, I didn't realize that AMD's busted
IRET behavior was different from Intel's busted IRET behavior. On
AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer
to certain userspace contexts. Gee, thanks. There's very little
the kernel can do about it. Modify the test so it passes.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/sigreturn.c | 46 -
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/tools/testing/selftests/x86/sigreturn.c
b/tools/testing/selftests/x86/sigreturn.c
index 246145b84a12..2559e2c01793 100644
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -612,19 +612,38 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
greg_t req = requested_regs[i], res = resulting_regs[i];
if (i == REG_TRAPNO || i == REG_IP)
continue; /* don't care */
- if (i == REG_SP) {
- printf("\tSP: %llx -> %llx\n", (unsigned long long)req,
- (unsigned long long)res);
+ if (i == REG_SP) {
/*
-* In many circumstances, the high 32 bits of rsp
-* are zeroed. For example, we could be a real
-* 32-bit program, or we could hit any of a number
-* of poorly-documented IRET or segmented ESP
-* oddities. If this happens, it's okay.
+* If we were using a 16-bit stack segment, then
+* the kernel is a bit stuck: IRET only restores
+* the low 16 bits of ESP/RSP if SS is 16-bit.
+* The kernel uses a hack to restore bits 31:16,
+* but that hack doesn't help with bits 63:32.
+* On Intel CPUs, bits 63:32 end up zeroed, and, on
+* AMD CPUs, they leak the high bits of the kernel
+* espfix64 stack pointer. There's very little that
+* the kernel can do about it.
+*
+* Similarly, if we are returning to a 32-bit context,
+* the CPU will often lose the high 32 bits of RSP.
*/
- if (res == (req & 0x))
- continue; /* OK; not expected to work */
+
+ if (res == req)
+ continue;
+
+ if (cs_bits != 64 && ((res ^ req) & 0x) == 0) {
+ printf("[NOTE]\tSP: %llx -> %llx\n",
+ (unsigned long long)req,
+ (unsigned long long)res);
+ continue;
+ }
+
+ printf("[FAIL]\tSP mismatch: requested 0x%llx; got
0x%llx\n",
+ (unsigned long long)requested_regs[i],
+ (unsigned long long)resulting_regs[i]);
+ nerrs++;
+ continue;
}
bool ignore_reg = false;
@@ -663,13 +682,6 @@ static int test_valid_sigreturn(int cs_bits, bool
use_16bit_ss, int force_ss)
}
if (requested_regs[i] != resulting_regs[i] && !ignore_reg) {
- /*
-* SP is particularly interesting here. The
-* usual cause of failures is that we hit the
-* nasty IRET case of returning to a 16-bit SS,
-* in which case bits 16:31 of the *kernel*
-* stack pointer persist in ESP.
-*/
printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got
0x%llx\n",
i, (unsigned long long)requested_regs[i],
(unsigned long long)resulting_regs[i]);
--
2.17.1
Re: test_syscall_vdso_32 [FAIL]
On Mon, Jun 25, 2018 at 6:23 PM Li Zhijian wrote: > > On 6/25/2018 11:40 PM, Andy Lutomirski wrote: > > On Mon, Jun 25, 2018 at 1:41 AM Li Zhijian wrote: > >> Hi > >> > >> Intel 0Day noticed that test_syscall_vdso_32 failed since > >> 8bb2610bc4967f19672444a7b0407367f1540028(x86/entry/64/compat: Preserve > >> r8-r11 in int $0x80) > >> [snipped] Indeed. Hi Thomas- Something went wrong when you applied the patch mentioned above. The original patch is here: https://lore.kernel.org/lkml/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.l...@kernel.org/ but somehow it got applied with huge offset -- the same exact change was made, but it was made to the entirely wrong function! I'm a little nervous about sending a fixup patch because there are three copies of that code in the file, and I don't want to just move the problem around. What's the right thing to do here? Clearly this needs to get fixed somehow, and the fix should go to -stable. --Andy
Re: test_syscall_vdso_32 [FAIL]
On Mon, Jun 25, 2018 at 6:23 PM Li Zhijian wrote: > > On 6/25/2018 11:40 PM, Andy Lutomirski wrote: > > On Mon, Jun 25, 2018 at 1:41 AM Li Zhijian wrote: > >> Hi > >> > >> Intel 0Day noticed that test_syscall_vdso_32 failed since > >> 8bb2610bc4967f19672444a7b0407367f1540028(x86/entry/64/compat: Preserve > >> r8-r11 in int $0x80) > >> [snipped] Indeed. Hi Thomas- Something went wrong when you applied the patch mentioned above. The original patch is here: https://lore.kernel.org/lkml/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.l...@kernel.org/ but somehow it got applied with huge offset -- the same exact change was made, but it was made to the entirely wrong function! I'm a little nervous about sending a fixup patch because there are three copies of that code in the file, and I don't want to just move the problem around. What's the right thing to do here? Clearly this needs to get fixed somehow, and the fix should go to -stable. --Andy
[PATCH v4 3/6] soc: qcom: rpmpd: Add a Power domain driver to model corners
The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.
We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
Acked-by: Rob Herring
---
drivers/soc/qcom/Kconfig | 9 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmpd.c | 294 ++
3 files changed, 304 insertions(+)
create mode 100644 drivers/soc/qcom/rpmpd.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9dc02f390ba3..131da9d34a40 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
Say y here if you intend to boot the modem remoteproc.
+config QCOM_RPMPD
+ bool "Qualcomm RPM Power domain driver"
+ depends on MFD_QCOM_RPM && QCOM_SMD_RPM
+ help
+ QCOM RPM Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPM which then translates it into corresponding voltage
+ for the voltage rail.
+
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 19dcf957cb3a..9550c170de93 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..a0b9f122d793
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER 0x636676 /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+ static struct rpmpd _platform##_##_active; \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .peer = &_platform##_##_active, \
+ .res_type = RPMPD_SMPA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }; \
+ static struct rpmpd _platform##_##_active = { \
+ .pd = { .name = #_active, },\
+ .peer = &_platform##_##_name, \
+ .active_only = true,\
+ .res_type = RPMPD_SMPA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_type = RPMPD_LDOA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type) \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_type = r_type, \
+ .res_id = r_id, \
+ .key = KEY_FLOOR_CORNER,\
+ }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id) \
+ DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+
+#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id) \
+
[PATCH v4 2/6] dt-bindings: power: Add qcom rpm power domain driver bindings
Add DT bindings to describe the rpm/rpmh power domains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPM/RPMh, which then translates it into corresponding voltage on a
PMIC rail.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
---
.../devicetree/bindings/power/qcom,rpmpd.txt | 146 ++
include/dt-bindings/power/qcom-rpmpd.h| 39 +
2 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
create mode 100644 include/dt-bindings/power/qcom-rpmpd.h
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
new file mode 100644
index ..8825080afa5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -0,0 +1,146 @@
+Qualcomm RPM/RPMh Power domains
+
+For RPM/RPMh Power domains, we communicate a performance state to RPM/RPMh
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+ * qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+ * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
+ - power-domain-cells: number of cells in Power domain specifier
+ must be 1.
+ - operating-points-v2: Phandle to the OPP table for the Power domain.
+ Refer to Documentation/devicetree/bindings/power/power_domain.txt
+ and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Refer to for the level values for
+various OPPs for different platforms as well as Power domain indexes
+
+Example: rpmh power domain controller and OPP table
+
+#include
+
+qcom,level values specified in the OPP tables for RPMh power domains
+should use the RPMH_REGULATOR_LEVEL_* constants from
+
+
+ rpmhpd: power-controller {
+ compatible = "qcom,sdm845-rpmhpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+ rpmhpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmhpd_opp_ret: opp1 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_min_svs: opp2 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_low_svs: opp3 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_svs: opp4 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_svs_l1: opp5 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_nom: opp6 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_nom_l1: opp7 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_nom_l2: opp8 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_turbo_l1: opp10 {
+ qcom,level = ;
+ };
+ };
+
+Example: rpm power domain controller and OPP table
+
+ rpmpd: power-controller {
+ compatible = "qcom,msm8996-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmpd_opp_low: opp1 {
+ qcom,level = <1>;
+ };
+
+ rpmpd_opp_ret: opp2 {
+ qcom,level = <2>;
+ };
+
+ rpmpd_opp_svs: opp3 {
+ qcom,level = <3>;
+ };
+
+ rpmpd_opp_normal: opp4 {
+ qcom,level = <4>;
+ };
+
+ rpmpd_opp_high: opp5 {
+ qcom,level = <5>;
+ };
+
+ rpmpd_opp_turbo: opp6 {
+ qcom,level = <6>;
+ };
+ };
+
+Example: Client/Consumer device using OPP table
+
+ leaky-device0@1235 {
+ compatible = "foo,i-leak-current";
+ reg = <0x1235 0x1000>;
+ power-domains = < SDM845_MX>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+
+ leaky_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp1 {
+ opp-hz = /bits/ 64 <144000>;
+ required-opps = <_opp_low>;
+ };
+
+ opp2 {
+ opp-hz = /bits/ 64 <40>;
+ required-opps = <_opp_ret>;
+ };
+
+ opp3 {
+ opp-hz = /bits/ 64 <2000>;
+
[PATCH v4 3/6] soc: qcom: rpmpd: Add a Power domain driver to model corners
The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.
We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
Acked-by: Rob Herring
---
drivers/soc/qcom/Kconfig | 9 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmpd.c | 294 ++
3 files changed, 304 insertions(+)
create mode 100644 drivers/soc/qcom/rpmpd.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9dc02f390ba3..131da9d34a40 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
Say y here if you intend to boot the modem remoteproc.
+config QCOM_RPMPD
+ bool "Qualcomm RPM Power domain driver"
+ depends on MFD_QCOM_RPM && QCOM_SMD_RPM
+ help
+ QCOM RPM Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPM which then translates it into corresponding voltage
+ for the voltage rail.
+
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 19dcf957cb3a..9550c170de93 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..a0b9f122d793
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER 0x636676 /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+ static struct rpmpd _platform##_##_active; \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .peer = &_platform##_##_active, \
+ .res_type = RPMPD_SMPA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }; \
+ static struct rpmpd _platform##_##_active = { \
+ .pd = { .name = #_active, },\
+ .peer = &_platform##_##_name, \
+ .active_only = true,\
+ .res_type = RPMPD_SMPA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_type = RPMPD_LDOA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type) \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_type = r_type, \
+ .res_id = r_id, \
+ .key = KEY_FLOOR_CORNER,\
+ }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id) \
+ DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+
+#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id) \
+
[PATCH v4 2/6] dt-bindings: power: Add qcom rpm power domain driver bindings
Add DT bindings to describe the rpm/rpmh power domains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPM/RPMh, which then translates it into corresponding voltage on a
PMIC rail.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
---
.../devicetree/bindings/power/qcom,rpmpd.txt | 146 ++
include/dt-bindings/power/qcom-rpmpd.h| 39 +
2 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
create mode 100644 include/dt-bindings/power/qcom-rpmpd.h
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
new file mode 100644
index ..8825080afa5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -0,0 +1,146 @@
+Qualcomm RPM/RPMh Power domains
+
+For RPM/RPMh Power domains, we communicate a performance state to RPM/RPMh
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+ * qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+ * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
+ - power-domain-cells: number of cells in Power domain specifier
+ must be 1.
+ - operating-points-v2: Phandle to the OPP table for the Power domain.
+ Refer to Documentation/devicetree/bindings/power/power_domain.txt
+ and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Refer to for the level values for
+various OPPs for different platforms as well as Power domain indexes
+
+Example: rpmh power domain controller and OPP table
+
+#include
+
+qcom,level values specified in the OPP tables for RPMh power domains
+should use the RPMH_REGULATOR_LEVEL_* constants from
+
+
+ rpmhpd: power-controller {
+ compatible = "qcom,sdm845-rpmhpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+ rpmhpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmhpd_opp_ret: opp1 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_min_svs: opp2 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_low_svs: opp3 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_svs: opp4 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_svs_l1: opp5 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_nom: opp6 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_nom_l1: opp7 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_nom_l2: opp8 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ qcom,level = ;
+ };
+
+ rpmhpd_opp_turbo_l1: opp10 {
+ qcom,level = ;
+ };
+ };
+
+Example: rpm power domain controller and OPP table
+
+ rpmpd: power-controller {
+ compatible = "qcom,msm8996-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmpd_opp_low: opp1 {
+ qcom,level = <1>;
+ };
+
+ rpmpd_opp_ret: opp2 {
+ qcom,level = <2>;
+ };
+
+ rpmpd_opp_svs: opp3 {
+ qcom,level = <3>;
+ };
+
+ rpmpd_opp_normal: opp4 {
+ qcom,level = <4>;
+ };
+
+ rpmpd_opp_high: opp5 {
+ qcom,level = <5>;
+ };
+
+ rpmpd_opp_turbo: opp6 {
+ qcom,level = <6>;
+ };
+ };
+
+Example: Client/Consumer device using OPP table
+
+ leaky-device0@1235 {
+ compatible = "foo,i-leak-current";
+ reg = <0x1235 0x1000>;
+ power-domains = < SDM845_MX>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+
+ leaky_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp1 {
+ opp-hz = /bits/ 64 <144000>;
+ required-opps = <_opp_low>;
+ };
+
+ opp2 {
+ opp-hz = /bits/ 64 <40>;
+ required-opps = <_opp_ret>;
+ };
+
+ opp3 {
+ opp-hz = /bits/ 64 <2000>;
+
[PATCH v4 4/6] soc: qcom: rpmpd: Add support for get/set performance state
Add support for the .set_performace_state() and .opp_to_performance_state()
callbacks in the rpmpd driver.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
---
drivers/soc/qcom/rpmpd.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index a0b9f122d793..eb1cfa6a03d6 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,8 @@
#define KEY_ENABLE 0x6e657773 /* swen */
#define KEY_FLOOR_CORNER 0x636676 /* vfc */
+#define MAX_RPMPD_STATE6
+
#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
static struct rpmpd _platform##_##_active; \
static struct rpmpd _platform##_##_name = { \
@@ -221,6 +224,47 @@ static int rpmpd_power_off(struct generic_pm_domain
*domain)
return ret;
}
+static int rpmpd_set_performance(struct generic_pm_domain *domain,
+unsigned int state)
+{
+ int ret = 0;
+ struct rpmpd *pd = domain_to_rpmpd(domain);
+
+ mutex_lock(_lock);
+
+ if (state > MAX_RPMPD_STATE)
+ goto out;
+
+ pd->corner = state;
+
+ if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))
+ goto out;
+
+ ret = rpmpd_aggregate_corner(pd);
+
+out:
+ mutex_unlock(_lock);
+
+ return ret;
+}
+
+static unsigned int rpmpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+ struct device_node *np;
+ unsigned int corner = 0;
+
+ np = dev_pm_opp_get_of_node(opp);
+ if (of_property_read_u32(np, "qcom,level", )) {
+ pr_err("%s: missing 'qcom,level' property\n", __func__);
+ return 0;
+ }
+
+ of_node_put(np);
+
+ return corner;
+}
+
static int rpmpd_probe(struct platform_device *pdev)
{
int i;
@@ -261,6 +305,8 @@ static int rpmpd_probe(struct platform_device *pdev)
rpmpds[i]->rpm = rpm;
rpmpds[i]->pd.power_off = rpmpd_power_off;
rpmpds[i]->pd.power_on = rpmpd_power_on;
+ rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
+ rpmpds[i]->pd.opp_to_performance_state = rpmpd_get_performance;
pm_genpd_init([i]->pd, NULL, true);
data->domains[i] = [i]->pd;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 6/6] soc: qcom: rpmhpd: Add RPMh Power domain driver
The RPMh Power domain driver aggregates the corner votes from various
consumers for the ARC resources and communicates it to RPMh.
With RPMh we use 2 different numbering space for corners, one used
by the clients to express their performance needs, and another used
to communicate to RPMh hardware.
The clients express their performance requirements using a sparse
numbering space which are mapped to meaningful levels like RET, SVS,
NOMINAL, TURBO etc which then get mapped to another number space
between 0 and 15 which is communicated to RPMh. The sparse number space,
also referred to as vlvl is mapped to the continuous number space of 0
to 15, also referred to as hlvl, using command DB.
Some power domain clients could request a performance state only while
the CPU is active, while some others could request for a certain
performance state all the time regardless of the state of the CPU.
We handle this by internally aggregating the votes from both type of
clients and then send the aggregated votes to RPMh.
There are also 3 different types of Votes that are comunicated to RPMh
for every resource.
1. ACTIVE_ONLY: This specifies the requirement for the resource when the
CPU is active
2. SLEEP: This specifies the requirement for the resource when the CPU
is going to sleep
3. WAKE_ONLY: This specifies the requirement for the resource when the
CPU is coming out of sleep to active state
We add data for all power domains on sdm845 SoC as part of the patch.
The driver can be extended to support other SoCs which support RPMh
Signed-off-by: Rajendra Nayak
Reviewed-by: Ulf Hansson
---
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmhpd.c | 406 ++
3 files changed, 416 insertions(+)
create mode 100644 drivers/soc/qcom/rpmhpd.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 131da9d34a40..3cb6085a851d 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
Say y here if you intend to boot the modem remoteproc.
+config QCOM_RPMHPD
+ bool "Qualcomm RPMh Power domain driver"
+ depends on QCOM_RPMH && QCOM_COMMAND_DB
+ help
+ QCOM RPMh Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPMh which then translates it into corresponding voltage
+ for the voltage rail.
+
config QCOM_RPMPD
bool "Qualcomm RPM Power domain driver"
depends on MFD_QCOM_RPM && QCOM_SMD_RPM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 9550c170de93..499513f63bef 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM) += smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
+obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
new file mode 100644
index ..a364fa5aac57
--- /dev/null
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
+
+#define DEFINE_RPMHPD_AO(_platform, _name, _active)\
+ static struct rpmhpd _platform##_##_active; \
+ static struct rpmhpd _platform##_##_name = {\
+ .pd = { .name = #_name, }, \
+ .peer = &_platform##_##_active, \
+ .res_name = #_name".lvl", \
+ }; \
+ static struct rpmhpd _platform##_##_active = { \
+ .pd = { .name = #_active, },\
+ .peer = &_platform##_##_name, \
+ .active_only = true,\
+ .res_name = #_name".lvl", \
+ }
+
+#define DEFINE_RPMHPD(_platform, _name)
\
+ static struct rpmhpd _platform##_##_name = {\
+ .pd = { .name = #_name, }, \
+ .res_name = #_name".lvl", \
+ }
+
+/*
+ * This is the number of bytes used for each command DB aux data entry of an
+ * ARC resource.
+ */
+#define RPMH_ARC_LEVEL_SIZE2
+#define RPMH_ARC_MAX_LEVELS16
+
+/**
+ * struct rpmhpd - top level RPMh power domain resource data structure
+
[PATCH v4 1/6] dt-bindings: opp: Introduce qcom-opp bindings
On Qualcomm Technologies, Inc. platforms, an OPP node needs to describe an additional level/corner value that is then communicated to a remote microprocessor by the CPU, which then takes some actions (like adjusting voltage values across various rails) based on the value passed. Describe these bindings in the qcom-opp bindings document. Signed-off-by: Rajendra Nayak Acked-by: Viresh Kumar Reviewed-by: Rob Herring --- .../devicetree/bindings/opp/qcom-opp.txt | 25 +++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt new file mode 100644 index ..db4d970c7ec7 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt @@ -0,0 +1,25 @@ +Qualcomm OPP bindings to descibe OPP nodes with corner/level values + +OPP tables for devices on Qualcomm platforms require an additional +platform specific corner/level value to be specified. +This value is passed on to the RPM (Resource Power Manager) by +the CPU, which then takes the necessary actions to set a voltage +rail to an appropriate voltage based on the value passed. + +The bindings are based on top of the operating-points-v2 bindings +described in Documentation/devicetree/bindings/opp/opp.txt +Additional properties are described below. + +* OPP Table Node + +Required properties: +- compatible: Allow OPPs to express their compatibility. It should be: + "operating-points-v2-qcom-level" + +* OPP Node + +Required properties: +- qcom,level: On Qualcomm platforms an OPP node can describe a positive value +representing a corner/level that's communicated with a remote microprocessor +(usually called the RPM) which then translates it into a certain voltage on +a voltage rail. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 4/6] soc: qcom: rpmpd: Add support for get/set performance state
Add support for the .set_performace_state() and .opp_to_performance_state()
callbacks in the rpmpd driver.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
---
drivers/soc/qcom/rpmpd.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index a0b9f122d793..eb1cfa6a03d6 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,8 @@
#define KEY_ENABLE 0x6e657773 /* swen */
#define KEY_FLOOR_CORNER 0x636676 /* vfc */
+#define MAX_RPMPD_STATE6
+
#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
static struct rpmpd _platform##_##_active; \
static struct rpmpd _platform##_##_name = { \
@@ -221,6 +224,47 @@ static int rpmpd_power_off(struct generic_pm_domain
*domain)
return ret;
}
+static int rpmpd_set_performance(struct generic_pm_domain *domain,
+unsigned int state)
+{
+ int ret = 0;
+ struct rpmpd *pd = domain_to_rpmpd(domain);
+
+ mutex_lock(_lock);
+
+ if (state > MAX_RPMPD_STATE)
+ goto out;
+
+ pd->corner = state;
+
+ if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))
+ goto out;
+
+ ret = rpmpd_aggregate_corner(pd);
+
+out:
+ mutex_unlock(_lock);
+
+ return ret;
+}
+
+static unsigned int rpmpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+ struct device_node *np;
+ unsigned int corner = 0;
+
+ np = dev_pm_opp_get_of_node(opp);
+ if (of_property_read_u32(np, "qcom,level", )) {
+ pr_err("%s: missing 'qcom,level' property\n", __func__);
+ return 0;
+ }
+
+ of_node_put(np);
+
+ return corner;
+}
+
static int rpmpd_probe(struct platform_device *pdev)
{
int i;
@@ -261,6 +305,8 @@ static int rpmpd_probe(struct platform_device *pdev)
rpmpds[i]->rpm = rpm;
rpmpds[i]->pd.power_off = rpmpd_power_off;
rpmpds[i]->pd.power_on = rpmpd_power_on;
+ rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
+ rpmpds[i]->pd.opp_to_performance_state = rpmpd_get_performance;
pm_genpd_init([i]->pd, NULL, true);
data->domains[i] = [i]->pd;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 6/6] soc: qcom: rpmhpd: Add RPMh Power domain driver
The RPMh Power domain driver aggregates the corner votes from various
consumers for the ARC resources and communicates it to RPMh.
With RPMh we use 2 different numbering space for corners, one used
by the clients to express their performance needs, and another used
to communicate to RPMh hardware.
The clients express their performance requirements using a sparse
numbering space which are mapped to meaningful levels like RET, SVS,
NOMINAL, TURBO etc which then get mapped to another number space
between 0 and 15 which is communicated to RPMh. The sparse number space,
also referred to as vlvl is mapped to the continuous number space of 0
to 15, also referred to as hlvl, using command DB.
Some power domain clients could request a performance state only while
the CPU is active, while some others could request for a certain
performance state all the time regardless of the state of the CPU.
We handle this by internally aggregating the votes from both type of
clients and then send the aggregated votes to RPMh.
There are also 3 different types of Votes that are comunicated to RPMh
for every resource.
1. ACTIVE_ONLY: This specifies the requirement for the resource when the
CPU is active
2. SLEEP: This specifies the requirement for the resource when the CPU
is going to sleep
3. WAKE_ONLY: This specifies the requirement for the resource when the
CPU is coming out of sleep to active state
We add data for all power domains on sdm845 SoC as part of the patch.
The driver can be extended to support other SoCs which support RPMh
Signed-off-by: Rajendra Nayak
Reviewed-by: Ulf Hansson
---
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmhpd.c | 406 ++
3 files changed, 416 insertions(+)
create mode 100644 drivers/soc/qcom/rpmhpd.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 131da9d34a40..3cb6085a851d 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
Say y here if you intend to boot the modem remoteproc.
+config QCOM_RPMHPD
+ bool "Qualcomm RPMh Power domain driver"
+ depends on QCOM_RPMH && QCOM_COMMAND_DB
+ help
+ QCOM RPMh Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPMh which then translates it into corresponding voltage
+ for the voltage rail.
+
config QCOM_RPMPD
bool "Qualcomm RPM Power domain driver"
depends on MFD_QCOM_RPM && QCOM_SMD_RPM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 9550c170de93..499513f63bef 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM) += smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
+obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
new file mode 100644
index ..a364fa5aac57
--- /dev/null
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
+
+#define DEFINE_RPMHPD_AO(_platform, _name, _active)\
+ static struct rpmhpd _platform##_##_active; \
+ static struct rpmhpd _platform##_##_name = {\
+ .pd = { .name = #_name, }, \
+ .peer = &_platform##_##_active, \
+ .res_name = #_name".lvl", \
+ }; \
+ static struct rpmhpd _platform##_##_active = { \
+ .pd = { .name = #_active, },\
+ .peer = &_platform##_##_name, \
+ .active_only = true,\
+ .res_name = #_name".lvl", \
+ }
+
+#define DEFINE_RPMHPD(_platform, _name)
\
+ static struct rpmhpd _platform##_##_name = {\
+ .pd = { .name = #_name, }, \
+ .res_name = #_name".lvl", \
+ }
+
+/*
+ * This is the number of bytes used for each command DB aux data entry of an
+ * ARC resource.
+ */
+#define RPMH_ARC_LEVEL_SIZE2
+#define RPMH_ARC_MAX_LEVELS16
+
+/**
+ * struct rpmhpd - top level RPMh power domain resource data structure
+
[PATCH v4 1/6] dt-bindings: opp: Introduce qcom-opp bindings
On Qualcomm Technologies, Inc. platforms, an OPP node needs to describe an additional level/corner value that is then communicated to a remote microprocessor by the CPU, which then takes some actions (like adjusting voltage values across various rails) based on the value passed. Describe these bindings in the qcom-opp bindings document. Signed-off-by: Rajendra Nayak Acked-by: Viresh Kumar Reviewed-by: Rob Herring --- .../devicetree/bindings/opp/qcom-opp.txt | 25 +++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt new file mode 100644 index ..db4d970c7ec7 --- /dev/null +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt @@ -0,0 +1,25 @@ +Qualcomm OPP bindings to descibe OPP nodes with corner/level values + +OPP tables for devices on Qualcomm platforms require an additional +platform specific corner/level value to be specified. +This value is passed on to the RPM (Resource Power Manager) by +the CPU, which then takes the necessary actions to set a voltage +rail to an appropriate voltage based on the value passed. + +The bindings are based on top of the operating-points-v2 bindings +described in Documentation/devicetree/bindings/opp/opp.txt +Additional properties are described below. + +* OPP Table Node + +Required properties: +- compatible: Allow OPPs to express their compatibility. It should be: + "operating-points-v2-qcom-level" + +* OPP Node + +Required properties: +- qcom,level: On Qualcomm platforms an OPP node can describe a positive value +representing a corner/level that's communicated with a remote microprocessor +(usually called the RPM) which then translates it into a certain voltage on +a voltage rail. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 5/6] arm64: dts: msm8996: Add rpmpd device node
Add rpmpd device node and its OPP table
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 8c7f9ca25b53..404a08630ccd 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -308,6 +308,40 @@
#clock-cells = <1>;
};
+ rpmpd: power-controller {
+ compatible = "qcom,msm8996-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmpd_opp1: opp1 {
+ qcom,level = <1>;
+ };
+
+ rpmpd_opp2: opp2 {
+ qcom,level = <2>;
+ };
+
+ rpmpd_opp3: opp3 {
+ qcom,level = <3>;
+ };
+
+ rpmpd_opp4: opp4 {
+ qcom,level = <4>;
+ };
+
+ rpmpd_opp5: opp5 {
+ qcom,level = <5>;
+ };
+
+ rpmpd_opp6: opp6 {
+ qcom,level = <6>;
+ };
+ };
+
pm8994-regulators {
compatible = "qcom,rpm-pm8994-regulators";
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 5/6] arm64: dts: msm8996: Add rpmpd device node
Add rpmpd device node and its OPP table
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
Reviewed-by: Ulf Hansson
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 8c7f9ca25b53..404a08630ccd 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -308,6 +308,40 @@
#clock-cells = <1>;
};
+ rpmpd: power-controller {
+ compatible = "qcom,msm8996-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <_opp_table>;
+ };
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmpd_opp1: opp1 {
+ qcom,level = <1>;
+ };
+
+ rpmpd_opp2: opp2 {
+ qcom,level = <2>;
+ };
+
+ rpmpd_opp3: opp3 {
+ qcom,level = <3>;
+ };
+
+ rpmpd_opp4: opp4 {
+ qcom,level = <4>;
+ };
+
+ rpmpd_opp5: opp5 {
+ qcom,level = <5>;
+ };
+
+ rpmpd_opp6: opp6 {
+ qcom,level = <6>;
+ };
+ };
+
pm8994-regulators {
compatible = "qcom,rpm-pm8994-regulators";
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 0/6] Add power domain driver for corners on msm8996/sdm845
Changes in v4: * Included the patch to add qcom-opp bindings (dropped accidentally in v3) * merged the patches to add bindings for rpm and rpmh, added consumer binding example * Made the drivers built in, removed .remove * Added better description in changelog for PATCH 6/6 * Updated rpmhpd_aggregate_corner() based on Davids feedback * rpmhpd_set_performance_state() returns max corner, in cases where its called with an INT_MAX * Dropped the patch to max vote on all corners at init, the patch did not work anyway, and it shouldn't be needed now Changes in v3: * Bindings split into seperate patches * Bindings updated to remove duplicate OPP table phandles * DT headers defining macros for Power domain indexes and OPP levels * Optimisations to use rpmh_write_async() whereever applicable * Fixed up handling of ACTIVE_ONLY/WAKE_ONLY/SLEEP voting for RPMh * Fixed the vlvl to hlvl conversions in set_performance * Other minor fixes based on review of v2 * TODO: This series does not handle the case where all VDD_MX votes should be higher than VDD_CX from APPs, as pointed out by David Collins in v2. This needs support at genpd to propogate performance state up the parents, if we model these as Parent/Child to handle the interdependency. Changes in v2: * added a power domain driver for sdm845 which supports communicating to RPMh * dropped the changes to sdhc driver to move over to using OPP as there is active discussion on using OPP as the interface vs handling all of it in clock drivers * Other minor binding updates based on review of v1 With performance state support for genpd/OPP merged, this is an effort to model a power domain driver to communicate corner/level values for qualcomm platforms to RPM (Remote Power Manager) and RPMh. Rajendra Nayak (6): dt-bindings: opp: Introduce qcom-opp bindings dt-bindings: power: Add qcom rpm power domain driver bindings soc: qcom: rpmpd: Add a Power domain driver to model corners soc: qcom: rpmpd: Add support for get/set performance state arm64: dts: msm8996: Add rpmpd device node soc: qcom: rpmhpd: Add RPMh Power domain driver .../devicetree/bindings/opp/qcom-opp.txt | 25 ++ .../devicetree/bindings/power/qcom,rpmpd.txt | 146 +++ arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ drivers/soc/qcom/Kconfig | 18 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/rpmhpd.c | 406 ++ drivers/soc/qcom/rpmpd.c | 340 +++ include/dt-bindings/power/qcom-rpmpd.h| 39 ++ 8 files changed, 1010 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt create mode 100644 drivers/soc/qcom/rpmhpd.c create mode 100644 drivers/soc/qcom/rpmpd.c create mode 100644 include/dt-bindings/power/qcom-rpmpd.h -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v4 0/6] Add power domain driver for corners on msm8996/sdm845
Changes in v4: * Included the patch to add qcom-opp bindings (dropped accidentally in v3) * merged the patches to add bindings for rpm and rpmh, added consumer binding example * Made the drivers built in, removed .remove * Added better description in changelog for PATCH 6/6 * Updated rpmhpd_aggregate_corner() based on Davids feedback * rpmhpd_set_performance_state() returns max corner, in cases where its called with an INT_MAX * Dropped the patch to max vote on all corners at init, the patch did not work anyway, and it shouldn't be needed now Changes in v3: * Bindings split into seperate patches * Bindings updated to remove duplicate OPP table phandles * DT headers defining macros for Power domain indexes and OPP levels * Optimisations to use rpmh_write_async() whereever applicable * Fixed up handling of ACTIVE_ONLY/WAKE_ONLY/SLEEP voting for RPMh * Fixed the vlvl to hlvl conversions in set_performance * Other minor fixes based on review of v2 * TODO: This series does not handle the case where all VDD_MX votes should be higher than VDD_CX from APPs, as pointed out by David Collins in v2. This needs support at genpd to propogate performance state up the parents, if we model these as Parent/Child to handle the interdependency. Changes in v2: * added a power domain driver for sdm845 which supports communicating to RPMh * dropped the changes to sdhc driver to move over to using OPP as there is active discussion on using OPP as the interface vs handling all of it in clock drivers * Other minor binding updates based on review of v1 With performance state support for genpd/OPP merged, this is an effort to model a power domain driver to communicate corner/level values for qualcomm platforms to RPM (Remote Power Manager) and RPMh. Rajendra Nayak (6): dt-bindings: opp: Introduce qcom-opp bindings dt-bindings: power: Add qcom rpm power domain driver bindings soc: qcom: rpmpd: Add a Power domain driver to model corners soc: qcom: rpmpd: Add support for get/set performance state arm64: dts: msm8996: Add rpmpd device node soc: qcom: rpmhpd: Add RPMh Power domain driver .../devicetree/bindings/opp/qcom-opp.txt | 25 ++ .../devicetree/bindings/power/qcom,rpmpd.txt | 146 +++ arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++ drivers/soc/qcom/Kconfig | 18 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/rpmhpd.c | 406 ++ drivers/soc/qcom/rpmpd.c | 340 +++ include/dt-bindings/power/qcom-rpmpd.h| 39 ++ 8 files changed, 1010 insertions(+) create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt create mode 100644 drivers/soc/qcom/rpmhpd.c create mode 100644 drivers/soc/qcom/rpmpd.c create mode 100644 include/dt-bindings/power/qcom-rpmpd.h -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH tip/core/rcu 16/27] rcu: Add comment documenting how rcu_seq_snap works
On Tue, Jun 26, 2018 at 07:30:55PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 05:35:02PM -0700, Paul E. McKenney wrote:
> > +/*
> > + * rcu_seq_snap - Take a snapshot of the update side's sequence number.
> > + *
> > + * This function returns the earliest value of the grace-period sequence
> > number
> > + * that will indicate that a full grace period has elapsed since the
> > current
> > + * time. Once the grace-period sequence number has reached this value, it
> > will
> > + * be safe to invoke all callbacks that have been registered prior to the
> > + * current time. This value is the current grace-period number plus two to
> > the
> > + * power of the number of low-order bits reserved for state, then rounded
> > up to
> > + * the next value in which the state bits are all zero.
>
> If you complete that by saying _why_ you need to round up there, then
> the below verbiage is completely redundant.
>
> > + * In the current design, RCU_SEQ_STATE_MASK=3 and the least significant
> > bit of
> > + * the seq is used to track if a GP is in progress or not. Given this, it
> > is
> > + * sufficient if we add (6+1) and mask with ~3 to get the next GP. Let's
> > see
> > + * why with an example:
> > + *
> > + * Say the current seq is 12 which is 0b1100 (GP is 3 and state bits are
> > 0b00).
> > + * To get to the next GP number of 4, we have to add 0b100 to this (0x1 <<
> > 2)
> > + * to account for the shift due to 2 state bits. Now, if the current seq is
> > + * 13 (GP is 3 and state bits are 0b01), then it means the current grace
> > period
> > + * is already in progress so the next GP that a future call back will be
> > queued
> > + * to run at is GP+2 = 5, not 4. To account for the extra +1, we just
> > overflow
> > + * the 2 lower bits by adding 0b11. In case the lower bit was set, the
> > overflow
> > + * will cause the extra +1 to the GP, along with the usual +1 explained
> > before.
> > + * This gives us GP+2. Finally we mask the lower to bits by ~0x3 in case
> > the
> > + * overflow didn't occur. This masking is needed because in case RCU was
> > idle
> > + * (no GP in progress so lower 2 bits are 0b00), then the overflow of the
> > lower
> > + * 2 state bits wouldn't occur, so we mask to zero out those lower 2 bits.
> > + *
> > + * In other words, the next seq can be obtained by (0b11 + 0b100) & (~0b11)
> > + * which can be generalized to:
> > + * seq + (RCU_SEQ_STATE_MASK + (RCU_SEQ_STATE_MASK + 1)) &
> > (~RCU_SEQ_STATE_MASK)
> > + */
>
> Is the below not much simpler:
>
> > static inline unsigned long rcu_seq_snap(unsigned long *sp)
> > {
> > unsigned long s;
>
> s = smp_load_aquire(sp);
>
> /* Add one GP */
> s += 1 << RCU_SEQ_CTR_SHIFT;
>
> /* Complete any pending state by rounding up */
I would suggest this comment be changed to "Add another GP if there was a
pending state".
> s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
>
I agree with Peter's suggestions for both the verbiage reduction in the
comments in the header, as the new code he is proposing is more
self-documenting. I believe I proposed a big comment just because the code
wasn't self-documenting or obvious previously so needed an explanation.
How would you like to proceed? Let me know what you guys decide, I am really
Ok with anything. If you guys agree, should I write a follow-up patch with
Peter's suggestion that applies on top of this one? Or do we want to drop
this one in favor of Peter's suggestion?
I guess we also have to conclude the other part about using memory barriers,
but I think that should be a separate patch.
thanks!
- Joel
Re: [PATCH tip/core/rcu 16/27] rcu: Add comment documenting how rcu_seq_snap works
On Tue, Jun 26, 2018 at 07:30:55PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 05:35:02PM -0700, Paul E. McKenney wrote:
> > +/*
> > + * rcu_seq_snap - Take a snapshot of the update side's sequence number.
> > + *
> > + * This function returns the earliest value of the grace-period sequence
> > number
> > + * that will indicate that a full grace period has elapsed since the
> > current
> > + * time. Once the grace-period sequence number has reached this value, it
> > will
> > + * be safe to invoke all callbacks that have been registered prior to the
> > + * current time. This value is the current grace-period number plus two to
> > the
> > + * power of the number of low-order bits reserved for state, then rounded
> > up to
> > + * the next value in which the state bits are all zero.
>
> If you complete that by saying _why_ you need to round up there, then
> the below verbiage is completely redundant.
>
> > + * In the current design, RCU_SEQ_STATE_MASK=3 and the least significant
> > bit of
> > + * the seq is used to track if a GP is in progress or not. Given this, it
> > is
> > + * sufficient if we add (6+1) and mask with ~3 to get the next GP. Let's
> > see
> > + * why with an example:
> > + *
> > + * Say the current seq is 12 which is 0b1100 (GP is 3 and state bits are
> > 0b00).
> > + * To get to the next GP number of 4, we have to add 0b100 to this (0x1 <<
> > 2)
> > + * to account for the shift due to 2 state bits. Now, if the current seq is
> > + * 13 (GP is 3 and state bits are 0b01), then it means the current grace
> > period
> > + * is already in progress so the next GP that a future call back will be
> > queued
> > + * to run at is GP+2 = 5, not 4. To account for the extra +1, we just
> > overflow
> > + * the 2 lower bits by adding 0b11. In case the lower bit was set, the
> > overflow
> > + * will cause the extra +1 to the GP, along with the usual +1 explained
> > before.
> > + * This gives us GP+2. Finally we mask the lower to bits by ~0x3 in case
> > the
> > + * overflow didn't occur. This masking is needed because in case RCU was
> > idle
> > + * (no GP in progress so lower 2 bits are 0b00), then the overflow of the
> > lower
> > + * 2 state bits wouldn't occur, so we mask to zero out those lower 2 bits.
> > + *
> > + * In other words, the next seq can be obtained by (0b11 + 0b100) & (~0b11)
> > + * which can be generalized to:
> > + * seq + (RCU_SEQ_STATE_MASK + (RCU_SEQ_STATE_MASK + 1)) &
> > (~RCU_SEQ_STATE_MASK)
> > + */
>
> Is the below not much simpler:
>
> > static inline unsigned long rcu_seq_snap(unsigned long *sp)
> > {
> > unsigned long s;
>
> s = smp_load_aquire(sp);
>
> /* Add one GP */
> s += 1 << RCU_SEQ_CTR_SHIFT;
>
> /* Complete any pending state by rounding up */
I would suggest this comment be changed to "Add another GP if there was a
pending state".
> s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
>
I agree with Peter's suggestions for both the verbiage reduction in the
comments in the header, as the new code he is proposing is more
self-documenting. I believe I proposed a big comment just because the code
wasn't self-documenting or obvious previously so needed an explanation.
How would you like to proceed? Let me know what you guys decide, I am really
Ok with anything. If you guys agree, should I write a follow-up patch with
Peter's suggestion that applies on top of this one? Or do we want to drop
this one in favor of Peter's suggestion?
I guess we also have to conclude the other part about using memory barriers,
but I think that should be a separate patch.
thanks!
- Joel
linux-next: Tree for Jun 27
Hi all, Changes since 20180626: The btrfs-kdave tree gained a build failure so I used the version from next-20180626. The rdma tree gained a conflict against the rdma-fixes tree. The drm tree still had its build failure for which I disabled some sample code. Non-merge commits (relative to Linus' tree): 2472 2673 files changed, 84090 insertions(+), 42546 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 281 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (813835028e9a Merge branch 'fixes-v4.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (4c1b0de3c413 kconfig: loop boundary condition fix) Merging arc-current/for-curr (6ddb19a32e79 ARC: Improve cmpxchg syscall implementation) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (71c8fc0c96ab arm64: mm: Ensure writes to swapper are ordered wrt subsequent cache maintenance) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (fadd03c61592 powerpc/mm/hash/4k: Free hugetlb page table caches correctly.) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (094bdaddf129 Merge branch 'lan78xx-minor-fixes') Merging bpf/master (dd349c3ffd93 selftests: bpf: notification about privilege required to run test_lwt_seg6local.sh testing script) Merging ipsec/master (86126b77dcd5 xfrm: free skb if nlsk pointer is NULL) Merging netfilter/master (b36e4523d4d5 netfilter: nf_conncount: fix garbage collection confirm race) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (92963318a255 mt7601u: remove warning when avg_rssi is zero) Merging mac80211/master (bf2b61a6838f cfg80211: fix rcu in cfg80211_unregister_wdev) Merging rdma-fixes/for-rc (b697d7d8c741 IB/hfi1: Fix incorrect mixing of ERR_PTR and NULL return values) Merging sound-current/for-linus (c9a4c63888db ALSA: seq: Fix UBSAN warning at SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT ioctl) Merging sound-asoc-fixes/for-linus (f930c55cd8dd Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (7daf201d7fe8 Linux 4.18-rc2) Merging regulator-fixes/for-linus (50635ef0b99b Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (58c2ec73d535 Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (925d31668d5b PCI: controller: Move PCI_DOMAINS selection to arch Kconfig) Merging driver-core.current/driver-core-linus (7daf201d7fe8 Linux 4.18-rc2) Merging tty.current/tty-linus (ce397d215ccd Linux 4.18-rc1) Merging usb.current/usb-linus (90f26cc6bb90 usb: chipidea: host: fix disconnection detect issue) Merging usb-gadget-fixes/fixes (1d8e5c002758 dwc2: gadget: Fix ISOC IN DDMA PID bitfield value calculation) Merging usb-serial-fixes/usb-linus (24160628a34a USB: serial: cp210x: add CESINEL dev
linux-next: Tree for Jun 27
Hi all, Changes since 20180626: The btrfs-kdave tree gained a build failure so I used the version from next-20180626. The rdma tree gained a conflict against the rdma-fixes tree. The drm tree still had its build failure for which I disabled some sample code. Non-merge commits (relative to Linus' tree): 2472 2673 files changed, 84090 insertions(+), 42546 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 281 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (813835028e9a Merge branch 'fixes-v4.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (4c1b0de3c413 kconfig: loop boundary condition fix) Merging arc-current/for-curr (6ddb19a32e79 ARC: Improve cmpxchg syscall implementation) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (71c8fc0c96ab arm64: mm: Ensure writes to swapper are ordered wrt subsequent cache maintenance) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (fadd03c61592 powerpc/mm/hash/4k: Free hugetlb page table caches correctly.) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (094bdaddf129 Merge branch 'lan78xx-minor-fixes') Merging bpf/master (dd349c3ffd93 selftests: bpf: notification about privilege required to run test_lwt_seg6local.sh testing script) Merging ipsec/master (86126b77dcd5 xfrm: free skb if nlsk pointer is NULL) Merging netfilter/master (b36e4523d4d5 netfilter: nf_conncount: fix garbage collection confirm race) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (92963318a255 mt7601u: remove warning when avg_rssi is zero) Merging mac80211/master (bf2b61a6838f cfg80211: fix rcu in cfg80211_unregister_wdev) Merging rdma-fixes/for-rc (b697d7d8c741 IB/hfi1: Fix incorrect mixing of ERR_PTR and NULL return values) Merging sound-current/for-linus (c9a4c63888db ALSA: seq: Fix UBSAN warning at SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT ioctl) Merging sound-asoc-fixes/for-linus (f930c55cd8dd Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (7daf201d7fe8 Linux 4.18-rc2) Merging regulator-fixes/for-linus (50635ef0b99b Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (58c2ec73d535 Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (925d31668d5b PCI: controller: Move PCI_DOMAINS selection to arch Kconfig) Merging driver-core.current/driver-core-linus (7daf201d7fe8 Linux 4.18-rc2) Merging tty.current/tty-linus (ce397d215ccd Linux 4.18-rc1) Merging usb.current/usb-linus (90f26cc6bb90 usb: chipidea: host: fix disconnection detect issue) Merging usb-gadget-fixes/fixes (1d8e5c002758 dwc2: gadget: Fix ISOC IN DDMA PID bitfield value calculation) Merging usb-serial-fixes/usb-linus (24160628a34a USB: serial: cp210x: add CESINEL dev
[PATCH v2] riscv: Add support to no-FPU systems
This patch adds an option, CONFIG_FPU, to enable/disable floating
procedures. Also, some style issues are fixed.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Zong Li
---
arch/riscv/Kconfig | 9
arch/riscv/Makefile| 19 +++
arch/riscv/include/asm/switch_to.h | 6 +++
arch/riscv/kernel/entry.S | 3 +-
arch/riscv/kernel/process.c| 7 ++-
arch/riscv/kernel/signal.c | 82 +-
6 files changed, 90 insertions(+), 36 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6debcc4afc72..6069597ba73f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -232,6 +232,15 @@ config RISCV_BASE_PMU
endmenu
+config FPU
+ bool "FPU support"
+ default y
+ help
+ Say N here if you want to disable all floating-point related procedure
+ in the kernel.
+
+ If you don't know what to do here, say Y.
+
endmenu
menu "Kernel type"
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 6d4a5f6c3f4f..ad3033739430 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y)
KBUILD_CFLAGS += -mabi=lp64
KBUILD_AFLAGS += -mabi=lp64
- KBUILD_MARCH = rv64im
LDFLAGS += -melf64lriscv
else
BITS := 32
@@ -34,22 +33,20 @@ else
KBUILD_CFLAGS += -mabi=ilp32
KBUILD_AFLAGS += -mabi=ilp32
- KBUILD_MARCH = rv32im
LDFLAGS += -melf32lriscv
endif
KBUILD_CFLAGS += -Wall
-ifeq ($(CONFIG_RISCV_ISA_A),y)
- KBUILD_ARCH_A = a
-endif
-ifeq ($(CONFIG_RISCV_ISA_C),y)
- KBUILD_ARCH_C = c
-endif
-
-KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C)
+# ISA string setting
+riscv-march-$(CONFIG_ARCH_RV32I) := rv32im
+riscv-march-$(CONFIG_ARCH_RV64I) := rv64im
+riscv-march-$(CONFIG_RISCV_ISA_A) := $(riscv-march-y)a
+riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd
+riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c
+KBUILD_CFLAGS += -march=$(riscv-march-y)
+KBUILD_AFLAGS += -march=$(riscv-march-y)
-KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C)
KBUILD_CFLAGS += -mno-save-restore
KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
diff --git a/arch/riscv/include/asm/switch_to.h
b/arch/riscv/include/asm/switch_to.h
index dd6b05bff75b..de333c012227 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -18,6 +18,7 @@
#include
#include
+#ifdef CONFIG_FPU
extern void __fstate_save(struct task_struct *save_to);
extern void __fstate_restore(struct task_struct *restore_from);
@@ -54,6 +55,11 @@ static inline void __switch_to_aux(struct task_struct *prev,
fstate_save(prev, regs);
fstate_restore(next, task_pt_regs(next));
}
+#else
+#define fstate_save(task, regs) do { } while (0)
+#define fstate_restore(task, regs) do { } while (0)
+#define __switch_to_aux(__prev, __next)
+#endif
extern struct task_struct *__switch_to(struct task_struct *,
struct task_struct *);
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 9aaf6c986771..89867c9aa4f5 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -357,6 +357,7 @@ ENTRY(__switch_to)
ret
ENDPROC(__switch_to)
+#ifdef CONFIG_FPU
ENTRY(__fstate_save)
li a2, TASK_THREAD_F0
add a0, a0, a2
@@ -442,7 +443,7 @@ ENTRY(__fstate_restore)
csrc sstatus, t1
ret
ENDPROC(__fstate_restore)
-
+#endif
.section ".rodata"
/* Exception vector table */
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index cb209139ba53..99d20283bb62 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -83,7 +83,12 @@ void show_regs(struct pt_regs *regs)
void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
- regs->sstatus = SR_SPIE /* User mode, irqs on */ | SR_FS_INITIAL;
+ /* User mode, irqs on */
+#ifdef CONFIG_FPU
+ regs->sstatus = SR_SPIE | SR_FS_INITIAL;
+#else
+ regs->sstatus = SR_SPIE | SR_FS_OFF;
+#endif
regs->sepc = pc;
regs->sp = sp;
set_fs(USER_DS);
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 718d0c984ef0..a7a5ed5598a8 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,8 +37,9 @@ struct rt_sigframe {
struct ucontext uc;
};
-static long restore_d_state(struct pt_regs *regs,
- struct __riscv_d_ext_state __user *state)
+#ifdef CONFIG_FPU
+static inline long __restore_d_state(struct pt_regs *regs,
+struct __riscv_d_ext_state __user *state)
{
long err;
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
@@ -47,35 +48,75 @@ static long restore_d_state(struct pt_regs *regs,
[PATCH v2] riscv: Add support to no-FPU systems
This patch adds an option, CONFIG_FPU, to enable/disable floating
procedures. Also, some style issues are fixed.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Zong Li
---
arch/riscv/Kconfig | 9
arch/riscv/Makefile| 19 +++
arch/riscv/include/asm/switch_to.h | 6 +++
arch/riscv/kernel/entry.S | 3 +-
arch/riscv/kernel/process.c| 7 ++-
arch/riscv/kernel/signal.c | 82 +-
6 files changed, 90 insertions(+), 36 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6debcc4afc72..6069597ba73f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -232,6 +232,15 @@ config RISCV_BASE_PMU
endmenu
+config FPU
+ bool "FPU support"
+ default y
+ help
+ Say N here if you want to disable all floating-point related procedure
+ in the kernel.
+
+ If you don't know what to do here, say Y.
+
endmenu
menu "Kernel type"
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 6d4a5f6c3f4f..ad3033739430 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y)
KBUILD_CFLAGS += -mabi=lp64
KBUILD_AFLAGS += -mabi=lp64
- KBUILD_MARCH = rv64im
LDFLAGS += -melf64lriscv
else
BITS := 32
@@ -34,22 +33,20 @@ else
KBUILD_CFLAGS += -mabi=ilp32
KBUILD_AFLAGS += -mabi=ilp32
- KBUILD_MARCH = rv32im
LDFLAGS += -melf32lriscv
endif
KBUILD_CFLAGS += -Wall
-ifeq ($(CONFIG_RISCV_ISA_A),y)
- KBUILD_ARCH_A = a
-endif
-ifeq ($(CONFIG_RISCV_ISA_C),y)
- KBUILD_ARCH_C = c
-endif
-
-KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C)
+# ISA string setting
+riscv-march-$(CONFIG_ARCH_RV32I) := rv32im
+riscv-march-$(CONFIG_ARCH_RV64I) := rv64im
+riscv-march-$(CONFIG_RISCV_ISA_A) := $(riscv-march-y)a
+riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd
+riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c
+KBUILD_CFLAGS += -march=$(riscv-march-y)
+KBUILD_AFLAGS += -march=$(riscv-march-y)
-KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C)
KBUILD_CFLAGS += -mno-save-restore
KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
diff --git a/arch/riscv/include/asm/switch_to.h
b/arch/riscv/include/asm/switch_to.h
index dd6b05bff75b..de333c012227 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -18,6 +18,7 @@
#include
#include
+#ifdef CONFIG_FPU
extern void __fstate_save(struct task_struct *save_to);
extern void __fstate_restore(struct task_struct *restore_from);
@@ -54,6 +55,11 @@ static inline void __switch_to_aux(struct task_struct *prev,
fstate_save(prev, regs);
fstate_restore(next, task_pt_regs(next));
}
+#else
+#define fstate_save(task, regs) do { } while (0)
+#define fstate_restore(task, regs) do { } while (0)
+#define __switch_to_aux(__prev, __next)
+#endif
extern struct task_struct *__switch_to(struct task_struct *,
struct task_struct *);
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 9aaf6c986771..89867c9aa4f5 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -357,6 +357,7 @@ ENTRY(__switch_to)
ret
ENDPROC(__switch_to)
+#ifdef CONFIG_FPU
ENTRY(__fstate_save)
li a2, TASK_THREAD_F0
add a0, a0, a2
@@ -442,7 +443,7 @@ ENTRY(__fstate_restore)
csrc sstatus, t1
ret
ENDPROC(__fstate_restore)
-
+#endif
.section ".rodata"
/* Exception vector table */
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index cb209139ba53..99d20283bb62 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -83,7 +83,12 @@ void show_regs(struct pt_regs *regs)
void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
- regs->sstatus = SR_SPIE /* User mode, irqs on */ | SR_FS_INITIAL;
+ /* User mode, irqs on */
+#ifdef CONFIG_FPU
+ regs->sstatus = SR_SPIE | SR_FS_INITIAL;
+#else
+ regs->sstatus = SR_SPIE | SR_FS_OFF;
+#endif
regs->sepc = pc;
regs->sp = sp;
set_fs(USER_DS);
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 718d0c984ef0..a7a5ed5598a8 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,8 +37,9 @@ struct rt_sigframe {
struct ucontext uc;
};
-static long restore_d_state(struct pt_regs *regs,
- struct __riscv_d_ext_state __user *state)
+#ifdef CONFIG_FPU
+static inline long __restore_d_state(struct pt_regs *regs,
+struct __riscv_d_ext_state __user *state)
{
long err;
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
@@ -47,35 +48,75 @@ static long restore_d_state(struct pt_regs *regs,
Re: [PATCH 1/5] i2c: smbus: add unlocked __i2c_smbus_xfer variant
On June 26, 2018 3:46:07 PM GMT+02:00, Wolfram Sang wrote: >> I don't think it's that easy as I just thought about another problem >> with lifting the locking from the emulation function. It calls >> kzalloc(..., GFP_KERNEL), at least in some cases, and that's not a >> very good idea from atomic/irq context... > >Right. However, we could simply bail out early when we are in atomic >context. Simply no DMA then... Yeah, we could bail out early, and perhaps we should. But we risk regressions, see below... And that should probably be fixed before we add the unlocked __i2c_smbus_xfer function. Because, thinking more about it, the problem with those allocs are not related to the locking details; adding another trylock to the mix just makes it so much more obvious. I mean, first we would specifically handle atomic/irq context with a trylock "documenting" that atomic/irq users are welcome to at least try xfers, and then we blattantly break the rulez with a GFP_KERNEL alloc... Also, the fact that the buffer is DMA-friendly does not mean that DMA is actually going to be used, so the patch that introduced those allocs might have regressed for this case: - SMBus user from atomic/irq context - SMBus emulated - emulation triggering a GFP_KERNEL alloc - the existing trylock in i2c_transfer succeeding - driver not ending up doing DMA Bailing out would break these users, always. Currently, I assume they are only broken when the alloc happens to need to do more than is allowed from the given context. Something which might or might not be common? But as usual, I might be missing something... Cheers, Peter
Re: [PATCH 1/5] i2c: smbus: add unlocked __i2c_smbus_xfer variant
On June 26, 2018 3:46:07 PM GMT+02:00, Wolfram Sang wrote: >> I don't think it's that easy as I just thought about another problem >> with lifting the locking from the emulation function. It calls >> kzalloc(..., GFP_KERNEL), at least in some cases, and that's not a >> very good idea from atomic/irq context... > >Right. However, we could simply bail out early when we are in atomic >context. Simply no DMA then... Yeah, we could bail out early, and perhaps we should. But we risk regressions, see below... And that should probably be fixed before we add the unlocked __i2c_smbus_xfer function. Because, thinking more about it, the problem with those allocs are not related to the locking details; adding another trylock to the mix just makes it so much more obvious. I mean, first we would specifically handle atomic/irq context with a trylock "documenting" that atomic/irq users are welcome to at least try xfers, and then we blattantly break the rulez with a GFP_KERNEL alloc... Also, the fact that the buffer is DMA-friendly does not mean that DMA is actually going to be used, so the patch that introduced those allocs might have regressed for this case: - SMBus user from atomic/irq context - SMBus emulated - emulation triggering a GFP_KERNEL alloc - the existing trylock in i2c_transfer succeeding - driver not ending up doing DMA Bailing out would break these users, always. Currently, I assume they are only broken when the alloc happens to need to do more than is allowed from the given context. Something which might or might not be common? But as usual, I might be missing something... Cheers, Peter
[PATCH v3 0/3] have the vt console preserve unicode characters
The vt code translates UTF-8 strings into glyph index values and stores those glyph values in the screen buffer. Because there can only be at most 512 glyphs at the moment, it is impossible to represent most unicode characters, in which case a default glyph (often '?') is displayed instead. The original unicode value is then lost. The 512-glyph limitation is inherent to text-mode VGA displays after which the core console code was modelled. This also means that the /dev/vcs* devices only provide user space with glyph index values, and then user applications must get hold of the unicode-to-glyph table the kernel is using in order to back-translate those into actual characters. It is not possible to get back the original unicode value when multiple unicode characters map to the same glyph, especially for the vast majority that maps to the default replacement glyph. Users of /dev/vcs* shouldn't have to be restricted to a narrow unicode space from lossy screen content because of that. This is especially true for accessibility applications such as BRLTTY that rely on /dev/vcs to render screen content onto braille terminals. It was also argued that the VGA-centric glyph buffer should eventually go entirely. The current design made sense when hardware was slow and managing the screen directly into the VGA memory made a difference (i.e. 25 years ago). Modern console display drivers no longer have to be limited to 512 glyphs. Quoting Alan Cox: |The only driver that it suits is the VGA text mode driver, which at |2GHz+ is going to be fast enough whatever format you convert from. We |have the memory, the processor power and the fact almost all our |displays are bitmapped (or more complex still) all in favour of |throwing away that limit. This patch series introduces unicode screen support to the core console code with /dev/vcs* as a first user. Memory is allocated, and possible CPU overhead introduced, only if /dev/vcsu is read at least once. For now both the glyph and unicode buffers are maintained in parallel to allow for a smooth transition. I'm a prime user of this new /dev/vcsu interface, as well as the BRLTTY maintainer Dave Mielke who implemented support for this in BRLTTY. There is therefore a vested interest in maintaining this feature as necessary. And this received extensive testing as well at this point. This is also available on top of v4.18-rc2 here: git://git.linaro.org/people/nicolas.pitre/linux vt-unicode Changes from v2: - Dropped patch #4 as it was useful only for initial debugging and it attracted all the review comments so far -- actually more than the patch is worth. - Added Adam Borowski's ACK. Changes from v1: - Rebased to v4.18-rc1. - Dropped first patch (now in mainline as commit 4b4ecd9cb8). - Removed a printk instance from an error path easily triggerable from user space. - Minor cleanup. Diffstat: drivers/tty/vt/vc_screen.c | 90 -- drivers/tty/vt/vt.c| 308 +++-- include/linux/console_struct.h | 2 + include/linux/selection.h | 5 + 4 files changed, 380 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] have the vt console preserve unicode characters
The vt code translates UTF-8 strings into glyph index values and stores those glyph values in the screen buffer. Because there can only be at most 512 glyphs at the moment, it is impossible to represent most unicode characters, in which case a default glyph (often '?') is displayed instead. The original unicode value is then lost. The 512-glyph limitation is inherent to text-mode VGA displays after which the core console code was modelled. This also means that the /dev/vcs* devices only provide user space with glyph index values, and then user applications must get hold of the unicode-to-glyph table the kernel is using in order to back-translate those into actual characters. It is not possible to get back the original unicode value when multiple unicode characters map to the same glyph, especially for the vast majority that maps to the default replacement glyph. Users of /dev/vcs* shouldn't have to be restricted to a narrow unicode space from lossy screen content because of that. This is especially true for accessibility applications such as BRLTTY that rely on /dev/vcs to render screen content onto braille terminals. It was also argued that the VGA-centric glyph buffer should eventually go entirely. The current design made sense when hardware was slow and managing the screen directly into the VGA memory made a difference (i.e. 25 years ago). Modern console display drivers no longer have to be limited to 512 glyphs. Quoting Alan Cox: |The only driver that it suits is the VGA text mode driver, which at |2GHz+ is going to be fast enough whatever format you convert from. We |have the memory, the processor power and the fact almost all our |displays are bitmapped (or more complex still) all in favour of |throwing away that limit. This patch series introduces unicode screen support to the core console code with /dev/vcs* as a first user. Memory is allocated, and possible CPU overhead introduced, only if /dev/vcsu is read at least once. For now both the glyph and unicode buffers are maintained in parallel to allow for a smooth transition. I'm a prime user of this new /dev/vcsu interface, as well as the BRLTTY maintainer Dave Mielke who implemented support for this in BRLTTY. There is therefore a vested interest in maintaining this feature as necessary. And this received extensive testing as well at this point. This is also available on top of v4.18-rc2 here: git://git.linaro.org/people/nicolas.pitre/linux vt-unicode Changes from v2: - Dropped patch #4 as it was useful only for initial debugging and it attracted all the review comments so far -- actually more than the patch is worth. - Added Adam Borowski's ACK. Changes from v1: - Rebased to v4.18-rc1. - Dropped first patch (now in mainline as commit 4b4ecd9cb8). - Removed a printk instance from an error path easily triggerable from user space. - Minor cleanup. Diffstat: drivers/tty/vt/vc_screen.c | 90 -- drivers/tty/vt/vt.c| 308 +++-- include/linux/console_struct.h | 2 + include/linux/selection.h | 5 + 4 files changed, 380 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] vt: preserve unicode values corresponding to screen characters
The vt code translates UTF-8 strings into glyph index values and stores
those glyph values directly in the screen buffer. Because there can only
be at most 512 glyphs, it is impossible to represent most unicode
characters, in which case a default glyph (often '?') is displayed
instead. The original unicode value is then lost.
This patch implements the basic screen buffer handling to preserve unicode
values alongside corresponding display glyphs. It is not activated by
default, meaning that people not relying on that functionality won't get
the implied overhead.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
Acked-by: Adam Borowski
---
drivers/tty/vt/vt.c| 220 +++--
include/linux/console_struct.h | 2 +
2 files changed, 211 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1eb1a376a0..7b636638b3 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -317,6 +317,171 @@ void schedule_console_callback(void)
schedule_work(_work);
}
+/*
+ * Code to manage unicode-based screen buffers
+ */
+
+#ifdef NO_VC_UNI_SCREEN
+/* this disables and optimizes related code away at compile time */
+#define get_vc_uniscr(vc) NULL
+#else
+#define get_vc_uniscr(vc) vc->vc_uni_screen
+#endif
+
+typedef uint32_t char32_t;
+
+/*
+ * Our screen buffer is preceded by an array of line pointers so that
+ * scrolling only implies some pointer shuffling.
+ */
+struct uni_screen {
+ char32_t *lines[0];
+};
+
+static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows)
+{
+ struct uni_screen *uniscr;
+ void *p;
+ unsigned int memsize, i;
+
+ /* allocate everything in one go */
+ memsize = cols * rows * sizeof(char32_t);
+ memsize += rows * sizeof(char32_t *);
+ p = kmalloc(memsize, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ /* initial line pointers */
+ uniscr = p;
+ p = uniscr->lines + rows;
+ for (i = 0; i < rows; i++) {
+ uniscr->lines[i] = p;
+ p += cols * sizeof(char32_t);
+ }
+ return uniscr;
+}
+
+static void vc_uniscr_set(struct vc_data *vc, struct uni_screen *new_uniscr)
+{
+ kfree(vc->vc_uni_screen);
+ vc->vc_uni_screen = new_uniscr;
+}
+
+static void vc_uniscr_putc(struct vc_data *vc, char32_t uc)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr)
+ uniscr->lines[vc->vc_y][vc->vc_x] = uc;
+}
+
+static void vc_uniscr_insert(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memmove([x + nr], [x], (cols - x - nr) * sizeof(*ln));
+ memset32([x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_delete(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memcpy([x], [x + nr], (cols - x - nr) * sizeof(*ln));
+ memset32([cols - nr], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_line(struct vc_data *vc, unsigned int x,
+unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+
+ memset32([x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_lines(struct vc_data *vc, unsigned int y,
+ unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int cols = vc->vc_cols;
+
+ while (nr--)
+ memset32(uniscr->lines[y++], ' ', cols);
+ }
+}
+
+static void vc_uniscr_scroll(struct vc_data *vc, unsigned int t, unsigned int
b,
+enum con_scroll dir, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int s, d, rescue, clear;
+ char32_t *save[nr];
+
+ s = clear = t;
+ d = t + nr;
+ rescue = b - nr;
+ if (dir == SM_UP) {
+ swap(s, d);
+ swap(clear, rescue);
+ }
+ memcpy(save, uniscr->lines + rescue, nr * sizeof(*save));
+ memmove(uniscr->lines + d, uniscr->lines + s,
+ (b - t - nr) * sizeof(*uniscr->lines));
+ memcpy(uniscr->lines + clear, save, nr * sizeof(*save));
+ vc_uniscr_clear_lines(vc, clear, nr);
+ }
+}
+
+static void vc_uniscr_copy_area(struct uni_screen *dst,
+ unsigned
[PATCH v3 1/3] vt: preserve unicode values corresponding to screen characters
The vt code translates UTF-8 strings into glyph index values and stores
those glyph values directly in the screen buffer. Because there can only
be at most 512 glyphs, it is impossible to represent most unicode
characters, in which case a default glyph (often '?') is displayed
instead. The original unicode value is then lost.
This patch implements the basic screen buffer handling to preserve unicode
values alongside corresponding display glyphs. It is not activated by
default, meaning that people not relying on that functionality won't get
the implied overhead.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
Acked-by: Adam Borowski
---
drivers/tty/vt/vt.c| 220 +++--
include/linux/console_struct.h | 2 +
2 files changed, 211 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1eb1a376a0..7b636638b3 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -317,6 +317,171 @@ void schedule_console_callback(void)
schedule_work(_work);
}
+/*
+ * Code to manage unicode-based screen buffers
+ */
+
+#ifdef NO_VC_UNI_SCREEN
+/* this disables and optimizes related code away at compile time */
+#define get_vc_uniscr(vc) NULL
+#else
+#define get_vc_uniscr(vc) vc->vc_uni_screen
+#endif
+
+typedef uint32_t char32_t;
+
+/*
+ * Our screen buffer is preceded by an array of line pointers so that
+ * scrolling only implies some pointer shuffling.
+ */
+struct uni_screen {
+ char32_t *lines[0];
+};
+
+static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows)
+{
+ struct uni_screen *uniscr;
+ void *p;
+ unsigned int memsize, i;
+
+ /* allocate everything in one go */
+ memsize = cols * rows * sizeof(char32_t);
+ memsize += rows * sizeof(char32_t *);
+ p = kmalloc(memsize, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ /* initial line pointers */
+ uniscr = p;
+ p = uniscr->lines + rows;
+ for (i = 0; i < rows; i++) {
+ uniscr->lines[i] = p;
+ p += cols * sizeof(char32_t);
+ }
+ return uniscr;
+}
+
+static void vc_uniscr_set(struct vc_data *vc, struct uni_screen *new_uniscr)
+{
+ kfree(vc->vc_uni_screen);
+ vc->vc_uni_screen = new_uniscr;
+}
+
+static void vc_uniscr_putc(struct vc_data *vc, char32_t uc)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr)
+ uniscr->lines[vc->vc_y][vc->vc_x] = uc;
+}
+
+static void vc_uniscr_insert(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memmove([x + nr], [x], (cols - x - nr) * sizeof(*ln));
+ memset32([x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_delete(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memcpy([x], [x + nr], (cols - x - nr) * sizeof(*ln));
+ memset32([cols - nr], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_line(struct vc_data *vc, unsigned int x,
+unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+
+ memset32([x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_lines(struct vc_data *vc, unsigned int y,
+ unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int cols = vc->vc_cols;
+
+ while (nr--)
+ memset32(uniscr->lines[y++], ' ', cols);
+ }
+}
+
+static void vc_uniscr_scroll(struct vc_data *vc, unsigned int t, unsigned int
b,
+enum con_scroll dir, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int s, d, rescue, clear;
+ char32_t *save[nr];
+
+ s = clear = t;
+ d = t + nr;
+ rescue = b - nr;
+ if (dir == SM_UP) {
+ swap(s, d);
+ swap(clear, rescue);
+ }
+ memcpy(save, uniscr->lines + rescue, nr * sizeof(*save));
+ memmove(uniscr->lines + d, uniscr->lines + s,
+ (b - t - nr) * sizeof(*uniscr->lines));
+ memcpy(uniscr->lines + clear, save, nr * sizeof(*save));
+ vc_uniscr_clear_lines(vc, clear, nr);
+ }
+}
+
+static void vc_uniscr_copy_area(struct uni_screen *dst,
+ unsigned
[PATCH v3 3/3] vt: unicode fallback for scrollback
There is currently no provision for scrollback content in the core code,
leaving that to backend video drivers where this can be highly optimized.
There is currently no common method for those drivers to tell the core
what part of the scrollback is actually displayed and what size the
scrollback buffer is either. Because of that, the unicode screen buffer
has no provision for any scrollback.
At least we can provide backtranslated glyph values when the scrollback
is active which should be plenty good enough for now.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
Acked-by: Adam Borowski
---
drivers/tty/vt/vc_screen.c | 3 ++-
drivers/tty/vt/vt.c| 31 +--
include/linux/selection.h | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 9c44252e52..2384ea85ff 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -311,7 +311,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
do {
if (nr > this_round/4)
nr = this_round/4;
- vc_uniscr_copy_line(vc, con_buf0, row, col, nr);
+ vc_uniscr_copy_line(vc, con_buf0, viewed,
+ row, col, nr);
con_buf0 += nr * 4;
this_round -= nr * 4;
row++;
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 062ce6be79..2d14bb195d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -533,13 +533,40 @@ int vc_uniscr_check(struct vc_data *vc)
* This must be preceded by a successful call to vc_uniscr_check() once
* the console lock has been taken.
*/
-void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col, unsigned int nr)
{
struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int offset = row * vc->vc_size_row + col * 2;
+ unsigned long pos;
BUG_ON(!uniscr);
- memcpy(dest, >lines[row][col], nr * sizeof(char32_t));
+
+ pos = (unsigned long)screenpos(vc, offset, viewed);
+ if (pos >= vc->vc_origin && pos < vc->vc_scr_end) {
+ /*
+* Desired position falls in the main screen buffer.
+* However the actual row/col might be different if
+* scrollback is active.
+*/
+ row = (pos - vc->vc_origin) / vc->vc_size_row;
+ col = ((pos - vc->vc_origin) % vc->vc_size_row) / 2;
+ memcpy(dest, >lines[row][col], nr * sizeof(char32_t));
+ } else {
+ /*
+* Scrollback is active. For now let's simply backtranslate
+* the screen glyphs until the unicode screen buffer does
+* synchronize with console display drivers for a scrollback
+* buffer of its own.
+*/
+ u16 *p = (u16 *)pos;
+ int mask = vc->vc_hi_font_mask | 0xff;
+ char32_t *uni_buf = dest;
+ while (nr--) {
+ u16 glyph = scr_readw(p++) & mask;
+ *uni_buf++ = inverse_translate(vc, glyph, true);
+ }
+ }
}
diff --git a/include/linux/selection.h b/include/linux/selection.h
index 2b34df9f1e..067d2e99c7 100644
--- a/include/linux/selection.h
+++ b/include/linux/selection.h
@@ -43,7 +43,7 @@ extern void vcs_scr_writew(struct vc_data *vc, u16 val, u16
*org);
extern void vcs_scr_updated(struct vc_data *vc);
extern int vc_uniscr_check(struct vc_data *vc);
-extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col,
unsigned int nr);
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] vt: introduce unicode mode for /dev/vcs
Now that the core vt code knows how to preserve unicode values for each
displayed character, it is then possible to let user space access it via
/dev/vcs*.
Unicode characters are presented as 32 bit values in native endianity
via the /dev/vcsu* devices, mimicking the simple /dev/vcs* devices.
Unicode with attributes (similarly to /dev/vcsa*) is not supported at
the moment.
Data is available only as long as the console is in UTF-8 mode. ENODATA
is returned otherwise.
This was tested with the latest development version (to become
version 5.7) of BRLTTY. Amongst other things, this allows ⠋⠕⠗ ⠞⠓⠊⠎
⠃⠗⠁⠊⠇⠇⠑⠀⠞⠑⠭⠞⠀to appear directly on braille displays regardless of the
console font being used.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
Acked-by: Adam Borowski
---
drivers/tty/vt/vc_screen.c | 89 --
drivers/tty/vt/vt.c| 61 ++
include/linux/selection.h | 5 +++
3 files changed, 141 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index e4a66e1fd0..9c44252e52 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -10,6 +10,12 @@
* Attribute/character pair is in native endianity.
*[minor: N+128]
*
+ * /dev/vcsuN: similar to /dev/vcsaN but using 4-byte unicode values
+ * instead of 1-byte screen glyph values.
+ *[minor: N+64]
+ *
+ * /dev/vcsuaN: same idea as /dev/vcsaN for unicode (not yet implemented).
+ *
* This replaces screendump and part of selection, so that the system
* administrator can control access using file system permissions.
*
@@ -51,6 +57,26 @@
#define CON_BUF_SIZE (CONFIG_BASE_SMALL ? 256 : PAGE_SIZE)
+/*
+ * Our minor space:
+ *
+ * 0 ... 63 glyph mode without attributes
+ * 64 ... 127 unicode mode without attributes
+ * 128 ... 191 glyph mode with attributes
+ * 192 ... 255 unused (reserved for unicode with attributes)
+ *
+ * This relies on MAX_NR_CONSOLES being <= 63, meaning 63 actual consoles
+ * with minors 0, 64, 128 and 192 being proxies for the foreground console.
+ */
+#if MAX_NR_CONSOLES > 63
+#warning "/dev/vcs* devices may not accommodate more than 63 consoles"
+#endif
+
+#define console(inode) (iminor(inode) & 63)
+#define use_unicode(inode) (iminor(inode) & 64)
+#define use_attributes(inode) (iminor(inode) & 128)
+
+
struct vcs_poll_data {
struct notifier_block notifier;
unsigned int cons_num;
@@ -102,7 +128,7 @@ vcs_poll_data_get(struct file *file)
poll = kzalloc(sizeof(*poll), GFP_KERNEL);
if (!poll)
return NULL;
- poll->cons_num = iminor(file_inode(file)) & 127;
+ poll->cons_num = console(file_inode(file));
init_waitqueue_head(>waitq);
poll->notifier.notifier_call = vcs_notifier;
if (register_vt_notifier(>notifier) != 0) {
@@ -140,7 +166,7 @@ vcs_poll_data_get(struct file *file)
static struct vc_data*
vcs_vc(struct inode *inode, int *viewed)
{
- unsigned int currcons = iminor(inode) & 127;
+ unsigned int currcons = console(inode);
WARN_CONSOLE_UNLOCKED();
@@ -164,7 +190,6 @@ static int
vcs_size(struct inode *inode)
{
int size;
- int minor = iminor(inode);
struct vc_data *vc;
WARN_CONSOLE_UNLOCKED();
@@ -175,8 +200,12 @@ vcs_size(struct inode *inode)
size = vc->vc_rows * vc->vc_cols;
- if (minor & 128)
+ if (use_attributes(inode)) {
+ if (use_unicode(inode))
+ return -EOPNOTSUPP;
size = 2*size + HEADER_SIZE;
+ } else if (use_unicode(inode))
+ size *= 4;
return size;
}
@@ -197,12 +226,10 @@ static ssize_t
vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
struct inode *inode = file_inode(file);
- unsigned int currcons = iminor(inode);
struct vc_data *vc;
struct vcs_poll_data *poll;
- long pos;
- long attr, read;
- int col, maxcol, viewed;
+ long pos, read;
+ int attr, uni_mode, row, col, maxcol, viewed;
unsigned short *org = NULL;
ssize_t ret;
char *con_buf;
@@ -218,7 +245,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
*/
console_lock();
- attr = (currcons & 128);
+ uni_mode = use_unicode(inode);
+ attr = use_attributes(inode);
ret = -ENXIO;
vc = vcs_vc(inode, );
if (!vc)
@@ -227,6 +255,10 @@ vcs_read(struct file *file, char __user *buf, size_t
count, loff_t *ppos)
ret = -EINVAL;
if (pos < 0)
goto unlock_out;
+ /* we enforce 32-bit alignment for pos and count in unicode mode */
+ if (uni_mode && (pos | count) & 3)
+ goto unlock_out;
+
poll = file->private_data;
if (count && poll)
poll->seen_last_update = true;
@@ -266,7
[PATCH v3 3/3] vt: unicode fallback for scrollback
There is currently no provision for scrollback content in the core code,
leaving that to backend video drivers where this can be highly optimized.
There is currently no common method for those drivers to tell the core
what part of the scrollback is actually displayed and what size the
scrollback buffer is either. Because of that, the unicode screen buffer
has no provision for any scrollback.
At least we can provide backtranslated glyph values when the scrollback
is active which should be plenty good enough for now.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
Acked-by: Adam Borowski
---
drivers/tty/vt/vc_screen.c | 3 ++-
drivers/tty/vt/vt.c| 31 +--
include/linux/selection.h | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 9c44252e52..2384ea85ff 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -311,7 +311,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
do {
if (nr > this_round/4)
nr = this_round/4;
- vc_uniscr_copy_line(vc, con_buf0, row, col, nr);
+ vc_uniscr_copy_line(vc, con_buf0, viewed,
+ row, col, nr);
con_buf0 += nr * 4;
this_round -= nr * 4;
row++;
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 062ce6be79..2d14bb195d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -533,13 +533,40 @@ int vc_uniscr_check(struct vc_data *vc)
* This must be preceded by a successful call to vc_uniscr_check() once
* the console lock has been taken.
*/
-void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col, unsigned int nr)
{
struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int offset = row * vc->vc_size_row + col * 2;
+ unsigned long pos;
BUG_ON(!uniscr);
- memcpy(dest, >lines[row][col], nr * sizeof(char32_t));
+
+ pos = (unsigned long)screenpos(vc, offset, viewed);
+ if (pos >= vc->vc_origin && pos < vc->vc_scr_end) {
+ /*
+* Desired position falls in the main screen buffer.
+* However the actual row/col might be different if
+* scrollback is active.
+*/
+ row = (pos - vc->vc_origin) / vc->vc_size_row;
+ col = ((pos - vc->vc_origin) % vc->vc_size_row) / 2;
+ memcpy(dest, >lines[row][col], nr * sizeof(char32_t));
+ } else {
+ /*
+* Scrollback is active. For now let's simply backtranslate
+* the screen glyphs until the unicode screen buffer does
+* synchronize with console display drivers for a scrollback
+* buffer of its own.
+*/
+ u16 *p = (u16 *)pos;
+ int mask = vc->vc_hi_font_mask | 0xff;
+ char32_t *uni_buf = dest;
+ while (nr--) {
+ u16 glyph = scr_readw(p++) & mask;
+ *uni_buf++ = inverse_translate(vc, glyph, true);
+ }
+ }
}
diff --git a/include/linux/selection.h b/include/linux/selection.h
index 2b34df9f1e..067d2e99c7 100644
--- a/include/linux/selection.h
+++ b/include/linux/selection.h
@@ -43,7 +43,7 @@ extern void vcs_scr_writew(struct vc_data *vc, u16 val, u16
*org);
extern void vcs_scr_updated(struct vc_data *vc);
extern int vc_uniscr_check(struct vc_data *vc);
-extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col,
unsigned int nr);
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] vt: introduce unicode mode for /dev/vcs
Now that the core vt code knows how to preserve unicode values for each
displayed character, it is then possible to let user space access it via
/dev/vcs*.
Unicode characters are presented as 32 bit values in native endianity
via the /dev/vcsu* devices, mimicking the simple /dev/vcs* devices.
Unicode with attributes (similarly to /dev/vcsa*) is not supported at
the moment.
Data is available only as long as the console is in UTF-8 mode. ENODATA
is returned otherwise.
This was tested with the latest development version (to become
version 5.7) of BRLTTY. Amongst other things, this allows ⠋⠕⠗ ⠞⠓⠊⠎
⠃⠗⠁⠊⠇⠇⠑⠀⠞⠑⠭⠞⠀to appear directly on braille displays regardless of the
console font being used.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
Acked-by: Adam Borowski
---
drivers/tty/vt/vc_screen.c | 89 --
drivers/tty/vt/vt.c| 61 ++
include/linux/selection.h | 5 +++
3 files changed, 141 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index e4a66e1fd0..9c44252e52 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -10,6 +10,12 @@
* Attribute/character pair is in native endianity.
*[minor: N+128]
*
+ * /dev/vcsuN: similar to /dev/vcsaN but using 4-byte unicode values
+ * instead of 1-byte screen glyph values.
+ *[minor: N+64]
+ *
+ * /dev/vcsuaN: same idea as /dev/vcsaN for unicode (not yet implemented).
+ *
* This replaces screendump and part of selection, so that the system
* administrator can control access using file system permissions.
*
@@ -51,6 +57,26 @@
#define CON_BUF_SIZE (CONFIG_BASE_SMALL ? 256 : PAGE_SIZE)
+/*
+ * Our minor space:
+ *
+ * 0 ... 63 glyph mode without attributes
+ * 64 ... 127 unicode mode without attributes
+ * 128 ... 191 glyph mode with attributes
+ * 192 ... 255 unused (reserved for unicode with attributes)
+ *
+ * This relies on MAX_NR_CONSOLES being <= 63, meaning 63 actual consoles
+ * with minors 0, 64, 128 and 192 being proxies for the foreground console.
+ */
+#if MAX_NR_CONSOLES > 63
+#warning "/dev/vcs* devices may not accommodate more than 63 consoles"
+#endif
+
+#define console(inode) (iminor(inode) & 63)
+#define use_unicode(inode) (iminor(inode) & 64)
+#define use_attributes(inode) (iminor(inode) & 128)
+
+
struct vcs_poll_data {
struct notifier_block notifier;
unsigned int cons_num;
@@ -102,7 +128,7 @@ vcs_poll_data_get(struct file *file)
poll = kzalloc(sizeof(*poll), GFP_KERNEL);
if (!poll)
return NULL;
- poll->cons_num = iminor(file_inode(file)) & 127;
+ poll->cons_num = console(file_inode(file));
init_waitqueue_head(>waitq);
poll->notifier.notifier_call = vcs_notifier;
if (register_vt_notifier(>notifier) != 0) {
@@ -140,7 +166,7 @@ vcs_poll_data_get(struct file *file)
static struct vc_data*
vcs_vc(struct inode *inode, int *viewed)
{
- unsigned int currcons = iminor(inode) & 127;
+ unsigned int currcons = console(inode);
WARN_CONSOLE_UNLOCKED();
@@ -164,7 +190,6 @@ static int
vcs_size(struct inode *inode)
{
int size;
- int minor = iminor(inode);
struct vc_data *vc;
WARN_CONSOLE_UNLOCKED();
@@ -175,8 +200,12 @@ vcs_size(struct inode *inode)
size = vc->vc_rows * vc->vc_cols;
- if (minor & 128)
+ if (use_attributes(inode)) {
+ if (use_unicode(inode))
+ return -EOPNOTSUPP;
size = 2*size + HEADER_SIZE;
+ } else if (use_unicode(inode))
+ size *= 4;
return size;
}
@@ -197,12 +226,10 @@ static ssize_t
vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
struct inode *inode = file_inode(file);
- unsigned int currcons = iminor(inode);
struct vc_data *vc;
struct vcs_poll_data *poll;
- long pos;
- long attr, read;
- int col, maxcol, viewed;
+ long pos, read;
+ int attr, uni_mode, row, col, maxcol, viewed;
unsigned short *org = NULL;
ssize_t ret;
char *con_buf;
@@ -218,7 +245,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
*/
console_lock();
- attr = (currcons & 128);
+ uni_mode = use_unicode(inode);
+ attr = use_attributes(inode);
ret = -ENXIO;
vc = vcs_vc(inode, );
if (!vc)
@@ -227,6 +255,10 @@ vcs_read(struct file *file, char __user *buf, size_t
count, loff_t *ppos)
ret = -EINVAL;
if (pos < 0)
goto unlock_out;
+ /* we enforce 32-bit alignment for pos and count in unicode mode */
+ if (uni_mode && (pos | count) & 3)
+ goto unlock_out;
+
poll = file->private_data;
if (count && poll)
poll->seen_last_update = true;
@@ -266,7
Re: [GIT PULL] ARM: uniphier: fixes for v4.18
Hi Olof,
2018-06-27 2:42 GMT+09:00 Olof Johansson :
> Hi,
>
> On Mon, Jun 25, 2018 at 11:13:04PM +0900, Masahiro Yamada wrote:
>> Hi Arnd, Olof,
>>
>> Please pull some fixes of ARM UniPhier platform.
>>
>>
>>
>> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>>
>> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
>> tags/uniphier-fixes-v4.18
>>
>> for you to fetch changes up to 4e62893c25bd3d5758058e15958364df3ca15fbc:
>>
>> arm64: uniphier: select RESET_CONTROLLER (2018-06-25 23:00:31 +0900)
>>
>>
>> UniPhier ARM SoC fixes for v4.18
>>
>> - add missing cooling device properties for CPUS
>> - fix widget name of headphone
>> - select RESET_CONTROLLER
>
> It's unclear to me what the severity of these fixes are. and I think the
> headphone widget name is the only bug that's causing problems for someone
> using
> this kernel, is that correct?
Right.
The others are on the boundary.
The criteria on those is different by maintainers
because some pull and some do not.
> If so, it would also be useful to get a "Fixes:" tag for it, seems like it
> should be:
>
> Fixes: fb21a0acaa2b7 ("arm64: dts: uniphier: add sound node")
> Care to resubmit with just the bugfix? Or, if it's easier, I can cherry-pick
> just that fix at this end and add the Fixes line. You should queue the other
> patches up for 4.19 and include in those pull requests.
If you care to cherry-pick with Fixes: tag,
that would be good.
Thanks.
>
> Thanks,
>
> -Olof
--
Best Regards
Masahiro Yamada
Re: [GIT PULL] ARM: uniphier: fixes for v4.18
Hi Olof,
2018-06-27 2:42 GMT+09:00 Olof Johansson :
> Hi,
>
> On Mon, Jun 25, 2018 at 11:13:04PM +0900, Masahiro Yamada wrote:
>> Hi Arnd, Olof,
>>
>> Please pull some fixes of ARM UniPhier platform.
>>
>>
>>
>> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>>
>> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
>> tags/uniphier-fixes-v4.18
>>
>> for you to fetch changes up to 4e62893c25bd3d5758058e15958364df3ca15fbc:
>>
>> arm64: uniphier: select RESET_CONTROLLER (2018-06-25 23:00:31 +0900)
>>
>>
>> UniPhier ARM SoC fixes for v4.18
>>
>> - add missing cooling device properties for CPUS
>> - fix widget name of headphone
>> - select RESET_CONTROLLER
>
> It's unclear to me what the severity of these fixes are. and I think the
> headphone widget name is the only bug that's causing problems for someone
> using
> this kernel, is that correct?
Right.
The others are on the boundary.
The criteria on those is different by maintainers
because some pull and some do not.
> If so, it would also be useful to get a "Fixes:" tag for it, seems like it
> should be:
>
> Fixes: fb21a0acaa2b7 ("arm64: dts: uniphier: add sound node")
> Care to resubmit with just the bugfix? Or, if it's easier, I can cherry-pick
> just that fix at this end and add the Fixes line. You should queue the other
> patches up for 4.19 and include in those pull requests.
If you care to cherry-pick with Fixes: tag,
that would be good.
Thanks.
>
> Thanks,
>
> -Olof
--
Best Regards
Masahiro Yamada
RE: [Patch v2 14/15] CIFS: Add support for direct I/O write
> Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
>
> On 6/26/2018 12:39 AM, Long Li wrote:
> >> Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
> >>
> >> On 5/30/2018 3:48 PM, Long Li wrote:
> >>> From: Long Li
> >>>
> >>> Implement the function for direct I/O write. It doesn't support AIO,
> >>> which will be implemented in a follow up patch.
> >>>
> >>> Signed-off-by: Long Li
> >>> ---
> >>>fs/cifs/cifsfs.h | 1 +
> >>>fs/cifs/file.c | 165
> >> +++
> >>>2 files changed, 166 insertions(+)
> >>>
> >>> diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h index
> >>> 7fba9aa..e9c5103 100644
> >>> --- a/fs/cifs/cifsfs.h
> >>> +++ b/fs/cifs/cifsfs.h
> >>> @@ -105,6 +105,7 @@ extern ssize_t cifs_user_readv(struct kiocb
> >>> *iocb,
> >> struct iov_iter *to);
> >>>extern ssize_t cifs_direct_readv(struct kiocb *iocb, struct iov_iter
> >>> *to);
> >>>extern ssize_t cifs_strict_readv(struct kiocb *iocb, struct iov_iter
> >>> *to);
> >>>extern ssize_t cifs_user_writev(struct kiocb *iocb, struct
> >>> iov_iter *from);
> >>> +extern ssize_t cifs_direct_writev(struct kiocb *iocb, struct
> >>> +iov_iter *from);
> >>>extern ssize_t cifs_strict_writev(struct kiocb *iocb, struct iov_iter
> *from);
> >>>extern int cifs_lock(struct file *, int, struct file_lock *);
> >>>extern int cifs_fsync(struct file *, loff_t, loff_t, int); diff
> >>> --git a/fs/cifs/file.c b/fs/cifs/file.c index e6e6f24..8c385b1
> >>> 100644
> >>> --- a/fs/cifs/file.c
> >>> +++ b/fs/cifs/file.c
> >>> @@ -2461,6 +2461,35 @@ cifs_uncached_writedata_release(struct kref
> >>> *refcount)
> >>>
> >>>static void collect_uncached_write_data(struct cifs_aio_ctx
> >>> *ctx);
> >>>
> >>> +static void cifs_direct_writedata_release(struct kref *refcount) {
> >>> + int i;
> >>> + struct cifs_writedata *wdata = container_of(refcount,
> >>> + struct cifs_writedata, refcount);
> >>> +
> >>> + for (i = 0; i < wdata->nr_pages; i++)
> >>> + put_page(wdata->pages[i]);
> >>> +
> >>> + cifs_writedata_release(refcount);
> >>> +}
> >>> +
> >>> +static void cifs_direct_writev_complete(struct work_struct *work) {
> >>> + struct cifs_writedata *wdata = container_of(work,
> >>> + struct cifs_writedata, work);
> >>> + struct inode *inode = d_inode(wdata->cfile->dentry);
> >>> + struct cifsInodeInfo *cifsi = CIFS_I(inode);
> >>> +
> >>> + spin_lock(>i_lock);
> >>> + cifs_update_eof(cifsi, wdata->offset, wdata->bytes);
> >>> + if (cifsi->server_eof > inode->i_size)
> >>> + i_size_write(inode, cifsi->server_eof);
> >>> + spin_unlock(>i_lock);
> >>> +
> >>> + complete(>done);
> >>> + kref_put(>refcount, cifs_direct_writedata_release); }
> >>> +
> >>>static void
> >>>cifs_uncached_writev_complete(struct work_struct *work)
> >>>{
> >>> @@ -2703,6 +2732,142 @@ static void
> >>> collect_uncached_write_data(struct
> >> cifs_aio_ctx *ctx)
> >>> complete(>done);
> >>>}
> >>>
> >>> +ssize_t cifs_direct_writev(struct kiocb *iocb, struct iov_iter
> >>> +*from) {
> >>> + struct file *file = iocb->ki_filp;
> >>> + ssize_t total_written = 0;
> >>> + struct cifsFileInfo *cfile;
> >>> + struct cifs_tcon *tcon;
> >>> + struct cifs_sb_info *cifs_sb;
> >>> + struct TCP_Server_Info *server;
> >>> + pid_t pid;
> >>> + unsigned long nr_pages;
> >>> + loff_t offset = iocb->ki_pos;
> >>> + size_t len = iov_iter_count(from);
> >>> + int rc;
> >>> + struct cifs_writedata *wdata;
> >>> +
> >>> + /*
> >>> + * iov_iter_get_pages_alloc doesn't work with ITER_KVEC.
> >>> + * In this case, fall back to non-direct write function.
> >>> + */
> >>> + if (from->type & ITER_KVEC) {
> >>> + cifs_dbg(FYI, "use non-direct cifs_user_writev for kvec
> >> I/O\n");
> >>> + return cifs_user_writev(iocb, from);
> >>> + }
> >>> +
> >>> + rc = generic_write_checks(iocb, from);
> >>> + if (rc <= 0)
> >>> + return rc;
> >>> +
> >>> + cifs_sb = CIFS_FILE_SB(file);
> >>> + cfile = file->private_data;
> >>> + tcon = tlink_tcon(cfile->tlink);
> >>> + server = tcon->ses->server;
> >>> +
> >>> + if (!server->ops->async_writev)
> >>> + return -ENOSYS;
> >>> +
> >>> + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_RWPIDFORWARD)
> >>> + pid = cfile->pid;
> >>> + else
> >>> + pid = current->tgid;
> >>> +
> >>> + do {
> >>> + unsigned int wsize, credits;
> >>> + struct page **pagevec;
> >>> + size_t start;
> >>> + ssize_t cur_len;
> >>> +
> >>> + rc = server->ops->wait_mtu_credits(server, cifs_sb->wsize,
> >>> +, );
> >>> + if (rc)
> >>> + break;
> >>> +
> >>> + cur_len = iov_iter_get_pages_alloc(
> >>> + from, , wsize, );
> >>> + if (cur_len < 0) {
> >>> + cifs_dbg(VFS,
> >>> +
RE: [Patch v2 14/15] CIFS: Add support for direct I/O write
> Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
>
> On 6/26/2018 12:39 AM, Long Li wrote:
> >> Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
> >>
> >> On 5/30/2018 3:48 PM, Long Li wrote:
> >>> From: Long Li
> >>>
> >>> Implement the function for direct I/O write. It doesn't support AIO,
> >>> which will be implemented in a follow up patch.
> >>>
> >>> Signed-off-by: Long Li
> >>> ---
> >>>fs/cifs/cifsfs.h | 1 +
> >>>fs/cifs/file.c | 165
> >> +++
> >>>2 files changed, 166 insertions(+)
> >>>
> >>> diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h index
> >>> 7fba9aa..e9c5103 100644
> >>> --- a/fs/cifs/cifsfs.h
> >>> +++ b/fs/cifs/cifsfs.h
> >>> @@ -105,6 +105,7 @@ extern ssize_t cifs_user_readv(struct kiocb
> >>> *iocb,
> >> struct iov_iter *to);
> >>>extern ssize_t cifs_direct_readv(struct kiocb *iocb, struct iov_iter
> >>> *to);
> >>>extern ssize_t cifs_strict_readv(struct kiocb *iocb, struct iov_iter
> >>> *to);
> >>>extern ssize_t cifs_user_writev(struct kiocb *iocb, struct
> >>> iov_iter *from);
> >>> +extern ssize_t cifs_direct_writev(struct kiocb *iocb, struct
> >>> +iov_iter *from);
> >>>extern ssize_t cifs_strict_writev(struct kiocb *iocb, struct iov_iter
> *from);
> >>>extern int cifs_lock(struct file *, int, struct file_lock *);
> >>>extern int cifs_fsync(struct file *, loff_t, loff_t, int); diff
> >>> --git a/fs/cifs/file.c b/fs/cifs/file.c index e6e6f24..8c385b1
> >>> 100644
> >>> --- a/fs/cifs/file.c
> >>> +++ b/fs/cifs/file.c
> >>> @@ -2461,6 +2461,35 @@ cifs_uncached_writedata_release(struct kref
> >>> *refcount)
> >>>
> >>>static void collect_uncached_write_data(struct cifs_aio_ctx
> >>> *ctx);
> >>>
> >>> +static void cifs_direct_writedata_release(struct kref *refcount) {
> >>> + int i;
> >>> + struct cifs_writedata *wdata = container_of(refcount,
> >>> + struct cifs_writedata, refcount);
> >>> +
> >>> + for (i = 0; i < wdata->nr_pages; i++)
> >>> + put_page(wdata->pages[i]);
> >>> +
> >>> + cifs_writedata_release(refcount);
> >>> +}
> >>> +
> >>> +static void cifs_direct_writev_complete(struct work_struct *work) {
> >>> + struct cifs_writedata *wdata = container_of(work,
> >>> + struct cifs_writedata, work);
> >>> + struct inode *inode = d_inode(wdata->cfile->dentry);
> >>> + struct cifsInodeInfo *cifsi = CIFS_I(inode);
> >>> +
> >>> + spin_lock(>i_lock);
> >>> + cifs_update_eof(cifsi, wdata->offset, wdata->bytes);
> >>> + if (cifsi->server_eof > inode->i_size)
> >>> + i_size_write(inode, cifsi->server_eof);
> >>> + spin_unlock(>i_lock);
> >>> +
> >>> + complete(>done);
> >>> + kref_put(>refcount, cifs_direct_writedata_release); }
> >>> +
> >>>static void
> >>>cifs_uncached_writev_complete(struct work_struct *work)
> >>>{
> >>> @@ -2703,6 +2732,142 @@ static void
> >>> collect_uncached_write_data(struct
> >> cifs_aio_ctx *ctx)
> >>> complete(>done);
> >>>}
> >>>
> >>> +ssize_t cifs_direct_writev(struct kiocb *iocb, struct iov_iter
> >>> +*from) {
> >>> + struct file *file = iocb->ki_filp;
> >>> + ssize_t total_written = 0;
> >>> + struct cifsFileInfo *cfile;
> >>> + struct cifs_tcon *tcon;
> >>> + struct cifs_sb_info *cifs_sb;
> >>> + struct TCP_Server_Info *server;
> >>> + pid_t pid;
> >>> + unsigned long nr_pages;
> >>> + loff_t offset = iocb->ki_pos;
> >>> + size_t len = iov_iter_count(from);
> >>> + int rc;
> >>> + struct cifs_writedata *wdata;
> >>> +
> >>> + /*
> >>> + * iov_iter_get_pages_alloc doesn't work with ITER_KVEC.
> >>> + * In this case, fall back to non-direct write function.
> >>> + */
> >>> + if (from->type & ITER_KVEC) {
> >>> + cifs_dbg(FYI, "use non-direct cifs_user_writev for kvec
> >> I/O\n");
> >>> + return cifs_user_writev(iocb, from);
> >>> + }
> >>> +
> >>> + rc = generic_write_checks(iocb, from);
> >>> + if (rc <= 0)
> >>> + return rc;
> >>> +
> >>> + cifs_sb = CIFS_FILE_SB(file);
> >>> + cfile = file->private_data;
> >>> + tcon = tlink_tcon(cfile->tlink);
> >>> + server = tcon->ses->server;
> >>> +
> >>> + if (!server->ops->async_writev)
> >>> + return -ENOSYS;
> >>> +
> >>> + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_RWPIDFORWARD)
> >>> + pid = cfile->pid;
> >>> + else
> >>> + pid = current->tgid;
> >>> +
> >>> + do {
> >>> + unsigned int wsize, credits;
> >>> + struct page **pagevec;
> >>> + size_t start;
> >>> + ssize_t cur_len;
> >>> +
> >>> + rc = server->ops->wait_mtu_credits(server, cifs_sb->wsize,
> >>> +, );
> >>> + if (rc)
> >>> + break;
> >>> +
> >>> + cur_len = iov_iter_get_pages_alloc(
> >>> + from, , wsize, );
> >>> + if (cur_len < 0) {
> >>> + cifs_dbg(VFS,
> >>> +
[PATCH 1/2] nvmem: imx-ocotp: add support for imx6sll
i.MX6SLL is a new SoC of i.MX6 family, enable ocotp
driver support for this SoC.
Signed-off-by: Anson Huang
---
drivers/nvmem/imx-ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 60816c8..afb429a 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -409,6 +409,12 @@ static const struct ocotp_params imx6sl_params = {
.set_timing = imx_ocotp_set_imx6_timing,
};
+static const struct ocotp_params imx6sll_params = {
+ .nregs = 128,
+ .bank_address_words = 0,
+ .set_timing = imx_ocotp_set_imx6_timing,
+};
+
static const struct ocotp_params imx6sx_params = {
.nregs = 128,
.bank_address_words = 0,
@@ -433,6 +439,7 @@ static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6sx-ocotp", .data = _params },
{ .compatible = "fsl,imx6ul-ocotp", .data = _params },
{ .compatible = "fsl,imx7d-ocotp", .data = _params },
+ { .compatible = "fsl,imx6sll-ocotp", .data = _params },
{ },
};
MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
--
2.7.4
[PATCH 1/2] nvmem: imx-ocotp: add support for imx6sll
i.MX6SLL is a new SoC of i.MX6 family, enable ocotp
driver support for this SoC.
Signed-off-by: Anson Huang
---
drivers/nvmem/imx-ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index 60816c8..afb429a 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -409,6 +409,12 @@ static const struct ocotp_params imx6sl_params = {
.set_timing = imx_ocotp_set_imx6_timing,
};
+static const struct ocotp_params imx6sll_params = {
+ .nregs = 128,
+ .bank_address_words = 0,
+ .set_timing = imx_ocotp_set_imx6_timing,
+};
+
static const struct ocotp_params imx6sx_params = {
.nregs = 128,
.bank_address_words = 0,
@@ -433,6 +439,7 @@ static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6sx-ocotp", .data = _params },
{ .compatible = "fsl,imx6ul-ocotp", .data = _params },
{ .compatible = "fsl,imx7d-ocotp", .data = _params },
+ { .compatible = "fsl,imx6sll-ocotp", .data = _params },
{ },
};
MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
--
2.7.4
[PATCH 2/2] dt-bindings: nvmem: imx-ocotp: add compatible string for imx6sll
Add new compatible string for i.MX6SLL SOC. Signed-off-by: Anson Huang --- Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index 729f674..792bc5f 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -1,7 +1,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings This binding represents the on-chip eFuse OTP controller found on -i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs. +i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL and i.MX6SLL SoCs. Required properties: - compatible: should be one of @@ -10,6 +10,7 @@ Required properties: "fsl,imx6sx-ocotp" (i.MX6SX), "fsl,imx6ul-ocotp" (i.MX6UL), "fsl,imx7d-ocotp" (i.MX7D/S), + "fsl,imx6sll-ocotp" (i.MX6SLL), followed by "syscon". - #address-cells : Should be 1 - #size-cells : Should be 1 -- 2.7.4
[PATCH 2/2] dt-bindings: nvmem: imx-ocotp: add compatible string for imx6sll
Add new compatible string for i.MX6SLL SOC. Signed-off-by: Anson Huang --- Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index 729f674..792bc5f 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -1,7 +1,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings This binding represents the on-chip eFuse OTP controller found on -i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs. +i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL and i.MX6SLL SoCs. Required properties: - compatible: should be one of @@ -10,6 +10,7 @@ Required properties: "fsl,imx6sx-ocotp" (i.MX6SX), "fsl,imx6ul-ocotp" (i.MX6UL), "fsl,imx7d-ocotp" (i.MX7D/S), + "fsl,imx6sll-ocotp" (i.MX6SLL), followed by "syscon". - #address-cells : Should be 1 - #size-cells : Should be 1 -- 2.7.4
RE: [Patch v2 06/15] CIFS: Introduce helper function to get page offset and length in smb_rqst
> Subject: Re: [Patch v2 06/15] CIFS: Introduce helper function to get page
> offset and length in smb_rqst
>
> On 6/25/2018 5:14 PM, Long Li wrote:
> >> Subject: Re: [Patch v2 06/15] CIFS: Introduce helper function to get
> >> page offset and length in smb_rqst
> >>
> >> On 5/30/2018 3:47 PM, Long Li wrote:
> >>> From: Long Li
> >>>
> >>> Introduce a function rqst_page_get_length to return the page offset
> >>> and length for a given page in smb_rqst. This function is to be used
> >>> by following patches.
> >>>
> >>> Signed-off-by: Long Li
> >>> ---
> >>>fs/cifs/cifsproto.h | 3 +++
> >>>fs/cifs/misc.c | 17 +
> >>>2 files changed, 20 insertions(+)
> >>>
> >>> diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h index
> >>> 7933c5f..89dda14 100644
> >>> --- a/fs/cifs/cifsproto.h
> >>> +++ b/fs/cifs/cifsproto.h
> >>> @@ -557,4 +557,7 @@ int cifs_alloc_hash(const char *name, struct
> >> crypto_shash **shash,
> >>> struct sdesc **sdesc);
> >>>void cifs_free_hash(struct crypto_shash **shash, struct sdesc
> >>> **sdesc);
> >>>
> >>> +extern void rqst_page_get_length(struct smb_rqst *rqst, unsigned
> >>> +int
> >> page,
> >>> + unsigned int *len, unsigned int *offset);
> >>> +
> >>>#endif /* _CIFSPROTO_H */
> >>> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c index 96849b5..e951417
> >>> 100644
> >>> --- a/fs/cifs/misc.c
> >>> +++ b/fs/cifs/misc.c
> >>> @@ -905,3 +905,20 @@ cifs_free_hash(struct crypto_shash **shash,
> >> struct sdesc **sdesc)
> >>> crypto_free_shash(*shash);
> >>> *shash = NULL;
> >>>}
> >>> +
> >>> +/**
> >>> + * rqst_page_get_length - obtain the length and offset for a page
> >>> +in smb_rqst
> >>> + * Input: rqst - a smb_rqst, page - a page index for rqst
> >>> + * Output: *len - the length for this page, *offset - the offset
> >>> +for this page */ void rqst_page_get_length(struct smb_rqst *rqst,
> >>> +unsigned int page,
> >>> + unsigned int *len, unsigned int *offset) {
> >>> + *len = rqst->rq_pagesz;
> >>> + *offset = (page == 0) ? rqst->rq_offset : 0;
> >>
> >> Really? Page 0 always has a zero offset??
> >
> > I think you are misreading this line. The offset for page 0 is rq_offset,
> > the
> offset for all subsequent pages are 0.
>
> Ah, yes, sorry I did read it incorrectly.
> >>> +
> >>> + if (rqst->rq_npages == 1 || page == rqst->rq_npages-1)
> >>> + *len = rqst->rq_tailsz;
> >>> + else if (page == 0)
> >>> + *len = rqst->rq_pagesz - rqst->rq_offset; }
> >>>
> >>
> >> This subroutine does what patch 5 does inline. Why not push this
> >> patch up in the sequence and use the helper?
> >
> > This is actually a little different. This function returns the length and
> > offset
> for a given page in the request. There might be multiple pages in a request.
>
> Ok, but I still think there is quite a bit of inline computation of this
> stuff that
> would more clearly and more robustly be done in a set of common functions.
> If someone ever touches the code to support a new upper layer, or even
> integrate with more complex compounding, things will get ugly fast.
>
> > The other function calculates the total length of all the pages in a
> > request.
>
> Again, a great candidate for a common set of subroutines, IMO.
I will look into this. The reason I didn't make a common function is that this
is the only patch that will use it in this way.
RE: [Patch v2 06/15] CIFS: Introduce helper function to get page offset and length in smb_rqst
> Subject: Re: [Patch v2 06/15] CIFS: Introduce helper function to get page
> offset and length in smb_rqst
>
> On 6/25/2018 5:14 PM, Long Li wrote:
> >> Subject: Re: [Patch v2 06/15] CIFS: Introduce helper function to get
> >> page offset and length in smb_rqst
> >>
> >> On 5/30/2018 3:47 PM, Long Li wrote:
> >>> From: Long Li
> >>>
> >>> Introduce a function rqst_page_get_length to return the page offset
> >>> and length for a given page in smb_rqst. This function is to be used
> >>> by following patches.
> >>>
> >>> Signed-off-by: Long Li
> >>> ---
> >>>fs/cifs/cifsproto.h | 3 +++
> >>>fs/cifs/misc.c | 17 +
> >>>2 files changed, 20 insertions(+)
> >>>
> >>> diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h index
> >>> 7933c5f..89dda14 100644
> >>> --- a/fs/cifs/cifsproto.h
> >>> +++ b/fs/cifs/cifsproto.h
> >>> @@ -557,4 +557,7 @@ int cifs_alloc_hash(const char *name, struct
> >> crypto_shash **shash,
> >>> struct sdesc **sdesc);
> >>>void cifs_free_hash(struct crypto_shash **shash, struct sdesc
> >>> **sdesc);
> >>>
> >>> +extern void rqst_page_get_length(struct smb_rqst *rqst, unsigned
> >>> +int
> >> page,
> >>> + unsigned int *len, unsigned int *offset);
> >>> +
> >>>#endif /* _CIFSPROTO_H */
> >>> diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c index 96849b5..e951417
> >>> 100644
> >>> --- a/fs/cifs/misc.c
> >>> +++ b/fs/cifs/misc.c
> >>> @@ -905,3 +905,20 @@ cifs_free_hash(struct crypto_shash **shash,
> >> struct sdesc **sdesc)
> >>> crypto_free_shash(*shash);
> >>> *shash = NULL;
> >>>}
> >>> +
> >>> +/**
> >>> + * rqst_page_get_length - obtain the length and offset for a page
> >>> +in smb_rqst
> >>> + * Input: rqst - a smb_rqst, page - a page index for rqst
> >>> + * Output: *len - the length for this page, *offset - the offset
> >>> +for this page */ void rqst_page_get_length(struct smb_rqst *rqst,
> >>> +unsigned int page,
> >>> + unsigned int *len, unsigned int *offset) {
> >>> + *len = rqst->rq_pagesz;
> >>> + *offset = (page == 0) ? rqst->rq_offset : 0;
> >>
> >> Really? Page 0 always has a zero offset??
> >
> > I think you are misreading this line. The offset for page 0 is rq_offset,
> > the
> offset for all subsequent pages are 0.
>
> Ah, yes, sorry I did read it incorrectly.
> >>> +
> >>> + if (rqst->rq_npages == 1 || page == rqst->rq_npages-1)
> >>> + *len = rqst->rq_tailsz;
> >>> + else if (page == 0)
> >>> + *len = rqst->rq_pagesz - rqst->rq_offset; }
> >>>
> >>
> >> This subroutine does what patch 5 does inline. Why not push this
> >> patch up in the sequence and use the helper?
> >
> > This is actually a little different. This function returns the length and
> > offset
> for a given page in the request. There might be multiple pages in a request.
>
> Ok, but I still think there is quite a bit of inline computation of this
> stuff that
> would more clearly and more robustly be done in a set of common functions.
> If someone ever touches the code to support a new upper layer, or even
> integrate with more complex compounding, things will get ugly fast.
>
> > The other function calculates the total length of all the pages in a
> > request.
>
> Again, a great candidate for a common set of subroutines, IMO.
I will look into this. The reason I didn't make a common function is that this
is the only patch that will use it in this way.
RE: [Patch v2 02/15] CIFS: Add support for direct pages in rdata
> Subject: Re: [Patch v2 02/15] CIFS: Add support for direct pages in rdata
>
> On 6/25/2018 5:01 PM, Jason Gunthorpe wrote:
> > On Sat, Jun 23, 2018 at 09:50:20PM -0400, Tom Talpey wrote:
> >> On 5/30/2018 3:47 PM, Long Li wrote:
> >>> From: Long Li
> >>>
> >>> Add a function to allocate rdata without allocating pages for data
> >>> transfer. This gives the caller an option to pass a number of pages
> >>> that point to the data buffer.
> >>>
> >>> rdata is still reponsible for free those pages after it's done.
> >>
> >> "Caller" is still responsible? Or is the rdata somehow freeing itself
> >> via another mechanism?
> >>
> >>>
> >>> Signed-off-by: Long Li
> >>> fs/cifs/cifsglob.h | 2 +-
> >>> fs/cifs/file.c | 23 ---
> >>> 2 files changed, 21 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index
> >>> 8d16c3e..56864a87 100644
> >>> +++ b/fs/cifs/cifsglob.h
> >>> @@ -1179,7 +1179,7 @@ struct cifs_readdata {
> >>> unsigned inttailsz;
> >>> unsigned intcredits;
> >>> unsigned intnr_pages;
> >>> - struct page *pages[];
> >>> + struct page **pages;
> >>
> >> Technically speaking, these are syntactically equivalent. It may not
> >> be worth changing this historic definition.
> >
> > [] is a C99 'flex array', it has a different allocation behavior than
> > ** and is not interchangeable..
>
> In that case, it's an even better reason to not change the declaration.
No, it needs to be declared separately.
With Direct I/O, **pages are allocated and returned from
iov_iter_get_pages_alloc() when locking those user pages. They can't be
allocated as part of struct cifs_readdata.
RE: [Patch v2 02/15] CIFS: Add support for direct pages in rdata
> Subject: Re: [Patch v2 02/15] CIFS: Add support for direct pages in rdata
>
> On 6/25/2018 5:01 PM, Jason Gunthorpe wrote:
> > On Sat, Jun 23, 2018 at 09:50:20PM -0400, Tom Talpey wrote:
> >> On 5/30/2018 3:47 PM, Long Li wrote:
> >>> From: Long Li
> >>>
> >>> Add a function to allocate rdata without allocating pages for data
> >>> transfer. This gives the caller an option to pass a number of pages
> >>> that point to the data buffer.
> >>>
> >>> rdata is still reponsible for free those pages after it's done.
> >>
> >> "Caller" is still responsible? Or is the rdata somehow freeing itself
> >> via another mechanism?
> >>
> >>>
> >>> Signed-off-by: Long Li
> >>> fs/cifs/cifsglob.h | 2 +-
> >>> fs/cifs/file.c | 23 ---
> >>> 2 files changed, 21 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index
> >>> 8d16c3e..56864a87 100644
> >>> +++ b/fs/cifs/cifsglob.h
> >>> @@ -1179,7 +1179,7 @@ struct cifs_readdata {
> >>> unsigned inttailsz;
> >>> unsigned intcredits;
> >>> unsigned intnr_pages;
> >>> - struct page *pages[];
> >>> + struct page **pages;
> >>
> >> Technically speaking, these are syntactically equivalent. It may not
> >> be worth changing this historic definition.
> >
> > [] is a C99 'flex array', it has a different allocation behavior than
> > ** and is not interchangeable..
>
> In that case, it's an even better reason to not change the declaration.
No, it needs to be declared separately.
With Direct I/O, **pages are allocated and returned from
iov_iter_get_pages_alloc() when locking those user pages. They can't be
allocated as part of struct cifs_readdata.
Re: linux-next: build failure after merge of the xarray tree
Hi all,
On Mon, 18 Jun 2018 10:09:20 -0700 Matthew Wilcox wrote:
>
> On Mon, Jun 18, 2018 at 09:50:33AM -0700, Dan Williams wrote:
> > On Sun, Jun 17, 2018 at 8:27 PM, Stephen Rothwell
> > wrote:
> > > Hi all,
> > >
> > > After merging the xarray tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> [...]
> > > from the nvdimm tree.
> > >
> > > Willy thanks for the heads up about this.
> > >
> > > I have applied the following merge fix patch (taken from the diff between
> > > the -next tree at this point and the xarray-20180615 branch from the
> > > xarray tree) for today.
> >
> > I was hoping that dax_lock_page() and the memory_failure() handling
> > could go in before the xarray rework. This helps -stable and distros
> > that need to backport this error handling support. Willy, would you be
> > amenable to rebasing on top of the next rev of the
> > dax+memory_failure() work?
> >
> > Apologies for the thrash.
>
> I am absolutely amenable to rebasing. The only problem is that I'm
> in Tokyo for the next two weeks. I can put some work in on this, but
> coordination may be a little off. If somebody else wants to do the work,
> the only (serious) difference between the xarray-20180615 and xarray
> branches in my repo is that the former is based on the dax_lock_page()
> changes having gone in.
>
> The differences sum up to:
>
> +@@ -414,8 +413,7 @@ struct page *dax_lock_page(unsigned long pfn)
> +
> + entry = __radix_tree_lookup(>i_pages, index, NULL,
> + );
> +- if (!entry ||
> +- WARN_ON_ONCE(!radix_tree_exceptional_entry(entry))) {
> ++ if (!entry || WARN_ON_ONCE(!xa_is_value(entry))) {
> + xa_unlock_irq(>i_pages);
> + break;
> + } else if (!slot_locked(mapping, slot)) {
>
> (in "xarray: Replace exceptional entries")
>
> then dax_entry_waitqueue() changing its argument in "dax: Hash on XArray
> instead of mapping".
>
> and finally the patch converting dax_lock_page() and dax_unlock_page().
>
> I really wanted to keep the thrash here to a minimum, but this is the
> best I could come up with in terms of minimising conflicts :-(
This has all gone away today as the conflicting commits have been
removed from the nvdimm tree.
--
Cheers,
Stephen Rothwell
pgpNt7LUkf9ku.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the xarray tree
Hi all,
On Mon, 18 Jun 2018 10:09:20 -0700 Matthew Wilcox wrote:
>
> On Mon, Jun 18, 2018 at 09:50:33AM -0700, Dan Williams wrote:
> > On Sun, Jun 17, 2018 at 8:27 PM, Stephen Rothwell
> > wrote:
> > > Hi all,
> > >
> > > After merging the xarray tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> [...]
> > > from the nvdimm tree.
> > >
> > > Willy thanks for the heads up about this.
> > >
> > > I have applied the following merge fix patch (taken from the diff between
> > > the -next tree at this point and the xarray-20180615 branch from the
> > > xarray tree) for today.
> >
> > I was hoping that dax_lock_page() and the memory_failure() handling
> > could go in before the xarray rework. This helps -stable and distros
> > that need to backport this error handling support. Willy, would you be
> > amenable to rebasing on top of the next rev of the
> > dax+memory_failure() work?
> >
> > Apologies for the thrash.
>
> I am absolutely amenable to rebasing. The only problem is that I'm
> in Tokyo for the next two weeks. I can put some work in on this, but
> coordination may be a little off. If somebody else wants to do the work,
> the only (serious) difference between the xarray-20180615 and xarray
> branches in my repo is that the former is based on the dax_lock_page()
> changes having gone in.
>
> The differences sum up to:
>
> +@@ -414,8 +413,7 @@ struct page *dax_lock_page(unsigned long pfn)
> +
> + entry = __radix_tree_lookup(>i_pages, index, NULL,
> + );
> +- if (!entry ||
> +- WARN_ON_ONCE(!radix_tree_exceptional_entry(entry))) {
> ++ if (!entry || WARN_ON_ONCE(!xa_is_value(entry))) {
> + xa_unlock_irq(>i_pages);
> + break;
> + } else if (!slot_locked(mapping, slot)) {
>
> (in "xarray: Replace exceptional entries")
>
> then dax_entry_waitqueue() changing its argument in "dax: Hash on XArray
> instead of mapping".
>
> and finally the patch converting dax_lock_page() and dax_unlock_page().
>
> I really wanted to keep the thrash here to a minimum, but this is the
> best I could come up with in terms of minimising conflicts :-(
This has all gone away today as the conflicting commits have been
removed from the nvdimm tree.
--
Cheers,
Stephen Rothwell
pgpNt7LUkf9ku.pgp
Description: OpenPGP digital signature
Re: [PATCH] arm: dts: socfpga: denali needs nand_x_clk too
2018-06-27 3:09 GMT+09:00 Miquel Raynal :
> Hi Masahiro,
>
> On Tue, 26 Jun 2018 11:38:21 +0900, Masahiro Yamada
> wrote:
>
>> 2018-06-25 23:55 GMT+09:00 Boris Brezillon :
>> > On Mon, 25 Jun 2018 09:50:18 -0500
>> > Dinh Nguyen wrote:
>> >
>> >> On 06/22/2018 10:58 AM, Richard Weinberger wrote:
>> >> > Masahiro,
>> >> >
>> >> > Am Freitag, 22. Juni 2018, 16:37:21 CEST schrieb Masahiro Yamada:
>> >> >> Hi Richard,
>> >> >>
>> >> >>
>> >> >> 2018-06-19 21:07 GMT+09:00 Richard Weinberger :
>> >> >>> The denali NAND flash controller needs at least two clocks to operate,
>> >> >>> nand_clk and nand_x_clk.
>> >> >>> Since 1bb88666775e ("mtd: nand: denali: handle timing parameters by
>> >> >>> setup_data_interface()") nand_x_clk is used to derive timing settings.
>> >> >>>
>> >> >>> Signed-off-by: Richard Weinberger
>> >> >>> ---
>> >> >>> Strictly speaking denali needs a ecc_clk too, but AFAIK such a clock
>> >> >>> is not present on this SoC.
>> >> >>> But my SoCFPGA knowledge is very limited.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> //richard
>> >> >>> ---
>> >> >>> arch/arm/boot/dts/socfpga.dtsi | 3 ++-
>> >> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >>>
>> >> >>> diff --git a/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> b/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> index 486d4e7433ed..562f7b375bbd 100644
>> >> >>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> @@ -754,7 +754,8 @@
>> >> >>> reg-names = "nand_data", "denali_reg";
>> >> >>> interrupts = <0x0 0x90 0x4>;
>> >> >>> dma-mask = <0x>;
>> >> >>> - clocks = <_clk>;
>> >> >>> + clocks = <_clk>, <_x_clk>;
>> >> >>> + clock-names = "nand", "nand_x";
>> >> >>
>> >> >>
>> >> >> IMHO, this should be
>> >> >>
>> >> >> clocks = <_clk>, <_x_clk>,
>> >> >> <_x_clk>;
>> >> >> clock-names = "nand", "nand_x", "ecc";
>> >>
>> >> No, it should be just the nand_x and ecc.
>> >>
>> >> There's already a patch to use the nand_x_clk and not the nand_clk.
>>
>>
>> Different people try to fix the problem in different ways.
>>
>> I think it is due to miscommunication across sub-systems.
>
> Is the series named
>
> mtd: rawnand: denali: add new clocks and improve
> setup_data_interface
>
> still valid?
Yes.
I believe V4 is valid.
Information for Dinh Nguyen:
http://patchwork.ozlabs.org/patch/933507/
http://patchwork.ozlabs.org/patch/933487/
http://patchwork.ozlabs.org/patch/933494/
http://patchwork.ozlabs.org/patch/933506/
If he is not convinced, I am open to discussion, though.
> I am about to apply it (patches 2/5 to 5/5) but it looks like the
> discussion is still ongoing.
>
> Thanks,
> Miquèl
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards
Masahiro Yamada
Re: [PATCH] arm: dts: socfpga: denali needs nand_x_clk too
2018-06-27 3:09 GMT+09:00 Miquel Raynal :
> Hi Masahiro,
>
> On Tue, 26 Jun 2018 11:38:21 +0900, Masahiro Yamada
> wrote:
>
>> 2018-06-25 23:55 GMT+09:00 Boris Brezillon :
>> > On Mon, 25 Jun 2018 09:50:18 -0500
>> > Dinh Nguyen wrote:
>> >
>> >> On 06/22/2018 10:58 AM, Richard Weinberger wrote:
>> >> > Masahiro,
>> >> >
>> >> > Am Freitag, 22. Juni 2018, 16:37:21 CEST schrieb Masahiro Yamada:
>> >> >> Hi Richard,
>> >> >>
>> >> >>
>> >> >> 2018-06-19 21:07 GMT+09:00 Richard Weinberger :
>> >> >>> The denali NAND flash controller needs at least two clocks to operate,
>> >> >>> nand_clk and nand_x_clk.
>> >> >>> Since 1bb88666775e ("mtd: nand: denali: handle timing parameters by
>> >> >>> setup_data_interface()") nand_x_clk is used to derive timing settings.
>> >> >>>
>> >> >>> Signed-off-by: Richard Weinberger
>> >> >>> ---
>> >> >>> Strictly speaking denali needs a ecc_clk too, but AFAIK such a clock
>> >> >>> is not present on this SoC.
>> >> >>> But my SoCFPGA knowledge is very limited.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> //richard
>> >> >>> ---
>> >> >>> arch/arm/boot/dts/socfpga.dtsi | 3 ++-
>> >> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >>>
>> >> >>> diff --git a/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> b/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> index 486d4e7433ed..562f7b375bbd 100644
>> >> >>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> >> >>> @@ -754,7 +754,8 @@
>> >> >>> reg-names = "nand_data", "denali_reg";
>> >> >>> interrupts = <0x0 0x90 0x4>;
>> >> >>> dma-mask = <0x>;
>> >> >>> - clocks = <_clk>;
>> >> >>> + clocks = <_clk>, <_x_clk>;
>> >> >>> + clock-names = "nand", "nand_x";
>> >> >>
>> >> >>
>> >> >> IMHO, this should be
>> >> >>
>> >> >> clocks = <_clk>, <_x_clk>,
>> >> >> <_x_clk>;
>> >> >> clock-names = "nand", "nand_x", "ecc";
>> >>
>> >> No, it should be just the nand_x and ecc.
>> >>
>> >> There's already a patch to use the nand_x_clk and not the nand_clk.
>>
>>
>> Different people try to fix the problem in different ways.
>>
>> I think it is due to miscommunication across sub-systems.
>
> Is the series named
>
> mtd: rawnand: denali: add new clocks and improve
> setup_data_interface
>
> still valid?
Yes.
I believe V4 is valid.
Information for Dinh Nguyen:
http://patchwork.ozlabs.org/patch/933507/
http://patchwork.ozlabs.org/patch/933487/
http://patchwork.ozlabs.org/patch/933494/
http://patchwork.ozlabs.org/patch/933506/
If he is not convinced, I am open to discussion, though.
> I am about to apply it (patches 2/5 to 5/5) but it looks like the
> discussion is still ongoing.
>
> Thanks,
> Miquèl
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards
Masahiro Yamada
Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline
On Tue, Jun 26, 2018 at 12:27:47PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 26, 2018 at 07:46:52PM +0800, Boqun Feng wrote:
> > On Tue, Jun 26, 2018 at 06:44:47PM +0800, Boqun Feng wrote:
> > > On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote:
> > > > On Mon, Jun 25, 2018 at 03:43:32PM -0700, Paul E. McKenney wrote:
> > > > > + preempt_disable();
> > > > > + for_each_leaf_node_possible_cpu(rnp, cpu) {
> > > > > + if (cpu_is_offline(cpu)) /* Preemption
> > > > > disabled. */
> > > > > + continue;
> > > >
> > > > Create for_each_node_online_cpu() instead? Seems a bit pointless to
> > > > iterate possible mask only to then check it against the online mask.
> > > > Just iterate the online mask directly.
> > > >
> > > > Or better yet, write this as:
> > > >
> > > > preempt_disable();
> > > > cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
> > > > if (cpu > rnp->grphi)
> > > > cpu = WORK_CPU_UNBOUND;
> > > > queue_work_on(cpu, rcu_par_gp_wq, >rew.rew_work);
> > > > preempt_enable();
> > > >
> > > > Which is what it appears to be doing.
> > > >
> > >
> > > Make sense! Thanks ;-)
> > >
> > > Applied this and running a TREE03 rcutorture. If all go well, I will
> > > send the updated patch.
> > >
> >
> > So the patch has passed one 30 min run for TREE03 rcutorture. Paul,
> > if it looks good, could you take it for your next spin or pull request
> > in the future? Thanks.
>
> I ended up with the following, mostly just rewording the comment and
> adding a one-liner on the change. Does this work for you?
>
Looks good to me. Only one thing I think we need to modify a little,
please see below:
> Thanx, Paul
>
>
>
> commit ef31fa78032536d594630d7bd315d3faf60d98ca
> Author: Boqun Feng
> Date: Fri Jun 15 12:06:31 2018 -0700
>
> rcu: Make expedited GPs handle CPU 0 being offline
>
> Currently, the parallelized initialization of expedited grace periods uses
> the workqueue associated with each rcu_node structure's ->grplo field.
> This works fine unless that CPU is offline. This commit therefore
> uses the CPU corresponding to the lowest-numbered online CPU, or just
> reports the quiescent states if there are no online CPUs on this rcu_node
> structure.
better write "or just queue the work on WORK_CPU_UNBOUND if there are
no online CPUs on this rcu_node structure"? Because we currently don't
report the QS directly if all CPU are offline.
Thoughts?
Regards,
Boqun
>
> Note that this patch uses cpu_is_offline() instead of the usual
> approach of checking bits in the rcu_node structure's ->qsmaskinitnext
> field. This is safe because preemption is disabled across both the
> cpu_is_offline() check and the call to queue_work_on().
>
> Signed-off-by: Boqun Feng
> [ paulmck: Disable preemption to close offline race window. ]
> Signed-off-by: Paul E. McKenney
> [ paulmck: Apply Peter Zijlstra feedback on CPU selection. ]
>
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index c6385ee1af65..b3df3b770afb 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -472,6 +472,7 @@ static void sync_rcu_exp_select_node_cpus(struct
> work_struct *wp)
> static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
>smp_call_func_t func)
> {
> + int cpu;
> struct rcu_node *rnp;
>
> trace_rcu_exp_grace_period(rsp->name, rcu_exp_gp_seq_endval(rsp),
> TPS("reset"));
> @@ -493,7 +494,13 @@ static void sync_rcu_exp_select_cpus(struct rcu_state
> *rsp,
> continue;
> }
> INIT_WORK(>rew.rew_work, sync_rcu_exp_select_node_cpus);
> - queue_work_on(rnp->grplo, rcu_par_gp_wq, >rew.rew_work);
> + preempt_disable();
> + cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
> + /* If all offline, queue the work on an unbound CPU. */
> + if (unlikely(cpu > rnp->grphi))
> + cpu = WORK_CPU_UNBOUND;
> + queue_work_on(cpu, rcu_par_gp_wq, >rew.rew_work);
> + preempt_enable();
> rnp->exp_need_flush = true;
> }
>
>
signature.asc
Description: PGP signature
Re: [PATCH tip/core/rcu 2/2] rcu: Make expedited GPs handle CPU 0 being offline
On Tue, Jun 26, 2018 at 12:27:47PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 26, 2018 at 07:46:52PM +0800, Boqun Feng wrote:
> > On Tue, Jun 26, 2018 at 06:44:47PM +0800, Boqun Feng wrote:
> > > On Tue, Jun 26, 2018 at 11:38:20AM +0200, Peter Zijlstra wrote:
> > > > On Mon, Jun 25, 2018 at 03:43:32PM -0700, Paul E. McKenney wrote:
> > > > > + preempt_disable();
> > > > > + for_each_leaf_node_possible_cpu(rnp, cpu) {
> > > > > + if (cpu_is_offline(cpu)) /* Preemption
> > > > > disabled. */
> > > > > + continue;
> > > >
> > > > Create for_each_node_online_cpu() instead? Seems a bit pointless to
> > > > iterate possible mask only to then check it against the online mask.
> > > > Just iterate the online mask directly.
> > > >
> > > > Or better yet, write this as:
> > > >
> > > > preempt_disable();
> > > > cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
> > > > if (cpu > rnp->grphi)
> > > > cpu = WORK_CPU_UNBOUND;
> > > > queue_work_on(cpu, rcu_par_gp_wq, >rew.rew_work);
> > > > preempt_enable();
> > > >
> > > > Which is what it appears to be doing.
> > > >
> > >
> > > Make sense! Thanks ;-)
> > >
> > > Applied this and running a TREE03 rcutorture. If all go well, I will
> > > send the updated patch.
> > >
> >
> > So the patch has passed one 30 min run for TREE03 rcutorture. Paul,
> > if it looks good, could you take it for your next spin or pull request
> > in the future? Thanks.
>
> I ended up with the following, mostly just rewording the comment and
> adding a one-liner on the change. Does this work for you?
>
Looks good to me. Only one thing I think we need to modify a little,
please see below:
> Thanx, Paul
>
>
>
> commit ef31fa78032536d594630d7bd315d3faf60d98ca
> Author: Boqun Feng
> Date: Fri Jun 15 12:06:31 2018 -0700
>
> rcu: Make expedited GPs handle CPU 0 being offline
>
> Currently, the parallelized initialization of expedited grace periods uses
> the workqueue associated with each rcu_node structure's ->grplo field.
> This works fine unless that CPU is offline. This commit therefore
> uses the CPU corresponding to the lowest-numbered online CPU, or just
> reports the quiescent states if there are no online CPUs on this rcu_node
> structure.
better write "or just queue the work on WORK_CPU_UNBOUND if there are
no online CPUs on this rcu_node structure"? Because we currently don't
report the QS directly if all CPU are offline.
Thoughts?
Regards,
Boqun
>
> Note that this patch uses cpu_is_offline() instead of the usual
> approach of checking bits in the rcu_node structure's ->qsmaskinitnext
> field. This is safe because preemption is disabled across both the
> cpu_is_offline() check and the call to queue_work_on().
>
> Signed-off-by: Boqun Feng
> [ paulmck: Disable preemption to close offline race window. ]
> Signed-off-by: Paul E. McKenney
> [ paulmck: Apply Peter Zijlstra feedback on CPU selection. ]
>
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index c6385ee1af65..b3df3b770afb 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -472,6 +472,7 @@ static void sync_rcu_exp_select_node_cpus(struct
> work_struct *wp)
> static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
>smp_call_func_t func)
> {
> + int cpu;
> struct rcu_node *rnp;
>
> trace_rcu_exp_grace_period(rsp->name, rcu_exp_gp_seq_endval(rsp),
> TPS("reset"));
> @@ -493,7 +494,13 @@ static void sync_rcu_exp_select_cpus(struct rcu_state
> *rsp,
> continue;
> }
> INIT_WORK(>rew.rew_work, sync_rcu_exp_select_node_cpus);
> - queue_work_on(rnp->grplo, rcu_par_gp_wq, >rew.rew_work);
> + preempt_disable();
> + cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
> + /* If all offline, queue the work on an unbound CPU. */
> + if (unlikely(cpu > rnp->grphi))
> + cpu = WORK_CPU_UNBOUND;
> + queue_work_on(cpu, rcu_par_gp_wq, >rew.rew_work);
> + preempt_enable();
> rnp->exp_need_flush = true;
> }
>
>
signature.asc
Description: PGP signature
Good day
Good day, I am Mrs. Deepak Rajappan a banker from India and I work with a bank here. I have a profitable and risk free business proposal that will benefit the both of us. Kindly contact me for more details. Thanks Mrs. Deepak Rajappan Email: deepakrajap...@hotmail.com
Good day
Good day, I am Mrs. Deepak Rajappan a banker from India and I work with a bank here. I have a profitable and risk free business proposal that will benefit the both of us. Kindly contact me for more details. Thanks Mrs. Deepak Rajappan Email: deepakrajap...@hotmail.com
Re: [PATCH 1/8] hwspinlock: Add one new API to support getting a specific hwlock by the name
On 27 June 2018 at 04:54, Bjorn Andersson wrote: > On Fri 22 Jun 01:08 PDT 2018, Baolin Wang wrote: > >> The hardware spinlock binding already supplied the 'hwlock-names' property >> to match and get a specific hwlock, but did not supply one API for users >> to get a specific hwlock by the hwlock name. So this patch introduces one >> API to support this requirement. >> >> Signed-off-by: Baolin Wang > > Thanks Baolin, > > Picked up all but patch 6 from the series; including 7 and 8 with Mark's > ack. OK. Thanks Bjorn and Mark. -- Baolin.wang Best Regards
Re: [PATCH 1/8] hwspinlock: Add one new API to support getting a specific hwlock by the name
On 27 June 2018 at 04:54, Bjorn Andersson wrote: > On Fri 22 Jun 01:08 PDT 2018, Baolin Wang wrote: > >> The hardware spinlock binding already supplied the 'hwlock-names' property >> to match and get a specific hwlock, but did not supply one API for users >> to get a specific hwlock by the hwlock name. So this patch introduces one >> API to support this requirement. >> >> Signed-off-by: Baolin Wang > > Thanks Baolin, > > Picked up all but patch 6 from the series; including 7 and 8 with Mark's > ack. OK. Thanks Bjorn and Mark. -- Baolin.wang Best Regards
Re: [PATCH 6/8] hwspinlock: sprd: Use devm_hwspin_lock_register()
On 27 June 2018 at 04:51, Bjorn Andersson wrote:
> On Fri 22 Jun 01:09 PDT 2018, Baolin Wang wrote:
>
>> Use devm_hwspin_lock_register() to register the hwlock controller to
>> avoid unregistering the device explicitly.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/hwspinlock/sprd_hwspinlock.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwspinlock/sprd_hwspinlock.c
>> b/drivers/hwspinlock/sprd_hwspinlock.c
>> index dc42bf5..ba5daf6 100644
>> --- a/drivers/hwspinlock/sprd_hwspinlock.c
>> +++ b/drivers/hwspinlock/sprd_hwspinlock.c
>> @@ -120,8 +120,9 @@ static int sprd_hwspinlock_probe(struct platform_device
>> *pdev)
>> platform_set_drvdata(pdev, sprd_hwlock);
>> pm_runtime_enable(>dev);
>>
>> - ret = hwspin_lock_register(_hwlock->bank, >dev,
>> -_hwspinlock_ops, 0, SPRD_HWLOCKS_NUM);
>> + ret = devm_hwspin_lock_register(>dev, _hwlock->bank,
>> + _hwspinlock_ops, 0,
>> + SPRD_HWLOCKS_NUM);
>> if (ret) {
>> pm_runtime_disable(>dev);
>> clk_disable_unprepare(sprd_hwlock->clk);
>> @@ -135,7 +136,6 @@ static int sprd_hwspinlock_remove(struct platform_device
>> *pdev)
>> {
>> struct sprd_hwspinlock_dev *sprd_hwlock = platform_get_drvdata(pdev);
>>
>> - hwspin_lock_unregister(_hwlock->bank);
>
> Until the hwspinlock is unregistered it's possible for clients to issue
> operations on it, so disabling power and clocks before that seems bad.
Yes, you are right. So may be register some additional actions with devm
core to call the clock disable as appropriate. Thanks.
--
Baolin.wang
Best Regards
Re: [PATCH 6/8] hwspinlock: sprd: Use devm_hwspin_lock_register()
On 27 June 2018 at 04:51, Bjorn Andersson wrote:
> On Fri 22 Jun 01:09 PDT 2018, Baolin Wang wrote:
>
>> Use devm_hwspin_lock_register() to register the hwlock controller to
>> avoid unregistering the device explicitly.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/hwspinlock/sprd_hwspinlock.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwspinlock/sprd_hwspinlock.c
>> b/drivers/hwspinlock/sprd_hwspinlock.c
>> index dc42bf5..ba5daf6 100644
>> --- a/drivers/hwspinlock/sprd_hwspinlock.c
>> +++ b/drivers/hwspinlock/sprd_hwspinlock.c
>> @@ -120,8 +120,9 @@ static int sprd_hwspinlock_probe(struct platform_device
>> *pdev)
>> platform_set_drvdata(pdev, sprd_hwlock);
>> pm_runtime_enable(>dev);
>>
>> - ret = hwspin_lock_register(_hwlock->bank, >dev,
>> -_hwspinlock_ops, 0, SPRD_HWLOCKS_NUM);
>> + ret = devm_hwspin_lock_register(>dev, _hwlock->bank,
>> + _hwspinlock_ops, 0,
>> + SPRD_HWLOCKS_NUM);
>> if (ret) {
>> pm_runtime_disable(>dev);
>> clk_disable_unprepare(sprd_hwlock->clk);
>> @@ -135,7 +136,6 @@ static int sprd_hwspinlock_remove(struct platform_device
>> *pdev)
>> {
>> struct sprd_hwspinlock_dev *sprd_hwlock = platform_get_drvdata(pdev);
>>
>> - hwspin_lock_unregister(_hwlock->bank);
>
> Until the hwspinlock is unregistered it's possible for clients to issue
> operations on it, so disabling power and clocks before that seems bad.
Yes, you are right. So may be register some additional actions with devm
core to call the clock disable as appropriate. Thanks.
--
Baolin.wang
Best Regards
Re: [PATCH 2/2] ASoC: tas517x: add tas5707 support
Hi Jerome, I love your patch! Perhaps something to improve: [auto build test WARNING on asoc/for-next] [also build test WARNING on v4.18-rc2 next-20180626] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jerome-Brunet/ASoC-add-tas5707-support/20180627-022004 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): >> sound/soc/codecs/tas571x.c:472:14: warning: duplicate 'const' declaration >> specifier [-Wduplicate-decl-specifier] static const SOC_VALUE_ENUM_SINGLE_DECL(tas5707_volume_slew_step_enum, ^ vim +/const +472 sound/soc/codecs/tas571x.c 471 > 472 static const SOC_VALUE_ENUM_SINGLE_DECL(tas5707_volume_slew_step_enum, 473 TAS571X_VOL_CFG_REG, 0, 0x3, 474 tas5707_volume_slew_step_txt, 475 tas5707_volume_slew_step_values); 476 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 2/2] ASoC: tas517x: add tas5707 support
Hi Jerome, I love your patch! Perhaps something to improve: [auto build test WARNING on asoc/for-next] [also build test WARNING on v4.18-rc2 next-20180626] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jerome-Brunet/ASoC-add-tas5707-support/20180627-022004 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): >> sound/soc/codecs/tas571x.c:472:14: warning: duplicate 'const' declaration >> specifier [-Wduplicate-decl-specifier] static const SOC_VALUE_ENUM_SINGLE_DECL(tas5707_volume_slew_step_enum, ^ vim +/const +472 sound/soc/codecs/tas571x.c 471 > 472 static const SOC_VALUE_ENUM_SINGLE_DECL(tas5707_volume_slew_step_enum, 473 TAS571X_VOL_CFG_REG, 0, 0x3, 474 tas5707_volume_slew_step_txt, 475 tas5707_volume_slew_step_values); 476 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v5 0/4] mm/sparse: Optimize memmap allocation during sparse_init()
On 06/27/18 at 09:31am, Baoquan He wrote: > This is v4 post. V3 can be found here: > https://lkml.org/lkml/2018/2/27/928 Sorry, forgot updating this part. This is v5 post, v4 can be found here: http://lkml.kernel.org/r/20180521101555.25610-1-...@redhat.com > > V1 can be found here: > https://www.spinics.net/lists/linux-mm/msg144486.html > > In sparse_init(), two temporary pointer arrays, usemap_map and map_map > are allocated with the size of NR_MEM_SECTIONS. They are used to store > each memory section's usemap and mem map if marked as present. In > 5-level paging mode, this will cost 512M memory though they will be > released at the end of sparse_init(). System with few memory, like > kdump kernel which usually only has about 256M, will fail to boot > because of allocation failure if CONFIG_X86_5LEVEL=y. > > In this patchset, optimize the memmap allocation code to only use > usemap_map and map_map with the size of nr_present_sections. This > makes kdump kernel boot up with normal crashkernel='' setting when > CONFIG_X86_5LEVEL=y. > > Change log: > v4->v5: > Improve patch 3/4 log according to Dave's suggestion. > > Correct the wrong copy of making 'nr_consumed_maps' to > 'alloc_usemap_and_memmap' mistakenly which is pointed out by > Dave in patch 4/4 code comment. > > Otherwise, no code change in this version. > v3->v4: > Improve according to Dave's three concerns which are in patch 0004: > > Rename variable 'idx_present' to 'nr_consumed_maps' which used to > index the memmap and usemap of present sections. > > Add a check if 'nr_consumed_maps' goes beyond nr_present_sections. > > Add code comment above the final for_each_present_section_nr() to > tell why 'nr_consumed_maps' need be increased in each iteration > whether the 'ms->section_mem_map' need cleared or out. > > v2->v3: > Change nr_present_sections as __initdata and add code comment > according to Andrew's suggestion. > > Change the local variable 'i' as idx_present which loops over the > present sections, and improve the code. These are suggested by > Dave and Pankaj. > > Add a new patch 0003 which adds a new parameter 'data_unit_size' > to function alloc_usemap_and_memmap() in which we will update 'data' > to make it point at new position. However its type 'void *' can't give > us needed info to do that. Need pass the unit size in. So change code > in patch 0004 accordingly. This is a code bug fix found when tested > the memory deployed on multiple nodes. > > v1-v2: > Split out the nr_present_sections adding as a single patch for easier > reviewing. > > Rewrite patch log according to Dave's suggestion. > > Fix code bug in patch 0002 reported by test robot. > > Baoquan He (4): > mm/sparse: Add a static variable nr_present_sections > mm/sparsemem: Defer the ms->section_mem_map clearing > mm/sparse: Add a new parameter 'data_unit_size' for > alloc_usemap_and_memmap > mm/sparse: Optimize memmap allocation during sparse_init() > > mm/sparse-vmemmap.c | 6 ++--- > mm/sparse.c | 72 > + > 2 files changed, 59 insertions(+), 19 deletions(-) > > -- > 2.13.6 >
Re: [PATCH v5 0/4] mm/sparse: Optimize memmap allocation during sparse_init()
On 06/27/18 at 09:31am, Baoquan He wrote: > This is v4 post. V3 can be found here: > https://lkml.org/lkml/2018/2/27/928 Sorry, forgot updating this part. This is v5 post, v4 can be found here: http://lkml.kernel.org/r/20180521101555.25610-1-...@redhat.com > > V1 can be found here: > https://www.spinics.net/lists/linux-mm/msg144486.html > > In sparse_init(), two temporary pointer arrays, usemap_map and map_map > are allocated with the size of NR_MEM_SECTIONS. They are used to store > each memory section's usemap and mem map if marked as present. In > 5-level paging mode, this will cost 512M memory though they will be > released at the end of sparse_init(). System with few memory, like > kdump kernel which usually only has about 256M, will fail to boot > because of allocation failure if CONFIG_X86_5LEVEL=y. > > In this patchset, optimize the memmap allocation code to only use > usemap_map and map_map with the size of nr_present_sections. This > makes kdump kernel boot up with normal crashkernel='' setting when > CONFIG_X86_5LEVEL=y. > > Change log: > v4->v5: > Improve patch 3/4 log according to Dave's suggestion. > > Correct the wrong copy of making 'nr_consumed_maps' to > 'alloc_usemap_and_memmap' mistakenly which is pointed out by > Dave in patch 4/4 code comment. > > Otherwise, no code change in this version. > v3->v4: > Improve according to Dave's three concerns which are in patch 0004: > > Rename variable 'idx_present' to 'nr_consumed_maps' which used to > index the memmap and usemap of present sections. > > Add a check if 'nr_consumed_maps' goes beyond nr_present_sections. > > Add code comment above the final for_each_present_section_nr() to > tell why 'nr_consumed_maps' need be increased in each iteration > whether the 'ms->section_mem_map' need cleared or out. > > v2->v3: > Change nr_present_sections as __initdata and add code comment > according to Andrew's suggestion. > > Change the local variable 'i' as idx_present which loops over the > present sections, and improve the code. These are suggested by > Dave and Pankaj. > > Add a new patch 0003 which adds a new parameter 'data_unit_size' > to function alloc_usemap_and_memmap() in which we will update 'data' > to make it point at new position. However its type 'void *' can't give > us needed info to do that. Need pass the unit size in. So change code > in patch 0004 accordingly. This is a code bug fix found when tested > the memory deployed on multiple nodes. > > v1-v2: > Split out the nr_present_sections adding as a single patch for easier > reviewing. > > Rewrite patch log according to Dave's suggestion. > > Fix code bug in patch 0002 reported by test robot. > > Baoquan He (4): > mm/sparse: Add a static variable nr_present_sections > mm/sparsemem: Defer the ms->section_mem_map clearing > mm/sparse: Add a new parameter 'data_unit_size' for > alloc_usemap_and_memmap > mm/sparse: Optimize memmap allocation during sparse_init() > > mm/sparse-vmemmap.c | 6 ++--- > mm/sparse.c | 72 > + > 2 files changed, 59 insertions(+), 19 deletions(-) > > -- > 2.13.6 >
