date:20201004

On 04-10-20, 21:55, Dave Jiang wrote:
> > > +static bool process_fault(struct idxd_desc *desc, u64 fault_addr)
> > > +{
> > > + if ((u64)desc->hw == fault_addr ||
> > > + (u64)desc->completion == fault_addr) {
> > 
> > you are casting descriptor address and completion, I can understand
> > former, but later..? Can you explain this please
> > 
> 
> It is possible to fail on the completion writeback address if the completion
> address programmed into the descriptor is bad.

Okay thanks for clarifying, maybe would help to add a comment.

-- 
~Vinod

Re: [PATCH 0/2] phy: phy-brcm-sata: Allow configuration SATA AFE TX amplitude

Hi Florian,

On 04-10-20, 19:56, Florian Fainelli wrote:
> 
> 
> On 9/30/2020 8:19 PM, Florian Fainelli wrote:
> > Hi Kishon,
> > 
> > This patch series allows the configuration of the Broadcom SATA PHY TX
> > amplitude which may be required in order to meet specific tests.
> 
> Hi Vinod,
> 
> Would you need me to resend these two patches? For some reason
> get_maintainers.pl did not pick up your email. If not, here are the two
> patches from lore:

Yes I dont have these in my inbox. Unfortunately it is late in the cycle
and I have already sent PR to greg for 5.10 so I am not accepting
patches till rc1. Please rebase on rc1 and resend...

> https://lore.kernel.org/linux-devicetree/20201001031916.411999-2-f.faine...@gmail.com/
> https://lore.kernel.org/linux-devicetree/20201001031916.411999-3-f.faine...@gmail.com/
> 
> Thanks
> -- 
> Florian

-- 
~Vinod

[PATCH] iio: adc: exynos: do not rely on 'users' counter in ISR

2020-10-04 Thread dmitry . torokhov

The order in which 'users' counter is decremented vs calling drivers'
close() method is implementation specific, and we should not rely on
it. Let's introduce driver private flag and use it to signal ISR
to exit when device is being closed.

This has a side-effect of fixing issue of accessing inut->users
outside of input->mutex protection.

Reported-by: Andrzej Pietrasiewicz 
Signed-off-by: Dmitry Torokhov 
---
 drivers/iio/adc/exynos_adc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 22131a677445..7eb2a5df6e98 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -135,6 +135,8 @@ struct exynos_adc {
u32 value;
unsigned intversion;
 
+   boolts_enabled;
+
boolread_ts;
u32 ts_x;
u32 ts_y;
@@ -633,7 +635,7 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
bool pressed;
int ret;
 
-   while (info->input->users) {
+   while (info->ts_enabled) {
ret = exynos_read_s3c64xx_ts(dev, , );
if (ret == -ETIMEDOUT)
break;
@@ -712,6 +714,8 @@ static int exynos_adc_ts_open(struct input_dev *dev)
 {
struct exynos_adc *info = input_get_drvdata(dev);
 
+   info->ts_enabled = true;
+   mb();
enable_irq(info->tsirq);
 
return 0;
@@ -721,6 +725,8 @@ static void exynos_adc_ts_close(struct input_dev *dev)
 {
struct exynos_adc *info = input_get_drvdata(dev);
 
+   info->ts_enabled = false;
+   mb();
disable_irq(info->tsirq);
 }
 
-- 
2.28.0.806.g8561365e88-goog


-- 
Dmitry

Re: [PATCH v4 2/2] hwmon: pmbus: max20730: adjust the vout reading given voltage divider

2020-10-04 Thread Guenter Roeck

On 10/4/20 8:07 PM, Chu Lin wrote:
> On Sun, Oct 4, 2020 at 8:43 AM Guenter Roeck  wrote:
>>
>> On Sun, Oct 04, 2020 at 03:14:45AM +, Chu Lin wrote:
>>> Problem:
>>> We use voltage dividers so that the voltage presented at the voltage
>>> sense pins is confusing. We might need to convert these readings to more
>>> meaningful readings given the voltage divider.
>>>
>>> Solution:
>>> Read the voltage divider resistance from dts and convert the voltage
>>> reading to a more meaningful reading.
>>>
>>> Testing:
>>> max20730 with voltage divider
>>>
>>> Signed-off-by: Chu Lin 
>>> ---
>>> ChangeLog v1 -> v2
>>>   hwmon: pmbus: max20730:
>>>   - Don't do anything to the ret if an error is returned from 
>>> pmbus_read_word
>>>   - avoid overflow when doing multiplication
>>>
>>> ChangeLog v2 -> v3
>>>   dt-bindings: hwmon: max20730:
>>>   - Provide the binding documentation in yaml format
>>>   hwmon: pmbus: max20730:
>>>   - No change
>>>
>>> ChangeLog v3 -> v4
>>>   dt-bindings: hwmon: max20730:
>>>   - Fix highefficiency to high efficiency in description
>>>   - Fix presents to present in vout-voltage-divider
>>>   - Add additionalProperties: false
>>>   hwmon: pmbus: max20730:
>>>   - No change
>>
>> You claim that there have been no changes since v2 of this patch,
>> yet you dropped my Reviewed-by: tag. Any reason ?
>>
>> Guenter
> Sorry for the confusion. I thought I can't tag the patch with the Review-by 
> tag.
> Just to make sure I do correctly next time, once you tagged a certain
> patch in the batch
> If there is no change from version to version for this patch, I should
> carry the tags when
> submitting new revisions. Also, please let me know what is the best
> way to fix this revision?
> Should I submit a new V5 with the tag attached?
> 

Actually, if you did not make changes to a patch, you are _expected_
to carry tags forward. In many cases, submitters will even send a new
version of a patch with all new tags included (and no other changes).
This helps reviewers to keep track on what has been reviewed, acked,
or tested in a series. Dropping a tag means that you changed
a patch so substantially that the tag no longer applies (for example,
fixing a spelling error or some formatting does not normally warrant
dropping a tag). If you do drop a tag, you should explain the reason
in the change log.

That is, of course, a honor system that must not be abused
(unfortunately I have seen that abuse happen a couple of times
recently, but that is another story).

No need to re-send in this case - I'll just send another tag
to remind myself that I reviewed this patch.

Guenter

> Sincerely,
> Chu
> 
>>
>>>
>>>  drivers/hwmon/pmbus/max20730.c | 18 ++
>>>  1 file changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
>>> index a151a2b588a5..fbf2f1e6c969 100644
>>> --- a/drivers/hwmon/pmbus/max20730.c
>>> +++ b/drivers/hwmon/pmbus/max20730.c
>>> @@ -31,6 +31,7 @@ struct max20730_data {
>>>   struct pmbus_driver_info info;
>>>   struct mutex lock;  /* Used to protect against parallel writes */
>>>   u16 mfr_devset1;
>>> + u32 vout_voltage_divider[2];
>>>  };
>>>
>>>  #define to_max20730_data(x)  container_of(x, struct max20730_data, info)
>>> @@ -114,6 +115,14 @@ static int max20730_read_word_data(struct i2c_client 
>>> *client, int page,
>>>   max_c = max_current[data->id][(data->mfr_devset1 >> 5) & 0x3];
>>>   ret = val_to_direct(max_c, PSC_CURRENT_OUT, info);
>>>   break;
>>> + case PMBUS_READ_VOUT:
>>> + ret = pmbus_read_word_data(client, page, phase, reg);
>>> + if (ret > 0 && data->vout_voltage_divider[0] && 
>>> data->vout_voltage_divider[1]) {
>>> + u64 temp = DIV_ROUND_CLOSEST_ULL((u64)ret * 
>>> data->vout_voltage_divider[1],
>>> +  
>>> data->vout_voltage_divider[0]);
>>> + ret = clamp_val(temp, 0, 0x);
>>> + }
>>> + break;
>>>   default:
>>>   ret = -ENODATA;
>>>   break;
>>> @@ -364,6 +373,15 @@ static int max20730_probe(struct i2c_client *client,
>>>   data->id = chip_id;
>>>   mutex_init(>lock);
>>>   memcpy(>info, _info[chip_id], sizeof(data->info));
>>> + if (of_property_read_u32_array(client->dev.of_node, 
>>> "vout-voltage-divider",
>>> +data->vout_voltage_divider,
>>> +
>>> ARRAY_SIZE(data->vout_voltage_divider)) != 0)
>>> + memset(data->vout_voltage_divider, 0, 
>>> sizeof(data->vout_voltage_divider));
>>> + if (data->vout_voltage_divider[1] < data->vout_voltage_divider[0]) {
>>> + dev_err(dev,
>>> + "The total resistance of voltage divider is less than 
>>> output resistance\n");
>>> + return -ENODEV;
>>> + }
>>>
>>>   ret =

RE: [PATCH 01/10] fpga: fpga-mgr: Add devm_fpga_mgr_register() API

2020-10-04 Thread Wu, Hao

> Subject: [PATCH 01/10] fpga: fpga-mgr: Add devm_fpga_mgr_register() API
> 
> Add a devm_fpga_mgr_register() API that can be used to register a FPGA
> Manager that was created using devm_fpga_mgr_create().
> 
> Introduce a struct fpga_mgr_devres that makes the devres
> allocation a little bit more readable and gets reused for
> devm_fpga_mgr_create() devm_fpga_mgr_register().
> 
> Signed-off-by: Moritz Fischer 
> ---
>  drivers/fpga/fpga-mgr.c   | 76 ++-
>  include/linux/fpga/fpga-mgr.h |  2 +
>  2 files changed, 68 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index f38bab01432e..774ac98fb69c 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -21,6 +21,10 @@
>  static DEFINE_IDA(fpga_mgr_ida);
>  static struct class *fpga_mgr_class;
> 
> +struct fpga_mgr_devres {
> + struct fpga_manager *mgr;
> +};
> +
>  /**
>   * fpga_image_info_alloc - Allocate a FPGA image info struct
>   * @dev: owning device
> @@ -651,21 +655,21 @@ struct fpga_manager
> *devm_fpga_mgr_create(struct device *dev, const char *name,
> const struct fpga_manager_ops
> *mops,
> void *priv)
>  {
> - struct fpga_manager **ptr, *mgr;
> + struct fpga_mgr_devres *dr;
> 
> - ptr = devres_alloc(devm_fpga_mgr_release, sizeof(*ptr),
> GFP_KERNEL);
> - if (!ptr)
> + dr = devres_alloc(devm_fpga_mgr_release, sizeof(*dr), GFP_KERNEL);

Should we update devm_fpga_mgr_release function to use fpga_mgr_devres as well?

> + if (!dr)
>   return NULL;
> 
> - mgr = fpga_mgr_create(dev, name, mops, priv);
> - if (!mgr) {
> - devres_free(ptr);
> - } else {
> - *ptr = mgr;
> - devres_add(dev, ptr);
> + dr->mgr = fpga_mgr_create(dev, name, mops, priv);
> + if (!dr->mgr) {
> + devres_free(dr);
> + return NULL;
>   }
> 
> - return mgr;
> + devres_add(dev, dr);
> +
> + return dr->mgr;
>  }
>  EXPORT_SYMBOL_GPL(devm_fpga_mgr_create);
> 
> @@ -722,6 +726,58 @@ void fpga_mgr_unregister(struct fpga_manager
> *mgr)
>  }
>  EXPORT_SYMBOL_GPL(fpga_mgr_unregister);
> 
> +static int fpga_mgr_devres_match(struct device *dev, void *priv,

Maybe it's better to use "res" instead of "priv" which matches the
dr_match_t, and also devm_fpga_mgr_release function. 

> +  void *match_data)
> +{
> + struct fpga_mgr_devres *dr = priv;
> +
> + return match_data == dr->mgr;
> +}
> +
> +static void devm_fpga_mgr_unregister(struct device *dev, void *priv)
> +{

Same.

> + struct fpga_mgr_devres *dr = priv;
> +
> + fpga_mgr_unregister(dr->mgr);
> +}
> +
> +/**
> + * devm_fpga_mgr_register - resource managed variant of
> fpga_mgr_register()
> + * @dev: managing device for this FPGA manager
> + * @mgr: fpga manager struct
> + *
> + * This is the devres variant of fpga_mgr_register() for which the unregister
> + * function will be called automatically when the managing device is
> detached.
> + */
> +int devm_fpga_mgr_register(struct device *dev, struct fpga_manager *mgr)
> +{
> + struct fpga_mgr_devres *dr;
> + int err;
> +
> + /* Make sure that the struct fpga_manager * that is passed in is
> +  * managed itself.
> +  */

Should we use the same style for code comments here, 
I see other places in this file are using style like

/*
  * ..
  */

Thanks
Hao

[PATCH] ACPI / button: fix handling lid state changes when input device closed

2020-10-04 Thread dmitry . torokhov

The original intent of 84d3f6b76447 was to delay evaluating lid state until
all drivers have been loaded, with input device being opened from userspace
serving as a signal for this condition. Let's ensure that state updates
happen even if userspace closed (or in the future inhibited) input device.

Note that if we go through suspend/resume cycle we assume the system has
been fully initialized even if LID input device has not been opened yet.

This has a side-effect of fixing access to input->users outside of
input->mutex protections by the way of eliminating said accesses and using
driver private flag.

Fixes: 84d3f6b76447 ("ACPI / button: Delay acpi_lid_initialize_state() until 
first user space open")
Signed-off-by: Dmitry Torokhov 
---
 drivers/acpi/button.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 78cfc70cb320..b8dd51d8f96d 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -154,6 +154,7 @@ struct acpi_button {
int last_state;
ktime_t last_time;
bool suspended;
+   bool lid_state_initialized;
 };
 
 static struct acpi_device *lid_device;
@@ -384,6 +385,8 @@ static int acpi_lid_update_state(struct acpi_device *device,
 
 static void acpi_lid_initialize_state(struct acpi_device *device)
 {
+   struct acpi_button *button = acpi_driver_data(device);
+
switch (lid_init_state) {
case ACPI_BUTTON_LID_INIT_OPEN:
(void)acpi_lid_notify_state(device, 1);
@@ -395,13 +398,14 @@ static void acpi_lid_initialize_state(struct acpi_device 
*device)
default:
break;
}
+
+   button->lid_state_initialized = true;
 }
 
 static void acpi_button_notify(struct acpi_device *device, u32 event)
 {
struct acpi_button *button = acpi_driver_data(device);
struct input_dev *input;
-   int users;
 
switch (event) {
case ACPI_FIXED_HARDWARE_EVENT:
@@ -410,10 +414,7 @@ static void acpi_button_notify(struct acpi_device *device, 
u32 event)
case ACPI_BUTTON_NOTIFY_STATUS:
input = button->input;
if (button->type == ACPI_BUTTON_TYPE_LID) {
-   mutex_lock(>input->mutex);
-   users = button->input->users;
-   mutex_unlock(>input->mutex);
-   if (users)
+   if (button->lid_state_initialized)
acpi_lid_update_state(device, true);
} else {
int keycode;
@@ -458,7 +459,7 @@ static int acpi_button_resume(struct device *dev)
struct acpi_button *button = acpi_driver_data(device);
 
button->suspended = false;
-   if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) {
+   if (button->type == ACPI_BUTTON_TYPE_LID) {
button->last_state = !!acpi_lid_evaluate_state(device);
button->last_time = ktime_get();
acpi_lid_initialize_state(device);
-- 
2.28.0.806.g8561365e88-goog


-- 
Dmitry

Re: [PATCH v4 3/7] ACPI: button: Access input device's users under appropriate mutex

On Thu, Jun 25, 2020 at 12:55:29PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jun 25, 2020 at 7:23 AM Dmitry Torokhov
>  wrote:
> >
> > On Wed, Jun 24, 2020 at 05:00:09PM +0200, Rafael J. Wysocki wrote:
> > > On Mon, Jun 8, 2020 at 1:22 PM Andrzej Pietrasiewicz
> > >  wrote:
> > > >
> > > > Inspecting input device's 'users' member should be done under device's
> > > > mutex, so add appropriate invocations.
> > > >
> > > > Signed-off-by: Andrzej Pietrasiewicz 
> > >
> > > This looks like a fix that might be applied independently of the other
> > > patches in the series.
> > >
> > > Do you want me to pick it up?
> >
> > If you pick it we'll have to have a dance with this series. Can I apply
> > instead?
> 
> Yes, please.
> 
> Also feel free to add
> 
> Acked-by: Rafael J. Wysocki 
> 
> to it.

Looking at the driver I think the patch and the original use of
input->users is not proper. I'll post another patch addressing this
shortly.

Thanks.

-- 
Dmitry

[GIT] Networking

2020-10-04 Thread David Miller



1) Make sure SKB control block is in the proper state during IPSEC
   ESP-in-TCP encapsulation.  From Sabrina Dubroca.

2) Various kinds of attributes were not being cloned properly when
   we build new xfrm_state objects from existing ones.  Fix from
   Antony Antony.

3) Make sure to keep BTF sections, from Tony Ambardar.

4) TX DMA channels need proper locking in lantiq driver, from Hauke
   Mehrtens.

5) Honour route MTU during forwarding, always.  From Maciej
   Żenczykowski.

6) Fix races in kTLS which can result in crashes, from Rohit
   Maheshwari.

7) Skip TCP DSACKs with rediculous sequence ranges, from Priyaranjan
   Jha.

8) Use correct address family in xfrm state lookups, from Herbert Xu.

9) A bridge FDB flush should not clear out user managed fdb entries
   with the ext_learn flag set, from Nikolay Aleksandrov.

10) Fix nested locking of netdev address lists, from Taehee Yoo.

11) Fix handling of 32-bit DATA_FIN values in mptcp, from Mat Martineau.

12) Fix r8169 data corruptions on RTL8402 chips, from Heiner Kallweit.

13) Don't free command entries in mlx5 while comp handler could still
be running, from Eran Ben Elisha.

14) Error flow of request_irq() in mlx5 is busted, due to an off by one
we try to free and IRQ never allocated.  From Maor Gottlieb.

15) Fix leak when dumping netlink policies, from Johannes Berg.

16) Sendpage cannot be performed when a page is a slab page, or the
page count is < 1.  Some subsystems such as nvme were doing so.
Create a "sendpage_ok()" helper and use it as needed, from
Coly Li.

17) Don't leak request socket when using syncookes with mptcp, from
Paolo Abeni.

Please pull, thanks a lot!!

The following changes since commit 805c6d3c19210c90c109107d189744e960eae025:

  Merge branch 'fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2020-09-22 15:08:41 
-0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git 

for you to fetch changes up to 4296adc3e32f5d544a95061160fe7e127be1b9ff:

  net/core: check length before updating Ethertype in skb_mpls_{push,pop} 
(2020-10-04 15:09:26 -0700)


Anant Thazhemadam (1):
  net: team: fix memory leak in __team_options_register

Andrii Nakryiko (1):
  libbpf: Fix XDP program load regression for old kernels

Anirudh Venkataramanan (1):
  ice: Fix call trace on suspend

Antony Antony (4):
  xfrm: clone XFRMA_SET_MARK in xfrm_do_migrate
  xfrm: clone XFRMA_REPLAY_ESN_VAL in xfrm_do_migrate
  xfrm: clone XFRMA_SEC_CTX in xfrm_do_migrate
  xfrm: clone whole liftime_cur structure in xfrm_do_migrate

Aya Levin (6):
  net/mlx5e: Fix error path for RQ alloc
  net/mlx5e: Add resiliency in Striding RQ mode for packets larger than MTU
  net/mlx5e: Fix driver's declaration to support GRE offload
  net/mlx5e: Fix return status when setting unsupported FEC mode
  net/mlx5e: Fix VLAN cleanup flow
  net/mlx5e: Fix VLAN create flow

Christophe JAILLET (1):
  net: typhoon: Fix a typo Typoon --> Typhoon

Coly Li (7):
  net: introduce helper sendpage_ok() in include/linux/net.h
  net: add WARN_ONCE in kernel_sendpage() for improper zero-copy send
  nvme-tcp: check page by sendpage_ok() before calling kernel_sendpage()
  tcp: use sendpage_ok() to detect misused .sendpage
  drbd: code cleanup by using sendpage_ok() to check page for 
kernel_sendpage()
  scsi: libiscsi: use sendpage_ok() in iscsi_tcp_segment_map()
  libceph: use sendpage_ok() in ceph_tcp_sendpage()

Cong Wang (4):
  net_sched: defer tcf_idr_insert() in tcf_action_init_1()
  net_sched: commit action insertions together
  net_sched: remove a redundant goto chain check
  net_sched: check error pointer in tcf_dump_walker()

David S. Miller (14):
  Merge branch 'net_sched-fix-a-UAF-in-tcf_action_init'
  Merge tag 'wireless-drivers-2020-09-25' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch '100GbE' of git://git.kernel.org/.../jkirsher/net-queue
  Merge branch 'bonding-team-basic-dev-needed_headroom-support'
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge branch 'net-core-fix-a-lockdep-splat-in-the-dev_addr_list'
  Merge branch 'More-incorrect-VCAP-offsets-for-mscc_ocelot-switch'
  Merge branch 'via-rhine-Resume-fix-and-other-maintenance-work'
  Merge branch 'mptcp-Fix-for-32-bit-DATA_FIN'
  Merge git://git.kernel.org/.../bpf/bpf
  Merge branch '100GbE' of https://github.com/anguy11/net-queue
  Merge branch 'Fix-bugs-in-Octeontx2-netdev-driver'
  Merge branch 
'Introduce-sendpage_ok-to-detect-misused-sendpage-in-network-related-drivers'
  Merge tag 'mlx5-fixes-2020-09-30' of git://git.kernel.org/.../saeed/linux

Eran Ben Elisha (4):
  net/mlx5: Fix a race when moving command interface to polling mode
  net/mlx5: Avoid

Re: [PATCH v4 4/7] ACPI: button: Use input_device_enabled() helper

On Wed, Jun 24, 2020 at 10:24:46PM -0700, Dmitry Torokhov wrote:
> On Mon, Jun 08, 2020 at 01:22:08PM +0200, Andrzej Pietrasiewicz wrote:
> > A new helper is available, so use it.
> > 
> > Signed-off-by: Andrzej Pietrasiewicz 
> > ---
> >  drivers/acpi/button.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index ff7ab291f678..4deb2b48d03c 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -411,7 +411,7 @@ static void acpi_button_notify(struct acpi_device 
> > *device, u32 event)
> > input = button->input;
> > if (button->type == ACPI_BUTTON_TYPE_LID) {
> > mutex_lock(>input->mutex);
> > -   users = button->input->users;
> > +   users = input_device_enabled(button->input);
> > mutex_unlock(>input->mutex);
> > if (users)
> 
> This chunk (pre-patch) is really wrong. 'users' value is obsolete and
> can not be trusted the moment we unlocked the mutex. "if" needs to be
> inside critical section.

So looking at this patch and the previous one again, I believe this
driver is wrong to key the behavior off input->users and we should not
apply either of the patches. I'll post another patch fixing this.

Thanks.

-- 
Dmitry

ld.lld: warning: drivers/built-in.a(hwmon/drivetemp.o):(.data..compoundliteral) is being placed in '.data..compoundliteral'

2020-10-04 Thread kernel test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   549738f15da0e5a00275977623be199fbbf7df50
commit: 1e1b6d63d6340764e00356873e5794225a2a03ea lib/string.c: implement stpcpy
date:   9 days ago
config: powerpc-randconfig-r002-20201005 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
bcd05599d0e53977a963799d6ee4f6e0bc21331b)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e1b6d63d6340764e00356873e5794225a2a03ea
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 1e1b6d63d6340764e00356873e5794225a2a03ea
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.2)
 is being placed in '.data..compoundliteral.2'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.3)
 is being placed in '.data..compoundliteral.3'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.4)
 is being placed in '.data..compoundliteral.4'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.5)
 is being placed in '.data..compoundliteral.5'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.6)
 is being placed in '.data..compoundliteral.6'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.7)
 is being placed in '.data..compoundliteral.7'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.8)
 is being placed in '.data..compoundliteral.8'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.9)
 is being placed in '.data..compoundliteral.9'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.10)
 is being placed in '.data..compoundliteral.10'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.11)
 is being placed in '.data..compoundliteral.11'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.12)
 is being placed in '.data..compoundliteral.12'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.13)
 is being placed in '.data..compoundliteral.13'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.14)
 is being placed in '.data..compoundliteral.14'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.15)
 is being placed in '.data..compoundliteral.15'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.16)
 is being placed in '.data..compoundliteral.16'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.17)
 is being placed in '.data..compoundliteral.17'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.18)
 is being placed in '.data..compoundliteral.18'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.19)
 is being placed in '.data..compoundliteral.19'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.20)
 is being placed in '.data..compoundliteral.20'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.21)
 is being placed in '.data..compoundliteral.21'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.22)
 is being placed in '.data..compoundliteral.22'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.23)
 is being placed in '.data..compoundliteral.23'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.24)
 is being placed in '.data..compoundliteral.24'
   ld.lld: warning: 
drivers/built-in.a(gpu/drm/panel/panel-innolux-p079zca.o):(.data..compoundliteral.25)
 is being placed in

Re: [PATCH] dt-bindings: Fix 'reg' size issues in zynqmp examples

On 28-09-20, 10:59, Rob Herring wrote:
> The default sizes in examples for 'reg' are 1 cell each. Fix the
> incorrect sizes in zynqmp examples:
> 
> Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.example.dt.yaml:
>  example-0: dma-controller@fd4c:reg:0: [0, 4249616384, 0, 4096] is too 
> long
>   From schema: 
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>  example-0: display@fd4a:reg:0: [0, 4249485312, 0, 4096] is too long
>   From schema: 
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>  example-0: display@fd4a:reg:1: [0, 4249526272, 0, 4096] is too long
>   From schema: 
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>  example-0: display@fd4a:reg:2: [0, 4249530368, 0, 4096] is too long
>   From schema: 
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml:
>  example-0: display@fd4a:reg:3: [0, 4249534464, 0, 4096] is too long
>   From schema: 
> /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml

Applied, thanks

-- 
~Vinod

Re: [PATCH v6 4/5] dmaengine: idxd: Clean up descriptors with fault error

2020-10-04 Thread Dave Jiang





On 10/4/2020 9:42 PM, Vinod Koul wrote:

On 24-09-20, 11:00, Dave Jiang wrote:

Add code to "complete" a descriptor when the descriptor or its completion
address hit a fault error when SVA mode is being used. This error can be
triggered due to bad programming by the user. A lock is introduced in order
to protect the descriptor completion lists since the fault handler will run
from the system work queue after being scheduled in the interrupt handler.

