Re: [RFC 3/7] tee: add private login method for kernel clients

[Jens Wiklander]

Hi Sumit,

On Tue, Jul 9, 2019 at 11:36 AM Sumit Garg  wrote:
>
> On Tue, 9 Jul 2019 at 12:33, Jens Wiklander  wrote:
> >
> > On Tue, Jul 09, 2019 at 11:26:19AM +0530, Sumit Garg wrote:
> > > Thanks Jens for your comments.
> > >
> > > On Mon, 8 Jul 2019 at 21:09, Jens Wiklander  
> > > wrote:
> > > >
> > > > Hi Sumit,
> > > >
> > > > On Thu, Jun 13, 2019 at 04:00:29PM +0530, Sumit Garg wrote:
> > > > > There are use-cases where user-space shouldn't be allowed to 
> > > > > communicate
> > > > > directly with a TEE device which is dedicated to provide a specific
> > > > > service for a kernel client. So add a private login method for kernel
> > > > > clients and disallow user-space to open-session using this login 
> > > > > method.
> > > > >
> > > > > Signed-off-by: Sumit Garg 
> > > > > ---
> > > > >  drivers/tee/tee_core.c   | 6 ++
> > > > >  include/uapi/linux/tee.h | 2 ++
> > > > >  2 files changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > > > index 0f16d9f..4581bd1 100644
> > > > > --- a/drivers/tee/tee_core.c
> > > > > +++ b/drivers/tee/tee_core.c
> > > > > @@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct 
> > > > > tee_context *ctx,
> > > > >   goto out;
> > > > >   }
> > > > >
> > > > > + if (arg.clnt_login == TEE_IOCTL_LOGIN_REE_KERNEL) {
> > > > TEE_IOCTL_LOGIN_REE_KERNEL is defined as 0x8000 which is in the
> > > > range specified and implementation defined by the GP spec. I wonder if
> > > > we shouldn't filter the entire implementation defined range instead of
> > > > just this value.
> > >
> > > Agree. Will rather check for entire implementation defined range:
> > > 0x8000 - 0x.
> > >
>
> I had a second thought on this. It would be more restrictive for
> user-space TEE client library which may need to use implementation
> defined login method. So either we could define specific ranges for
> kernel and user-space or we can start with single login method
> reserved for kernel.

I think we should reserve a range for kernel internal use. Only
reserving a single single login for kernel could force us to restrict
the API once more later, better to take a chunk now and be done with
it. Half of 0x8000 - 0x is probably more than enough too
to leave a range for user space too.

>
> > > >
> > > > > + pr_err("login method not allowed for user-space 
> > > > > client\n");
> > > > pr_debug(), if it's needed at all.
> > > >
> > >
> > > Ok will use pr_debug() instead.
> > >
> > > > > + rc = -EPERM;
> > > > > + goto out;
> > > > > + }
> > > > > +
> > > > >   rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
> > > > >   if (rc)
> > > > >   goto out;
> > > > > diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
> > > > > index 4b9eb06..f33c69c 100644
> > > > > --- a/include/uapi/linux/tee.h
> > > > > +++ b/include/uapi/linux/tee.h
> > > > > @@ -172,6 +172,8 @@ struct tee_ioctl_buf_data {
> > > > >  #define TEE_IOCTL_LOGIN_APPLICATION  4
> > > > >  #define TEE_IOCTL_LOGIN_USER_APPLICATION 5
> > > > >  #define TEE_IOCTL_LOGIN_GROUP_APPLICATION6
> > > > > +/* Private login method for REE kernel clients */
> > > > It's worth noting that this is filtered by the TEE framework, compared
> > > > to everything else which is treated opaquely.
> > > >
> > >
> > > IIUC, you are referring to login filter in optee_os. Change to prevent
> > > filter for this login method is part of this PR [1].
> > >
> > > [1] https://github.com/OP-TEE/optee_os/pull/3082
> >
> > No, I was referring to the changes in tee_ioctl_open_session() above.
> > It's relevant for user space to know since it will be prevented from
> > using that range of login identifiers.
>
> Ok, so you mean to extend the comment here for user-space to know that
> this login method/range is filtered by the TEE framework. Will do
> that.
>
> > This will restrict the user space
> > API, but I think the risk of breakage is minimal as OP-TEE is the only
> > in-tree driver registering in the TEE framework. I'm not aware of any
> > out-of-tree drivers registering.
>
> I am not sure if I follow you here. How do you expect this change to
> break out-of-tree TEE driver registration?

It's a change in common code that put restrictions on the API.

Thanks,
Jens


>
> -Sumit
>
> >
> > Thanks,
> > Jens
> >
> > >
> > > -Sumit
> > >
> > > > > +#define TEE_IOCTL_LOGIN_REE_KERNEL   0x8000
> > > > >
> > > > >  /**
> > > > >   * struct tee_ioctl_param - parameter
> > > > > --
> > > > > 2.7.4
> > > > >
> > > >
> > > > Thanks,
> > > > Jens

Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups

[Chao Yu]

On 2019/7/29 14:27, Jaegeuk Kim wrote:
> On 07/28, Chao Yu wrote:
>> On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
>>>  /* Flags that are appropriate for regular files (all but dir-specific 
>>> ones). */
>>>  #define F2FS_REG_FLMASK(~(F2FS_DIRSYNC_FL | 
>>> F2FS_PROJINHERIT_FL))
>>
>> We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.
> 
> Applied.
> 
>>
>>> @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode *inode, 
>>> u32 iflags, u32 mask)
>>> return -EPERM;
>>>  
>>> oldflags = fi->i_flags;
>>> +   if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
>>> +   if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
>>> +   return -EOPNOTSUPP;
>>> +
>>> +   if (!S_ISDIR(inode->i_mode))
>>> +   return -ENOTDIR;
>>>  
>>> +   if (!f2fs_empty_dir(inode))
>>> +   return -ENOTEMPTY;
>>> +   }
> 
> Modified like this:
> @@ -1665,6 +1665,13 @@ static int f2fs_setflags_common(struct inode *inode, 
> u32 iflags, u32 mask)
> if (IS_NOQUOTA(inode))
> return -EPERM;
> 
> +   if ((iflags ^ fi->i_flags) & F2FS_CASEFOLD_FL) {
> +   if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
> +   return -EOPNOTSUPP;
> +   if (!f2fs_empty_dir(inode))
> +   return -ENOTEMPTY;
> +   }
> +
> 
> Note that, directory is checked by above change.
> 
> I've uploaded in f2fs.git, so could you check it out and test a bit?