Signed-off-by: Dave Jiang 
Reviewed-by: Tony Luck 
Reviewed-by: Dan Williams 
---
  drivers/dma/idxd/idxd.h |   5 ++
  drivers/dma/idxd/init.c |   1 +
  drivers/dma/idxd/irq.c  | 143 
  3 files changed, 137 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index 43a216c42d25..b64b6266ca97 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -34,6 +34,11 @@ struct idxd_irq_entry {
int id;
struct llist_head pending_llist;
struct list_head work_list;
+   /*
+* Lock to protect access between irq thread process descriptor
+* and irq thread processing error descriptor.
+*/
+   spinlock_t list_lock;
  };
  
  struct idxd_group {

diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
index 626401a71fdd..1bb7637b02eb 100644
--- a/drivers/dma/idxd/init.c
+++ b/drivers/dma/idxd/init.c
@@ -97,6 +97,7 @@ static int idxd_setup_interrupts(struct idxd_device *idxd)
for (i = 0; i < msixcnt; i++) {
idxd->irq_entries[i].id = i;
idxd->irq_entries[i].idxd = idxd;
+   spin_lock_init(>irq_entries[i].list_lock);
}
  
  	msix = >msix_entries[0];

diff --git a/drivers/dma/idxd/irq.c b/drivers/dma/idxd/irq.c
index 17a65a13fb64..9e6cc55ad22f 100644
--- a/drivers/dma/idxd/irq.c
+++ b/drivers/dma/idxd/irq.c
@@ -11,6 +11,24 @@
  #include "idxd.h"
  #include "registers.h"
  
+enum irq_work_type {

+   IRQ_WORK_NORMAL = 0,
+   IRQ_WORK_PROCESS_FAULT,
+};
+
+struct idxd_fault {
+   struct work_struct work;
+   u64 addr;
+   struct idxd_device *idxd;
+};
+
+static int irq_process_work_list(struct idxd_irq_entry *irq_entry,
+enum irq_work_type wtype,
+int *processed, u64 data);
+static int irq_process_pending_llist(struct idxd_irq_entry *irq_entry,
+enum irq_work_type wtype,
+int *processed, u64 data);
+
  static void idxd_device_reinit(struct work_struct *work)
  {
struct idxd_device *idxd = container_of(work, struct idxd_device, work);
@@ -44,6 +62,46 @@ static void idxd_device_reinit(struct work_struct *work)
idxd_device_wqs_clear_state(idxd);
  }
  
+static void idxd_device_fault_work(struct work_struct *work)

+{
+   struct idxd_fault *fault = container_of(work, struct idxd_fault, work);
+   struct idxd_irq_entry *ie;
+   int i;
+   int processed;
+   int irqcnt = fault->idxd->num_wq_irqs + 1;
+
+   for (i = 1; i < irqcnt; i++) {
+   ie = >idxd->irq_entries[i];
+   irq_process_work_list(ie, IRQ_WORK_PROCESS_FAULT,
+ , fault->addr);
+   if (processed)
+   break;
+
+   irq_process_pending_llist(ie, IRQ_WORK_PROCESS_FAULT,
+ , fault->addr);
+   if (processed)
+   break;
+   }
+
+   kfree(fault);
+}
+
+static int idxd_device_schedule_fault_process(struct idxd_device *idxd,
+ u64 fault_addr)
+{
+   struct idxd_fault *fault;
+
+   fault = kmalloc(sizeof(*fault), GFP_ATOMIC);
+   if (!fault)
+   return -ENOMEM;
+
+   fault->addr = fault_addr;
+   fault->idxd = idxd;
+   INIT_WORK(>work, idxd_device_fault_work);
+   queue_work(idxd->wq, >work);
+   return 0;
+}
+
  irqreturn_t idxd_irq_handler(int vec, void *data)
  {
struct idxd_irq_entry *irq_entry = data;
@@ -125,6 +183,16 @@ irqreturn_t idxd_misc_thread(int vec, void *data)
if (!err)
goto out;
  
+	/*

+* This case should rarely happen and typically is due to software
+* programming error by the driver.
+*/
+   if (idxd->sw_err.valid &&
+   idxd->sw_err.desc_valid &&
+   idxd->sw_err.fault_addr)
+   idxd_device_schedule_fault_process(idxd,
+  idxd->sw_err.fault_addr);


This should fit in a single line ;)


Yes. With the new 100 col guideline this should be single line.




+
gensts.bits = ioread32(idxd->reg_base + IDXD_GENSTATS_OFFSET);
if (gensts.state == IDXD_DEVICE_STATE_HALT) {
idxd->state = IDXD_DEV_HALTED;
@@ -152,57 +220,106 @@ irqreturn_t idxd_misc_thread(int vec, void *data)

Re: [Patch 2/2] cpufreq: tegra194: Fix unlisted boot freq warning

2020-10-04 Thread Viresh Kumar

On 16-09-20, 22:41, Sumit Gupta wrote:
> Warning coming during boot because the boot freq set by bootloader
> gets filtered out due to big freq steps while creating freq_table.
> Fixing this by setting closest ndiv value from freq_table.
> Warning:
>   cpufreq: cpufreq_online: CPU0: Running at unlisted freq
>   cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed
> 
> Also, added change in init to wait till current frequency becomes
> equal or near to the previously requested frequency. This is done
> because it takes some time to restore the previous frequency while
> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).

So you are trying to figure if the frequency is listed in freq-table or not,
otherwise setting the frequency to a value you think is appropriate. Right ?

This is what the cpufreq core already does when it printed these boot time
messages. Do we really need to add this much code in here ?

If you really don't want to see the warning, how about fixing it the way cpufreq
core does ? i.e. with this call:

ret = __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);

-- 
viresh

[PATCH v10 6/7] Asoc: qcom: lpass-platform : Increase buffer size

From: V Sujith Kumar Reddy 

Increase buffer size to support audio over DP.

Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao Mandadapu 
---
 sound/soc/qcom/lpass-platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index a5ab5f1..92ccedb 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -23,7 +23,7 @@ struct lpass_pcm_data {
int i2s_port;
 };
 
-#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_BUFFER_SIZE (24 *  2 * 1024)
 #define LPASS_PLATFORM_PERIODS 2
 
 static const struct snd_pcm_hardware lpass_platform_pcm_hardware = {
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v10 7/7] ASoC: qcom: sc7180: Add support for audio over DP

From: V Sujith Kumar Reddy 

Add support for audio playback over DP in lpass
sc7180 platform driver. Update lpass_variant
structure for hdmi data configuaration.

Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/lpass-sc7180.c | 116 +-
 1 file changed, 102 insertions(+), 14 deletions(-)

diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index a8a3d8f..c6292f9e 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -60,38 +60,65 @@ static struct snd_soc_dai_driver 
sc7180_lpass_cpu_dai_driver[] = {
.probe  = _qcom_lpass_cpu_dai_probe,
.ops= _qcom_lpass_cpu_dai_ops,
},
+   [LPASS_DP_RX] = {
+   .id = LPASS_DP_RX,
+   .name = "Hdmi",
+   .playback = {
+   .stream_name = "Hdmi Playback",
+   .formats= SNDRV_PCM_FMTBIT_S24,
+   .rates = SNDRV_PCM_RATE_48000,
+   .rate_min   = 48000,
+   .rate_max   = 48000,
+   .channels_min   = 2,
+   .channels_max   = 2,
+   },
+   .ops= _qcom_lpass_hdmi_dai_ops,
+   },
 };
 
 static int sc7180_lpass_alloc_dma_channel(struct lpass_data *drvdata,
-  int direction)
+  int direction, unsigned int dai_id)
 {
struct lpass_variant *v = drvdata->variant;
int chan = 0;
 
-   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
-   chan = find_first_zero_bit(>dma_ch_bit_map,
-   v->rdma_channels);
+   if (dai_id == LPASS_DP_RX) {
+   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+   chan = 
find_first_zero_bit(>hdmi_dma_ch_bit_map,
+   v->hdmi_rdma_channels);
+
+   if (chan >= v->hdmi_rdma_channels)
+   return -EBUSY;
+   }
+   set_bit(chan, >hdmi_dma_ch_bit_map);
+   } else {
+   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+   chan = find_first_zero_bit(>dma_ch_bit_map,
+   v->rdma_channels);
 
if (chan >= v->rdma_channels)
return -EBUSY;
-   } else {
-   chan = find_next_zero_bit(>dma_ch_bit_map,
+   } else {
+   chan = find_next_zero_bit(>dma_ch_bit_map,
v->wrdma_channel_start +
v->wrdma_channels,
v->wrdma_channel_start);
 
-   if (chan >=  v->wrdma_channel_start + v->wrdma_channels)
-   return -EBUSY;
-   }
-
-   set_bit(chan, >dma_ch_bit_map);
+   if (chan >=  v->wrdma_channel_start + v->wrdma_channels)
+   return -EBUSY;
+   }
 
+   set_bit(chan, >dma_ch_bit_map);
+   }
return chan;
 }
 
-static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan, 
unsigned int dai_id)
 {
-   clear_bit(chan, >dma_ch_bit_map);
+   if (dai_id == LPASS_DP_RX)
+   clear_bit(chan, >hdmi_dma_ch_bit_map);
+   else
+   clear_bit(chan, >dma_ch_bit_map);
 
return 0;
 }
@@ -144,6 +171,9 @@ static struct lpass_variant sc7180_data = {
.rdma_reg_base  = 0xC000,
.rdma_reg_stride= 0x1000,
.rdma_channels  = 5,
+   .hdmi_rdma_reg_base = 0x64000,
+   .hdmi_rdma_reg_stride   = 0x1000,
+   .hdmi_rdma_channels = 4,
.dmactl_audif_start = 1,
.wrdma_reg_base = 0x18000,
.wrdma_reg_stride   = 0x1000,
@@ -163,7 +193,7 @@ static struct lpass_variant sc7180_data = {
.rdma_dyncclk   = REG_FIELD_ID(0xC000, 21, 21, 5, 0x1000),
.rdma_bursten   = REG_FIELD_ID(0xC000, 20, 20, 5, 0x1000),
.rdma_wpscnt= REG_FIELD_ID(0xC000, 16, 19, 5, 0x1000),
-   .rdma_intf  = REG_FIELD_ID(0xC000, 12, 15, 5, 0x1000),
+   .rdma_intf  = REG_FIELD_ID(0xC000, 12, 15, 5, 
0x1000),
.rdma_fifowm= REG_FIELD_ID(0xC000, 1, 5, 5, 0x1000),
.rdma_enable= REG_FIELD_ID(0xC000, 0, 0, 5, 0x1000),
 
@@ -174,6 +204,64 @@ static struct lpass_variant sc7180_data = {
.wrdma_fifowm   = REG_FIELD_ID(0x18000, 1, 5, 4, 0x1000),
.wrdma_enable   = REG_FIELD_ID(0x18000, 0, 0, 4, 0x1000),
 
+   .hdmi_tx_ctl_addr   = 0x1000,
+   .hdmi_legacy_addr   =

[PATCH v10 5/7] ASoC: qcom: Add support for lpass hdmi driver

From: V Sujith Kumar Reddy 

Upadate lpass cpu and platform driver to support audio over dp.
Also add lpass-hdmi.c and lpass-hdmi.h.

Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/Kconfig   |   5 +
 sound/soc/qcom/Makefile  |   2 +
 sound/soc/qcom/lpass-apq8016.c   |   4 +-
 sound/soc/qcom/lpass-cpu.c   |  51 -
 sound/soc/qcom/lpass-hdmi.c  | 468 +++
 sound/soc/qcom/lpass-hdmi.h  | 106 +
 sound/soc/qcom/lpass-ipq806x.c   |   4 +-
 sound/soc/qcom/lpass-lpaif-reg.h |  52 -
 sound/soc/qcom/lpass-platform.c  | 391 ++--
 sound/soc/qcom/lpass.h   | 113 +-
 10 files changed, 1097 insertions(+), 99 deletions(-)
 create mode 100644 sound/soc/qcom/lpass-hdmi.c
 create mode 100644 sound/soc/qcom/lpass-hdmi.h

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index a7ef626..28e775f 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -12,6 +12,10 @@ config SND_SOC_LPASS_CPU
tristate
select REGMAP_MMIO
 
+config SND_SOC_LPASS_HDMI
+   tristate
+   select REGMAP_MMIO
+
 config SND_SOC_LPASS_PLATFORM
tristate
select REGMAP_MMIO
@@ -30,6 +34,7 @@ config SND_SOC_LPASS_SC7180
tristate
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
+   select SND_SOC_LPASS_HDMI
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 7972c94..0bd90d7 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -1,12 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0
 # Platform
 snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-hdmi-objs := lpass-hdmi.o
 snd-soc-lpass-platform-objs := lpass-platform.o
 snd-soc-lpass-ipq806x-objs := lpass-ipq806x.o
 snd-soc-lpass-apq8016-objs := lpass-apq8016.o
 snd-soc-lpass-sc7180-objs := lpass-sc7180.o
 
 obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_HDMI) += snd-soc-lpass-hdmi.o
 obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
 obj-$(CONFIG_SND_SOC_LPASS_IPQ806X) += snd-soc-lpass-ipq806x.o
 obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 5c8ae22..0aedb3a 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -125,7 +125,7 @@ static struct snd_soc_dai_driver 
apq8016_lpass_cpu_dai_driver[] = {
 };
 
 static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
-  int direction)
+  int direction, unsigned int dai_id)
 {
struct lpass_variant *v = drvdata->variant;
int chan = 0;
@@ -151,7 +151,7 @@ static int apq8016_lpass_alloc_dma_channel(struct 
lpass_data *drvdata,
return chan;
 }
 
-static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int 
chan, unsigned int dai_id)
 {
clear_bit(chan, >dma_ch_bit_map);
 
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 12950d2..b6d243e 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -535,13 +535,17 @@ static void of_lpass_cpu_parse_dai_data(struct device 
*dev,
dev_err(dev, "valid dai id not found: %d\n", ret);
continue;
}
-
-   data->mi2s_playback_sd_mode[id] =
-   of_lpass_cpu_parse_sd_lines(dev, node,
-   "qcom,playback-sd-lines");
-   data->mi2s_capture_sd_mode[id] =
-   of_lpass_cpu_parse_sd_lines(dev, node,
+   if (id == LPASS_DP_RX) {
+   data->hdmi_port_enable = 1;
+   dev_err(dev, "HDMI Port is enabled: %d\n", id);
+   } else {
+   data->mi2s_playback_sd_mode[id] =
+   of_lpass_cpu_parse_sd_lines(dev, node,
+   
"qcom,playback-sd-lines");
+   data->mi2s_capture_sd_mode[id] =
+   of_lpass_cpu_parse_sd_lines(dev, node,
"qcom,capture-sd-lines");
+   }
}
 }
 
@@ -596,6 +600,27 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
return PTR_ERR(drvdata->lpaif_map);
}
 
+   if (drvdata->hdmi_port_enable) {
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
"lpass-hdmiif");
+
+   drvdata->hdmiif = devm_ioremap_resource(dev, res);
+   if (IS_ERR((void const __force *)drvdata->hdmiif)) {
+

Re: [PATCH 09/14] dmaengine: rcar-dmac: drop double zeroing

On 20-09-20, 13:26, Julia Lawall wrote:
> sg_init_table zeroes its first argument, so the allocation of that argument
> doesn't have to.
> 
> the semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)

Applied, thanks

-- 
~Vinod

Re: [PATCH 04/14] dmaengine: sh: drop double zeroing

On 20-09-20, 13:26, Julia Lawall wrote:
> sg_init_table zeroes its first argument, so the allocation of that argument
> doesn't have to.
> 
> the semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)

Applied, thanks

-- 
~Vinod

[PATCH v10 3/7] Asoc:qcom:lpass-cpu:Update dts property read API

From: V Sujith Kumar Reddy 

Update dts property read API call with platform get property
by name, as it make code more readable and avoid conflicts
when array of properties to be used.

Signed-off-by: V Sujith Kumar Reddy 
Reviewed-by: Srinivas Kandagatla 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/lpass-cpu.c  | 2 +-
 sound/soc/qcom/lpass-platform.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 0718a0f..12950d2 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -575,7 +575,7 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
 
of_lpass_cpu_parse_dai_data(dev, drvdata);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpass-lpaif");
 
drvdata->lpaif = devm_ioremap_resource(dev, res);
if (IS_ERR((void const __force *)drvdata->lpaif)) {
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 7ac2629..e7cf4e5 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -621,7 +621,7 @@ int asoc_qcom_lpass_platform_register(struct 
platform_device *pdev)
struct lpass_variant *v = drvdata->variant;
int ret;
 
-   drvdata->lpaif_irq = platform_get_irq(pdev, 0);
+   drvdata->lpaif_irq = platform_get_irq_byname(pdev, "lpass-irq-lpaif");
if (drvdata->lpaif_irq < 0)
return -ENODEV;
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v10 4/7] Asoc: qcom: lpass:Update lpaif_dmactl members order

From: V Sujith Kumar Reddy 

Update the lpaif_dmactl struct members order to match
HDMI reg map members sequence. Separate Interface reg map
as it is used for I2S control but not for HDMI control,
to make use of bulk API, which makes code more readable.

Signed-off-by: V Sujith Kumar Reddy 
Reviewed-by: Srinivas Kandagatla 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/lpass-platform.c | 8 
 sound/soc/qcom/lpass.h  | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index e7cf4e5..db0d959 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -71,13 +71,13 @@ static int lpass_platform_alloc_dmactl_fields(struct device 
*dev,
rd_dmactl = drvdata->rd_dmactl;
wr_dmactl = drvdata->wr_dmactl;
 
-   rval = devm_regmap_field_bulk_alloc(dev, map, _dmactl->bursten,
-   >rdma_bursten, 6);
+   rval = devm_regmap_field_bulk_alloc(dev, map, _dmactl->intf,
+   >rdma_intf, 6);
if (rval)
return rval;
 
-   return devm_regmap_field_bulk_alloc(dev, map, _dmactl->bursten,
-   >wrdma_bursten, 6);
+   return devm_regmap_field_bulk_alloc(dev, map, _dmactl->intf,
+   >wrdma_intf, 6);
 }
 
 static int lpass_platform_pcmops_open(struct snd_soc_component *component,
diff --git a/sound/soc/qcom/lpass.h b/sound/soc/qcom/lpass.h
index 51c9991..7089d4c 100644
--- a/sound/soc/qcom/lpass.h
+++ b/sound/soc/qcom/lpass.h
@@ -31,9 +31,9 @@ struct lpaif_i2sctl {
 
 
 struct lpaif_dmactl {
+   struct regmap_field *intf;
struct regmap_field *bursten;
struct regmap_field *wpscnt;
-   struct regmap_field *intf;
struct regmap_field *fifowm;
struct regmap_field *enable;
struct regmap_field *dyncclk;
@@ -110,17 +110,17 @@ struct lpass_variant {
struct reg_field bitwidth;
 
/* RD_DMA Register fields */
+   struct reg_field rdma_intf;
struct reg_field rdma_bursten;
struct reg_field rdma_wpscnt;
-   struct reg_field rdma_intf;
struct reg_field rdma_fifowm;
struct reg_field rdma_enable;
struct reg_field rdma_dyncclk;
 
/* WR_DMA Register fields */
+   struct reg_field wrdma_intf;
struct reg_field wrdma_bursten;
struct reg_field wrdma_wpscnt;
-   struct reg_field wrdma_intf;
struct reg_field wrdma_fifowm;
struct reg_field wrdma_enable;
struct reg_field wrdma_dyncclk;
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v10 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS
Asoc. It includes machine driver, cpu driver, platform driver updates for 
HDMI path support, device tree documention, lpass variant structure 
optimization and configuration changes.
These patches depends on the DP patch series
https://patchwork.kernel.org/project/dri-devel/list/?series=332029
https://lore.kernel.org/patchwork/project/lkml/list/?series=464856

changes since V9:
-- Removed unused structures lpass_hdmi.h
changes since V8:
-- Removed redundant structure wrapper for reg map field memebrs
-- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true
   and others as false.
changes since V7:
-- Fixed typo errors
-- Created Separate patch for buffer size change 
changes since V6:
-- Removed compile time define flag, which used for enabling
 HDMI code, based on corresponding config param is included.
-- Updated reg map alloc API with reg map bulk API.
-- Removed unnecessary line splits
changes since V5:
-- Removed unused struct regmap *map in 
lpass_platform_alloc_hdmidmactl_fields.
-- DMA alloc and free API signature change in lpass-apq8016.c, 
lpass-ipq806x.c 
-- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro
Changes Since v4:
-- Updated with single compatible node for both I2S and HDMI.
Changes Since v3:
-- Removed id in lpass variant structure and used snd_soc_dai_driver id.
Changes Since v2:
-- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c 
increased.
Changes Since v1:
-- Commit messages are updated
-- Addressed Rob Herring review comments

V Sujith Kumar Reddy (8):
  ASoC: Add sc7180-lpass binding header hdmi define
  ASoC: dt-bindings: Add dt binding for lpass hdmi
  Asoc:qcom:lpass-cpu:Update dts property read API
  Asoc: qcom: lpass:Update lpaif_dmactl members order
  ASoC: qcom: Add support for lpass hdmi driver
  Asoc: qcom: lpass-platform : Increase buffer size
  ASoC: qcom: sc7180: Add support for audio over DP

 .../devicetree/bindings/sound/qcom,lpass-cpu.yaml  |  74 +++-
 include/dt-bindings/sound/sc7180-lpass.h   |   1 +
 sound/soc/qcom/Kconfig |   5 +
 sound/soc/qcom/Makefile|   2 +
 sound/soc/qcom/lpass-apq8016.c |   4 +-
 sound/soc/qcom/lpass-cpu.c |  53 ++-
 sound/soc/qcom/lpass-hdmi.c| 468 +
 sound/soc/qcom/lpass-hdmi.h| 106 +
 sound/soc/qcom/lpass-ipq806x.c |   4 +-
 sound/soc/qcom/lpass-lpaif-reg.h   |  52 ++-
 sound/soc/qcom/lpass-platform.c| 403 ++
 sound/soc/qcom/lpass-sc7180.c  | 116 -
 sound/soc/qcom/lpass.h | 119 +-
 13 files changed, 1262 insertions(+), 145 deletions(-)
 create mode 100644 sound/soc/qcom/lpass-hdmi.c
 create mode 100644 sound/soc/qcom/lpass-hdmi.h

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v10 2/7] ASoC: dt-bindings: Add dt binding for lpass hdmi

From: V Sujith Kumar Reddy 

Adds bindings for lpass hdmi interface
which can support audio path over dp.

Signed-off-by: V Sujith Kumar Reddy 
Reviewed-by: Rob Herring 
Signed-off-by: Srinivasa Rao 
---
 .../devicetree/bindings/sound/qcom,lpass-cpu.yaml  | 74 +++---
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml 
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index 09c9bd2..f6f9fb4 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -24,9 +24,10 @@ properties:
   - qcom,sc7180-lpass-cpu
 
   reg:
-maxItems: 1
+maxItems: 2
 description: LPAIF core registers
-
+  reg-names:
+ maxItems: 2
   clocks:
 minItems: 3
 maxItems: 6
@@ -36,15 +37,16 @@ properties:
 maxItems: 6
 
   interrupts:
-maxItems: 1
+maxItems: 2
 description: LPAIF DMA buffer interrupt
-
+  interrupt-names:
+maxItems: 2
   qcom,adsp:
 $ref: /schemas/types.yaml#/definitions/phandle
 description: Phandle for the audio DSP node
 
   iommus:
-maxItems: 1
+maxItems: 2
 description: Phandle to apps_smmu node with sid mask
 
   power-domains:
@@ -60,10 +62,12 @@ properties:
 const: 0
 
 patternProperties:
-  "(^mi2s-[0-9a-f]$|mi2s)":
+  "^dai-link@[0-9a-f]$":
 type: object
-description: Required properties for each DAI
-
+description: |
+  LPASS CPU dai node for each I2S device. Bindings of each node
+  depends on the specific driver providing the functionality and
+  properties.
 properties:
   reg:
 maxItems: 1
@@ -85,9 +89,11 @@ patternProperties:
 required:
   - compatible
   - reg
+  - reg-names
   - clocks
   - clock-names
   - interrupts
+  - interrupt-names
   - '#sound-dai-cells'
 
 additionalProperties: false
@@ -134,13 +140,32 @@ allOf:
 then:
   properties:
 clock-names:
-  items:
-- const: pcnoc-sway-clk
-- const: audio-core
-- const: mclk0
-- const: pcnoc-mport-clk
-- const: mi2s-bit-clk0
-- const: mi2s-bit-clk1
+  oneOf:
+   - items:   #for I2S
+  - const: pcnoc-sway-clk
+  - const: audio-core
+  - const: mclk0
+  - const: pcnoc-mport-clk
+  - const: mi2s-bit-clk0
+  - const: mi2s-bit-clk1
+   - items:   #for HDMI
+  - const: pcnoc-sway-clk
+  - const: audio-core
+  - const: pcnoc-mport-clk
+reg-names:
+  anyOf:
+- items:   #for I2S
+  - const: lpass-lpaif
+- items:   #for I2S and HDMI
+  - const: lpass-hdmiif
+  - const: lpass-lpaif
+interrupt-names:
+  anyOf:
+- items:   #for I2S
+  - const: lpass-irq-lpaif
+- items:   #for I2S and HDMI
+  - const: lpass-irq-lpaif
+  - const: lpass-irq-hdmi
   required:
 - iommus
 - power-domains
@@ -152,12 +177,15 @@ examples:
 soc {
 #address-cells = <2>;
 #size-cells = <2>;
-lpass@62f0 {
+lpass@62d8 {
 compatible = "qcom,sc7180-lpass-cpu";
 
-reg = <0 0x62f0  0 0x29000>;
-
-iommus = <_smmu 0x1020 0>;
+reg = <0 0x62d87000 0 0x68000>,
+  <0 0x62f0 0 0x29000>;
+reg-names = "lpass-hdmiif",
+"lpass-lpaif";
+iommus = <_smmu 0x1020 0>,
+ <_smmu 0x1032 0>;
 power-domains = <_hm 0>;
 
 clocks = < 131>,
@@ -171,14 +199,16 @@ examples:
   "mclk0", "pcnoc-mport-clk",
   "mi2s-bit-clk0", "mi2s-bit-clk1";
 
-interrupts = <0 160 1>;
-
+interrupts = <0 160 1>,
+ <0 268 1>;
+interrupt-names = "lpass-irq-lpaif",
+  "lpass-irq-hdmi";
 #sound-dai-cells = <1>;
 
 #address-cells = <1>;
 #size-cells = <0>;
 /* Optional to set different MI2S SD lines */
-mi2s-primary@0 {
+dai-link@0 {
 reg = ;
 qcom,playback-sd-lines = <1>;
 qcom,capture-sd-lines = <0>;
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v10 1/7] ASoC: Add sc7180-lpass binding header hdmi define

From: V Sujith Kumar Reddy 

Add header defining hdmi dai-id for SC7180 lpass soc
in dt bindings.

Signed-off-by: V Sujith Kumar Reddy 
Acked-by: Rob Herring 
Signed-off-by: Srinivasa Rao 
---
 include/dt-bindings/sound/sc7180-lpass.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/sound/sc7180-lpass.h 
b/include/dt-bindings/sound/sc7180-lpass.h
index 7d988f6..56ecaaf 100644
--- a/include/dt-bindings/sound/sc7180-lpass.h
+++ b/include/dt-bindings/sound/sc7180-lpass.h
@@ -4,6 +4,7 @@
 
 #define MI2S_PRIMARY   0
 #define MI2S_SECONDARY 1
+#define LPASS_DP_RX2
 
 #define LPASS_MCLK00
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] dmaengine: ioat: Allocate correct size for descriptor chunk

On 22-09-20, 14:08, Logan Gunthorpe wrote:
> dma_alloc_coherent() is called with a fixed SZ_2M size, but frees happen
> with IOAT_CHUNK_SIZE. Recently, IOAT_CHUNK_SIZE was reduced to 512M but
> the allocation did not change. To fix, change to using the
> IOAT_CHUNK_SIZE define.
> 
> This was caught with the upcoming patchset for converting Intel platforms to 
> the
> dma-iommu implementation. It has a warning when the unmapped size differs from
> the mapped size.

Applied, thanks

-- 
~Vinod

Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq

2020-10-04 Thread Viresh Kumar

On 16-09-20, 22:41, Sumit Gupta wrote:
> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
> and keeps changing slightly. This change returns a consistent value
> from freq_table. If the reconstructed frequency has acceptable delta
> from the last written value, then return the frequency corresponding
> to the last written ndiv value from freq_table. Otherwise, print a
> warning and return the reconstructed freq.
> 
> Signed-off-by: Sumit Gupta 
> ---
>  drivers/cpufreq/tegra194-cpufreq.c | 66 
> --
>  1 file changed, 57 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra194-cpufreq.c 
> b/drivers/cpufreq/tegra194-cpufreq.c
> index e1d931c..d5b608d 100644
> --- a/drivers/cpufreq/tegra194-cpufreq.c
> +++ b/drivers/cpufreq/tegra194-cpufreq.c
> @@ -180,9 +180,65 @@ static unsigned int tegra194_get_speed_common(u32 cpu, 
> u32 delay)
>   return (rate_mhz * KHZ); /* in KHz */
>  }
>  
> +static void get_cpu_ndiv(void *ndiv)
> +{
> + u64 ndiv_val;
> +
> + asm volatile("mrs %0, s3_0_c15_c0_4" : "=r" (ndiv_val) : );
> +
> + *(u64 *)ndiv = ndiv_val;
> +}
> +
> +static void set_cpu_ndiv(void *data)
> +{
> + struct cpufreq_frequency_table *tbl = data;
> + u64 ndiv_val = (u64)tbl->driver_data;
> +
> + asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
> +}
> +
>  static unsigned int tegra194_get_speed(u32 cpu)
>  {
> - return tegra194_get_speed_common(cpu, US_DELAY);
> + struct cpufreq_frequency_table *table, *pos;
> + struct cpufreq_policy policy;
> + unsigned int rate;
> + u64 ndiv;
> + int err;
> +
> + cpufreq_get_policy(, cpu);
> + table = policy.freq_table;

Maybe getting freq-table from cluster specific data would be better/faster.

> +
> + /* reconstruct actual cpu freq using counters*/
> + rate = tegra194_get_speed_common(cpu, US_DELAY);
> +
> + /* get last written ndiv value*/
> + err = smp_call_function_single(cpu, get_cpu_ndiv, , true);
> + if (err) {
> + pr_err("cpufreq: Failed to get ndiv for CPU%d, ret:%d\n",
> +cpu, err);
> + return rate;
> + }
> +
> + /* if the reconstructed frequency has acceptable delta from

Both have got the multi-line comments wrong. Format is wrong and every sentence
needs to start with a capital letter.

> +  * the last written value, then return freq corresponding
> +  * to the last written ndiv value from freq_table. This is
> +  * done to return consistent value.
> +  */
> + cpufreq_for_each_valid_entry(pos, table) {
> + if (pos->driver_data != ndiv)
> + continue;
> +
> + if (abs(pos->frequency - rate) > 115200) {
> + pr_warn("cpufreq: high delta (%d) on CPU%d\n",
> + abs(pos->frequency - rate), cpu);
> + pr_warn("cpufreq: cur:%u, set:%u, set ndiv:%llu\n",
> + rate, pos->frequency, ndiv);

Both of these can be merged in a single line I think. There is no need to print
delta as you already print both the frequencies.

> + } else {
> + rate = pos->frequency;
> + }
> + break;
> + }
> + return rate;
>  }
>  
>  static int tegra194_cpufreq_init(struct cpufreq_policy *policy)
> @@ -209,14 +265,6 @@ static int tegra194_cpufreq_init(struct cpufreq_policy 
> *policy)
>   return 0;
>  }
>  
> -static void set_cpu_ndiv(void *data)
> -{
> - struct cpufreq_frequency_table *tbl = data;
> - u64 ndiv_val = (u64)tbl->driver_data;
> -
> - asm volatile("msr s3_0_c15_c0_4, %0" : : "r" (ndiv_val));
> -}
> -
>  static int tegra194_cpufreq_set_target(struct cpufreq_policy *policy,
>  unsigned int index)
>  {
> -- 
> 2.7.4

-- 
viresh

Re: [PATCH] test_power: add missing newlines when printing parameters by sysfs

2020-10-04 Thread Harley A.W. Lorenzo

On Monday, October 5, 2020 12:19 AM, Joe Perches  wrote:
> I did not suggest this.

My apologies. Revised patch (still diffing from Xiongfeng Wang) here.

[PATCH v2] test_power: revise parameter printing to use sprintf

Signed-off-by: Harley A.W. Lorenzo 
Suggested-by: Joe Perches 
---
 drivers/power/supply/test_power.c | 32 +--
 1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/drivers/power/supply/test_power.c 
b/drivers/power/supply/test_power.c
index 4895ee5e63a9..5f510ddc946d 100644
--- a/drivers/power/supply/test_power.c
+++ b/drivers/power/supply/test_power.c
@@ -352,9 +352,8 @@ static int param_set_ac_online(const char *key, const 
struct kernel_param *kp)

 static int param_get_ac_online(char *buffer, const struct kernel_param *kp)
 {
-   strcpy(buffer, map_get_key(map_ac_online, ac_online, "unknown"));
-   strcat(buffer, "\n");
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n",
+   map_get_key(map_ac_online, ac_online, "unknown"));
 }

 static int param_set_usb_online(const char *key, const struct kernel_param *kp)
@@ -366,9 +365,8 @@ static int param_set_usb_online(const char *key, const 
struct kernel_param *kp)

 static int param_get_usb_online(char *buffer, const struct kernel_param *kp)
 {
-   strcpy(buffer, map_get_key(map_ac_online, usb_online, "unknown"));
-   strcat(buffer, "\n");
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n",
+   map_get_key(map_ac_online, usb_online, "unknown"));
 }

 static int param_set_battery_status(const char *key,
@@ -381,9 +379,8 @@ static int param_set_battery_status(const char *key,

 static int param_get_battery_status(char *buffer, const struct kernel_param 
*kp)
 {
-   strcpy(buffer, map_get_key(map_status, battery_status, "unknown"));
-   strcat(buffer, "\n");
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n",
+   map_get_key(map_ac_online, battery_status, "unknown"));
 }

 static int param_set_battery_health(const char *key,
@@ -396,9 +393,8 @@ static int param_set_battery_health(const char *key,

 static int param_get_battery_health(char *buffer, const struct kernel_param 
*kp)
 {
-   strcpy(buffer, map_get_key(map_health, battery_health, "unknown"));
-   strcat(buffer, "\n");
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n",
+   map_get_key(map_ac_online, battery_health, "unknown"));
 }

 static int param_set_battery_present(const char *key,
@@ -412,9 +408,8 @@ static int param_set_battery_present(const char *key,
 static int param_get_battery_present(char *buffer,
const struct kernel_param *kp)
 {
-   strcpy(buffer, map_get_key(map_present, battery_present, "unknown"));
-   strcat(buffer, "\n");
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n",
+   map_get_key(map_ac_online, battery_present, "unknown"));
 }

 static int param_set_battery_technology(const char *key,
@@ -429,10 +424,9 @@ static int param_set_battery_technology(const char *key,
 static int param_get_battery_technology(char *buffer,
const struct kernel_param *kp)
 {
-   strcpy(buffer,
-   map_get_key(map_technology, battery_technology, "unknown"));
-   strcat(buffer, "\n");
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n",
+   map_get_key(map_ac_online, battery_technology,
+   "unknown"));
 }

 static int param_set_battery_capacity(const char *key,
--
2.28.0

Re: [PATCH v6 5/5] dmaengine: idxd: Add ABI documentation for shared wq

On 24-09-20, 11:00, Dave Jiang wrote:
> Add the sysfs attribute bits in ABI/stable for shared wq support.

OK I take back the documentation comment now

> 
> Signed-off-by: Jing Lin 
> Signed-off-by: Dave Jiang 
> Reviewed-by: Tony Luck 
> Reviewed-by: Dan Williams 
> ---
>  Documentation/ABI/stable/sysfs-driver-dma-idxd | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd 
> b/Documentation/ABI/stable/sysfs-driver-dma-idxd
> index b44183880935..42d3dc03ffea 100644
> --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd
> +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd
> @@ -77,6 +77,13 @@ Contact:dmaeng...@vger.kernel.org
>  Description:The operation capability bit mask specify the operation types
>   supported by the this device.
>  
> +What:/sys/bus/dsa/devices/dsa/pasid_enabled
> +Date:Sep 17, 2020
> +KernelVersion:   5.10.0
> +Contact: dmaeng...@vger.kernel.org
> +Description: To indicate if PASID (process address space identifier) is
> + enabled or not for this device.
> +
>  What:   /sys/bus/dsa/devices/dsa/state
>  Date:   Oct 25, 2019
>  KernelVersion:  5.6.0
> @@ -122,6 +129,13 @@ KernelVersion:   5.10.0
>  Contact: dmaeng...@vger.kernel.org
>  Description: The last executed device administrative command's status/error.
>  
> +What:/sys/bus/dsa/devices/wq./block_on_fault
> +Date:Sept 17, 2020
> +KernelVersion:   5.10.0
> +Contact: dmaeng...@vger.kernel.org
> +Description: To indicate block on fault is allowed or not for the work queue
> + to support on demand paging.
> +
>  What:   /sys/bus/dsa/devices/wq./group_id
>  Date:   Oct 25, 2019
>  KernelVersion:  5.6.0
> -- 
> 2.21.3

-- 
~Vinod

Re: [PATCH v6 4/5] dmaengine: idxd: Clean up descriptors with fault error

On 24-09-20, 11:00, Dave Jiang wrote:
> Add code to "complete" a descriptor when the descriptor or its completion
> address hit a fault error when SVA mode is being used. This error can be
> triggered due to bad programming by the user. A lock is introduced in order
> to protect the descriptor completion lists since the fault handler will run
> from the system work queue after being scheduled in the interrupt handler.
> 
> Signed-off-by: Dave Jiang 
> Reviewed-by: Tony Luck 
> Reviewed-by: Dan Williams 
> ---
>  drivers/dma/idxd/idxd.h |   5 ++
>  drivers/dma/idxd/init.c |   1 +
>  drivers/dma/idxd/irq.c  | 143 
>  3 files changed, 137 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
> index 43a216c42d25..b64b6266ca97 100644
> --- a/drivers/dma/idxd/idxd.h
> +++ b/drivers/dma/idxd/idxd.h
> @@ -34,6 +34,11 @@ struct idxd_irq_entry {
>   int id;
>   struct llist_head pending_llist;
>   struct list_head work_list;
> + /*
> +  * Lock to protect access between irq thread process descriptor
> +  * and irq thread processing error descriptor.
> +  */
> + spinlock_t list_lock;
>  };
>  
>  struct idxd_group {
> diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
> index 626401a71fdd..1bb7637b02eb 100644
> --- a/drivers/dma/idxd/init.c
> +++ b/drivers/dma/idxd/init.c
> @@ -97,6 +97,7 @@ static int idxd_setup_interrupts(struct idxd_device *idxd)
>   for (i = 0; i < msixcnt; i++) {
>   idxd->irq_entries[i].id = i;
>   idxd->irq_entries[i].idxd = idxd;
> + spin_lock_init(>irq_entries[i].list_lock);
>   }
>  
>   msix = >msix_entries[0];
> diff --git a/drivers/dma/idxd/irq.c b/drivers/dma/idxd/irq.c
> index 17a65a13fb64..9e6cc55ad22f 100644
> --- a/drivers/dma/idxd/irq.c
> +++ b/drivers/dma/idxd/irq.c
> @@ -11,6 +11,24 @@
>  #include "idxd.h"
>  #include "registers.h"
>  
> +enum irq_work_type {
> + IRQ_WORK_NORMAL = 0,
> + IRQ_WORK_PROCESS_FAULT,
> +};
> +
> +struct idxd_fault {
> + struct work_struct work;
> + u64 addr;
> + struct idxd_device *idxd;
> +};
> +
> +static int irq_process_work_list(struct idxd_irq_entry *irq_entry,
> +  enum irq_work_type wtype,
> +  int *processed, u64 data);
> +static int irq_process_pending_llist(struct idxd_irq_entry *irq_entry,
> +  enum irq_work_type wtype,
> +  int *processed, u64 data);
> +
>  static void idxd_device_reinit(struct work_struct *work)
>  {
>   struct idxd_device *idxd = container_of(work, struct idxd_device, work);
> @@ -44,6 +62,46 @@ static void idxd_device_reinit(struct work_struct *work)
>   idxd_device_wqs_clear_state(idxd);
>  }
>  
> +static void idxd_device_fault_work(struct work_struct *work)
> +{
> + struct idxd_fault *fault = container_of(work, struct idxd_fault, work);
> + struct idxd_irq_entry *ie;
> + int i;
> + int processed;
> + int irqcnt = fault->idxd->num_wq_irqs + 1;
> +
> + for (i = 1; i < irqcnt; i++) {
> + ie = >idxd->irq_entries[i];
> + irq_process_work_list(ie, IRQ_WORK_PROCESS_FAULT,
> +   , fault->addr);
> + if (processed)
> + break;
> +
> + irq_process_pending_llist(ie, IRQ_WORK_PROCESS_FAULT,
> +   , fault->addr);
> + if (processed)
> + break;
> + }
> +
> + kfree(fault);
> +}
> +
> +static int idxd_device_schedule_fault_process(struct idxd_device *idxd,
> +   u64 fault_addr)
> +{
> + struct idxd_fault *fault;
> +
> + fault = kmalloc(sizeof(*fault), GFP_ATOMIC);
> + if (!fault)
> + return -ENOMEM;
> +
> + fault->addr = fault_addr;
> + fault->idxd = idxd;
> + INIT_WORK(>work, idxd_device_fault_work);
> + queue_work(idxd->wq, >work);
> + return 0;
> +}
> +
>  irqreturn_t idxd_irq_handler(int vec, void *data)
>  {
>   struct idxd_irq_entry *irq_entry = data;
> @@ -125,6 +183,16 @@ irqreturn_t idxd_misc_thread(int vec, void *data)
>   if (!err)
>   goto out;
>  
> + /*
> +  * This case should rarely happen and typically is due to software
> +  * programming error by the driver.
> +  */
> + if (idxd->sw_err.valid &&
> + idxd->sw_err.desc_valid &&
> + idxd->sw_err.fault_addr)
> + idxd_device_schedule_fault_process(idxd,
> +idxd->sw_err.fault_addr);

This should fit in a single line ;)

> +
>   gensts.bits = ioread32(idxd->reg_base + IDXD_GENSTATS_OFFSET);
>   if (gensts.state == IDXD_DEVICE_STATE_HALT) {
>   idxd->state = IDXD_DEV_HALTED;
> @@ -152,57 +220,106 @@ irqreturn_t idxd_misc_thread(int vec, void

Re: [PATCH v1] trace: Fix race in trace_open and buffer resize call

2020-10-04 Thread Gaurav Kohli


Hi Steven,

please let us know, if below looks good to you or need modifications.

Thanks
Gaurav

On 9/24/2020 7:25 PM, Gaurav Kohli wrote:

Below race can come, if trace_open and resize of
cpu buffer is running parallely on different cpus
CPUXCPUY
ring_buffer_resize
atomic_read(>resize_disabled)
tracing_open
tracing_reset_online_cpus
ring_buffer_reset_cpu
rb_reset_cpu
rb_update_pages
remove/insert pages
resetting pointer
This race can cause data abort or some times infinte loop in
rb_remove_pages and rb_insert_pages while checking pages
for sanity.

Signed-off-by: Gaurav Kohli 
Cc: sta...@vger.kernel.org
---
Changes since v0:
   -Addressed Steven's review comments.

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 93ef0ab..15bf28b 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4866,6 +4866,9 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer, 
int cpu)
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return;
  
+	/* prevent another thread from changing buffer sizes */

+   mutex_lock(>mutex);
+
atomic_inc(_buffer->resize_disabled);
atomic_inc(_buffer->record_disabled);
  
@@ -4876,6 +4879,8 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu)
  
  	atomic_dec(_buffer->record_disabled);

atomic_dec(_buffer->resize_disabled);
+
+   mutex_unlock(>mutex);
  }
  EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
  
@@ -4889,6 +4894,9 @@ void ring_buffer_reset_online_cpus(struct trace_buffer *buffer)

struct ring_buffer_per_cpu *cpu_buffer;
int cpu;
  
+	/* prevent another thread from changing buffer sizes */

+   mutex_lock(>mutex);
+
for_each_online_buffer_cpu(buffer, cpu) {
cpu_buffer = buffer->buffers[cpu];
  
@@ -4907,6 +4915,8 @@ void ring_buffer_reset_online_cpus(struct trace_buffer *buffer)

atomic_dec(_buffer->record_disabled);
atomic_dec(_buffer->resize_disabled);
}
+
+   mutex_unlock(>mutex);
  }
  
  /**




--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH v6 3/5] dmaengine: idxd: Add shared workqueue support

On 24-09-20, 11:00, Dave Jiang wrote:

> @@ -1154,6 +1268,8 @@ static struct attribute *idxd_wq_attributes[] = {
>   _attr_wq_mode.attr,
>   _attr_wq_size.attr,
>   _attr_wq_priority.attr,
> + _attr_wq_block_on_fault.attr,
> + _attr_wq_threshold.attr,
>   _attr_wq_type.attr,
>   _attr_wq_name.attr,
>   _attr_wq_cdev_minor.attr,
> @@ -1305,6 +1421,16 @@ static ssize_t clients_show(struct device *dev,
>  }
>  static DEVICE_ATTR_RO(clients);
>  
> +static ssize_t pasid_enabled_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + struct idxd_device *idxd =
> + container_of(dev, struct idxd_device, conf_dev);
> +
> + return sprintf(buf, "%u\n", device_pasid_enabled(idxd));
> +}
> +static DEVICE_ATTR_RO(pasid_enabled);
> +
>  static ssize_t state_show(struct device *dev,
> struct device_attribute *attr, char *buf)
>  {
> @@ -1424,6 +1550,7 @@ static struct attribute *idxd_device_attributes[] = {
>   _attr_gen_cap.attr,
>   _attr_configurable.attr,
>   _attr_clients.attr,
> + _attr_pasid_enabled.attr,

No Documentation again for these new files! Please add them as well

-- 
~Vinod

Re: [Patch 1/2] cpufreq: tegra194: get consistent cpuinfo_cur_freq

2020-10-04 Thread Viresh Kumar

On 17-09-20, 09:36, Jon Hunter wrote:
> Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
> to resend with the Fixes tag or are you happy to add?

I understand that this fixes a patch which got merged recently, but I am not
sure if anything is broken badly right now, i.e. will make the hardware work
incorrectly.

Do we really need to get these in 5.9 ? As these are significant changes and may
cause more bugs. Won't getting them in 5.9-stable and 5.10-rc1 be enough ?

-- 
viresh

Re: [PATCH] dma: dma-jz4780: Fix race in jz4780_dma_tx_status

On 04-10-20, 16:03, Paul Cercueil wrote:
> The jz4780_dma_tx_status() function would check if a channel's cookie
> state was set to 'completed', and if not, it would enter the critical
> section. However, in that time frame, the jz4780_dma_chan_irq() function
> was able to set the cookie to 'completed', and clear the jzchan->vchan
> pointer, which was deferenced in the critical section of the first
> function.
> 
> Fix this race by checking the channel's cookie state after entering the
> critical function and not before.

Applied, thanks

-- 
~Vinod

Re: [PATCH] test_power: add missing newlines when printing parameters by sysfs

2020-10-04 Thread Joe Perches

On Mon, 2020-10-05 at 01:30 +, Harley A.W. Lorenzo wrote:
> Here is the updated patch using sprintf, diffing from the original patch by 
> Xiongfeng Wang.
> 
> [PATCH] test_power: revise parameter printing to use sprintf
> 
> Signed-off-by: Harley A.W. Lorenzo 
> Suggested-by: Joe Perches 

I did not suggest this.

> diff --git a/drivers/power/supply/test_power.c 
> b/drivers/power/supply/test_power.c
[]
> @@ -352,8 +352,8 @@ static int param_set_ac_online(const char *key, const 
> struct kernel_param *kp)
> 
>  static int param_get_ac_online(char *buffer, const struct kernel_param *kp)
>  {.
> - strcpy(buffer, map_get_key(map_ac_online, ac_online, "unknown"));
> - strcat(buffer, "\n");
> + char const *out = map_get_key(map_ac_online, ac_online, "unknown");
> + sprintf(buffer, "%s\n", out);
>   return strlen(buffer);
>  }

No temporary is necessary nor is strlen as
that's the same as the return from sprintf.

All of these should be similar to:

static int param_get_ac_online(char *buffer, const struct kernel_param *kp)
{
return sprintf(buffer, "%s\n",
   map_get_key(map_ac_online, ac_online, "unknown"));
}

Re: [PATCH net-next v2 0/2] net: Constify struct genl_small_ops

2020-10-04 Thread David Miller

From: Rikard Falkeborn 
Date: Mon,  5 Oct 2020 01:44:15 +0200

> Make a couple of static struct genl_small_ops const to allow the compiler
> to put them in read-only memory. Patches are independent.
> 
> v2: Rebase on net-next, genl_ops -> genl_small_ops

Applied, thank you.

[PATCH v9 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS
Asoc. It includes machine driver, cpu driver, platform driver updates for 
HDMI path support, device tree documention, lpass variant structure 
optimization and configuration changes.
These patches depends on the DP patch series
https://patchwork.kernel.org/project/dri-devel/list/?series=332029
https://lore.kernel.org/patchwork/project/lkml/list/?series=464856

changes since V8:
-- Removed extra structure wrapper for reg map field memebrs
-- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true
   and others as false.
changes since V7:
-- Fixed typo errors
-- Created Separate patch for buffer size change 
changes since V6:
-- Removed compile time define flag, which used for enabling
 HDMI code, based on corresponding config param is included.
-- Updated reg map alloc API with reg map bulk API.
-- Removed unnecessary line splits
changes since V5:
-- Removed unused struct regmap *map in 
lpass_platform_alloc_hdmidmactl_fields.
-- DMA alloc and free API signature change in lpass-apq8016.c, 
lpass-ipq806x.c 
-- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro
Changes Since v4:
-- Updated with single compatible node for both I2S and HDMI.
Changes Since v3:
-- Removed id in lpass variant structure and used snd_soc_dai_driver id.
Changes Since v2:
-- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c 
increased.
Changes Since v1:
-- Commit messages are updated
-- Addressed Rob Herring review comments

V Sujith Kumar Reddy (8):
  ASoC: Add sc7180-lpass binding header hdmi define
  ASoC: dt-bindings: Add dt binding for lpass hdmi
  Asoc:qcom:lpass-cpu:Update dts property read API
  Asoc: qcom: lpass:Update lpaif_dmactl members order
  ASoC: qcom: Add support for lpass hdmi driver
  Asoc: qcom: lpass-platform : Increase buffer size
  ASoC: qcom: sc7180: Add support for audio over DP

 .../devicetree/bindings/sound/qcom,lpass-cpu.yaml  |  74 +++-
 include/dt-bindings/sound/sc7180-lpass.h   |   1 +
 sound/soc/qcom/Kconfig |   5 +
 sound/soc/qcom/Makefile|   2 +
 sound/soc/qcom/lpass-apq8016.c |   4 +-
 sound/soc/qcom/lpass-cpu.c |  53 ++-
 sound/soc/qcom/lpass-hdmi.c| 469 +
 sound/soc/qcom/lpass-hdmi.h| 122 ++
 sound/soc/qcom/lpass-ipq806x.c |   4 +-
 sound/soc/qcom/lpass-lpaif-reg.h   |  52 ++-
 sound/soc/qcom/lpass-platform.c| 403 ++
 sound/soc/qcom/lpass-sc7180.c  | 116 -
 sound/soc/qcom/lpass.h | 119 +-
 13 files changed, 1279 insertions(+), 145 deletions(-)
 create mode 100644 sound/soc/qcom/lpass-hdmi.c
 create mode 100644 sound/soc/qcom/lpass-hdmi.h

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v9 7/7] ASoC: qcom: sc7180: Add support for audio over DP

From: V Sujith Kumar Reddy 

Add support for audio playback over DP in lpass
sc7180 platform driver. Update lpass_variant
structure for hdmi data configuaration.

Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/lpass-sc7180.c | 116 +-
 1 file changed, 102 insertions(+), 14 deletions(-)

diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index a8a3d8f..c6292f9e 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -60,38 +60,65 @@ static struct snd_soc_dai_driver 
sc7180_lpass_cpu_dai_driver[] = {
.probe  = _qcom_lpass_cpu_dai_probe,
.ops= _qcom_lpass_cpu_dai_ops,
},
+   [LPASS_DP_RX] = {
+   .id = LPASS_DP_RX,
+   .name = "Hdmi",
+   .playback = {
+   .stream_name = "Hdmi Playback",
+   .formats= SNDRV_PCM_FMTBIT_S24,
+   .rates = SNDRV_PCM_RATE_48000,
+   .rate_min   = 48000,
+   .rate_max   = 48000,
+   .channels_min   = 2,
+   .channels_max   = 2,
+   },
+   .ops= _qcom_lpass_hdmi_dai_ops,
+   },
 };
 
 static int sc7180_lpass_alloc_dma_channel(struct lpass_data *drvdata,
-  int direction)
+  int direction, unsigned int dai_id)
 {
struct lpass_variant *v = drvdata->variant;
int chan = 0;
 
-   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
-   chan = find_first_zero_bit(>dma_ch_bit_map,
-   v->rdma_channels);
+   if (dai_id == LPASS_DP_RX) {
+   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+   chan = 
find_first_zero_bit(>hdmi_dma_ch_bit_map,
+   v->hdmi_rdma_channels);
+
+   if (chan >= v->hdmi_rdma_channels)
+   return -EBUSY;
+   }
+   set_bit(chan, >hdmi_dma_ch_bit_map);
+   } else {
+   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+   chan = find_first_zero_bit(>dma_ch_bit_map,
+   v->rdma_channels);
 
if (chan >= v->rdma_channels)
return -EBUSY;
-   } else {
-   chan = find_next_zero_bit(>dma_ch_bit_map,
+   } else {
+   chan = find_next_zero_bit(>dma_ch_bit_map,
v->wrdma_channel_start +
v->wrdma_channels,
v->wrdma_channel_start);
 
-   if (chan >=  v->wrdma_channel_start + v->wrdma_channels)
-   return -EBUSY;
-   }
-
-   set_bit(chan, >dma_ch_bit_map);
+   if (chan >=  v->wrdma_channel_start + v->wrdma_channels)
+   return -EBUSY;
+   }
 
+   set_bit(chan, >dma_ch_bit_map);
+   }
return chan;
 }
 
-static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan, 
unsigned int dai_id)
 {
-   clear_bit(chan, >dma_ch_bit_map);
+   if (dai_id == LPASS_DP_RX)
+   clear_bit(chan, >hdmi_dma_ch_bit_map);
+   else
+   clear_bit(chan, >dma_ch_bit_map);
 
return 0;
 }
@@ -144,6 +171,9 @@ static struct lpass_variant sc7180_data = {
.rdma_reg_base  = 0xC000,
.rdma_reg_stride= 0x1000,
.rdma_channels  = 5,
+   .hdmi_rdma_reg_base = 0x64000,
+   .hdmi_rdma_reg_stride   = 0x1000,
+   .hdmi_rdma_channels = 4,
.dmactl_audif_start = 1,
.wrdma_reg_base = 0x18000,
.wrdma_reg_stride   = 0x1000,
@@ -163,7 +193,7 @@ static struct lpass_variant sc7180_data = {
.rdma_dyncclk   = REG_FIELD_ID(0xC000, 21, 21, 5, 0x1000),
.rdma_bursten   = REG_FIELD_ID(0xC000, 20, 20, 5, 0x1000),
.rdma_wpscnt= REG_FIELD_ID(0xC000, 16, 19, 5, 0x1000),
-   .rdma_intf  = REG_FIELD_ID(0xC000, 12, 15, 5, 0x1000),
+   .rdma_intf  = REG_FIELD_ID(0xC000, 12, 15, 5, 
0x1000),
.rdma_fifowm= REG_FIELD_ID(0xC000, 1, 5, 5, 0x1000),
.rdma_enable= REG_FIELD_ID(0xC000, 0, 0, 5, 0x1000),
 
@@ -174,6 +204,64 @@ static struct lpass_variant sc7180_data = {
.wrdma_fifowm   = REG_FIELD_ID(0x18000, 1, 5, 4, 0x1000),
.wrdma_enable   = REG_FIELD_ID(0x18000, 0, 0, 4, 0x1000),
 
+   .hdmi_tx_ctl_addr   = 0x1000,
+   .hdmi_legacy_addr   =

[PATCH v9 2/7] ASoC: dt-bindings: Add dt binding for lpass hdmi

From: V Sujith Kumar Reddy 

Adds bindings for lpass hdmi interface
which can support audio path over dp.

Signed-off-by: V Sujith Kumar Reddy 
Reviewed-by: Rob Herring 
Signed-off-by: Srinivasa Rao 
---
 .../devicetree/bindings/sound/qcom,lpass-cpu.yaml  | 74 +++---
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml 
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index 09c9bd2..f6f9fb4 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -24,9 +24,10 @@ properties:
   - qcom,sc7180-lpass-cpu
 
   reg:
-maxItems: 1
+maxItems: 2
 description: LPAIF core registers
-
+  reg-names:
+ maxItems: 2
   clocks:
 minItems: 3
 maxItems: 6
@@ -36,15 +37,16 @@ properties:
 maxItems: 6
 
   interrupts:
-maxItems: 1
+maxItems: 2
 description: LPAIF DMA buffer interrupt
-
+  interrupt-names:
+maxItems: 2
   qcom,adsp:
 $ref: /schemas/types.yaml#/definitions/phandle
 description: Phandle for the audio DSP node
 
   iommus:
-maxItems: 1
+maxItems: 2
 description: Phandle to apps_smmu node with sid mask
 
   power-domains:
@@ -60,10 +62,12 @@ properties:
 const: 0
 
 patternProperties:
-  "(^mi2s-[0-9a-f]$|mi2s)":
+  "^dai-link@[0-9a-f]$":
 type: object
-description: Required properties for each DAI
-
+description: |
+  LPASS CPU dai node for each I2S device. Bindings of each node
+  depends on the specific driver providing the functionality and
+  properties.
 properties:
   reg:
 maxItems: 1
@@ -85,9 +89,11 @@ patternProperties:
 required:
   - compatible
   - reg
+  - reg-names
   - clocks
   - clock-names
   - interrupts
+  - interrupt-names
   - '#sound-dai-cells'
 
 additionalProperties: false
@@ -134,13 +140,32 @@ allOf:
 then:
   properties:
 clock-names:
-  items:
-- const: pcnoc-sway-clk
-- const: audio-core
-- const: mclk0
-- const: pcnoc-mport-clk
-- const: mi2s-bit-clk0
-- const: mi2s-bit-clk1
+  oneOf:
+   - items:   #for I2S
+  - const: pcnoc-sway-clk
+  - const: audio-core
+  - const: mclk0
+  - const: pcnoc-mport-clk
+  - const: mi2s-bit-clk0
+  - const: mi2s-bit-clk1
+   - items:   #for HDMI
+  - const: pcnoc-sway-clk
+  - const: audio-core
+  - const: pcnoc-mport-clk
+reg-names:
+  anyOf:
+- items:   #for I2S
+  - const: lpass-lpaif
+- items:   #for I2S and HDMI
+  - const: lpass-hdmiif
+  - const: lpass-lpaif
+interrupt-names:
+  anyOf:
+- items:   #for I2S
+  - const: lpass-irq-lpaif
+- items:   #for I2S and HDMI
+  - const: lpass-irq-lpaif
+  - const: lpass-irq-hdmi
   required:
 - iommus
 - power-domains
@@ -152,12 +177,15 @@ examples:
 soc {
 #address-cells = <2>;
 #size-cells = <2>;
-lpass@62f0 {
+lpass@62d8 {
 compatible = "qcom,sc7180-lpass-cpu";
 
-reg = <0 0x62f0  0 0x29000>;
-
-iommus = <_smmu 0x1020 0>;
+reg = <0 0x62d87000 0 0x68000>,
+  <0 0x62f0 0 0x29000>;
+reg-names = "lpass-hdmiif",
+"lpass-lpaif";
+iommus = <_smmu 0x1020 0>,
+ <_smmu 0x1032 0>;
 power-domains = <_hm 0>;
 
 clocks = < 131>,
@@ -171,14 +199,16 @@ examples:
   "mclk0", "pcnoc-mport-clk",
   "mi2s-bit-clk0", "mi2s-bit-clk1";
 
-interrupts = <0 160 1>;
-
+interrupts = <0 160 1>,
+ <0 268 1>;
+interrupt-names = "lpass-irq-lpaif",
+  "lpass-irq-hdmi";
 #sound-dai-cells = <1>;
 
 #address-cells = <1>;
 #size-cells = <0>;
 /* Optional to set different MI2S SD lines */
-mi2s-primary@0 {
+dai-link@0 {
 reg = ;
 qcom,playback-sd-lines = <1>;
 qcom,capture-sd-lines = <0>;
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v9 5/7] ASoC: qcom: Add support for lpass hdmi driver

From: V Sujith Kumar Reddy 

Upadate lpass cpu and platform driver to support audio over dp.
Also add lpass-hdmi.c and lpass-hdmi.h.

Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/Kconfig   |   5 +
 sound/soc/qcom/Makefile  |   2 +
 sound/soc/qcom/lpass-apq8016.c   |   4 +-
 sound/soc/qcom/lpass-cpu.c   |  51 -
 sound/soc/qcom/lpass-hdmi.c  | 469 +++
 sound/soc/qcom/lpass-hdmi.h  | 122 ++
 sound/soc/qcom/lpass-ipq806x.c   |   4 +-
 sound/soc/qcom/lpass-lpaif-reg.h |  52 -
 sound/soc/qcom/lpass-platform.c  | 391 ++--
 sound/soc/qcom/lpass.h   | 113 +-
 10 files changed, 1114 insertions(+), 99 deletions(-)
 create mode 100644 sound/soc/qcom/lpass-hdmi.c
 create mode 100644 sound/soc/qcom/lpass-hdmi.h

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index a7ef626..28e775f 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -12,6 +12,10 @@ config SND_SOC_LPASS_CPU
tristate
select REGMAP_MMIO
 
+config SND_SOC_LPASS_HDMI
+   tristate
+   select REGMAP_MMIO
+
 config SND_SOC_LPASS_PLATFORM
tristate
select REGMAP_MMIO
@@ -30,6 +34,7 @@ config SND_SOC_LPASS_SC7180
tristate
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
+   select SND_SOC_LPASS_HDMI
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 7972c94..0bd90d7 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -1,12 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0
 # Platform
 snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-hdmi-objs := lpass-hdmi.o
 snd-soc-lpass-platform-objs := lpass-platform.o
 snd-soc-lpass-ipq806x-objs := lpass-ipq806x.o
 snd-soc-lpass-apq8016-objs := lpass-apq8016.o
 snd-soc-lpass-sc7180-objs := lpass-sc7180.o
 
 obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_HDMI) += snd-soc-lpass-hdmi.o
 obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
 obj-$(CONFIG_SND_SOC_LPASS_IPQ806X) += snd-soc-lpass-ipq806x.o
 obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 5c8ae22..0aedb3a 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -125,7 +125,7 @@ static struct snd_soc_dai_driver 
apq8016_lpass_cpu_dai_driver[] = {
 };
 
 static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
-  int direction)
+  int direction, unsigned int dai_id)
 {
struct lpass_variant *v = drvdata->variant;
int chan = 0;
@@ -151,7 +151,7 @@ static int apq8016_lpass_alloc_dma_channel(struct 
lpass_data *drvdata,
return chan;
 }
 
-static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int 
chan, unsigned int dai_id)
 {
clear_bit(chan, >dma_ch_bit_map);
 
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 12950d2..b6d243e 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -535,13 +535,17 @@ static void of_lpass_cpu_parse_dai_data(struct device 
*dev,
dev_err(dev, "valid dai id not found: %d\n", ret);
continue;
}
-
-   data->mi2s_playback_sd_mode[id] =
-   of_lpass_cpu_parse_sd_lines(dev, node,
-   "qcom,playback-sd-lines");
-   data->mi2s_capture_sd_mode[id] =
-   of_lpass_cpu_parse_sd_lines(dev, node,
+   if (id == LPASS_DP_RX) {
+   data->hdmi_port_enable = 1;
+   dev_err(dev, "HDMI Port is enabled: %d\n", id);
+   } else {
+   data->mi2s_playback_sd_mode[id] =
+   of_lpass_cpu_parse_sd_lines(dev, node,
+   
"qcom,playback-sd-lines");
+   data->mi2s_capture_sd_mode[id] =
+   of_lpass_cpu_parse_sd_lines(dev, node,
"qcom,capture-sd-lines");
+   }
}
 }
 
@@ -596,6 +600,27 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
return PTR_ERR(drvdata->lpaif_map);
}
 
+   if (drvdata->hdmi_port_enable) {
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
"lpass-hdmiif");
+
+   drvdata->hdmiif = devm_ioremap_resource(dev, res);
+   if (IS_ERR((void const __force *)drvdata->hdmiif)) {
+

[PATCH v9 6/7] Asoc: qcom: lpass-platform : Increase buffer size

From: V Sujith Kumar Reddy 

Increase buffer size to support audio over DP.

Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao Mandadapu 
---
 sound/soc/qcom/lpass-platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index a5ab5f1..92ccedb 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -23,7 +23,7 @@ struct lpass_pcm_data {
int i2s_port;
 };
 
-#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_BUFFER_SIZE (24 *  2 * 1024)
 #define LPASS_PLATFORM_PERIODS 2
 
 static const struct snd_pcm_hardware lpass_platform_pcm_hardware = {
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v9 4/7] Asoc: qcom: lpass:Update lpaif_dmactl members order

From: V Sujith Kumar Reddy 

Update the lpaif_dmactl struct members order to match
HDMI reg map members sequence. Separate Interface reg map
as it is used for I2S control but not for HDMI control,
to make use of bulk API, which makes code more readable.

Signed-off-by: V Sujith Kumar Reddy 
Reviewed-by: Srinivas Kandagatla 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/lpass-platform.c | 8 
 sound/soc/qcom/lpass.h  | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index e7cf4e5..db0d959 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -71,13 +71,13 @@ static int lpass_platform_alloc_dmactl_fields(struct device 
*dev,
rd_dmactl = drvdata->rd_dmactl;
wr_dmactl = drvdata->wr_dmactl;
 
-   rval = devm_regmap_field_bulk_alloc(dev, map, _dmactl->bursten,
-   >rdma_bursten, 6);
+   rval = devm_regmap_field_bulk_alloc(dev, map, _dmactl->intf,
+   >rdma_intf, 6);
if (rval)
return rval;
 
-   return devm_regmap_field_bulk_alloc(dev, map, _dmactl->bursten,
-   >wrdma_bursten, 6);
+   return devm_regmap_field_bulk_alloc(dev, map, _dmactl->intf,
+   >wrdma_intf, 6);
 }
 
 static int lpass_platform_pcmops_open(struct snd_soc_component *component,
diff --git a/sound/soc/qcom/lpass.h b/sound/soc/qcom/lpass.h
index 51c9991..7089d4c 100644
--- a/sound/soc/qcom/lpass.h
+++ b/sound/soc/qcom/lpass.h
@@ -31,9 +31,9 @@ struct lpaif_i2sctl {
 
 
 struct lpaif_dmactl {
+   struct regmap_field *intf;
struct regmap_field *bursten;
struct regmap_field *wpscnt;
-   struct regmap_field *intf;
struct regmap_field *fifowm;
struct regmap_field *enable;
struct regmap_field *dyncclk;
@@ -110,17 +110,17 @@ struct lpass_variant {
struct reg_field bitwidth;
 
/* RD_DMA Register fields */
+   struct reg_field rdma_intf;
struct reg_field rdma_bursten;
struct reg_field rdma_wpscnt;
-   struct reg_field rdma_intf;
struct reg_field rdma_fifowm;
struct reg_field rdma_enable;
struct reg_field rdma_dyncclk;
 
/* WR_DMA Register fields */
+   struct reg_field wrdma_intf;
struct reg_field wrdma_bursten;
struct reg_field wrdma_wpscnt;
-   struct reg_field wrdma_intf;
struct reg_field wrdma_fifowm;
struct reg_field wrdma_enable;
struct reg_field wrdma_dyncclk;
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v9 1/7] ASoC: Add sc7180-lpass binding header hdmi define

From: V Sujith Kumar Reddy 

Add header defining hdmi dai-id for SC7180 lpass soc
in dt bindings.

Signed-off-by: V Sujith Kumar Reddy 
Acked-by: Rob Herring 
Signed-off-by: Srinivasa Rao 
---
 include/dt-bindings/sound/sc7180-lpass.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/sound/sc7180-lpass.h 
b/include/dt-bindings/sound/sc7180-lpass.h
index 7d988f6..56ecaaf 100644
--- a/include/dt-bindings/sound/sc7180-lpass.h
+++ b/include/dt-bindings/sound/sc7180-lpass.h
@@ -4,6 +4,7 @@
 
 #define MI2S_PRIMARY   0
 #define MI2S_SECONDARY 1
+#define LPASS_DP_RX2
 
 #define LPASS_MCLK00
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v9 3/7] Asoc:qcom:lpass-cpu:Update dts property read API

From: V Sujith Kumar Reddy 

Update dts property read API call with platform get property
by name, as it make code more readable and avoid conflicts
when array of properties to be used.

Signed-off-by: V Sujith Kumar Reddy 
Reviewed-by: Srinivas Kandagatla 
Signed-off-by: Srinivasa Rao 
---
 sound/soc/qcom/lpass-cpu.c  | 2 +-
 sound/soc/qcom/lpass-platform.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 0718a0f..12950d2 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -575,7 +575,7 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
 
of_lpass_cpu_parse_dai_data(dev, drvdata);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpass-lpaif");
 
drvdata->lpaif = devm_ioremap_resource(dev, res);
if (IS_ERR((void const __force *)drvdata->lpaif)) {
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 7ac2629..e7cf4e5 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -621,7 +621,7 @@ int asoc_qcom_lpass_platform_register(struct 
platform_device *pdev)
struct lpass_variant *v = drvdata->variant;
int ret;
 
-   drvdata->lpaif_irq = platform_get_irq(pdev, 0);
+   drvdata->lpaif_irq = platform_get_irq_byname(pdev, "lpass-irq-lpaif");
if (drvdata->lpaif_irq < 0)
return -ENODEV;
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] Input: stmpe: Add axis inversion and swapping capability

On Tue, Sep 22, 2020 at 11:39:03AM +0200, Stefan Riedmueller wrote:
> Make use of generic touchscreen_properties structure to add axis
> inversion and swapping capabilities. It's configurable via devicetree
> properties:
>   touchscreen-inverted-x
>   touchscreen-inverted-y
>   touchscreen-swapped-x-y
> 
> Signed-off-by: Stefan Riedmueller 

Applied, thank you.

-- 
Dmitry

Re: INFO: task can't die in request_wait_answer

2020-10-04 Thread syzbot

syzbot has found a reproducer for the following issue on:

HEAD commit:2172e358 Add linux-next specific files for 20201002
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1596c7a390
kernel config:  https://syzkaller.appspot.com/x/.config?x=70698f530a7e856f
dashboard link: https://syzkaller.appspot.com/bug?extid=ea48ca29949b1820e745
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=16e1c8e790
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10a166af90

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ea48ca29949b1820e...@syzkaller.appspotmail.com

INFO: task syz-executor220:7040 can't die for more than 143 seconds.
task:syz-executor220 state:D stack:28792 pid: 7040 ppid:  6888 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:3772 [inline]
 __schedule+0xec5/0x2200 kernel/sched/core.c:4521
 schedule+0xcf/0x270 kernel/sched/core.c:4599
 request_wait_answer+0x505/0x7f0 fs/fuse/dev.c:402
 __fuse_request_send fs/fuse/dev.c:421 [inline]
 fuse_simple_request+0x526/0xc10 fs/fuse/dev.c:503
 fuse_do_getattr+0x226/0xc40 fs/fuse/dir.c:952
 fuse_update_get_attr fs/fuse/dir.c:988 [inline]
 fuse_getattr+0x37f/0x430 fs/fuse/dir.c:1723
 vfs_getattr_nosec+0x246/0x2e0 fs/stat.c:87
 vfs_getattr fs/stat.c:124 [inline]
 vfs_statx+0x18d/0x390 fs/stat.c:189
 vfs_fstatat fs/stat.c:207 [inline]
 vfs_stat include/linux/fs.h:3148 [inline]
 __do_sys_newstat+0x91/0x110 fs/stat.c:349
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446c99
Code: Bad RIP value.
RSP: 002b:7fafe2cfedb8 EFLAGS: 0246 ORIG_RAX: 0004
RAX: ffda RBX: 006dbc28 RCX: 00446c99
RDX: 00446c99 RSI:  RDI: 24c0
RBP: 006dbc20 R08:  R09: 
R10:  R11: 0246 R12: 006dbc2c
R13: 7fff48a82c7f R14: 7fafe2cff9c0 R15: 
INFO: task syz-executor220:7040 blocked for more than 143 seconds.
  Not tainted 5.9.0-rc7-next-20201002-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor220 state:D stack:28792 pid: 7040 ppid:  6888 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:3772 [inline]
 __schedule+0xec5/0x2200 kernel/sched/core.c:4521
 schedule+0xcf/0x270 kernel/sched/core.c:4599
 request_wait_answer+0x505/0x7f0 fs/fuse/dev.c:402
 __fuse_request_send fs/fuse/dev.c:421 [inline]
 fuse_simple_request+0x526/0xc10 fs/fuse/dev.c:503
 fuse_do_getattr+0x226/0xc40 fs/fuse/dir.c:952
 fuse_update_get_attr fs/fuse/dir.c:988 [inline]
 fuse_getattr+0x37f/0x430 fs/fuse/dir.c:1723
 vfs_getattr_nosec+0x246/0x2e0 fs/stat.c:87
 vfs_getattr fs/stat.c:124 [inline]
 vfs_statx+0x18d/0x390 fs/stat.c:189
 vfs_fstatat fs/stat.c:207 [inline]
 vfs_stat include/linux/fs.h:3148 [inline]
 __do_sys_newstat+0x91/0x110 fs/stat.c:349
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446c99
Code: Bad RIP value.
RSP: 002b:7fafe2cfedb8 EFLAGS: 0246 ORIG_RAX: 0004
RAX: ffda RBX: 006dbc28 RCX: 00446c99
RDX: 00446c99 RSI:  RDI: 24c0
RBP: 006dbc20 R08:  R09: 
R10:  R11: 0246 R12: 006dbc2c
R13: 7fff48a82c7f R14: 7fafe2cff9c0 R15: 
INFO: task syz-executor220:7044 can't die for more than 143 seconds.
task:syz-executor220 state:D stack:28752 pid: 7044 ppid:  6887 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:3772 [inline]
 __schedule+0xec5/0x2200 kernel/sched/core.c:4521
 schedule+0xcf/0x270 kernel/sched/core.c:4599
 request_wait_answer+0x505/0x7f0 fs/fuse/dev.c:402
 __fuse_request_send fs/fuse/dev.c:421 [inline]
 fuse_simple_request+0x526/0xc10 fs/fuse/dev.c:503
 fuse_do_getattr+0x226/0xc40 fs/fuse/dir.c:952
 fuse_update_get_attr fs/fuse/dir.c:988 [inline]
 fuse_getattr+0x37f/0x430 fs/fuse/dir.c:1723
 vfs_getattr_nosec+0x246/0x2e0 fs/stat.c:87
 vfs_getattr fs/stat.c:124 [inline]
 vfs_statx+0x18d/0x390 fs/stat.c:189
 vfs_fstatat fs/stat.c:207 [inline]
 vfs_stat include/linux/fs.h:3148 [inline]
 __do_sys_newstat+0x91/0x110 fs/stat.c:349
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446c99
Code: Bad RIP value.
RSP: 002b:7fafe2cfedb8 EFLAGS: 0246 ORIG_RAX: 0004
RAX: ffda RBX: 006dbc28 RCX: 00446c99
RDX: 00446c99 RSI:  RDI: 24c0
RBP: 006dbc20 R08:  R09: 
R10:  R11: 0246 R12: 006dbc2c
R13: 7fff48a82c7f R14: 7fafe2cff9c0 R15: 
INFO: task syz-executor220:7044

Re: [PATCH v3] Bluetooth: Check for encryption key size on connect

2020-10-04 Thread Archie Pusaka

[Re-sending in plain text]
Hi Marcel,

I tried Alex's patch and it works for me as well.

Thanks,
Archie


On Thu, 1 Oct 2020 at 15:14, Marcel Holtmann  wrote:
>
> Hi Archie,
>
> > When receiving connection, we only check whether the link has been
> > encrypted, but not the encryption key size of the link.
> >
> > This patch adds check for encryption key size, and reject L2CAP
> > connection which size is below the specified threshold (default 7)
> > with security block.
> >
> > Here is some btmon trace.
> > @ MGMT Event: New Link Key (0x0009) plen 26{0x0001} [hci0] 
> > 5.847722
> >Store hint: No (0x00)
> >BR/EDR Address: 38:00:25:F7:F1:B0 (OUI 38-00-25)
> >Key type: Unauthenticated Combination key from P-192 (0x04)
> >Link key: 7bf2f68c81305d63a6b0ee2c5a7a34bc
> >PIN length: 0
> >> HCI Event: Encryption Change (0x08) plen 4#29 [hci0] 
> >> 5.871537
> >Status: Success (0x00)
> >Handle: 256
> >Encryption: Enabled with E0 (0x01)
> > < HCI Command: Read Encryp... (0x05|0x0008) plen 2  #30 [hci0] 
> > 5.871609
> >Handle: 256
> >> HCI Event: Command Complete (0x0e) plen 7 #31 [hci0] 
> >> 5.872524
> >  Read Encryption Key Size (0x05|0x0008) ncmd 1
> >Status: Success (0x00)
> >Handle: 256
> >Key size: 3
> >
> > // WITHOUT PATCH //
> >> ACL Data RX: Handle 256 flags 0x02 dlen 12#42 [hci0] 
> >> 5.895023
> >  L2CAP: Connection Request (0x02) ident 3 len 4
> >PSM: 4097 (0x1001)
> >Source CID: 64
> > < ACL Data TX: Handle 256 flags 0x00 dlen 16#43 [hci0] 
> > 5.895213
> >  L2CAP: Connection Response (0x03) ident 3 len 8
> >Destination CID: 64
> >Source CID: 64
> >Result: Connection successful (0x)
> >Status: No further information available (0x)
> >
> > // WITH PATCH //
> >> ACL Data RX: Handle 256 flags 0x02 dlen 12#42 [hci0] 
> >> 4.887024
> >  L2CAP: Connection Request (0x02) ident 3 len 4
> >PSM: 4097 (0x1001)
> >Source CID: 64
> > < ACL Data TX: Handle 256 flags 0x00 dlen 16#43 [hci0] 
> > 4.887127
> >  L2CAP: Connection Response (0x03) ident 3 len 8
> >Destination CID: 0
> >Source CID: 64
> >Result: Connection refused - security block (0x0003)
> >Status: No further information available (0x)
> >
> > Signed-off-by: Archie Pusaka 
> >
> > ---
> >
> > Changes in v3:
> > * Move the check to hci_conn_check_link_mode()
> >
> > Changes in v2:
> > * Add btmon trace to the commit message
> >
> > net/bluetooth/hci_conn.c | 4 
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index 9832f8445d43..89085fac797c 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -1348,6 +1348,10 @@ int hci_conn_check_link_mode(struct hci_conn 
> > *conn)
> >   !test_bit(HCI_CONN_ENCRYPT, >flags))
> >   return 0;
> >
> > + if (test_bit(HCI_CONN_ENCRYPT, >flags) &&
> > + conn->enc_key_size < conn->hdev->min_enc_key_size)
> > + return 0;
> > +
> >   return 1;
> > }
> 
>  I am a bit concerned since we had that check and I on purpose moved 
>  it. See commit 693cd8ce3f88 for the change where I removed and 
>  commit d5bb334a8e17 where I initially added it.
> 
>  Naively adding the check in that location caused a major regression 
>  with Bluetooth 2.0 devices. This makes me a bit reluctant to re-add 
>  it here since I restructured the whole change to check the key size 
>  a different location.
> >>>
> >>> I have tried this patch (both v2 and v3) to connect with a Bluetooth
> >>> 2.0 device, it doesn't have any connection problem.
> >>> I suppose because in the original patch (d5bb334a8e17), there is no
> >>> check for the HCI_CONN_ENCRYPT flag.
> >>
> >> while that might be the case, I am still super careful. Especially 
> >> also in conjunction with the email / patch from Alex trying to add 
> >> just another encryption key size check. If we really need them or even 
> >> both, we have to audit the whole code since I must have clearly missed 
> >> something when adding the KNOB fix.
> >>
>  Now I have to ask, are you running an

[PATCH v2 2/3] KEYS: trusted: Reserve TPM for seal and unseal operations

When TPM 2.0 trusted keys code was moved to the trusted keys subsystem,
the operations were unwrapped from tpm_try_get_ops() and tpm_put_ops(),
which are used to take temporarily the ownership of the TPM chip. The
ownership is only taken inside tpm_send(), but this is not sufficient,
as in the key load TPM2_CC_LOAD, TPM2_CC_UNSEAL and TPM2_FLUSH_CONTEXT
need to be done as a one single atom.

Fix this issue by introducting trusted_tpm_load() and trusted_tpm_new(),
which wrap these operations, and take the TPM chip ownership before
sending anything. Use tpm_transmit_cmd() to send TPM commands instead
of tpm_send(), reverting back to the old behaviour.

Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code")
Reported-by: "James E.J. Bottomley" 
Cc: sta...@vger.kernel.org
Cc: David Howells 
Cc: Mimi Zohar 
Cc: Sumit Garg 
Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h|  4 --
 include/linux/tpm.h   | 16 -
 security/keys/trusted-keys/trusted_tpm1.c | 78 +++
 security/keys/trusted-keys/trusted_tpm2.c |  6 +-
 4 files changed, 71 insertions(+), 33 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 947d1db0a5cc..283f78211c3a 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -164,8 +164,6 @@ extern const struct file_operations tpmrm_fops;
 extern struct idr dev_nums_idr;
 
 ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz);
-ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
-size_t min_rsp_body_length, const char *desc);
 int tpm_get_timeouts(struct tpm_chip *);
 int tpm_auto_startup(struct tpm_chip *chip);
 
@@ -194,8 +192,6 @@ static inline void tpm_msleep(unsigned int delay_msec)
 int tpm_chip_start(struct tpm_chip *chip);
 void tpm_chip_stop(struct tpm_chip *chip);
 struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip);
-__must_check int tpm_try_get_ops(struct tpm_chip *chip);
-void tpm_put_ops(struct tpm_chip *chip);
 
 struct tpm_chip *tpm_chip_alloc(struct device *dev,
const struct tpm_class_ops *ops);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 8f4ff39f51e7..fc0ece0d8d46 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -397,6 +397,10 @@ static inline u32 tpm2_rc_value(u32 rc)
 #if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
 
 extern int tpm_is_tpm2(struct tpm_chip *chip);
+extern __must_check int tpm_try_get_ops(struct tpm_chip *chip);
+extern void tpm_put_ops(struct tpm_chip *chip);
+extern ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+   size_t min_rsp_body_length, const char *desc);
 extern int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digest);
 extern int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