I've checked it out, it looks good to me now, and later I will test this new
version.

Reviewed-by: Chao Yu 

Thanks,

> 
> Thanks,
> 
>>
>> I applied the patches based on last Jaegeuk's dev branch, it seems we needs 
>> to
>> adjust above code a bit. Otherwise it looks good to me.
>>
>> BTW, it looks the patchset works fine with generic/556 testcase.
>>
>> Thanks,
> .
> 

Re: [PATCH 00/43] Convert doc files to ReST

[Geert Uytterhoeven]

Hi Mauro,

On Fri, Jun 28, 2019 at 2:25 PM Mauro Carvalho Chehab
 wrote:
>
> This patchset contains the patches that weren't merged yet from
> part 2 and 3 of the previous ReST conversion patchset.
>
> This is based aganst linux-next (next-20190627), so they may not
> apply cleanly at docs-next.
>
> It does contain file renames, but, except for a few exceptions, the files
> are kept where they are.
>
> The first patches on this series were agreed to be merged via subsystem's
> tree, but, as they didn't appear at -next, I'm recending as a gentile
> ping.

[...]

>  .../arm/{SH-Mobile => sh-mobile}/.gitignore   |0

I guess that should have been "shmobile^H^H^H^H^H^H^H^Hrenesas",
for consistency with modern naming?
For whatever it's worth keeping empty subdirectories, of course,
containing just an obsolete .gitignore file...

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 0/2] Add CCPI2 PMU support

[Ganapatrao Kulkarni]

Hi Will,

Any comments to this patchset?

On Tue, Jul 23, 2019 at 2:46 PM Ganapatrao Kulkarni
 wrote:
>
> Add Cavium Coherent Processor Interconnect (CCPI2) PMU
> support in ThunderX2 Uncore driver.
>
> v3: Rebased to 5.3-rc1
>
> v2: Updated with review comments [1]
>
> [1] https://lkml.org/lkml/2019/6/14/965
>
> v1: initial patch
>
> Ganapatrao Kulkarni (2):
>   Documentation: perf: Update documentation for ThunderX2 PMU uncore
> driver
>   drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
>
>  .../admin-guide/perf/thunderx2-pmu.rst|  20 +-
>  drivers/perf/thunderx2_pmu.c  | 248 +++---
>  2 files changed, 225 insertions(+), 43 deletions(-)
>
> --
> 2.17.1
>

Thanks,
Ganapat

Re: [RFC 3/7] tee: add private login method for kernel clients

[Sumit Garg]

On Mon, 29 Jul 2019 at 12:39, Jens Wiklander  wrote:
>
> Hi Sumit,
>
> On Tue, Jul 9, 2019 at 11:36 AM Sumit Garg  wrote:
> >
> > On Tue, 9 Jul 2019 at 12:33, Jens Wiklander  
> > wrote:
> > >
> > > On Tue, Jul 09, 2019 at 11:26:19AM +0530, Sumit Garg wrote:
> > > > Thanks Jens for your comments.
> > > >
> > > > On Mon, 8 Jul 2019 at 21:09, Jens Wiklander  
> > > > wrote:
> > > > >
> > > > > Hi Sumit,
> > > > >
> > > > > On Thu, Jun 13, 2019 at 04:00:29PM +0530, Sumit Garg wrote:
> > > > > > There are use-cases where user-space shouldn't be allowed to 
> > > > > > communicate
> > > > > > directly with a TEE device which is dedicated to provide a specific
> > > > > > service for a kernel client. So add a private login method for 
> > > > > > kernel
> > > > > > clients and disallow user-space to open-session using this login 
> > > > > > method.
> > > > > >
> > > > > > Signed-off-by: Sumit Garg 
> > > > > > ---
> > > > > >  drivers/tee/tee_core.c   | 6 ++
> > > > > >  include/uapi/linux/tee.h | 2 ++
> > > > > >  2 files changed, 8 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > > > > index 0f16d9f..4581bd1 100644
> > > > > > --- a/drivers/tee/tee_core.c
> > > > > > +++ b/drivers/tee/tee_core.c
> > > > > > @@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct 
> > > > > > tee_context *ctx,
> > > > > >   goto out;
> > > > > >   }
> > > > > >
> > > > > > + if (arg.clnt_login == TEE_IOCTL_LOGIN_REE_KERNEL) {
> > > > > TEE_IOCTL_LOGIN_REE_KERNEL is defined as 0x8000 which is in the
> > > > > range specified and implementation defined by the GP spec. I wonder if
> > > > > we shouldn't filter the entire implementation defined range instead of
> > > > > just this value.
> > > >
> > > > Agree. Will rather check for entire implementation defined range:
> > > > 0x8000 - 0x.
> > > >
> >
> > I had a second thought on this. It would be more restrictive for
> > user-space TEE client library which may need to use implementation
> > defined login method. So either we could define specific ranges for
> > kernel and user-space or we can start with single login method
> > reserved for kernel.
>
> I think we should reserve a range for kernel internal use. Only
> reserving a single single login for kernel could force us to restrict
> the API once more later, better to take a chunk now and be done with
> it. Half of 0x8000 - 0x is probably more than enough too
> to leave a range for user space too.
>

Ok then, will rather reserve this range for kernel.

> >
> > > > >
> > > > > > + pr_err("login method not allowed for user-space 
> > > > > > client\n");
> > > > > pr_debug(), if it's needed at all.
> > > > >
> > > >
> > > > Ok will use pr_debug() instead.
> > > >
> > > > > > + rc = -EPERM;
> > > > > > + goto out;
> > > > > > + }
> > > > > > +
> > > > > >   rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
> > > > > >   if (rc)
> > > > > >   goto out;
> > > > > > diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
> > > > > > index 4b9eb06..f33c69c 100644
> > > > > > --- a/include/uapi/linux/tee.h
> > > > > > +++ b/include/uapi/linux/tee.h
> > > > > > @@ -172,6 +172,8 @@ struct tee_ioctl_buf_data {
> > > > > >  #define TEE_IOCTL_LOGIN_APPLICATION  4
> > > > > >  #define TEE_IOCTL_LOGIN_USER_APPLICATION 5
> > > > > >  #define TEE_IOCTL_LOGIN_GROUP_APPLICATION6
> > > > > > +/* Private login method for REE kernel clients */
> > > > > It's worth noting that this is filtered by the TEE framework, compared
> > > > > to everything else which is treated opaquely.
> > > > >
> > > >
> > > > IIUC, you are referring to login filter in optee_os. Change to prevent
> > > > filter for this login method is part of this PR [1].
> > > >
> > > > [1] https://github.com/OP-TEE/optee_os/pull/3082
> > >
> > > No, I was referring to the changes in tee_ioctl_open_session() above.
> > > It's relevant for user space to know since it will be prevented from
> > > using that range of login identifiers.
> >
> > Ok, so you mean to extend the comment here for user-space to know that
> > this login method/range is filtered by the TEE framework. Will do
> > that.
> >
> > > This will restrict the user space
> > > API, but I think the risk of breakage is minimal as OP-TEE is the only
> > > in-tree driver registering in the TEE framework. I'm not aware of any
> > > out-of-tree drivers registering.
> >
> > I am not sure if I follow you here. How do you expect this change to
> > break out-of-tree TEE driver registration?
>
> It's a change in common code that put restrictions on the API.
>

Okay.

-Sumit

> Thanks,
> Jens
>
>
> >
> > -Sumit
> >
> > >
> > > Thanks,
> > > Jens
> > >
> > > >
> > > > -Sumit
> > > >
> > > > > > +#define TEE_IOCTL_LOGIN_REE_KERNEL   0x8000
> > > > > >
> > > > > >  /**
> > > > > >   * struct tee_ioctl_param - param

Re: [PATCH] Documentation: move Documentation/virtual to Documentation/virt

[Jonathan Corbet]

On Sat, 27 Jul 2019 00:10:32 +0200
Paolo Bonzini  wrote:

> Does the userspace API
> cover only syscall or perhaps sysfs interfaces?   There are more API
> files (amd-memory-encryption.txt, cpuid.txt, halt-polling.txt msr.txt,
> ppc-pv.txt, s390-diag.txt) but, with the exception of
> amd-memory-encryption.txt and halt-polling.txt, they cover the
> emulated-hardware interfaces that KVM provides to virtual machines.

The user-space API certainly goes beyond system calls.  For sysfs, I
guess, the question would be whether a given knob is something that an
application would use (userspace-api) or something that a sysadmin would
want to tweak (admin-guide).

Thanks,

jon

[PATCH v2] Documentation: gpio: fix function links in the HTML docs

[Jeremy Cline]

The shorthand [_data] and [devm_] cause the HTML documentation to not
link to the function documentation properly. This expands the references
to the complete function names with the exception of
devm_gpiochip_remove() which was dropped by commit 48207d7595d2 ("gpio:
drop devm_gpiochip_remove()").

Signed-off-by: Jeremy Cline 
---
New in v2:
  - Rebased onto v5.3-rc2

 Documentation/driver-api/gpio/driver.rst | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/driver-api/gpio/driver.rst 
b/Documentation/driver-api/gpio/driver.rst
index 921c71a3d683..906af220b164 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -69,9 +69,9 @@ driver code:
 
 The code implementing a gpio_chip should support multiple instances of the
 controller, preferably using the driver model. That code will configure each
-gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
-Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
-when it is unavoidable.
+gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
+devm_gpiochip_add_data().  Removing a GPIO controller should be rare; use
+gpiochip_remove() when it is unavoidable.
 
 Often a gpio_chip is part of an instance-specific structure with states not
 exposed by the GPIO interfaces, such as addressing, power management, and more.
@@ -418,11 +418,11 @@ symbol:
 
 If there is a need to exclude certain GPIO lines from the IRQ domain handled by
 these helpers, we can set .irq.need_valid_mask of the gpiochip before
-``[devm_]gpiochip_add_data()`` is called. This allocates an .irq.valid_mask 
with as
-many bits set as there are GPIO lines in the chip, each bit representing line
-0..n-1. Drivers can exclude GPIO lines by clearing bits from this mask. The 
mask
-must be filled in before gpiochip_irqchip_add() or 
gpiochip_irqchip_add_nested()
-is called.
+devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
+.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
+bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
+from this mask. The mask must be filled in before gpiochip_irqchip_add() or
+gpiochip_irqchip_add_nested() is called.
 
 To use the helpers please keep the following in mind:
 
-- 
2.21.0

Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups

[Chao Yu]

On 2019-7-29 15:22, Chao Yu wrote:
> On 2019/7/29 14:27, Jaegeuk Kim wrote:
>> On 07/28, Chao Yu wrote:
>>> On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
  /* Flags that are appropriate for regular files (all but dir-specific 
 ones). */
  #define F2FS_REG_FLMASK   (~(F2FS_DIRSYNC_FL | 
 F2FS_PROJINHERIT_FL))
>>>
>>> We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.
>>
>> Applied.
>>
>>>
 @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode 
 *inode, u32 iflags, u32 mask)
return -EPERM;
  
oldflags = fi->i_flags;
 +  if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
 +  if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
 +  return -EOPNOTSUPP;
 +
 +  if (!S_ISDIR(inode->i_mode))
 +  return -ENOTDIR;
  
 +  if (!f2fs_empty_dir(inode))
 +  return -ENOTEMPTY;
 +  }
>>
>> Modified like this:
>> @@ -1665,6 +1665,13 @@ static int f2fs_setflags_common(struct inode *inode, 
>> u32 iflags, u32 mask)
>> if (IS_NOQUOTA(inode))
>> return -EPERM;
>>
>> +   if ((iflags ^ fi->i_flags) & F2FS_CASEFOLD_FL) {
>> +   if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
>> +   return -EOPNOTSUPP;
>> +   if (!f2fs_empty_dir(inode))
>> +   return -ENOTEMPTY;
>> +   }
>> +
>>
>> Note that, directory is checked by above change.
>>
>> I've uploaded in f2fs.git, so could you check it out and test a bit?
> 
> I've checked it out, it looks good to me now, and later I will test this new
> version.
> 
> Reviewed-by: Chao Yu 

It can pass generic/556 as well.

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>
>>> I applied the patches based on last Jaegeuk's dev branch, it seems we needs 
>>> to
>>> adjust above code a bit. Otherwise it looks good to me.
>>>
>>> BTW, it looks the patchset works fine with generic/556 testcase.
>>>
>>> Thanks,
>> .
>>

Re: [EXTERNAL][PATCH v15 04/13] mfd/syscon: Add device_node_to_regmap()

[Paul Burton]

Lee, Arnd,

On Wed, Jul 24, 2019 at 01:16:06PM -0400, Paul Cercueil wrote:
> device_node_to_regmap() is exactly like syscon_node_to_regmap(), but it
> does not check that the node is compatible with "syscon", and won't
> attach the first clock it finds to the regmap.
> 
> The rationale behind this, is that one device node with a standard
> compatible string "foo,bar" can be covered by multiple drivers sharing a
> regmap, or by a single driver doing all the job without a regmap, but
> these are implementation details which shouldn't reflect on the
> devicetree.

Does this looks like a good path forwards to you? Its use in this case
is described by Documentation/devicetree/bindings/timer/ingenic,tcu.txt
in patch 3 of the series.

If you're OK with it an ack would be appreciated so I can take the
series through mips-next, otherwise I guess we'd need to go back to the
v14 approach.

Thanks,
Paul

> Signed-off-by: Paul Cercueil 
> ---
> 
> Notes:
> v15: New patch
> 
>  drivers/mfd/syscon.c   | 46 +-
>  include/linux/mfd/syscon.h |  6 +
>  2 files changed, 36 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index b65e585fc8c6..660723276481 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -40,7 +40,7 @@ static const struct regmap_config syscon_regmap_config = {
>   .reg_stride = 4,
>  };
>  
> -static struct syscon *of_syscon_register(struct device_node *np)
> +static struct syscon *of_syscon_register(struct device_node *np, bool 
> check_clk)
>  {
>   struct clk *clk;
>   struct syscon *syscon;
> @@ -51,9 +51,6 @@ static struct syscon *of_syscon_register(struct device_node 
> *np)
>   struct regmap_config syscon_config = syscon_regmap_config;
>   struct resource res;
>  
> - if (!of_device_is_compatible(np, "syscon"))
> - return ERR_PTR(-EINVAL);
> -
>   syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
>   if (!syscon)
>   return ERR_PTR(-ENOMEM);
> @@ -117,16 +114,18 @@ static struct syscon *of_syscon_register(struct 
> device_node *np)
>   goto err_regmap;
>   }
>  
> - clk = of_clk_get(np, 0);
> - if (IS_ERR(clk)) {
> - ret = PTR_ERR(clk);
> - /* clock is optional */
> - if (ret != -ENOENT)
> - goto err_clk;
> - } else {
> - ret = regmap_mmio_attach_clk(regmap, clk);
> - if (ret)
> - goto err_attach;
> + if (check_clk) {
> + clk = of_clk_get(np, 0);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + /* clock is optional */
> + if (ret != -ENOENT)
> + goto err_clk;
> + } else {
> + ret = regmap_mmio_attach_clk(regmap, clk);
> + if (ret)
> + goto err_attach;
> + }
>   }
>  
>   syscon->regmap = regmap;
> @@ -150,7 +149,8 @@ static struct syscon *of_syscon_register(struct 
> device_node *np)
>   return ERR_PTR(ret);
>  }
>  
> -struct regmap *syscon_node_to_regmap(struct device_node *np)
> +static struct regmap *device_node_get_regmap(struct device_node *np,
> +  bool check_clk)
>  {
>   struct syscon *entry, *syscon = NULL;
>  
> @@ -165,13 +165,27 @@ struct regmap *syscon_node_to_regmap(struct device_node 
> *np)
>   spin_unlock(&syscon_list_slock);
>  
>   if (!syscon)
> - syscon = of_syscon_register(np);
> + syscon = of_syscon_register(np, check_clk);
>  
>   if (IS_ERR(syscon))
>   return ERR_CAST(syscon);
>  
>   return syscon->regmap;
>  }
> +
> +struct regmap *device_node_to_regmap(struct device_node *np)
> +{
> + return device_node_get_regmap(np, false);
> +}
> +EXPORT_SYMBOL_GPL(device_node_to_regmap);
> +
> +struct regmap *syscon_node_to_regmap(struct device_node *np)
> +{
> + if (!of_device_is_compatible(np, "syscon"))
> + return ERR_PTR(-EINVAL);
> +
> + return device_node_get_regmap(np, true);
> +}
>  EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
>  
>  struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
> index 8cfda0554381..112dc66262cc 100644
> --- a/include/linux/mfd/syscon.h
> +++ b/include/linux/mfd/syscon.h
> @@ -17,12 +17,18 @@
>  struct device_node;
>  
>  #ifdef CONFIG_MFD_SYSCON
> +extern struct regmap *device_node_to_regmap(struct device_node *np);
>  extern struct regmap *syscon_node_to_regmap(struct device_node *np);
>  extern struct regmap *syscon_regmap_lookup_by_compatible(const char *s);
>  extern struct regmap *syscon_regmap_lookup_by_phandle(
>   struct device_node *np,
>   const char *property);
>  #

[PATCH 1/1] psi: do not require setsched permission from the trigger creator

[Suren Baghdasaryan]

When a process creates a new trigger by writing into /proc/pressure/*
files, permissions to write such a file should be used to determine whether
the process is allowed to do so or not. Current implementation would also
require such a process to have setsched capability. Setting of psi trigger
thread's scheduling policy is an implementation detail and should not be
exposed to the user level. Remove the permission check by using _nocheck
version of the function.

Suggested-by: Nick Kralevich 
Signed-off-by: Suren Baghdasaryan 
---
 kernel/sched/psi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632c3b82..ed9a1d573cb1 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group 
*group,
mutex_unlock(&group->trigger_lock);
return ERR_CAST(kworker);
}
-   sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
+   sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
kthread_init_delayed_work(&group->poll_work,
psi_poll_work);
rcu_assign_pointer(group->poll_kworker, kworker);
-- 
2.22.0.709.g102302147b-goog

Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator

[Greg KH]

On Mon, Jul 29, 2019 at 12:42:05PM -0700, Suren Baghdasaryan wrote:
> When a process creates a new trigger by writing into /proc/pressure/*
> files, permissions to write such a file should be used to determine whether
> the process is allowed to do so or not. Current implementation would also
> require such a process to have setsched capability. Setting of psi trigger
> thread's scheduling policy is an implementation detail and should not be
> exposed to the user level. Remove the permission check by using _nocheck
> version of the function.
> 
> Suggested-by: Nick Kralevich 
> Signed-off-by: Suren Baghdasaryan 
> ---
>  kernel/sched/psi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

$ ./scripts/get_maintainer.pl --file kernel/sched/psi.c
Ingo Molnar  (maintainer:SCHEDULER)
Peter Zijlstra  (maintainer:SCHEDULER)
linux-ker...@vger.kernel.org (open list:SCHEDULER)


No where am I listed there, so why did you send this "To:" me?

please fix up and resend.

greg k-h

Re: [PATCH 1/1] psi: do not require setsched permission from the trigger creator

[Suren Baghdasaryan]

On Mon, Jul 29, 2019 at 12:57 PM Greg KH  wrote:
>
> On Mon, Jul 29, 2019 at 12:42:05PM -0700, Suren Baghdasaryan wrote:
> > When a process creates a new trigger by writing into /proc/pressure/*
> > files, permissions to write such a file should be used to determine whether
> > the process is allowed to do so or not. Current implementation would also
> > require such a process to have setsched capability. Setting of psi trigger
> > thread's scheduling policy is an implementation detail and should not be
> > exposed to the user level. Remove the permission check by using _nocheck
> > version of the function.
> >
> > Suggested-by: Nick Kralevich 
> > Signed-off-by: Suren Baghdasaryan 
> > ---
> >  kernel/sched/psi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> $ ./scripts/get_maintainer.pl --file kernel/sched/psi.c
> Ingo Molnar  (maintainer:SCHEDULER)
> Peter Zijlstra  (maintainer:SCHEDULER)
> linux-ker...@vger.kernel.org (open list:SCHEDULER)
>
>
> No where am I listed there, so why did you send this "To:" me?
>

Oh, sorry about that. Both Ingo and Peter are CC'ed directly. Should I
still resend?

> please fix up and resend.
>
> greg k-h

[PATCH] doc:it_IT: align translation to mainline

[Federico Vaga]

The patch translates the following patches in Italian:

1fb12b35e5ff kbuild: Raise the minimum required binutils version to 2.21
9c3c0c204814 isdn: remove isdn4linux

Signed-off-by: Federico Vaga 
---
 .../translations/it_IT/process/changes.rst| 22 ---
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/Documentation/translations/it_IT/process/changes.rst 
b/Documentation/translations/it_IT/process/changes.rst
index d0874327f301..94a6499742ac 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -26,16 +26,15 @@ Prima di pensare d'avere trovato un baco, aggiornate i 
seguenti programmi
 usando, il comando indicato dovrebbe dirvelo.
 
 Questa lista presume che abbiate già un kernel Linux funzionante.  In aggiunta,
-non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete un
-modem ISDN, per esempio, probabilmente non dovreste preoccuparvi di
-isdn4k-utils.
+non tutti gli strumenti sono necessari ovunque; ovviamente, se non avete una
+PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
 
 == =  

 Programma   Versione minima   Comando per verificare la 
versione
 == =  

 GNU C  4.6gcc --version
 GNU make   3.81   make --version
-binutils   2.20   ld -v
+binutils   2.21   ld -v
 flex   2.5.35 flex --version
 bison  2.0bison --version
 util-linux 2.10o  fdformat --version
@@ -49,7 +48,6 @@ btrfs-progs0.18   btrfsck
 pcmciautils004pccardctl -V
 quota-tools3.09   quota -V
 PPP2.4.0  pppd --version
-isdn4k-utils   3.1pre1isdnctrl 2>&1|grep version
 nfs-utils  1.0.5  showmount --version
 procps 3.2.0  ps --version
 oprofile   0.9oprofiled --version
@@ -81,10 +79,7 @@ Per compilare il kernel vi servirà GNU make 3.81 o 
successivo.
 Binutils
 
 
-Il sistema di compilazione, dalla versione 4.13,  per la produzione dei passi
-intermedi, si è convertito all'uso di *thin archive* (`ar T`) piuttosto che
-all'uso del *linking* incrementale (`ld -r`). Questo richiede binutils 2.20 o
-successivo.
+Per generare il kernel è necessario avere Binutils 2.21 o superiore.
 
 pkg-config
 --
@@ -286,11 +281,6 @@ col seguente comando::
 
   mknod /dev/ppp c 108 0
 
-Isdn4k-utils
-
-
-Per via della modifica del campo per il numero di telefono, il pacchetto
-isdn4k-utils dev'essere ricompilato o (preferibilmente) aggiornato.
 
 NFS-utils
 -
@@ -456,10 +446,6 @@ PPP
 
 - 
 
-Isdn4k-utils
-
-
-- 
 
 NFS-utils
 -
-- 
2.21.0

[PATCH v8 3/7] of/platform: Add functional dependency link from DT bindings

[Saravana Kannan]

Add device-links after the devices are created (but before they are
probed) by looking at common DT bindings like clocks and
interconnects.

Automatically adding device-links for functional dependencies at the
framework level provides the following benefits:

- Optimizes device probe order and avoids the useless work of
  attempting probes of devices that will not probe successfully
  (because their suppliers aren't present or haven't probed yet).

  For example, in a commonly available mobile SoC, registering just
  one consumer device's driver at an initcall level earlier than the
  supplier device's driver causes 11 failed probe attempts before the
  consumer device probes successfully. This was with a kernel with all
  the drivers statically compiled in. This problem gets a lot worse if
  all the drivers are loaded as modules without direct symbol
  dependencies.

- Supplier devices like clock providers, interconnect providers, etc
  need to keep the resources they provide active and at a particular
  state(s) during boot up even if their current set of consumers don't
  request the resource to be active. This is because the rest of the
  consumers might not have probed yet and turning off the resource
  before all the consumers have probed could lead to a hang or
  undesired user experience.

  Some frameworks (Eg: regulator) handle this today by turning off
  "unused" resources at late_initcall_sync and hoping all the devices
  have probed by then. This is not a valid assumption for systems with
  loadable modules. Other frameworks (Eg: clock) just don't handle
  this due to the lack of a clear signal for when they can turn off
  resources. This leads to downstream hacks to handle cases like this
  that can easily be solved in the upstream kernel.

  By linking devices before they are probed, we give suppliers a clear
  count of the number of dependent consumers. Once all of the
  consumers are active, the suppliers can turn off the unused
  resources without making assumptions about the number of consumers.

By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they probe.

Signed-off-by: Saravana Kannan 
---
 .../admin-guide/kernel-parameters.txt |   5 +
 drivers/of/platform.c | 165 ++
 2 files changed, 170 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7ccd158b3894..dba3200d3516 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3170,6 +3170,11 @@
This can be set from sysctl after boot.
See Documentation/admin-guide/sysctl/vm.rst for details.
 
+   of_devlink  [KNL] Make device links from common DT bindings. Useful
+   for optimizing probe order and making sure resources
+   aren't turned off before the consumer devices have
+   probed.
+
ohci1394_dma=early  [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
info.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7801e25e6895..4344419a26fc 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -508,6 +508,170 @@ int of_platform_default_populate(struct device_node *root,
 }
 EXPORT_SYMBOL_GPL(of_platform_default_populate);
 
+bool of_link_is_valid(struct device_node *con, struct device_node *sup)
+{
+   of_node_get(sup);
+   /*
+* Don't allow linking a device node as a consumer of one of its
+* descendant nodes. By definition, a child node can't be a functional
+* dependency for the parent node.
+*/
+   while (sup) {
+   if (sup == con) {
+   of_node_put(sup);
+   return false;
+   }
+   sup = of_get_next_parent(sup);
+   }
+   return true;
+}
+
+static int of_link_to_phandle(struct device *dev, struct device_node *sup_np)
+{
+   struct platform_device *sup_dev;
+   u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+   int ret = 0;
+
+   /*
+* Since we are trying to create device links, we need to find
+* the actual device node that owns this supplier phandle.
+* Often times it's the same node, but sometimes it can be one
+* of the parents. So walk up the parent till you find a
+* device.
+*/
+   while (sup_np && !of_find_property(sup_np, "compatible", NULL))
+   sup_np = of_get_next_parent(sup_np);
+   if (!sup_np)
+   return 0;
+
+   if (!of_link_is_valid(dev->of_node, sup_np)) {
+   of_node_p

[PATCH 1/1] psi: do not require setsched permission from the trigger creator

[Suren Baghdasaryan]

When a process creates a new trigger by writing into /proc/pressure/*
files, permissions to write such a file should be used to determine whether
the process is allowed to do so or not. Current implementation would also
require such a process to have setsched capability. Setting of psi trigger
thread's scheduling policy is an implementation detail and should not be
exposed to the user level. Remove the permission check by using _nocheck
version of the function.

Suggested-by: Nick Kralevich 
Signed-off-by: Suren Baghdasaryan 
---
 kernel/sched/psi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7acc632c3b82..ed9a1d573cb1 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -1061,7 +1061,7 @@ struct psi_trigger *psi_trigger_create(struct psi_group 
*group,
mutex_unlock(&group->trigger_lock);
return ERR_CAST(kworker);
}
-   sched_setscheduler(kworker->task, SCHED_FIFO, ¶m);
+   sched_setscheduler_nocheck(kworker->task, SCHED_FIFO, ¶m);
kthread_init_delayed_work(&group->poll_work,
psi_poll_work);
rcu_assign_pointer(group->poll_kworker, kworker);
-- 
2.22.0.709.g102302147b-goog