@@ -410,7 +414,17 @@ static inline int tpm_is_tpm2(struct tpm_chip *chip)
 {
return -ENODEV;
 }
-
+static inline int tpm_try_get_ops(struct tpm_chip *chip)
+{
+   return -ENODEV;
+}
+static inline void tpm_put_ops(struct tpm_chip *chip)
+{
+}
+static inline ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf 
*buf,
+  size_t min_rsp_body_length, const char 
*desc)
+{
+}
 static inline int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx,
   struct tpm_digest *digest)
 {
diff --git a/security/keys/trusted-keys/trusted_tpm1.c 
b/security/keys/trusted-keys/trusted_tpm1.c
index c7b1701cdac5..c1dfc32c780b 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -950,6 +950,51 @@ static struct trusted_key_payload 
*trusted_payload_alloc(struct key *key)
return p;
 }
 
+static int trusted_tpm_load(struct tpm_chip *chip,
+   struct trusted_key_payload *payload,
+   struct trusted_key_options *options)
+{
+   int ret;
+
+   if (tpm_is_tpm2(chip)) {
+   ret = tpm_try_get_ops(chip);
+   if (!ret) {
+   ret = tpm2_unseal_trusted(chip, payload, options);
+   tpm_put_ops(chip);
+   }
+   } else {
+   ret = key_unseal(payload, options);
+   }
+
+   return ret;
+}
+
+static int trusted_tpm_new(struct tpm_chip *chip,
+  struct trusted_key_payload *payload,
+  struct trusted_key_options *options)
+{
+   int ret;
+
+   ret = tpm_get_random(chip, payload->key, payload->key_len);
+   if (ret < 0)
+   return ret;
+
+   if (ret != payload->key_len)
+   return -EIO;
+
+   if (tpm_is_tpm2(chip)) {
+   ret = tpm_try_get_ops(chip);
+   if (!ret) {
+   ret = tpm2_seal_trusted(chip, payload, options);
+

[PATCH v2 3/3] KEYS: trusted: Fix migratable=1 failing

Consider the following transcript:

$ keyctl add trusted kmk "new 32 blobauth=helloworld keyhandle=8000 
migratable=1" @u
add_key: Invalid argument

The documentation has the following description:

  migratable=   0|1 indicating permission to reseal to new PCR values,
default 1 (resealing allowed)

The consequence is that "migratable=1" should succeed. Fix this by
allowing this condition to pass instead of return -EINVAL.

[*] Documentation/security/keys/trusted-encrypted.rst

Cc: sta...@vger.kernel.org
Cc: "James E.J. Bottomley" 
Cc: Mimi Zohar 
Cc: David Howells 
Fixes: d00a1c72f7f4 ("keys: add new trusted key-type")
Signed-off-by: Jarkko Sakkinen 
---
 security/keys/trusted-keys/trusted_tpm1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/trusted-keys/trusted_tpm1.c 
b/security/keys/trusted-keys/trusted_tpm1.c
index c1dfc32c780b..20ca18e17437 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -801,7 +801,7 @@ static int getoptions(char *c, struct trusted_key_payload 
*pay,
case Opt_migratable:
if (*args[0].from == '0')
pay->migratable = 0;
-   else
+   else if (*args[0].from != '1')
return -EINVAL;
break;
case Opt_pcrlock:
-- 
2.25.1

[PATCH v2 1/3] KEYS: trusted: Fix incorrect handling of tpm_get_random()

When tpm_get_random() was introduced, it defined the following API for the
return value:

1. A positive value tells how many bytes of random data was generated.
2. A negative value on error.

However, in the call sites the API was used incorrectly, i.e. as it would
only return negative values and otherwise zero. Returning he positive read
counts to the user space does not make any possible sense.

Fix this by returning -EIO when tpm_get_random() returns a positive value.

Fixes: 41ab999c80f1 ("tpm: Move tpm_get_random api into the TPM device driver")
Cc: sta...@vger.kernel.org
Cc: Mimi Zohar 
Cc: "James E.J. Bottomley" 
Cc: David Howells 
Cc: Kent Yoder 
Signed-off-by: Jarkko Sakkinen 
---
 security/keys/trusted-keys/trusted_tpm1.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/security/keys/trusted-keys/trusted_tpm1.c 
b/security/keys/trusted-keys/trusted_tpm1.c
index b9fe02e5f84f..c7b1701cdac5 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -403,9 +403,12 @@ static int osap(struct tpm_buf *tb, struct osapsess *s,
int ret;
 
ret = tpm_get_random(chip, ononce, TPM_NONCE_SIZE);
-   if (ret != TPM_NONCE_SIZE)
+   if (ret < 0)
return ret;
 
+   if (ret != TPM_NONCE_SIZE)
+   return -EIO;
+
tpm_buf_reset(tb, TPM_TAG_RQU_COMMAND, TPM_ORD_OSAP);
tpm_buf_append_u16(tb, type);
tpm_buf_append_u32(tb, handle);
@@ -496,8 +499,12 @@ static int tpm_seal(struct tpm_buf *tb, uint16_t keytype,
goto out;
 
ret = tpm_get_random(chip, td->nonceodd, TPM_NONCE_SIZE);
+   if (ret < 0)
+   return ret;
+
if (ret != TPM_NONCE_SIZE)
-   goto out;
+   return -EIO;
+
ordinal = htonl(TPM_ORD_SEAL);
datsize = htonl(datalen);
pcrsize = htonl(pcrinfosize);
@@ -601,9 +608,12 @@ static int tpm_unseal(struct tpm_buf *tb,
 
ordinal = htonl(TPM_ORD_UNSEAL);
ret = tpm_get_random(chip, nonceodd, TPM_NONCE_SIZE);
+   if (ret < 0)
+   return ret;
+
if (ret != TPM_NONCE_SIZE) {
pr_info("trusted_key: tpm_get_random failed (%d)\n", ret);
-   return ret;
+   return -EIO;
}
ret = TSS_authhmac(authdata1, keyauth, TPM_NONCE_SIZE,
   enonce1, nonceodd, cont, sizeof(uint32_t),
@@ -1013,8 +1023,12 @@ static int trusted_instantiate(struct key *key,
case Opt_new:
key_len = payload->key_len;
ret = tpm_get_random(chip, payload->key, key_len);
+   if (ret < 0)
+   goto out;
+
if (ret != key_len) {
pr_info("trusted_key: key_create failed (%d)\n", ret);
+   ret = -EIO;
goto out;
}
if (tpm2)
-- 
2.25.1

Re: [RFC PATCH v3 2/4] objtool: x86 instruction decoder and big endian cross compiles

2020-10-04 Thread Masami Hiramatsu

On Fri, 2 Oct 2020 10:18:41 -0500
Josh Poimboeuf  wrote:

> On Thu, Oct 01, 2020 at 12:17:25AM +0200, Vasily Gorbik wrote:
> > From: Martin Schwidefsky 
> > 
> > Currently objtool seems to be the only tool from build tools needed
> > which breaks x86 cross compilation on big endian systems. Make the x86
> > instruction decoder of the objtool usable on big endian machines.
> > 
> > Signed-off-by: Martin Schwidefsky 
> > Co-developed-by: Vasily Gorbik 
> > Signed-off-by: Vasily Gorbik 
> 
> Since this changes the decoder (which is shared with the kernel), please
> prefix the subject with "x86/insn:" instead of "objtool".

Thanks for pointing it.

> 
> This patch is a bit ugly, but I don't necessarily have a better idea.
> 
> Masami?

Yeah, agreed. Maybe we can split that part in different header, but
that makes it more ugly. And code itself looks good to me.
(I like insn_field_set() idea :) )

Acked-by: Masami Hiramatsu 

Thank you!


> -- 
> Josh
> 


-- 
Masami Hiramatsu

Re: [PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled

2020-10-04 Thread Alexandre Courbot

On Sun, Oct 4, 2020 at 9:22 PM Alexandre Courbot  wrote:
>
> The addition of MT8183 support added a dependency on the SCP remoteproc
> module. However the initial patch used the "select" Kconfig directive,
> which may result in the SCP module to not be compiled if remoteproc was
> disabled. In such a case, mtk-vcodec would try to link against
> non-existent SCP symbols. "select" was clearly misused here as explained
> in kconfig-language.txt.
>
> Replace this by a "depends" directive on at least one of the VPU and
> SCP modules, to allow the driver to be compiled as long as one of these
> is enabled, and adapt the code to support this new scenario.
>
> Also adapt the Kconfig text to explain the extra requirements for MT8173
> and MT8183.
>
> Reported-by: Sakari Ailus 
> Signed-off-by: Alexandre Courbot 
> Acked-by: Randy Dunlap  # build-tested

Forgot to send the changelog, so here it is:

Changes since v1:
* Added Acked-by from Randy.
* Fixed typo in Kconfig description.

> ---
>  drivers/media/platform/Kconfig| 10 +--
>  .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 72 ---
>  2 files changed, 54 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index a3cb104956d5..98eb62e49ec2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -253,14 +253,16 @@ config VIDEO_MEDIATEK_VCODEC
> depends on MTK_IOMMU || COMPILE_TEST
> depends on VIDEO_DEV && VIDEO_V4L2
> depends on ARCH_MEDIATEK || COMPILE_TEST
> +   depends on VIDEO_MEDIATEK_VPU || MTK_SCP
> select VIDEOBUF2_DMA_CONTIG
> select V4L2_MEM2MEM_DEV
> -   select VIDEO_MEDIATEK_VPU
> -   select MTK_SCP
> help
> Mediatek video codec driver provides HW capability to
> -   encode and decode in a range of video formats
> -   This driver rely on VPU driver to communicate with VPU.
> +   encode and decode in a range of video formats on MT8173
> +   and MT8183.
> +
> +   Note that support for MT8173 requires VIDEO_MEDIATEK_VPU to
> +   also be selected. Support for MT8183 depends on MTK_SCP.
>
> To compile this driver as modules, choose M here: the
> modules will be called mtk-vcodec-dec and mtk-vcodec-enc.
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
> index 6c2a2568d844..23a80027a8fb 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
> @@ -13,6 +13,7 @@ struct mtk_vcodec_fw_ops {
> mtk_vcodec_ipi_handler handler, const char *name, 
> void *priv);
> int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
> unsigned int len, unsigned int wait);
> +   void (*release)(struct mtk_vcodec_fw *fw);
>  };
>
>  struct mtk_vcodec_fw {
> @@ -22,6 +23,8 @@ struct mtk_vcodec_fw {
> struct mtk_scp *scp;
>  };
>
> +#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VPU)
> +
>  static int mtk_vcodec_vpu_load_firmware(struct mtk_vcodec_fw *fw)
>  {
> return vpu_load_firmware(fw->pdev);
> @@ -64,6 +67,27 @@ static int mtk_vcodec_vpu_ipi_send(struct mtk_vcodec_fw 
> *fw, int id, void *buf,
> return vpu_ipi_send(fw->pdev, id, buf, len);
>  }
>
> +static void mtk_vcodec_vpu_release(struct mtk_vcodec_fw *fw)
> +{
> +   put_device(>pdev->dev);
> +}
> +
> +static void mtk_vcodec_vpu_reset_handler(void *priv)
> +{
> +   struct mtk_vcodec_dev *dev = priv;
> +   struct mtk_vcodec_ctx *ctx;
> +
> +   mtk_v4l2_err("Watchdog timeout!!");
> +
> +   mutex_lock(>dev_mutex);
> +   list_for_each_entry(ctx, >ctx_list, list) {
> +   ctx->state = MTK_STATE_ABORT;
> +   mtk_v4l2_debug(0, "[%d] Change to state MTK_STATE_ABORT",
> +  ctx->id);
> +   }
> +   mutex_unlock(>dev_mutex);
> +}
> +
>  static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = {
> .load_firmware = mtk_vcodec_vpu_load_firmware,
> .get_vdec_capa = mtk_vcodec_vpu_get_vdec_capa,
> @@ -71,8 +95,13 @@ static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = 
> {
> .map_dm_addr = mtk_vcodec_vpu_map_dm_addr,
> .ipi_register = mtk_vcodec_vpu_set_ipi_register,
> .ipi_send = mtk_vcodec_vpu_ipi_send,
> +   .release = mtk_vcodec_vpu_release,
>  };
>
> +#endif  /* IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VPU) */
> +
> +#if IS_ENABLED(CONFIG_MTK_SCP)
> +
>  static int mtk_vcodec_scp_load_firmware(struct mtk_vcodec_fw *fw)
>  {
> return rproc_boot(scp_get_rproc(fw->scp));
> @@ -107,6 +136,11 @@ static int mtk_vcodec_scp_ipi_send(struct mtk_vcodec_fw 
> *fw, int id, void *buf,
> return scp_ipi_send(fw->scp, id, buf, len, wait);
>  }
>
> +static void mtk_vcodec_scp_release(struct mtk_vcodec_fw *fw)
> +{
> +

[GIT PULL v2] extcon next for v5.10

2020-10-04 Thread Chanwoo Choi

Dear Greg,

This is extcon-next pull request for v5.10. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Changes from v1:
- Fix the wrong commit id of patch.

Best Regards,
Chanwoo Choi


The following changes since commit 856deb866d16e29bd65952e0289066f6078af773:

  Linux 5.9-rc5 (2020-09-13 16:06:00 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-5.10-v2

for you to fetch changes up to dbc888072a976c2a7f74ad2df1ca3e6894f96002:

  extcon: axp288: Use module_platform_driver to simplify the code (2020-09-30 
00:40:06 +0900)



Detailed description for this pull request:

1. Update extcon driver with minor updates:
- Covert the devicetree binding format from txt to yaml and edit
  the bidning document for extcon-ptn5150.c.

- Clean-up the code of extcon-ptn5150.c without any behavior changes.

- Replace HTTP links with HTTPS ones on extcon-palmas.c and extcon-usb-gpio.c.

- Return the proper error code on extcon-max14577/max77693/max77843.c.

- Simplify with dev_err_probe() on extcon-palmas.c.

- Use module_platform_driver to simplify the code on extcon-axp288.c.

2. Update MAINTAINERS
- Add Krzysztof Kozlowski as maintainer of NXP PTN5150A CC/extcon driver
to provide review, feedback and testing.


Alexander A. Klimov (1):
  extcon: Replace HTTP links with HTTPS ones

Andy Shevchenko (1):
  extcon: ptn5150: Deduplicate parts of dev_err_probe()

Krzysztof Kozlowski (20):
  dt-bindings: extcon: ptn5150: Convert binding to DT schema
  dt-bindings: extcon: ptn5150: Use generic "interrupts" property
  dt-bindings: extcon: ptn5150: Make 'vbus-gpios' optional
  extcon: ptn5150: Fix usage of atomic GPIO with sleeping GPIO chips
  extcon: ptn5150: Use generic "interrupts" property
  extcon: ptn5150: Simplify getting vbus-gpios with flags
  extcon: ptn5150: Lower the noisiness of probe
  extcon: ptn5150: Check current USB mode when probing
  extcon: ptn5150: Make 'vbus-gpios' optional
  extcon: ptn5150: Reduce the amount of logs on deferred probe
  extcon: ptn5150: Convert to module_i2c_driver
  extcon: ptn5150: Convert to .probe_new
  MAINTAINERS: Add entry for NXP PTN5150A CC driver
  extcon: max14577: Return error code of extcon_dev_allocate()
  extcon: max77693: Return error code of extcon_dev_allocate()
  extcon: max77843: Return error code of extcon_dev_allocate()
  extcon: max8997: Return error code of extcon_dev_allocate()
  extcon: palmas: Simplify with dev_err_probe()
  extcon: ptn5150: Use defines for registers
  extcon: ptn5150: Do not print error during probe if nothing is attached

Liu Shixin (1):
  extcon: axp288: Use module_platform_driver to simplify the code

Ramuthevar Vadivel Murugan (2):
  extcon: ptn5150: Switch to GENMASK() and BIT() macros
  extcon: ptn5150: Set the VBUS and POLARITY property capability

 .../devicetree/bindings/extcon/extcon-ptn5150.txt  |  27 ---
 .../devicetree/bindings/extcon/extcon-ptn5150.yaml |  60 ++
 MAINTAINERS|   7 +
 drivers/extcon/extcon-axp288.c |  13 +-
 drivers/extcon/extcon-max14577.c   |   2 +-
 drivers/extcon/extcon-max77693.c   |   2 +-
 drivers/extcon/extcon-max77843.c   |   2 +-
 drivers/extcon/extcon-max8997.c|   2 +-
 drivers/extcon/extcon-palmas.c |  20 +-
 drivers/extcon/extcon-ptn5150.c| 226 ++---
 drivers/extcon/extcon-usb-gpio.c   |   2 +-
 11 files changed, 185 insertions(+), 178 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml

Re: [PATCH v4 2/2] hwmon: pmbus: max20730: adjust the vout reading given voltage divider

2020-10-04 Thread Chu Lin

On Sun, Oct 4, 2020 at 8:43 AM Guenter Roeck  wrote:
>
> On Sun, Oct 04, 2020 at 03:14:45AM +, Chu Lin wrote:
> > Problem:
> > We use voltage dividers so that the voltage presented at the voltage
> > sense pins is confusing. We might need to convert these readings to more
> > meaningful readings given the voltage divider.
> >
> > Solution:
> > Read the voltage divider resistance from dts and convert the voltage
> > reading to a more meaningful reading.
> >
> > Testing:
> > max20730 with voltage divider
> >
> > Signed-off-by: Chu Lin 
> > ---
> > ChangeLog v1 -> v2
> >   hwmon: pmbus: max20730:
> >   - Don't do anything to the ret if an error is returned from 
> > pmbus_read_word
> >   - avoid overflow when doing multiplication
> >
> > ChangeLog v2 -> v3
> >   dt-bindings: hwmon: max20730:
> >   - Provide the binding documentation in yaml format
> >   hwmon: pmbus: max20730:
> >   - No change
> >
> > ChangeLog v3 -> v4
> >   dt-bindings: hwmon: max20730:
> >   - Fix highefficiency to high efficiency in description
> >   - Fix presents to present in vout-voltage-divider
> >   - Add additionalProperties: false
> >   hwmon: pmbus: max20730:
> >   - No change
>
> You claim that there have been no changes since v2 of this patch,
> yet you dropped my Reviewed-by: tag. Any reason ?
>
> Guenter
Sorry for the confusion. I thought I can't tag the patch with the Review-by tag.
Just to make sure I do correctly next time, once you tagged a certain
patch in the batch
If there is no change from version to version for this patch, I should
carry the tags when
submitting new revisions. Also, please let me know what is the best
way to fix this revision?
Should I submit a new V5 with the tag attached?

Sincerely,
Chu

>
> >
> >  drivers/hwmon/pmbus/max20730.c | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
> > index a151a2b588a5..fbf2f1e6c969 100644
> > --- a/drivers/hwmon/pmbus/max20730.c
> > +++ b/drivers/hwmon/pmbus/max20730.c
> > @@ -31,6 +31,7 @@ struct max20730_data {
> >   struct pmbus_driver_info info;
> >   struct mutex lock;  /* Used to protect against parallel writes */
> >   u16 mfr_devset1;
> > + u32 vout_voltage_divider[2];
> >  };
> >
> >  #define to_max20730_data(x)  container_of(x, struct max20730_data, info)
> > @@ -114,6 +115,14 @@ static int max20730_read_word_data(struct i2c_client 
> > *client, int page,
> >   max_c = max_current[data->id][(data->mfr_devset1 >> 5) & 0x3];
> >   ret = val_to_direct(max_c, PSC_CURRENT_OUT, info);
> >   break;
> > + case PMBUS_READ_VOUT:
> > + ret = pmbus_read_word_data(client, page, phase, reg);
> > + if (ret > 0 && data->vout_voltage_divider[0] && 
> > data->vout_voltage_divider[1]) {
> > + u64 temp = DIV_ROUND_CLOSEST_ULL((u64)ret * 
> > data->vout_voltage_divider[1],
> > +  
> > data->vout_voltage_divider[0]);
> > + ret = clamp_val(temp, 0, 0x);
> > + }
> > + break;
> >   default:
> >   ret = -ENODATA;
> >   break;
> > @@ -364,6 +373,15 @@ static int max20730_probe(struct i2c_client *client,
> >   data->id = chip_id;
> >   mutex_init(>lock);
> >   memcpy(>info, _info[chip_id], sizeof(data->info));
> > + if (of_property_read_u32_array(client->dev.of_node, 
> > "vout-voltage-divider",
> > +data->vout_voltage_divider,
> > +
> > ARRAY_SIZE(data->vout_voltage_divider)) != 0)
> > + memset(data->vout_voltage_divider, 0, 
> > sizeof(data->vout_voltage_divider));
> > + if (data->vout_voltage_divider[1] < data->vout_voltage_divider[0]) {
> > + dev_err(dev,
> > + "The total resistance of voltage divider is less than 
> > output resistance\n");
> > + return -ENODEV;
> > + }
> >
> >   ret = i2c_smbus_read_word_data(client, MAX20730_MFR_DEVSET1);
> >   if (ret < 0)
> > --
> > 2.28.0.806.g8561365e88-goog
> >

Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver

On Mon, Oct 05, 2020 at 02:30:53AM +0100, Matthew Wilcox wrote:
> > In my Geminilake NUC the maximum size of the address space is 64GB for
> > an enclave, and it is not fixed but can grow in microarchitectures
> > beyond that.
> > 
> > That means that in (*artificial*) worst case the locks would be kept for
> > 64*1024*1024*1024/4096 = 16777216 iterations.
> 
> Oh, there's support for that on the XArray API too.
> 
> xas_lock_irq();
> xas_for_each_marked(, page, end, PAGECACHE_TAG_DIRTY) {
> xas_set_mark(, PAGECACHE_TAG_TOWRITE);
> if (++tagged % XA_CHECK_SCHED)
> continue;
> 
> xas_pause();
> xas_unlock_irq();
> cond_resched();
> xas_lock_irq();
> }
> xas_unlock_irq();

Assuming we can iterate the array without encl->lock, I think this
would translate to:

/*
 * Not taking encl->lock because:
 * 1. page attributes are not written.
 * 2. the only page attribute read is set before it is put to the array
 *and stays constant throughout the enclave life-cycle.
 */
xas_lock();
xas_for_each_marked(, page, idx_end) {
if (++tagged % XA_CHECK_SCHED)
continue;

xas_pause();
xas_unlock();

/*
 * Attributes are not protected by the xa_lock, so I'm assuming
 * that this is the legit place for the check.
 */
if (!page || (~page->vm_max_prot_bits & vm_prot_bits))
return -EACCES;

cond_resched();
xas_lock();
}
xas_unlock();

Obviously, we cannot use this pattern by taking the encl->lock inside
the loop (ABBA and encl->lock is a mutex).

Let's enumerate:

A. sgx_encl_add_page(): uses xa_insert() and xa_erase().
B. sgx_encl_load_page(): uses xa_load().
C. sgx_encl_may_map(): is broken (for the moment).

A and B implicitly the lock and if a page exist at all we only access
a pure constant.

Also, since the open file keeps the instance alive, nobody is going
to pull carpet under our feet.

OK, I've just concluded tha we don't need to take encl->lock in this
case. Great.

/Jarkko

[PATCH v2] vmlinux.lds.h: Keep .ctors.* with .ctors

2020-10-04 Thread Kees Cook

Under some circumstances, the compiler generates .ctors.* sections. This
is seen doing a cross compile of x86_64 from a powerpc64el host:

x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
`kernel/trace/trace_clock.o' being
placed in section `.ctors.65435'
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
`kernel/trace/ftrace.o' being
placed in section `.ctors.65435'
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
`kernel/trace/ring_buffer.o' being
placed in section `.ctors.65435'

Include these orphans along with the regular .ctors section.

Reported-by: Stephen Rothwell 
Tested-by: Stephen Rothwell 
Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
Signed-off-by: Kees Cook 
---
v2: brown paper bag version: fix whitespace for proper backslash alignment
---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 5430febd34be..b83c00c63997 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -684,6 +684,7 @@
 #ifdef CONFIG_CONSTRUCTORS
 #define KERNEL_CTORS() . = ALIGN(8);  \
__ctors_start = .; \
+   KEEP(*(SORT(.ctors.*)))\
KEEP(*(.ctors))\
KEEP(*(SORT(.init_array.*)))   \
KEEP(*(.init_array))   \
-- 
2.25.1

Re: [PATCH 0/2] phy: phy-brcm-sata: Allow configuration SATA AFE TX amplitude

2020-10-04 Thread Florian Fainelli





On 9/30/2020 8:19 PM, Florian Fainelli wrote:

Hi Kishon,

This patch series allows the configuration of the Broadcom SATA PHY TX
amplitude which may be required in order to meet specific tests.


Hi Vinod,

Would you need me to resend these two patches? For some reason 
get_maintainers.pl did not pick up your email. If not, here are the two 
patches from lore:


https://lore.kernel.org/linux-devicetree/20201001031916.411999-2-f.faine...@gmail.com/
https://lore.kernel.org/linux-devicetree/20201001031916.411999-3-f.faine...@gmail.com/

Thanks
--
Florian

[PATCH] vmlinux.lds.h: Keep .ctors.* with .ctors

2020-10-04 Thread Kees Cook

Under some circumstances, the compiler generates .ctors.* sections. This
is seen doing a cross compile of x86_64 from a powerpc64el host:

x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
`kernel/trace/trace_clock.o' being
placed in section `.ctors.65435'
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
`kernel/trace/ftrace.o' being
placed in section `.ctors.65435'
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
`kernel/trace/ring_buffer.o' being
placed in section `.ctors.65435'

Include these orphans along with the regular .ctors section.

Reported-by: Stephen Rothwell 
Link: https://lore.kernel.org/lkml/20200914132249.40c88...@canb.auug.org.au
Tested-by: Stephen Rothwell 
Link: https://lore.kernel.org/lkml/20201004210018.5bbc6...@canb.auug.org.au
Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
Signed-off-by: Kees Cook 
---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 5430febd34be..45c8b362ca45 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -684,6 +684,7 @@
 #ifdef CONFIG_CONSTRUCTORS
 #define KERNEL_CTORS() . = ALIGN(8);  \
__ctors_start = .; \
+   KEEP(*(SORT(.ctors.*)))\
KEEP(*(.ctors))\
KEEP(*(SORT(.init_array.*)))   \
KEEP(*(.init_array))   \
-- 
2.25.1

Re: [PATCH v3 1/2] Input: synaptics-rmi4 - rename f30_data to gpio_data

On Wed, Sep 30, 2020 at 05:41:46PM +0800, Vincent Huang wrote:
> f30_data in rmi_device_platform_data could be also referenced by RMI
> function 3A, so rename it and the structure name to avoid confusion.
> 
> Signed-off-by: Vincent Huang 
> Reviewed-by: Hans de Goede 
> Tested-by: Hans de Goede 

Applied, thank you.

-- 
Dmitry

Re: [PATCH v3 2/2] Input: synaptics-rmi4 - add support for F3A

On Wed, Sep 30, 2020 at 05:41:47PM +0800, Vincent Huang wrote:
> RMI4 F3A supports the touchpad GPIO function, it's designed to
> support more GPIOs and used on newer touchpads. This patch adds
> support of the touchpad buttons.
> 
> Signed-off-by: Vincent Huang 
> Reviewed-by: Hans de Goede 
> Tested-by: Hans de Goede 

Applied, thank you.

-- 
Dmitry

Re: linux-next: build warning after merge of the tip tree

2020-10-04 Thread Kees Cook

On Sun, Oct 04, 2020 at 09:00:18PM +1100, Stephen Rothwell wrote:
> Hi Kees,
> 
> On Sun, 4 Oct 2020 01:27:01 -0700 Kees Cook  wrote:
> >
> > I assume CONFIG_CONSTRUCTORS is enabled for your build (it should be for
> 
> yes, indeed.
> 
> > allmodconfig). Does this patch fix it? (I'm kind of blindly guessing
> > based on my understanding of where this could be coming from...)
> > 
> > 
> > diff --git a/include/asm-generic/vmlinux.lds.h 
> > b/include/asm-generic/vmlinux.lds.h
> > index e1843976754a..22f14956214a 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -701,6 +701,7 @@
> >  #ifdef CONFIG_CONSTRUCTORS
> >  #define KERNEL_CTORS() . = ALIGN(8);  \
> > __ctors_start = .; \
> > +   KEEP(*(SORT(.ctors.*)))\
> > KEEP(*(.ctors))\
> > KEEP(*(SORT(.init_array.*)))   \
> > KEEP(*(.init_array))   \
> 
> And that makes the messages go away.

Okay then! Thanks for testing. :) I'm not sure why the ppc-hosted
compiler generates those. Regardless, I'll send a proper patch...

-- 
Kees Cook

[RESEND,PATCH v4 0/3] Try to release mmap_lock temporarily in smaps_rollup

Recently, we have observed some janky issues caused by unpleasantly long
contention on mmap_lock which is held by smaps_rollup when probing large
processes. To address the problem, we let smaps_rollup detect if anyone
wants to acquire mmap_lock for write attempts. If yes, just release the
lock temporarily to ease the contention.

smaps_rollup is a procfs interface which allows users to summarize the
process's memory usage without the overhead of seq_* calls. Android uses it
to sample the memory usage of various processes to balance its memory pool
sizes. If no one wants to take the lock for write requests, smaps_rollup
with this patch will behave like the original one.

Although there are on-going mmap_lock optimizations like range-based locks,
the lock applied to smaps_rollup would be the coarse one, which is hard to
avoid the occurrence of aforementioned issues. So the detection and
temporary release for write attempts on mmap_lock in smaps_rollup is still
necessary.

Change since v1:
- If current VMA is freed after dropping the lock, it will return
- incomplete result. To fix this issue, refine the code flow as
- suggested by Steve. [1]

Change since v2:
- When getting back the mmap lock, the address where you stopped last
- time could now be in the middle of a vma. Add one more check to handle
- this case as suggested by Michel. [2]

Change since v3:
- last_stopped is easily confused with last_vma_end. Replace it with
- a direct call to smap_gather_stats(vma, , last_vma_end) as
- suggested by Steve. [3]

[1] https://lore.kernel.org/lkml/bf40676e-b14b-44cd-75ce-419c70194...@arm.com/
[2]
https://lore.kernel.org/lkml/cann689ftcsc71cjajs0gpspohgo_hrj+diwsou1wr98ypkt...@mail.gmail.com/
[3] https://lore.kernel.org/lkml/db0d40e2-72f3-09d5-c162-9c49218f1...@arm.com/

Chinwen Chang (3):
mmap locking API: add mmap_lock_is_contended()
mm: smaps*: extend smap_gather_stats to support specified beginning
mm: proc: smaps_rollup: do not stall write attempts on mmap_lock

fs/proc/task_mmu.c| 96 +++
include/linux/mmap_lock.h | 5 ++
2 files changed, 92 insertions(+), 9 deletions(-)

[RESEND, PATCH v4 2/3] mm: smaps*: extend smap_gather_stats to support specified beginning

Extend smap_gather_stats to support indicated beginning address at
which it should start gathering. To achieve the goal, we add a new
parameter @start assigned by the caller and try to refactor it for
simplicity.

If @start is 0, it will use the range of @vma for gathering.

Change since v2:
- This is a new change to make the retry behavior of smaps_rollup
- more complete as suggested by Michel [1]

[1] 
https://lore.kernel.org/lkml/cann689ftcsc71cjajs0gpspohgo_hrj+diwsou1wr98ypkt...@mail.gmail.com/

Change-Id: I8652e0ee6c5e93fb56376a68d71ed6cdd8ac10e8
Signed-off-by: Chinwen Chang 
CC: Michel Lespinasse 
Reviewed-by: Steven Price 
---
 fs/proc/task_mmu.c | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index dbda449..76e623a 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -723,9 +723,21 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long 
hmask,
.pte_hole   = smaps_pte_hole,
 };
 
+/*
+ * Gather mem stats from @vma with the indicated beginning
+ * address @start, and keep them in @mss.
+ *
+ * Use vm_start of @vma as the beginning address if @start is 0.
+ */
 static void smap_gather_stats(struct vm_area_struct *vma,
-struct mem_size_stats *mss)
+   struct mem_size_stats *mss, unsigned long start)
 {
+   const struct mm_walk_ops *ops = _walk_ops;
+
+   /* Invalid start */
+   if (start >= vma->vm_end)
+   return;
+
 #ifdef CONFIG_SHMEM
/* In case of smaps_rollup, reset the value from previous vma */
mss->check_shmem_swap = false;
@@ -742,18 +754,20 @@ static void smap_gather_stats(struct vm_area_struct *vma,
 */
unsigned long shmem_swapped = shmem_swap_usage(vma);
 
-   if (!shmem_swapped || (vma->vm_flags & VM_SHARED) ||
-   !(vma->vm_flags & VM_WRITE)) {
+   if (!start && (!shmem_swapped || (vma->vm_flags & VM_SHARED) ||
+   !(vma->vm_flags & VM_WRITE))) {
mss->swap += shmem_swapped;
} else {
mss->check_shmem_swap = true;
-   walk_page_vma(vma, _shmem_walk_ops, mss);
-   return;
+   ops = _shmem_walk_ops;
}
}
 #endif
/* mmap_lock is held in m_start */
-   walk_page_vma(vma, _walk_ops, mss);
+   if (!start)
+   walk_page_vma(vma, ops, mss);
+   else
+   walk_page_range(vma->vm_mm, start, vma->vm_end, ops, mss);
 }
 
 #define SEQ_PUT_DEC(str, val) \
@@ -805,7 +819,7 @@ static int show_smap(struct seq_file *m, void *v)
 
memset(, 0, sizeof(mss));
 
-   smap_gather_stats(vma, );
+   smap_gather_stats(vma, , 0);
 
show_map_vma(m, vma);
 
@@ -854,7 +868,7 @@ static int show_smaps_rollup(struct seq_file *m, void *v)
hold_task_mempolicy(priv);
 
for (vma = priv->mm->mmap; vma; vma = vma->vm_next) {
-   smap_gather_stats(vma, );
+   smap_gather_stats(vma, , 0);
last_vma_end = vma->vm_end;
}
 
-- 
1.9.1

[RESEND, PATCH v4 1/3] mmap locking API: add mmap_lock_is_contended()

Add new API to query if someone wants to acquire mmap_lock
for write attempts.

Using this instead of rwsem_is_contended makes it more tolerant
of future changes to the lock type.

Change-Id: Idb21478bb0580ba72b9926aba3bbc4b1f75deec2
Signed-off-by: Chinwen Chang 
Reviewed-by: Steven Price 
Acked-by: Michel Lespinasse 
---
 include/linux/mmap_lock.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index 0707671..18e7eae 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -87,4 +87,9 @@ static inline void mmap_assert_write_locked(struct mm_struct 
*mm)
VM_BUG_ON_MM(!rwsem_is_locked(>mmap_lock), mm);
 }
 
+static inline int mmap_lock_is_contended(struct mm_struct *mm)
+{
+   return rwsem_is_contended(>mmap_lock);
+}
+
 #endif /* _LINUX_MMAP_LOCK_H */
-- 
1.9.1

[RESEND, PATCH v4 3/3] mm: proc: smaps_rollup: do not stall write attempts on mmap_lock

smaps_rollup will try to grab mmap_lock and go through the whole vma
list until it finishes the iterating. When encountering large processes,
the mmap_lock will be held for a longer time, which may block other
write requests like mmap and munmap from progressing smoothly.

There are upcoming mmap_lock optimizations like range-based locks, but
the lock applied to smaps_rollup would be the coarse type, which doesn't
avoid the occurrence of unpleasant contention.

To solve aforementioned issue, we add a check which detects whether
anyone wants to grab mmap_lock for write attempts.

Change since v1:
- If current VMA is freed after dropping the lock, it will return
- incomplete result. To fix this issue, refine the code flow as
- suggested by Steve. [1]

Change since v2:
- When getting back the mmap lock, the address where you stopped last
- time could now be in the middle of a vma. Add one more check to handle
- this case as suggested by Michel. [2]

Change since v3:
- last_stopped is easily confused with last_vma_end. Replace it with
- a direct call to smap_gather_stats(vma, , last_vma_end) as
- suggested by Steve. [3]

[1] https://lore.kernel.org/lkml/bf40676e-b14b-44cd-75ce-419c70194...@arm.com/
[2] 
https://lore.kernel.org/lkml/cann689ftcsc71cjajs0gpspohgo_hrj+diwsou1wr98ypkt...@mail.gmail.com/
[3] https://lore.kernel.org/lkml/db0d40e2-72f3-09d5-c162-9c49218f1...@arm.com/

Change-Id: Idcdb6478ccd06a9e5edd4eda9285378e961a6b94
Signed-off-by: Chinwen Chang 
Reviewed-by: Steven Price 
CC: Michel Lespinasse 
---
 fs/proc/task_mmu.c | 66 +-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 76e623a..1a80624 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -867,9 +867,73 @@ static int show_smaps_rollup(struct seq_file *m, void *v)
 
hold_task_mempolicy(priv);
 
-   for (vma = priv->mm->mmap; vma; vma = vma->vm_next) {
+   for (vma = priv->mm->mmap; vma;) {
smap_gather_stats(vma, , 0);
last_vma_end = vma->vm_end;
+
+   /*
+* Release mmap_lock temporarily if someone wants to
+* access it for write request.
+*/
+   if (mmap_lock_is_contended(mm)) {
+   mmap_read_unlock(mm);
+   ret = mmap_read_lock_killable(mm);
+   if (ret) {
+   release_task_mempolicy(priv);
+   goto out_put_mm;
+   }
+
+   /*
+* After dropping the lock, there are four cases to
+* consider. See the following example for explanation.
+*
+*   +--+--+---+
+*   | VMA1 | VMA2 | VMA3  |
+*   +--+--+---+
+*   |  |  |   |
+*  4k 8k 16k 400k
+*
+* Suppose we drop the lock after reading VMA2 due to
+* contention, then we get:
+*
+*  last_vma_end = 16k
+*
+* 1) VMA2 is freed, but VMA3 exists:
+*
+*find_vma(mm, 16k - 1) will return VMA3.
+*In this case, just continue from VMA3.
+*
+* 2) VMA2 still exists:
+*
+*find_vma(mm, 16k - 1) will return VMA2.
+*Iterate the loop like the original one.
+*
+* 3) No more VMAs can be found:
+*
+*find_vma(mm, 16k - 1) will return NULL.
+*No more things to do, just break.
+*
+* 4) (last_vma_end - 1) is the middle of a vma (VMA'):
+*
+*find_vma(mm, 16k - 1) will return VMA' whose range
+*contains last_vma_end.
+*Iterate VMA' from last_vma_end.
+*/
+   vma = find_vma(mm, last_vma_end - 1);
+   /* Case 3 above */
+   if (!vma)
+   break;
+
+   /* Case 1 above */
+   if (vma->vm_start >= last_vma_end)
+   continue;
+
+   /* Case 4 above */
+   if (vma->vm_end > last_vma_end)
+   smap_gather_stats(vma, , last_vma_end);
+   }
+   /* Case 2 above */
+   vma

Re: Litmus test for question from Al Viro

2020-10-04 Thread Alan Stern

On Sun, Oct 04, 2020 at 04:31:46PM -0700, Paul E. McKenney wrote:
> Nice simple example!  How about like this?
> 
>   Thanx, Paul
> 
> 
> 
> commit c964f404eabe4d8ce294e59dda713d8c19d340cf
> Author: Alan Stern 
> Date:   Sun Oct 4 16:27:03 2020 -0700
> 
> manual/kernel: Add a litmus test with a hidden dependency
> 
> This commit adds a litmus test that has a data dependency that can be
> hidden by control flow.  In this test, both the taken and the not-taken
> branches of an "if" statement must be accounted for in order to properly
> analyze the litmus test.  But herd7 looks only at individual executions
> in isolation, so fails to see the dependency.
> 
> Signed-off-by: Alan Stern 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/manual/kernel/crypto-control-data.litmus 
> b/manual/kernel/crypto-control-data.litmus
> new file mode 100644
> index 000..6baecf9
> --- /dev/null
> +++ b/manual/kernel/crypto-control-data.litmus
> @@ -0,0 +1,31 @@
> +C crypto-control-data
> +(*
> + * LB plus crypto-control-data plus data
> + *
> + * Result: Sometimes
> + *
> + * This is an example of OOTA and we would like it to be forbidden.
> + * The WRITE_ONCE in P0 is both data-dependent and (at the hardware level)
> + * control-dependent on the preceding READ_ONCE.  But the dependencies are
> + * hidden by the form of the conditional control construct, hence the 
> + * name "crypto-control-data".  The memory model doesn't recognize them.
> + *)
> +
> +{}
> +
> +P0(int *x, int *y)
> +{
> + int r1;
> +
> + r1 = 1;
> + if (READ_ONCE(*x) == 0)
> + r1 = 0;
> + WRITE_ONCE(*y, r1);
> +}
> +
> +P1(int *x, int *y)
> +{
> + WRITE_ONCE(*x, READ_ONCE(*y));
> +}
> +
> +exists (0:r1=1)

Considering the bug in herd7 pointed out by Akira, we should rewrite P1 as:

P1(int *x, int *y)
{
int r2;

r = READ_ONCE(*y);
WRITE_ONCE(*x, r2);
}

Other than that, this is fine.

Alan

Re: [RFC 1/3] Initialize devlink health dump framework for the dlge driver

2020-10-04 Thread Coiby Xu


On Fri, Aug 21, 2020 at 11:08:22AM +0800, Coiby Xu wrote:

On Sun, Aug 16, 2020 at 11:56:40AM +0900, Benjamin Poirier wrote:

On 2020-08-15 00:05 +0800, Coiby Xu wrote:

Initialize devlink health dump framework for the dlge driver so the
coredump could be done via devlink.

Signed-off-by: Coiby Xu 
---
drivers/staging/qlge/Makefile  |  2 +-
drivers/staging/qlge/qlge.h|  9 +++
drivers/staging/qlge/qlge_health.c | 43 ++
drivers/staging/qlge/qlge_health.h |  2 ++
drivers/staging/qlge/qlge_main.c   | 21 +++
5 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 drivers/staging/qlge/qlge_health.c
create mode 100644 drivers/staging/qlge/qlge_health.h

diff --git a/drivers/staging/qlge/Makefile b/drivers/staging/qlge/Makefile
index 1dc2568e820c..0a1e4c8dd546 100644
--- a/drivers/staging/qlge/Makefile
+++ b/drivers/staging/qlge/Makefile
@@ -5,4 +5,4 @@

obj-$(CONFIG_QLGE) += qlge.o

-qlge-objs := qlge_main.o qlge_dbg.o qlge_mpi.o qlge_ethtool.o
+qlge-objs := qlge_main.o qlge_dbg.o qlge_mpi.o qlge_ethtool.o qlge_health.o
diff --git a/drivers/staging/qlge/qlge.h b/drivers/staging/qlge/qlge.h
index fc8c5ca8935d..055ded6dab60 100644
--- a/drivers/staging/qlge/qlge.h
+++ b/drivers/staging/qlge/qlge.h
@@ -2061,6 +2061,14 @@ struct nic_operations {
int (*port_initialize) (struct ql_adapter *);
};



This patch doesn't apply over the latest staging tree. I think your tree
is missing commit d923bb6bf508 ("staging: qlge: qlge.h: Function
definition arguments should have names.")


Thank you for applying the patch to test it! I had incorrect
understanding about the word "RFC" and didn't do a rebase onto
the latest staging tree.




+
+
+struct qlge_devlink {
+struct ql_adapter *qdev;
+struct net_device *ndev;


I don't have experience implementing devlink callbacks but looking at
some other devlink users (mlx4, ionic, ice), all of them use devlink
priv space for their main private structure. That would be struct
ql_adapter in this case. Is there a good reason to stray from that
pattern?


+struct devlink_health_reporter *reporter;
+};
+
/*
 * The main Adapter structure definition.
 * This structure has all fields relevant to the hardware.
@@ -2078,6 +2086,7 @@ struct ql_adapter {
struct pci_dev *pdev;
struct net_device *ndev;/* Parent NET device */

+   struct qlge_devlink *devlink;
/* Hardware information */
u32 chip_rev_id;
u32 fw_rev_id;
diff --git a/drivers/staging/qlge/qlge_health.c 
b/drivers/staging/qlge/qlge_health.c
new file mode 100644
index ..292f6b1827e1
--- /dev/null
+++ b/drivers/staging/qlge/qlge_health.c
@@ -0,0 +1,43 @@
+#include "qlge.h"
+#include "qlge_health.h"
+
+static int
+qlge_reporter_coredump(struct devlink_health_reporter *reporter,
+   struct devlink_fmsg *fmsg, void *priv_ctx,
+   struct netlink_ext_ack *extack)
+{
+   return 0;
+}
+
+static const struct devlink_health_reporter_ops qlge_reporter_ops = {
+   .name = "dummy",
+   .dump = qlge_reporter_coredump,
+};


I think
select NET_DEVLINK
should be added to drivers/staging/qlge/Kconfig


Thank you for reminding me!




+
+int qlge_health_create_reporters(struct qlge_devlink *priv)
+{
+   int err;
+
+   struct devlink_health_reporter *reporter;
+   struct devlink *devlink;
+
+   devlink = priv_to_devlink(priv);
+   reporter =
+   devlink_health_reporter_create(devlink, _reporter_ops,
+  0,
+  priv);
+   if (IS_ERR(reporter)) {
+   netdev_warn(priv->ndev,
+   "Failed to create reporter, err = %ld\n",
+   PTR_ERR(reporter));
+   return PTR_ERR(reporter);
+   }
+   priv->reporter = reporter;
+
+   if (err)
+   return err;
+
+   return 0;
+}
+
+


Stray newlines


Will fix it in v1.




diff --git a/drivers/staging/qlge/qlge_health.h 
b/drivers/staging/qlge/qlge_health.h
new file mode 100644
index ..07d3bafab845
--- /dev/null
+++ b/drivers/staging/qlge/qlge_health.h
@@ -0,0 +1,2 @@
+#include 
+int qlge_health_create_reporters(struct qlge_devlink *priv);


I would suggest to put this in qlge.h instead of creating a new file.


Although there are only two lines for now, is it possible qlge will add
more devlink code? If that's the case, a file to single out these code
is necessary as is the same to some other drivers,

   $ find drivers -name *health*.h
   drivers/net/ethernet/mellanox/mlx5/core/en/health.h

   $ find drivers -name *devlink*.h
   drivers/net/ethernet/huawei/hinic/hinic_devlink.h
   drivers/net/ethernet/mellanox/mlx5/core/devlink.h
   drivers/net/ethernet/mellanox/mlx5/core/en/devlink.h
   drivers/net/ethernet/intel/ice/ice_devlink.h

Re: [RFC V2] mm/vmstat: Add events for HugeTLB migration

2020-10-04 Thread Anshuman Khandual

On 10/02/2020 05:34 PM, Michal Hocko wrote:
> On Wed 30-09-20 11:30:49, Anshuman Khandual wrote:
>> Add following new vmstat events which will track HugeTLB page migration.
>>
>> 1. HUGETLB_MIGRATION_SUCCESS
>> 2. HUGETLB_MIGRATION_FAILURE
>>
>> It follows the existing semantics to accommodate HugeTLB subpages in total
>> page migration statistics. While here, this updates current trace event
>> 'mm_migrate_pages' to accommodate now available HugeTLB based statistics.
> What is the actual usecase? And how do you deal with the complexity
> introduced by many different hugetlb page sizes. Really, what is the
> point to having such a detailed view on hugetlb migration?
>

It helps differentiate various page migration events i.e normal, THP and
HugeTLB and gives us more reliable and accurate measurement. Current stats
as per PGMIGRATE_SUCCESS and PGMIGRATE_FAIL are misleading, as they contain
both normal and HugeTLB pages as single entities, which is not accurate.

After this change, PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will contain page
migration statistics in terms of normal pages irrespective of whether any
previous migrations until that point involved normal pages, THP or HugeTLB
(any size) pages. At the least, this fixes existing misleading stats with
PGMIGRATE_SUCCESS and PGMIGRATE_FAIL.

Besides, it helps us understand HugeTLB migrations in more detail. Even
though HugeTLB can be of various sizes on a given platform, these new
stats HUGETLB_MIGRATION_SUCCESS and HUGETLB_MIGRATION_FAILURE give enough
overall insight into HugeTLB migration events.

Though these new stats accumulate HugeTLB migration success and failure
irrespective of their size, it will still be helpful as HugeTLB is user
driven, who should be able to decipher these accumulated stats. But this
is a limitation, as it might be difficult to determine available HugeTLB
sizes at compile time.

Re: [PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW

2020-10-04 Thread Hector Yuan

On Fri, 2020-09-25 at 15:25 +0800, Hector Yuan wrote:
> Hi, Rob sir:
> 
> Yes, my patch follows
> Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt way to
> define frequency domain.
> Is it OK to you if I use the same way to do?
> And if there exist any schema problem, please kindly let me know how to
> fix it.
> 
> My patch reference
> Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> to use the cpu node.
> https://elixir.bootlin.com/linux/v5.9-rc6/source/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> 
> Thanks a lot.
> 
Hi, Rob sir:

Sorry to bother you, may we know your comment for this.
Thanks so much. 

> On Fri, 2020-09-25 at 11:45 +0530, Viresh Kumar wrote:
> > On 25-09-20, 10:27, Hector Yuan wrote:
> > > Hi, Viresh & Rob Sir:
> > > 
> > > I will change frequency domain to below and define it in cpufreq_hw
> > > schema rather than cpu node.
> > > 
> > > mediatek,freq-domain-0 = <>, <>;
> > 
> > I think it would be better to do it the standard way we have done it 
> > elsewhere.
> > i.e. follow Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt, 
> > that
> > is similar to what you did earlier.
> > 
>

Re: [PATCH 1/6] efistub: pass uefi secureboot flag via fdt params

2020-10-04 Thread Chester Lin

On Mon, Sep 14, 2020 at 04:05:22PM +0800, Chester Lin wrote:
> Hi Ard,
> 
> On Fri, Sep 11, 2020 at 06:01:09PM +0300, Ard Biesheuvel wrote:
> > On Fri, 4 Sep 2020 at 10:29, Chester Lin  wrote:
> > >
> > > Add a new UEFI parameter: "linux,uefi-secure-boot" in fdt boot params
> > > as other architectures have done in their own boot data. For example,
> > > the boot_params->secure_boot in x86.
> > >
> > > Signed-off-by: Chester Lin 
> > 
> > Why do we need this flag? Can't the OS simply check the variable directly?
> > 
> 
> In fact, there's a difficulty to achieve this.
> 
> When linux kernel is booting on ARM, the runtime services are enabled later 
> on.
> It's done by arm_enable_runtime_services(), which is registered as an 
> early_initcall.
> Before it calls efi_native_runtime_setup(), all EFI runtime callbacks are 
> still
> NULL so calling efi.get_variable() will cause NULL pointer dereference.
> 
> There's a case that arch_ima_get_secureboot() can be called in early boot 
> stage.
> For example, when you try to set "ima_appraise=off" in kernel command line, 
> it's
> actually handled early:
> 
> [0.00] Kernel command line: 
> BOOT_IMAGE=/boot/Image-5.9.0-rc3-9.gdd61cda-
> vanilla root=UUID=a88bfb80-8abb-425c-a0f3-ad317465c28b splash=silent 
> mitigations
> =auto ignore_loglevel earlycon=pl011,mmio,0x900 console=ttyAMA0 
> ima_appraise=off
> [0.00] ima: Secure boot enabled: ignoring ima_appraise=off boot 
> parameter option
> [0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 
> bytes, linear)
> 
> However EFI services are remapped and enabled afterwards.
> 
> [0.082286] rcu: Hierarchical SRCU implementation.
> [0.089592] Remapping and enabling EFI services.
> [0.097509] smp: Bringing up secondary CPUs ...
> 
> Another problem is that efi_rts_wq is created in subsys_initcall so we have to
> wait for both EFI services mapping and the workqueue get initiated before 
> calling
> efi.get_variable() on ARM.
> 
> The only way I can think of is to put a flag via fdt params. May I have your
> suggestions? I will appreciate if there's any better approach.
> 
> Thanks,
> Chester

Ping. May I have some suggestions here?

Thanks,
Chester

> 
> > > ---
> > >  drivers/firmware/efi/libstub/fdt.c | 39 +-
> > >  1 file changed, 38 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/firmware/efi/libstub/fdt.c 
> > > b/drivers/firmware/efi/libstub/fdt.c
> > > index 11ecf3c4640e..c9a341e4715f 100644
> > > --- a/drivers/firmware/efi/libstub/fdt.c
> > > +++ b/drivers/firmware/efi/libstub/fdt.c
> > > @@ -136,6 +136,10 @@ static efi_status_t update_fdt(void *orig_fdt, 
> > > unsigned long orig_fdt_size,
> > > if (status)
> > > goto fdt_set_fail;
> > >
> > > +   status = fdt_setprop_var(fdt, node, "linux,uefi-secure-boot", 
> > > fdt_val32);
> > > +   if (status)
> > > +   goto fdt_set_fail;
> > > +
> > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> > > efi_status_t efi_status;
> > >
> > > @@ -199,6 +203,24 @@ static efi_status_t update_fdt_memmap(void *fdt, 
> > > struct efi_boot_memmap *map)
> > > return EFI_SUCCESS;
> > >  }
> > >
> > > +static efi_status_t update_fdt_secboot(void *fdt, u32 secboot)
> > > +{
> > > +   int node = fdt_path_offset(fdt, "/chosen");
> > > +   u32 fdt_val32;
> > > +   int err;
> > > +
> > > +   if (node < 0)
> > > +   return EFI_LOAD_ERROR;
> > > +
> > > +   fdt_val32 = cpu_to_fdt32(secboot);
> > > +
> > > +   err = fdt_setprop_inplace_var(fdt, node, 
> > > "linux,uefi-secure-boot", fdt_val32);
> > > +   if (err)
> > > +   return EFI_LOAD_ERROR;
> > > +
> > > +   return EFI_SUCCESS;
> > > +}
> > > +
> > >  struct exit_boot_struct {
> > > efi_memory_desc_t   *runtime_map;
> > > int *runtime_entry_count;
> > > @@ -208,6 +230,9 @@ struct exit_boot_struct {
> > >  static efi_status_t exit_boot_func(struct efi_boot_memmap *map,
> > >void *priv)
> > >  {
> > > +   efi_status_t status;
> > > +   enum efi_secureboot_mode secboot_status;
> > > +   u32 secboot_var = 0;
> > > struct exit_boot_struct *p = priv;
> > > /*
> > >  * Update the memory map with virtual addresses. The function 
> > > will also
> > > @@ -217,7 +242,19 @@ static efi_status_t exit_boot_func(struct 
> > > efi_boot_memmap *map,
> > > efi_get_virtmap(*map->map, *map->map_size, *map->desc_size,
> > > p->runtime_map, p->runtime_entry_count);
> > >
> > > -   return update_fdt_memmap(p->new_fdt_addr, map);
> > > +   status = update_fdt_memmap(p->new_fdt_addr, map);
> > > +
> > > +   if (status != EFI_SUCCESS)
> > > +   return status;
> > > +
> > > +   secboot_status = efi_get_secureboot();
> > > +
> > > +   if (secboot_status ==

[PATCH v2] rcu/tree: nocb: Avoid raising softirq when there are ready to execute CBs

2020-10-04 Thread Joel Fernandes (Google)

During testing, I see it is possible that rcu_pending() returns 1 when
offloaded callbacks are ready to execute thus raising the RCU softirq.

However, softirq does not execute offloaded callbacks. They are executed in a
kthread which is awakened independent of the softirq.

This commit therefore avoids raising the softirq in the first place. That's
probably a good thing considering that the purpose of callback offloading is to
reduce softirq activity.

Passed 30 minute tests of TREE01 through TREE09 each.

On TREE08, I notice that there is atmost 150us from when the softirq was
NOT raised when ready cbs were present, to when the ready callbacks were
invoked by the rcuop thread. This also further confirms that there is no
need to raise the softirq for ready cbs in the first place.

Cc: neer...@codeaurora.org
Signed-off-by: Joel Fernandes (Google) 

---

v1->v2: Also cleaned up another test of the nocb configuration macro.

 kernel/rcu/tree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f78ee759af9c..2b1e1b21db92 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3652,13 +3652,13 @@ static int rcu_pending(int user)
return 1;
 
/* Does this CPU have callbacks ready to invoke? */
-   if (rcu_segcblist_ready_cbs(>cblist))
+   if (!rcu_segcblist_is_offloaded(>cblist) &&
+   rcu_segcblist_ready_cbs(>cblist))
return 1;
 
/* Has RCU gone idle with this CPU needing another grace period? */
if (!gp_in_progress && rcu_segcblist_is_enabled(>cblist) &&
-   (!IS_ENABLED(CONFIG_RCU_NOCB_CPU) ||
-!rcu_segcblist_is_offloaded(>cblist)) &&
+   (!rcu_segcblist_is_offloaded(>cblist)) &&
!rcu_segcblist_restempty(>cblist, RCU_NEXT_READY_TAIL))
return 1;
 
-- 
2.28.0.806.g8561365e88-goog

Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition

2020-10-04 Thread Lars Melin


On 10/4/2020 23:03, Leonid Bloch wrote:

Lars,


Thank you for your review! The changes which you have suggested also 
made ModemManager to recognize the device (which it didn't do before). 
Please check out the v2.



Cheers,
Leonid.


The v2 looks good to me

br
Lars

Re: [PATCH] ARM: dts: aspeed-g6: Add sgpiom/sgpios node

2020-10-04 Thread Billy Tsai

Hi Andrew,

On 2020/10/1, 8:36 AM, Andrew Jeffery wrote:

Hi Billy,

On Wed, 30 Sep 2020, at 14:41, Billy Tsai wrote:
> This commit add two sgpiom and two sgpios node into aspeed-g6.dtsi
> and change the register range of gpio0 to fix the hardware design.
> 
> Signed-off-by: Billy Tsai 
> ---
>  arch/arm/boot/dts/aspeed-g6.dtsi | 51 +++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi 
b/arch/arm/boot/dts/aspeed-g6.dtsi
> index 97ca743363d7..00237daec2a1 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -357,7 +357,7 @@
>   #gpio-cells = <2>;
>   gpio-controller;
>   compatible = "aspeed,ast2600-gpio";
> - reg = <0x1e78 0x800>;
> + reg = <0x1e78 0x500>;
>   interrupts = ;
>   gpio-ranges = < 0 0 208>;
>   ngpios = <208>;
> @@ -365,6 +365,55 @@
>   interrupt-controller;
>   #interrupt-cells = <2>;
>   };
> + sgpiom0: sgpiom@1e780500 {
> + #gpio-cells = <2>;
> + gpio-controller;
> + compatible = "aspeed,ast2600-sgpiom";
> + reg = <0x1e780500 0x100>;
> + interrupts = ;
> + ngpios = <128>;
> + clocks = < ASPEED_CLK_APB2>;
> + interrupt-controller;
> + bus-frequency = <1200>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_sgpm1_default>;
> + status = "disabled";
> + };
> +
> + sgpiom1: sgpiom@1e780600 {
> + #gpio-cells = <2>;
> + gpio-controller;
> + compatible = "aspeed,ast2600-sgpiom";
> + reg = <0x1e780600 0x100>;
> + interrupts = ;
> + ngpios = <80>;
> + clocks = < ASPEED_CLK_APB2>;
> + interrupt-controller;
> + bus-frequency = <1200>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_sgpm2_default>;

   > Have you tried building this on top of upstream? Because neither sgpm2 nor 
   > sgps2 are supported by the pinctrl driver. If you have patches that 
implement 
   > both mux configurations, can you post them too?

   > Andrew

Sorry for that.

I will resend another patch which includes pinctrl information to fix this 
error.
  
Best Regards,
Billy Tsai

Re: [PATCH v2 06/12] soc: mediatek: pm-domains: Add SMI block as bus protection block

2020-10-04 Thread Nicolas Boichat

On Fri, Oct 2, 2020 at 4:56 PM Matthias Brugger  wrote:
>
>
>
> On 01/10/2020 18:01, Enric Balletbo i Serra wrote:
> > From: Matthias Brugger 
> >
> > Apart from the infracfg block, the SMI block is used to enable the bus
> > protection for some power domains. Add support for this block.
> >
> > Signed-off-by: Matthias Brugger 
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> >
> > Changes in v2: None
> >
> >   drivers/soc/mediatek/mtk-pm-domains.c | 64 ---
> >   include/linux/soc/mediatek/infracfg.h |  6 +++
> >   2 files changed, 53 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
> > b/drivers/soc/mediatek/mtk-pm-domains.c
> > index b5e7c9846c34..38f2630bdd0a 100644
> > --- a/drivers/soc/mediatek/mtk-pm-domains.c
> > +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> > @@ -56,8 +56,25 @@
> >
> >   #define SPM_MAX_BUS_PROT_DATA   3
> >
> > +#define _BUS_PROT(_mask, _set, _clr, _sta, _update) {\
> > + .bus_prot_mask = (_mask),   \
> > + .bus_prot_set = _set,   \
> > + .bus_prot_clr = _clr,   \
> > + .bus_prot_sta = _sta,   \
> > + .bus_prot_reg_update = _update, \
> > + }
> > +
> > +#define BUS_PROT_WR(_mask, _set, _clr, _sta) \
> > + _BUS_PROT(_mask, _set, _clr, _sta, false)
> > +
> > +#define BUS_PROT_UPDATE(_mask, _set, _clr, _sta) \
> > + _BUS_PROT(_mask, _set, _clr, _sta, true)
> > +
> >   struct scpsys_bus_prot_data {
> >   u32 bus_prot_mask;
> > + u32 bus_prot_set;
> > + u32 bus_prot_clr;
> > + u32 bus_prot_sta;
> >   bool bus_prot_reg_update;
> >   };
> >
> > @@ -69,6 +86,7 @@ struct scpsys_bus_prot_data {
> >* @sram_pdn_ack_bits: The mask for sram power control acked bits.
> >* @caps: The flag for active wake-up action.
> >* @bp_infracfg: bus protection for infracfg subsystem
> > + * @bp_smi: bus protection for smi subsystem
> >*/
> >   struct scpsys_domain_data {
> >   u32 sta_mask;
> > @@ -77,6 +95,7 @@ struct scpsys_domain_data {
> >   u32 sram_pdn_ack_bits;
> >   u8 caps;
> >   const struct scpsys_bus_prot_data bp_infracfg[SPM_MAX_BUS_PROT_DATA];
> > + const struct scpsys_bus_prot_data bp_smi[SPM_MAX_BUS_PROT_DATA];
> >   };
> >
> >   struct scpsys_domain {
> > @@ -86,6 +105,7 @@ struct scpsys_domain {
> >   int num_clks;
> >   struct clk_bulk_data *clks;
> >   struct regmap *infracfg;
> > + struct regmap *smi;
> >   };
> >
> >   struct scpsys_soc_data {
> > @@ -175,9 +195,9 @@ static int _scpsys_bus_protect_enable(const struct 
> > scpsys_bus_prot_data *bpd, st
> >   if (bpd[i].bus_prot_reg_update)
> >   regmap_update_bits(regmap, INFRA_TOPAXI_PROTECTEN, 
> > mask, mask);
> >   else
> > - regmap_write(regmap, INFRA_TOPAXI_PROTECTEN_SET, 
> > mask);
> > + regmap_write(regmap, bpd[i].bus_prot_set, mask);
> >
> > - ret = regmap_read_poll_timeout(regmap, 
> > INFRA_TOPAXI_PROTECTSTA1,
> > + ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> >  val, (val & mask) == mask,
> >  MTK_POLL_DELAY_US, 
> > MTK_POLL_TIMEOUT);
> >   if (ret)
> > @@ -193,7 +213,11 @@ static int scpsys_bus_protect_enable(struct 
> > scpsys_domain *pd)
> >   int ret;
> >
> >   ret = _scpsys_bus_protect_enable(bpd, pd->infracfg);
> > - return ret;
> > + if (ret)
> > + return ret;
> > +
> > + bpd = pd->data->bp_smi;
> > + return _scpsys_bus_protect_enable(bpd, pd->smi);

Not a huge fan or reusing bpd for 2 different things.

I think this is easier to follow:

_scpsys_bus_protect_enable(pd->data->bp_infracfg, pd->infracfg);
...
_scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi);


> >   }
> >  [snip]

[PATCH resend] seccomp: Make duplicate listener detection non-racy

2020-10-04 Thread Jann Horn

Currently, init_listener() tries to prevent adding a filter with
SECCOMP_FILTER_FLAG_NEW_LISTENER if one of the existing filters already
has a listener. However, this check happens without holding any lock that
would prevent another thread from concurrently installing a new filter
(potentially with a listener) on top of the ones we already have.

Theoretically, this is also a data race: The plain load from
current->seccomp.filter can race with concurrent writes to the same
location.

Fix it by moving the check into the region that holds the siglock to guard
against concurrent TSYNC.

(I am not marking this for stable backport because I believe that this does
not have any implications beyond a theoretical data race and allowing
userspace to create seccomp filters with weird semantics if userspace
concurrently installs seccomp filters in a way no benign userspace workload
would.)

(The "Fixes" tag points to the commit that introduced the theoretical
data race; concurrent installation of another filter with TSYNC only
became possible later, in commit 51891498f2da ("seccomp: allow TSYNC and
USER_NOTIF together").)

Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Reviewed-by: Tycho Andersen 
Signed-off-by: Jann Horn 
---
NOTE: After Tycho gave his Reviewed-by, I've had to adjust the errno
to -EBUSY (my original patch broke UAPI, good thing we have selftests),
remove the unused "cur" from init_listener(), and remove the now
useless initialization of "ret".

resending because the first time I mangled the diff... sorry

 kernel/seccomp.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 676d4af62103..c359ef4380ad 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1472,13 +1472,7 @@ static const struct file_operations seccomp_notify_ops = 
{
 
 static struct file *init_listener(struct seccomp_filter *filter)
 {
-   struct file *ret = ERR_PTR(-EBUSY);
-   struct seccomp_filter *cur;
-
-   for (cur = current->seccomp.filter; cur; cur = cur->prev) {
-   if (cur->notif)
-   goto out;
-   }
+   struct file *ret;
 
ret = ERR_PTR(-ENOMEM);
filter->notif = kzalloc(sizeof(*(filter->notif)), GFP_KERNEL);
@@ -1504,6 +1498,31 @@ static struct file *init_listener(struct seccomp_filter 
*filter)
return ret;
 }
 
+/*
+ * Does @new_child have a listener while an ancestor also has a listener?
+ * If so, we'll want to reject this filter.
+ * This only has to be tested for the current process, even in the TSYNC case,
+ * because TSYNC installs @child with the same parent on all threads.
+ * Note that @new_child is not hooked up to its parent at this point yet, so
+ * we use current->seccomp.filter.
+ */
+static bool has_duplicate_listener(struct seccomp_filter *new_child)
+{
+   struct seccomp_filter *cur;
+
+   /* must be protected against concurrent TSYNC */
+   lockdep_assert_held(>sighand->siglock);
+
+   if (!new_child->notif)
+   return false;
+   for (cur = current->seccomp.filter; cur; cur = cur->prev) {
+   if (cur->notif)
+   return true;
+   }
+
+   return false;
+}
+
 /**
  * seccomp_set_mode_filter: internal function for setting seccomp filter
  * @flags:  flags to change filter behavior
@@ -1575,6 +1594,11 @@ static long seccomp_set_mode_filter(unsigned int flags,
if (!seccomp_may_assign_mode(seccomp_mode))
goto out;
 
+   if (has_duplicate_listener(prepared)) {
+   ret = -EBUSY;
+   goto out;
+   }
+
ret = seccomp_attach_filter(flags, prepared);
if (ret)
goto out;

base-commit: fb0155a09b0224a7147cb07a4ce6034c8d29667f
-- 
2.28.0.806.g8561365e88-goog

Re: [PATCH v2 02/12] soc: mediatek: Add MediaTek SCPSYS power domains

2020-10-04 Thread Nicolas Boichat

On Fri, Oct 2, 2020 at 12:02 AM Enric Balletbo i Serra
 wrote:
>
> The System Control Processor System (SCPSYS) has several power management
> related tasks in the system. This driver implements support to handle
> the different power domains supported in order to meet high performance
> and low power requirements.
>
> Co-developed-by: Matthias Brugger 
> Signed-off-by: Matthias Brugger 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>
> Changes in v2:
> - Get base address from parent syscon. We have now a scpsys syscon node
>   and a child for the SPM (System Power Manager).
> - Use regmap API to acces de base address.
>
>  drivers/soc/mediatek/Kconfig  |  13 +
>  drivers/soc/mediatek/Makefile |   1 +
>  drivers/soc/mediatek/mtk-pm-domains.c | 628 ++
>  3 files changed, 642 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 59a56cd790ec..68d800f9e4a5 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -44,6 +44,19 @@ config MTK_SCPSYS
>   Say yes here to add support for the MediaTek SCPSYS power domain
>   driver.
>
> +config MTK_SCPSYS_PM_DOMAINS
> +   bool "MediaTek SCPSYS generic power domain"
> +   default ARCH_MEDIATEK
> +   depends on PM
> +   depends on MTK_INFRACFG
> +   select PM_GENERIC_DOMAINS
> +   select REGMAP
> +   help
> + Say y here to enable power domain support.
> + In order to meet high performance and low power requirements, the 
> System
> + Control Processor System (SCPSYS) has several power management 
> related
> + tasks in the system.
> +
>  config MTK_MMSYS
> bool "MediaTek MMSYS Support"
> default ARCH_MEDIATEK
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 01f9f873634a..1e60fb4f89d4 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -3,4 +3,5 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
>  obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> +obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
>  obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
> b/drivers/soc/mediatek/mtk-pm-domains.c
> new file mode 100644
> index ..68886bf437f9
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> @@ -0,0 +1,628 @@
> [snip]
> +
> +static int scpsys_domain_is_on(struct scpsys_domain *pd)
> +{
> +   struct scpsys *scpsys = pd->scpsys;
> +   u32 status, status2;
> +
> +   regmap_read(scpsys->base, scpsys->soc_data->pwr_sta_offs, );
> +   status &= pd->data->sta_mask;
> +
> +   regmap_read(scpsys->base, scpsys->soc_data->pwr_sta2nd_offs, 
> );
> +   status2 &= pd->data->sta_mask;
> +
> +   /*
> +* A domain is on when both status bits are set. If only one is set
> +* return an error. This happens while powering up a domain
> +*/
> +
> +   if (status && status2)
> +   return true;
> +   if (!status && !status2)
> +   return false;
> +
> +   return -EINVAL;


Why do you care? It seems like all you ever do with this is check if
the domain is powered on, so it seems like you could just
return (status && status2); ?

> +}
> +
> +static int scpsys_sram_enable(struct scpsys_domain *pd)
> +{
> +   u32 pdn_ack = pd->data->sram_pdn_ack_bits;
> +   struct scpsys *scpsys = pd->scpsys;
> +   u32 val;
> +   int tmp;

regmap_read_poll_timeout => regmap_read technically takes a `unsigned
int *` parameter, so this should probably be unsigned too (or... just
reuse val?)

> +
> +   regmap_read(scpsys->base, pd->data->ctl_offs, );
> +   val &= ~pd->data->sram_pdn_bits;
> +   regmap_write(scpsys->base, pd->data->ctl_offs, val);

Replace with regmap_update_bits?

> +
> +   /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> +   return regmap_read_poll_timeout(scpsys->base, pd->data->ctl_offs, tmp,
> +   (tmp & pdn_ack) == 0, 
> MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> +}
> +
> +static int scpsys_sram_disable(struct scpsys_domain *pd)
> +{
> +   u32 pdn_ack = pd->data->sram_pdn_ack_bits;
> +   struct scpsys *scpsys = pd->scpsys;
> +   u32 val;
> +   int tmp;
> +
> +   regmap_read(scpsys->base, pd->data->ctl_offs, );
> +   val |= pd->data->sram_pdn_bits;
> +   regmap_write(scpsys->base, pd->data->ctl_offs, val);
> +
> +   /* Either wait until SRAM_PDN_ACK all 1 or 0 */
> +   return regmap_read_poll_timeout(scpsys->base, pd->data->ctl_offs, tmp,
> +   (tmp & pdn_ack) == pdn_ack, 
> MTK_POLL_DELAY_US,
> +   MTK_POLL_TIMEOUT);
> +}
> +
> +static int

Re: [PATCH 1/2] mmap locking API: Order lock of nascent mm outside lock of live mm

2020-10-04 Thread Jann Horn

On Sat, Oct 3, 2020 at 11:30 PM Michel Lespinasse  wrote:
> Unrelated to the above: copy_from_user and copy_to_user should not be
> called with mmap_lock held; it may be worth adding these assertions
> too (probably in separate patches) ?

We already have that: All (hopefully?) the userspace accessors call
might_fault(), and that does might_lock_read(>mm->mmap_lock)
(if we're not running in a lazytlb kernel thread or KERNEL_DS is on or
we're in IRQ context or page faults have explicitly been disabled).


But another place where lockdep asserts should be added is find_vma();
there are currently several architectures that sometimes improperly
call that with no lock held:

SPARC's arch_validate_prot():
https://lore.kernel.org/linux-mm/cag48ez3ysftfofka-po58e4pnp7fk54mfbkk3aupsrt3lwt...@mail.gmail.com/

nios2 sys_cacheflush():
https://lore.kernel.org/linux-mm/CAG48ez3hxeXU29UGWRH-gRXX2jb5Lc==npbxft8udrwo4eh...@mail.gmail.com/

nds32 sys_cacheflush():
https://lore.kernel.org/linux-mm/CAG48ez1UnQEMok9rqFQC4XHBaMmBe=eaedu8z_rxdjfhtna...@mail.gmail.com/

Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver

2020-10-04 Thread Matthew Wilcox

On Mon, Oct 05, 2020 at 02:41:53AM +0300, Jarkko Sakkinen wrote:
> On Sun, Oct 04, 2020 at 11:27:50PM +0100, Matthew Wilcox wrote:
> > int ret = 0;
> > 
> > mutex_lock(>lock);
> > rcu_read_lock();
> 
> Right, so xa_*() take RCU lock implicitly and xas_* do not.

Not necessarily the RCU lock ... I did document all this in xarray.rst:

https://www.kernel.org/doc/html/latest/core-api/xarray.html

> > while (xas.index < idx_end) {
> > page = xas_next();
> 
> It should iterate through every possible page index within the range,
> even the ones that do not have an entry, i.e. this loop also checks
> that there are no empty slots.
> 
> Does xas_next() go through every possible index, or skip the non-empty
> ones?

xas_next(), as its documentation says, will move to the next array
index:

https://www.kernel.org/doc/html/latest/core-api/xarray.html#c.xas_next

> > if (!page || (~page->vm_max_prot_bits & vm_prot_bits))
> > ret = -EACCESS;
> > break;
> > }
> > }
> > rcu_read_unlock();
> > mutex_unlock(>lock);
> 
> In my Geminilake NUC the maximum size of the address space is 64GB for
> an enclave, and it is not fixed but can grow in microarchitectures
> beyond that.
> 
> That means that in (*artificial*) worst case the locks would be kept for
> 64*1024*1024*1024/4096 = 16777216 iterations.

Oh, there's support for that on the XArray API too.

xas_lock_irq();
xas_for_each_marked(, page, end, PAGECACHE_TAG_DIRTY) {
xas_set_mark(, PAGECACHE_TAG_TOWRITE);
if (++tagged % XA_CHECK_SCHED)
continue;

xas_pause();
xas_unlock_irq();
cond_resched();
xas_lock_irq();
}
xas_unlock_irq();

Re: [PATCH] test_power: add missing newlines when printing parameters by sysfs

2020-10-04 Thread Harley A.W. Lorenzo

Here is the updated patch using sprintf, diffing from the original patch by 
Xiongfeng Wang.

[PATCH] test_power: revise parameter printing to use sprintf

Signed-off-by: Harley A.W. Lorenzo 
Suggested-by: Joe Perches 
---
 drivers/power/supply/test_power.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/power/supply/test_power.c 
b/drivers/power/supply/test_power.c
index 4895ee5e63a9..fbb179a1b615 100644
--- a/drivers/power/supply/test_power.c
+++ b/drivers/power/supply/test_power.c
@@ -352,8 +352,8 @@ static int param_set_ac_online(const char *key, const 
struct kernel_param *kp)

 static int param_get_ac_online(char *buffer, const struct kernel_param *kp)
 {
-   strcpy(buffer, map_get_key(map_ac_online, ac_online, "unknown"));
-   strcat(buffer, "\n");
+   char const *out = map_get_key(map_ac_online, ac_online, "unknown");
+   sprintf(buffer, "%s\n", out);
return strlen(buffer);
 }

@@ -366,8 +366,8 @@ static int param_set_usb_online(const char *key, const 
struct kernel_param *kp)

 static int param_get_usb_online(char *buffer, const struct kernel_param *kp)
 {
-   strcpy(buffer, map_get_key(map_ac_online, usb_online, "unknown"));
-   strcat(buffer, "\n");
+   char const *out = map_get_key(map_ac_online, usb_online, "unknown");
+   sprintf(buffer, "%s\n", out);
return strlen(buffer);
 }

@@ -381,8 +381,8 @@ static int param_set_battery_status(const char *key,

 static int param_get_battery_status(char *buffer, const struct kernel_param 
*kp)
 {
-   strcpy(buffer, map_get_key(map_status, battery_status, "unknown"));
-   strcat(buffer, "\n");
+   char const *out = map_get_key(map_ac_online, battery_status, "unknown");
+   sprintf(buffer, "%s\n", out);
return strlen(buffer);
 }

@@ -396,8 +396,8 @@ static int param_set_battery_health(const char *key,

 static int param_get_battery_health(char *buffer, const struct kernel_param 
*kp)
 {
-   strcpy(buffer, map_get_key(map_health, battery_health, "unknown"));
-   strcat(buffer, "\n");
+   char const *out = map_get_key(map_ac_online, battery_health, "unknown");
+   sprintf(buffer, "%s\n", out);
return strlen(buffer);
 }

@@ -412,8 +412,9 @@ static int param_set_battery_present(const char *key,
 static int param_get_battery_present(char *buffer,
const struct kernel_param *kp)
 {
-   strcpy(buffer, map_get_key(map_present, battery_present, "unknown"));
-   strcat(buffer, "\n");
+   char const *out = map_get_key(map_ac_online, battery_present,
+   "unknown");
+   sprintf(buffer, "%s\n", out);
return strlen(buffer);
 }

@@ -429,9 +430,9 @@ static int param_set_battery_technology(const char *key,
 static int param_get_battery_technology(char *buffer,
const struct kernel_param *kp)
 {
-   strcpy(buffer,
-   map_get_key(map_technology, battery_technology, "unknown"));
-   strcat(buffer, "\n");
+   char const *out = map_get_key(map_ac_online, battery_technology,
+   "unknown");
+   sprintf(buffer, "%s\n", out);
return strlen(buffer);
 }

--
2.28.0

Re: [PATCH v2] soc: mediatek: Check if power domains can be powered on at boot time

2020-10-04 Thread Nicolas Boichat

On Thu, Oct 1, 2020 at 11:03 PM Matthias Brugger  wrote:
>
>
>
> On 28/09/2020 05:31, Nicolas Boichat wrote:
> > In the error case, where a power domain cannot be powered on
> > successfully at boot time (in mtk_register_power_domains),
> > pm_genpd_init would still be called with is_off=false, and the
> > system would later try to disable the power domain again, triggering
> > warnings as disabled clocks are disabled again (and other potential
> > issues).
> >
> > Also print a warning splat in that case, as this should never
> > happen.
> >
> > Fixes: c84e358718a66f7 ("soc: Mediatek: Add SCPSYS power domain driver")
> > Signed-off-by: Nicolas Boichat 
>
> Applied to v5.10-tmp/soc which will be v5.10-next/soc as soon as v5.10-rc1 
> gets
> published.
>
> Nicolas can you please make sure that similar logic will be part of the series
> Enric is working on?

https://patchwork.kernel.org/patch/11811767/ the logic is a bit
different, and the whole scpsys driver would fail to probe, but I
think that's also reasonable behaviour.

Thanks,

>
> Thanks a lot.
> Matthias
>
> > ---
> >
> > Changes in v2:
> >   - Add WARN_ON if the domain can't be powered on, to make it more
> > obvious that this should not happen (there is already an error
> > message).
> >
> >   drivers/soc/mediatek/mtk-scpsys.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index f669d3754627..ca75b14931ec 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -524,6 +524,7 @@ static void mtk_register_power_domains(struct 
> > platform_device *pdev,
> >   for (i = 0; i < num; i++) {
> >   struct scp_domain *scpd = >domains[i];
> >   struct generic_pm_domain *genpd = >genpd;
> > + bool on;
> >
> >   /*
> >* Initially turn on all domains to make the domains usable
> > @@ -531,9 +532,9 @@ static void mtk_register_power_domains(struct 
> > platform_device *pdev,
> >* software.  The unused domains will be switched off during
> >* late_init time.
> >*/
> > - genpd->power_on(genpd);
> > + on = !WARN_ON(genpd->power_on(genpd) < 0);
> >
> > - pm_genpd_init(genpd, NULL, false);
> > + pm_genpd_init(genpd, NULL, !on);
> >   }
> >
> >   /*
> >

[PATCH 3/3] KEYS: trusted: Fix migratable=1 failing

Consider the following transcript:

$ keyctl add trusted kmk "new 32 blobauth=helloworld keyhandle=8000 
migratable=1" @u
add_key: Invalid argument

The documentation has the following description:

  migratable=   0|1 indicating permission to reseal to new PCR values,
default 1 (resealing allowed)

The consequence is that "migratable=1" should succeed. Fix this by
allowing this condition to pass instead of return -EINVAL.

[*] Documentation/security/keys/trusted-encrypted.rst

Cc: sta...@vger.kernel.org
Cc: "James E.J. Bottomley" 
Cc: Mimi Zohar 
Cc: David Howells 
Fixes: d00a1c72f7f4 ("keys: add new trusted key-type")
Signed-off-by: Jarkko Sakkinen 
---
 security/keys/trusted-keys/trusted_tpm1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/trusted-keys/trusted_tpm1.c 
b/security/keys/trusted-keys/trusted_tpm1.c
index c1dfc32c780b..20ca18e17437 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -801,7 +801,7 @@ static int getoptions(char *c, struct trusted_key_payload 
*pay,
case Opt_migratable:
if (*args[0].from == '0')
pay->migratable = 0;
-   else
+   else if (*args[0].from != '1')
return -EINVAL;
break;
case Opt_pcrlock:
-- 
2.25.1

[PATCH 2/3] KEYS: trusted: Reserve TPM for seal and unseal operations

When TPM 2.0 trusted keys code was moved to the trusted keys subsystem,
the operations were unwrapped from tpm_try_get_ops() and tpm_put_ops(),
which are used to take temporarily the ownership of the TPM chip. The
ownership is only taken inside tpm_send(), but this is not sufficient,
as in the key load TPM2_CC_LOAD, TPM2_CC_UNSEAL and TPM2_FLUSH_CONTEXT
need to be done as a one single atom.

Fix this issue by introducting trusted_tpm_load() and trusted_tpm_new(),
which wrap these operations, and take the TPM chip ownership before
sending anything. Use tpm_transmit_cmd() to send TPM commands instead
of tpm_send(), reverting back to the old behaviour.

Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code")
Reported-by: "James E.J. Bottomley" 
Cc: sta...@vger.kernel.org
Cc: David Howells 
Cc: Mimi Zohar 
Cc: Sumit Garg 
Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h|  4 --
 include/linux/tpm.h   | 16 -
 security/keys/trusted-keys/trusted_tpm1.c | 78 +++
 security/keys/trusted-keys/trusted_tpm2.c |  6 +-
 4 files changed, 71 insertions(+), 33 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 947d1db0a5cc..283f78211c3a 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -164,8 +164,6 @@ extern const struct file_operations tpmrm_fops;
 extern struct idr dev_nums_idr;
 
 ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz);
-ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
-size_t min_rsp_body_length, const char *desc);
 int tpm_get_timeouts(struct tpm_chip *);
 int tpm_auto_startup(struct tpm_chip *chip);
 
@@ -194,8 +192,6 @@ static inline void tpm_msleep(unsigned int delay_msec)
 int tpm_chip_start(struct tpm_chip *chip);
 void tpm_chip_stop(struct tpm_chip *chip);
 struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip);
-__must_check int tpm_try_get_ops(struct tpm_chip *chip);
-void tpm_put_ops(struct tpm_chip *chip);
 
 struct tpm_chip *tpm_chip_alloc(struct device *dev,
const struct tpm_class_ops *ops);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 8f4ff39f51e7..c908349a2f15 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -397,6 +397,10 @@ static inline u32 tpm2_rc_value(u32 rc)
 #if defined(CONFIG_TCG_TPM) || defined(CONFIG_TCG_TPM_MODULE)
 
 extern int tpm_is_tpm2(struct tpm_chip *chip);
+extern __must_check int tpm_try_get_ops(struct tpm_chip *chip);
+extern void tpm_put_ops(struct tpm_chip *chip);
+extern ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+   size_t min_rsp_body_length, const char *desc);
 extern int tpm_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digest);
 extern int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
@@ -410,7 +414,17 @@ static inline int tpm_is_tpm2(struct tpm_chip *chip)
 {
return -ENODEV;
 }
-
+static inline int tpm_try_get_ops(struct tpm_chip *chip)
+{
+   return -ENODEV;
+}
+static inline void tpm_put_ops(struct tpm_chip *chip)
+{
+}
+extern ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+   size_t min_rsp_body_length, const char *desc)
+{
+}
 static inline int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx,
   struct tpm_digest *digest)
 {
diff --git a/security/keys/trusted-keys/trusted_tpm1.c 
b/security/keys/trusted-keys/trusted_tpm1.c
index c7b1701cdac5..c1dfc32c780b 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -950,6 +950,51 @@ static struct trusted_key_payload 
*trusted_payload_alloc(struct key *key)
return p;
 }
 
+static int trusted_tpm_load(struct tpm_chip *chip,
+   struct trusted_key_payload *payload,
+   struct trusted_key_options *options)
+{
+   int ret;
+
+   if (tpm_is_tpm2(chip)) {
+   ret = tpm_try_get_ops(chip);
+   if (!ret) {
+   ret = tpm2_unseal_trusted(chip, payload, options);
+   tpm_put_ops(chip);
+   }
+   } else {
+   ret = key_unseal(payload, options);
+   }
+
+   return ret;
+}
+
+static int trusted_tpm_new(struct tpm_chip *chip,
+  struct trusted_key_payload *payload,
+  struct trusted_key_options *options)
+{
+   int ret;
+
+   ret = tpm_get_random(chip, payload->key, payload->key_len);
+   if (ret < 0)
+   return ret;
+
+   if (ret != payload->key_len)
+   return -EIO;
+
+   if (tpm_is_tpm2(chip)) {
+   ret = tpm_try_get_ops(chip);
+   if (!ret) {
+   ret = tpm2_seal_trusted(chip, payload, options);
+   tpm_put_ops(chip);
+

[PATCH 1/3] KEYS: trusted: Fix incorrect handling of tpm_get_random()

When tpm_get_random() was introduced, it defined the following API for the
return value:

1. A positive value tells how many bytes of random data was generated.
2. A negative value on error.

However, in the call sites the API was used incorrectly, i.e. as it would
only return negative values and otherwise zero. Returning he positive read
counts to the user space does not make any possible sense.

Fix this by returning -EIO when tpm_get_random() returns a positive value.

Fixes: 41ab999c80f1 ("tpm: Move tpm_get_random api into the TPM device driver")
Cc: sta...@vger.kernel.org
Cc: Mimi Zohar 
Cc: "James E.J. Bottomley" 
Cc: David Howells 
Cc: Kent Yoder 
Signed-off-by: Jarkko Sakkinen 
---
 security/keys/trusted-keys/trusted_tpm1.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/security/keys/trusted-keys/trusted_tpm1.c 
b/security/keys/trusted-keys/trusted_tpm1.c
index b9fe02e5f84f..c7b1701cdac5 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -403,9 +403,12 @@ static int osap(struct tpm_buf *tb, struct osapsess *s,
int ret;
 
ret = tpm_get_random(chip, ononce, TPM_NONCE_SIZE);
-   if (ret != TPM_NONCE_SIZE)
+   if (ret < 0)
return ret;
 
+   if (ret != TPM_NONCE_SIZE)
+   return -EIO;
+
tpm_buf_reset(tb, TPM_TAG_RQU_COMMAND, TPM_ORD_OSAP);
tpm_buf_append_u16(tb, type);
tpm_buf_append_u32(tb, handle);
@@ -496,8 +499,12 @@ static int tpm_seal(struct tpm_buf *tb, uint16_t keytype,
goto out;
 
ret = tpm_get_random(chip, td->nonceodd, TPM_NONCE_SIZE);
+   if (ret < 0)
+   return ret;
+
if (ret != TPM_NONCE_SIZE)
-   goto out;
+   return -EIO;
+
ordinal = htonl(TPM_ORD_SEAL);
datsize = htonl(datalen);
pcrsize = htonl(pcrinfosize);
@@ -601,9 +608,12 @@ static int tpm_unseal(struct tpm_buf *tb,
 
ordinal = htonl(TPM_ORD_UNSEAL);
ret = tpm_get_random(chip, nonceodd, TPM_NONCE_SIZE);
+   if (ret < 0)
+   return ret;
+
if (ret != TPM_NONCE_SIZE) {
pr_info("trusted_key: tpm_get_random failed (%d)\n", ret);
-   return ret;
+   return -EIO;
}
ret = TSS_authhmac(authdata1, keyauth, TPM_NONCE_SIZE,
   enonce1, nonceodd, cont, sizeof(uint32_t),
@@ -1013,8 +1023,12 @@ static int trusted_instantiate(struct key *key,
case Opt_new:
key_len = payload->key_len;
ret = tpm_get_random(chip, payload->key, key_len);
+   if (ret < 0)
+   goto out;
+
if (ret != key_len) {
pr_info("trusted_key: key_create failed (%d)\n", ret);
+   ret = -EIO;
goto out;
}
if (tpm2)
-- 
2.25.1

Re: [PATCH] rcu,ftrace: Fix ftrace recursion

2020-10-04 Thread Paul E. McKenney

On Tue, Sep 29, 2020 at 01:04:49PM -0400, Steven Rostedt wrote:
> On Tue, 29 Sep 2020 09:56:40 -0700
> "Paul E. McKenney"  wrote:
> 
> > > Well, I think we should actually apply both, but the comment needs to be
> > > updated, as it will no longer be outside recursion. And the comment is
> > > wrong now as well, as its only outside recursion protection for the
> > > assist_func(). 
> > > 
> > > But it does prevent it from being always called for perf.
> > > 
> > >  * Make notrace because it can be called by the internal functions of
> > >  * ftrace, and making this notrace removes unnecessary recursion calls.  
> > 
> > Fair enough.  ;-)
> > 
> > If I don't hear otherwise by late today (Tuesday), Pacific Time, I will
> > update the comment and pull it into -rcu.  If you guys have some other
> > route to mainline in mind, you have my Reviewed-by.  Either way, just
> > let me know.
> 
> I'm currently testing the recursion fix and will push that to Linus when
> done. But you can take the comment update through your tree.
> 
> Peter, are you OK if Paul changes your comment to what I suggested?

Hearing no objections, I have queued the patch with the comment updated
as suggested by Steven.  Thank you all!

Thanx, Paul

Re: [PATCH 04/14] drm/msm: Add priv->mm_lock to protect active/inactive lists

2020-10-04 Thread Rob Clark

On Sun, Oct 4, 2020 at 3:15 PM Daniel Vetter  wrote:
>
> On Sun, Oct 4, 2020 at 9:21 PM Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > Rather than relying on the big dev->struct_mutex hammer, introduce a
> > more specific lock for protecting the bo lists.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/msm_debugfs.c  |  7 +++
> >  drivers/gpu/drm/msm/msm_drv.c  |  1 +
> >  drivers/gpu/drm/msm/msm_drv.h  | 13 +++-
> >  drivers/gpu/drm/msm/msm_gem.c  | 28 +++---
> >  drivers/gpu/drm/msm/msm_gem_shrinker.c | 12 +++
> >  drivers/gpu/drm/msm/msm_gpu.h  |  5 -
> >  6 files changed, 52 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
> > b/drivers/gpu/drm/msm/msm_debugfs.c
> > index ee2e270f464c..64afbed89821 100644
> > --- a/drivers/gpu/drm/msm/msm_debugfs.c
> > +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> > @@ -112,6 +112,11 @@ static int msm_gem_show(struct drm_device *dev, struct 
> > seq_file *m)
> >  {
> > struct msm_drm_private *priv = dev->dev_private;
> > struct msm_gpu *gpu = priv->gpu;
> > +   int ret;
> > +
> > +   ret = mutex_lock_interruptible(>mm_lock);
> > +   if (ret)
> > +   return ret;
> >
> > if (gpu) {
> > seq_printf(m, "Active Objects (%s):\n", gpu->name);
> > @@ -121,6 +126,8 @@ static int msm_gem_show(struct drm_device *dev, struct 
> > seq_file *m)
> > seq_printf(m, "Inactive Objects:\n");
> > msm_gem_describe_objects(>inactive_list, m);
> >
> > +   mutex_unlock(>mm_lock);
> > +
> > return 0;
> >  }
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index 49685571dc0e..dc6efc089285 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -441,6 +441,7 @@ static int msm_drm_init(struct device *dev, struct 
> > drm_driver *drv)
> > init_llist_head(>free_list);
> >
> > INIT_LIST_HEAD(>inactive_list);
> > +   mutex_init(>mm_lock);
>
> I highly recommend you drop a
>
> fs_reclaim_acquire(GFP_KERNEL);
> might_lock(>mm_lock);
> fs_reclaim_release(GFP_KERNEL);
>
> in here to teach lockdep about your ordering against the shrinker.
> Gives you full testing every boot, even if your shrinker never gets
> called.

Good idea..

(tbf, I have tested this with android+lockdep which pretty is great
shrinker exercise.. but immediate notification of future problems is a
good plan)

BR,
-R

Re: [PATCH v4] staging: qlge: fix build breakage with dumping enabled

2020-10-04 Thread Benjamin Poirier

On 2020-10-04 23:22 +0800, Coiby Xu wrote:
> On Sat, Oct 03, 2020 at 02:53:48PM +0900, Benjamin Poirier wrote:
> > On 2020-10-03 07:59 +0800, Coiby Xu wrote:
> > > This fixes commit 0107635e15ac
> > > ("staging: qlge: replace pr_err with netdev_err") which introduced an
> > > build breakage of missing `struct ql_adapter *qdev` for some functions
> > > and a warning of type mismatch with dumping enabled, i.e.,
> > > 
> > > $ make CFLAGS_MODULE="-DQL_ALL_DUMP -DQL_OB_DUMP -DQL_CB_DUMP \
> > > -DQL_IB_DUMP -DQL_REG_DUMP -DQL_DEV_DUMP" M=drivers/staging/qlge
> > > 
> > > qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’:
> > > qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this 
> > > function); did you mean ‘cdev’?
> > >  2051 |  netdev_err(qdev->ndev, "%s\n", __func__);
> > >   | ^~~~
> > > qlge_dbg.c: In function ‘ql_dump_routing_entries’:
> > > qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char 
> > > *’, but argument 3 has type ‘int’ [-Wformat=]
> > >  1435 |"%s: Routing Mask %d = 0x%.08x\n",
> > >   | ~^
> > >   |  |
> > >   |  char *
> > >   | %d
> > >  1436 |i, value);
> > >   |~
> > >   ||
> > >   |int
> > > qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned 
> > > int’ argument [-Wformat=]
> > >  1435 |"%s: Routing Mask %d = 0x%.08x\n",
> > >   | ^
> > >   | |
> > >   | unsigned int
> > > 
> > > Note that now ql_dump_rx_ring/ql_dump_tx_ring won't check if the passed
> > > parameter is a null pointer.
> > > 
> > > Fixes: 0107635e15ac ("staging: qlge: replace pr_err with netdev_err")
> > > Reported-by: Benjamin Poirier 
> > > Suggested-by: Benjamin Poirier 
> > > Signed-off-by: Coiby Xu 
> > > ---
> > 
> > Reviewed-by: Benjamin Poirier 
> 
> Thank you! Btw, I guess when this patch is picked, the "Reviewed-by" tag
> will also be included. So I needn't to send another patch, am I right?

I think so. Maintainers usually take care of adding attribution tags
from followup emails and that's what Greg has done for your previous
qlge patch it looks like.

[PATCH net-next v2 1/2] mptcp: Constify mptcp_pm_ops

2020-10-04 Thread Rikard Falkeborn

The only usages of mptcp_pm_ops is to assign its address to the small_ops
field of the genl_family struct, which is a const pointer, and applying
ARRAY_SIZE() on it. Make it const to allow the compiler to put it in
read-only memory.

Signed-off-by: Rikard Falkeborn 
---
 net/mptcp/pm_netlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index 9f9cd41b7733..0d6f3d912891 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -1054,7 +1054,7 @@ mptcp_nl_cmd_get_limits(struct sk_buff *skb, struct 
genl_info *info)
return -EMSGSIZE;
 }
 
-static struct genl_small_ops mptcp_pm_ops[] = {
+static const struct genl_small_ops mptcp_pm_ops[] = {
{
.cmd= MPTCP_PM_CMD_ADD_ADDR,
.doit   = mptcp_nl_cmd_add_addr,
-- 
2.28.0

[PATCH net-next v2 2/2] net: openvswitch: Constify static struct genl_small_ops

2020-10-04 Thread Rikard Falkeborn

The only usage of these is to assign their address to the small_ops field
in the genl_family struct, which is a const pointer, and applying
ARRAY_SIZE() on them. Make them const to allow the compiler to put them
in read-only memory.

Signed-off-by: Rikard Falkeborn 
---
 net/openvswitch/conntrack.c | 2 +-
 net/openvswitch/meter.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 18af10b7ef0e..e6fe26a9c892 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -2231,7 +2231,7 @@ static int ovs_ct_limit_cmd_get(struct sk_buff *skb, 
struct genl_info *info)
return err;
 }
 
-static struct genl_small_ops ct_limit_genl_ops[] = {
+static const struct genl_small_ops ct_limit_genl_ops[] = {
{ .cmd = OVS_CT_LIMIT_CMD_SET,
.validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN
diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c
index 50541e874726..8fbefd52af7f 100644
--- a/net/openvswitch/meter.c
+++ b/net/openvswitch/meter.c
@@ -672,7 +672,7 @@ bool ovs_meter_execute(struct datapath *dp, struct sk_buff 
*skb,
return false;
 }
 
-static struct genl_small_ops dp_meter_genl_ops[] = {
+static const struct genl_small_ops dp_meter_genl_ops[] = {
{ .cmd = OVS_METER_CMD_FEATURES,
.validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
.flags = 0,   /* OK for unprivileged users. */
-- 
2.28.0

[PATCH net-next v2 0/2] net: Constify struct genl_small_ops

2020-10-04 Thread Rikard Falkeborn

Make a couple of static struct genl_small_ops const to allow the compiler
to put them in read-only memory. Patches are independent.

v2: Rebase on net-next, genl_ops -> genl_small_ops

Rikard Falkeborn (2):
  mptcp: Constify mptcp_pm_ops
  net: openvswitch: Constify static struct genl_small_ops

 net/mptcp/pm_netlink.c  | 2 +-
 net/openvswitch/conntrack.c | 2 +-
 net/openvswitch/meter.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.28.0

riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1251: undefined reference to `mlx5_fill_page_frag_array_perm'

2020-10-04 Thread kernel test robot

Hi Eli,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   22fbc037cd32e4e6771d2271b565806cfb8c134c
commit: 1a86b377aa2147a7c866b03142e848c18e5f3cb8 vdpa/mlx5: Add VDPA driver for 
supported mlx5 devices
date:   9 weeks ago
config: riscv-randconfig-r036-20201005 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a86b377aa2147a7c866b03142e848c18e5f3cb8
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 1a86b377aa2147a7c866b03142e848c18e5f3cb8
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   riscv32-linux-ld: drivers/vdpa/mlx5/net/main.o: in function `mlx5_vdpa_exit':
   drivers/vdpa/mlx5/net/main.c:72: undefined reference to 
`mlx5_unregister_interface'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/main.o: in function `mlx5_vdpa_init':
   drivers/vdpa/mlx5/net/main.c:67: undefined reference to 
`mlx5_register_interface'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`qp_prepare':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:350: undefined reference to 
`mlx5_fill_page_frag_array'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`create_tir':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:1244: undefined reference to 
`mlx5_frag_buf_alloc_node'
>> riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1251: undefined 
>> reference to `mlx5_fill_page_frag_array_perm'
>> riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1252: undefined 
>> reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`create_umem':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:623: undefined reference to 
`mlx5_frag_buf_free'
>> riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:650: undefined reference 
>> to `mlx5_frag_buf_alloc_node'
>> riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:651: undefined reference 
>> to `mlx5_db_alloc'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function `umem_size':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:605: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function `qp_create':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:373: undefined reference to `mlx5_db_free'
>> riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:376: undefined reference 
>> to `mlx5_frag_buf_free'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:402: undefined reference 
to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`alloc_inout':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:889: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:904: undefined reference 
to `mlx5_cmd_exec'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:922: undefined reference 
to `mlx5_db_alloc'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:926: undefined reference 
to `mlx5_frag_buf_alloc_node'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function `modify_qp':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:967: undefined reference to 
`mlx5_fill_page_frag_array'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`modify_virtqueue':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:1044: undefined reference to 
`mlx5_vector2eqn'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1061: undefined 
reference to `mlx5_core_create_cq'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`suspend_vq':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:1137: undefined reference to 
`mlx5_frag_buf_free'
>> riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1137: undefined 
>> reference to `mlx5_db_free'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1143: undefined 
reference to `mlx5_core_destroy_cq'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`mlx5_vdpa_set_vq_ready':
   drivers/vdpa/mlx5/net/mlx5_vnet.c:1376: undefined reference to 
`mlx5_frag_buf_free'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.c:1378: undefined 
reference to `mlx5_db_free'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`mlx5_init_fbc_offset':
   include/linux/mlx5/driver.h:846: undefined reference to `mlx5_cmd_exec'
   riscv32-linux-ld: include/linux/mlx5/driver.h:848: undefined reference to 
`mlx5_frag_buf_free'
   riscv32-linux-ld: drivers/vdpa/mlx5/net/mlx5_vnet.o: in function 
`umem_destroy':

Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver