Re: [PATCH 1/3] thermal: core: Add indication for userspace usage

2020-11-29 Thread Daniel Lezcano


[Added Srinivas]

On 28/11/2020 18:54, Kai-Heng Feng wrote:
> We are seeing thermal shutdown on Intel based mobile workstations, the
> shutdown happens during the first trip handle in
> thermal_zone_device_register():
> kernel: thermal thermal_zone15: critical temperature reached (101 C), 
> shutting down
> 
> However, we shouldn't do a thermal shutdown here, since
> 1) We may want to use a dedicated daemon, Intel's thermald in this case,
> to handle thermal shutdown.
> 
> 2) For ACPI based system, _CRT doesn't mean shutdown unless it's inside
> ThermalZone. ACPI Spec, 11.4.4 _CRT (Critical Temperature):
> "... If this object it present under a device, the device’s driver
> evaluates this object to determine the device’s critical cooling
> temperature trip point. This value may then be used by the device’s
> driver to program an internal device temperature sensor trip point."
> 
> So a "critical trip" here merely means we should take a more aggressive
> cooling method.

Well, actually it is stated before:

"This object, when defined under a thermal zone, returns the critical
temperature at which OSPM must shutdown the system".

That is what does the thermal subsystem, no ?

> So add an indication to let thermal core know it should leave thermal
> device to userspace to handle.

You may want to check the 'HOT' trip point and then use the notification
mechanism to get notified in userspace and take action from there (eg.
offline some CPUs).

> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/thermal/thermal_core.c | 3 +++
>  include/linux/thermal.h| 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index c6d74bc1c90b..6561e3767529 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1477,6 +1477,9 @@ thermal_zone_device_register(const char *type, int 
> trips, int mask,
>   goto unregister;
>   }
>  
> + if (tz->tzp && tz->tzp->userspace)
> + thermal_zone_device_disable(tz);
> +
>   mutex_lock(_list_lock);
>   list_add_tail(>node, _tz_list);
>   mutex_unlock(_list_lock);
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index d07ea27e72a9..e8e8fac78fc8 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -247,6 +247,8 @@ struct thermal_zone_params {
>*/
>   bool no_hwmon;
>  
> + bool userspace;
> +
>   int num_tbps;   /* Number of tbp entries */
>   struct thermal_bind_params *tbp;
>  
> 


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


Re: [GIT pull] locking/urgent for v5.10-rc6

2020-11-29 Thread Peter Zijlstra
On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote:
> On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner  wrote:
> >
> > Yet two more places which invoke tracing from RCU disabled regions in the
> > idle path. Similar to the entry path the low level idle functions have to
> > be non-instrumentable.
> 
> This really seems less than optimal.
> 
> In particular, lookie here:
> 
> > @@ -94,9 +94,35 @@ void __cpuidle default_idle_call(void)
> >
> > trace_cpu_idle(1, smp_processor_id());
> > stop_critical_timings();
> > +
> > +   /*
> > +* arch_cpu_idle() is supposed to enable IRQs, however
> > +* we can't do that because of RCU and tracing.
> > +*
> > +* Trace IRQs enable here, then switch off RCU, and have
> > +* arch_cpu_idle() use raw_local_irq_enable(). Note that
> > +* rcu_idle_enter() relies on lockdep IRQ state, so switch 
> > that
> > +* last -- this is very similar to the entry code.
> > +*/
> > +   trace_hardirqs_on_prepare();
> > +   lockdep_hardirqs_on_prepare(_THIS_IP_);
> > rcu_idle_enter();
> > +   lockdep_hardirqs_on(_THIS_IP_);
> > +
> > arch_cpu_idle();
> > +
> > +   /*
> > +* OK, so IRQs are enabled here, but RCU needs them 
> > disabled to
> > +* turn itself back on.. funny thing is that disabling IRQs
> > +* will cause tracing, which needs RCU. Jump through hoops 
> > to
> > +* make it 'work'.
> > +*/
> > +   raw_local_irq_disable();
> > +   lockdep_hardirqs_off(_THIS_IP_);
> > rcu_idle_exit();
> > +   lockdep_hardirqs_on(_THIS_IP_);
> > +   raw_local_irq_enable();
> > +
> > start_critical_timings();
> > trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> > }
> 
> And look at what the code generation for the idle exit path is when
> lockdep isn't even on.

Agreed.

The idea was to flip all of arch_cpu_idle() to not enable interrupts.

This is suboptimal for things like x86 where arch_cpu_idle() is
basically STI;HLT, but x86 isn't likely to actually use this code path
anyway, given all the various cpuidle drivers it has.

Many of the other archs are now doing things like arm's:
wfi();raw_local_irq_enable().

Doing that tree-wide interrupt-state flip was something I didn't want to
do at this late a stage, the chanse of messing that up is just too high.

After that I need to go look at flipping cpuidle, which is even more
'interesting'. cpuidle_enter() has the exact same semantics, and this is
the code path that x86 actually uses, and here it's inconsitent at best.


Re: [RESEND PATCH V20 3/3] Input: new da7280 haptic driver

2020-11-29 Thread Dmitry Torokhov
Hi Roy,

On Thu, Nov 26, 2020 at 01:07:39AM +0900, Roy Im wrote:
> Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
> multiple mode and integrated waveform memory and wideband support.
> It communicates via an I2C bus to the device.

I am looking at the driver and should finish review tomorrow. If you do
not hear from me by Wednesday please poke me again - I want to get the
driver into the upcoming merge window.

Thanks!

-- 
Dmitry


Re: [PATCH v2 0/8] Venus stateful encoder compliance

2020-11-29 Thread Stanimir Varbanov
Hi Fritz,

On 11/29/20 9:17 PM, Fritz Koenig wrote:
> Since this patchset adds support for V4L2_ENC_CMD_STOP and
> VENUS_ENC_STATE_ENCODING it should also add support for
> VIDIOC_TRY_ENCODER_CMD so that those commands are discoverable.  I've

6/8 is adding it:

+   .vidioc_try_encoder_cmd = v4l2_m2m_ioctl_try_encoder_cmd,

> made an attempt at that here:
> https://www.spinics.net/lists/linux-media/msg182319.html
> 
> On Wed, Nov 11, 2020 at 6:38 AM Stanimir Varbanov
>  wrote:
>>
>> Hello,
>>
>> Here is v2 of the subject patchset.
>>
>> The patchset starts with few small preparation and fix patches, 1/8 to 5/8.
>> 6/8 is redesigned Dikshita's patch and 7/8 add Reset encoder state handling.
>> The last 8/8 just delete not needed helper function.
>>
>> The major changes are:
>>  * An attempt to reuse m2m helpers for drain and reset state in 6/8 and 7/8.
>>  * Use null encoder buffer to signal end-of-stream in 6/8.
>>
>> Comments are welcome!
>>
>> regards,
>> Stan
>>
>> Dikshita Agarwal (1):
>>   venus: venc: add handling for VIDIOC_ENCODER_CMD
>>
>> Stanimir Varbanov (7):
>>   venus: hfi: Use correct state in unload resources
>>   venus: helpers: Add a new helper for buffer processing
>>   venus: hfi_cmds: Allow null buffer address on encoder input
>>   venus: helpers: Calculate properly compressed buffer size
>>   venus: pm_helpers: Check instance state when calculate instance
>> frequency
>>   venus: venc: Handle reset encoder state
>>   venus: helpers: Delete unused stop streaming helper
>>
>>  drivers/media/platform/qcom/venus/helpers.c   |  65 ++---
>>  drivers/media/platform/qcom/venus/helpers.h   |   2 +-
>>  drivers/media/platform/qcom/venus/hfi.c   |   2 +-
>>  drivers/media/platform/qcom/venus/hfi.h   |   1 -
>>  drivers/media/platform/qcom/venus/hfi_cmds.c  |   2 +-
>>  .../media/platform/qcom/venus/pm_helpers.c|   3 +
>>  drivers/media/platform/qcom/venus/venc.c  | 232 +++---
>>  7 files changed, 226 insertions(+), 81 deletions(-)
>>
>> --
>> 2.17.1
>>

-- 
regards,
Stan


[PATCH v3 6/9] misc: xilinx-ai-engine: add request and release tiles

2020-11-29 Thread Wendy Liang
Add request/release and related clock gating functions to AI engine
driver:
* scanning when the partition is being requested to know which tiles
  are in use.
* check if a tile is gated or not
* tiles requesting and releasing ioctl so that user application can
  enable/disable tiles at runtime.

Signed-off-by: Wendy Liang 
Reviewed-by: Hyun Kwon 
---
 drivers/misc/xilinx-ai-engine/Makefile |   1 +
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  | 225 +++
 drivers/misc/xilinx-ai-engine/ai-engine-clock.c| 245 +
 drivers/misc/xilinx-ai-engine/ai-engine-dev.c  |  19 +-
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h |  34 +++
 drivers/misc/xilinx-ai-engine/ai-engine-part.c |  32 +++
 drivers/misc/xilinx-ai-engine/ai-engine-res.c  |  51 +
 include/uapi/linux/xlnx-ai-engine.h|  31 +++
 8 files changed, 631 insertions(+), 7 deletions(-)
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-clock.c

diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
b/drivers/misc/xilinx-ai-engine/Makefile
index 1b743fa..2e67b25 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_XILINX_AIE)   += xilinx-aie.o
 
 xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
+  ai-engine-clock.o \
   ai-engine-dev.o \
   ai-engine-dma.o \
   ai-engine-mem.o \
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index ac95aff..ff721b3 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -41,6 +41,9 @@
 #define AIE_SHIMPL_SHIMRST_MASK0x1U
 #define AIE_SHIMPL_COLRST_MASK 0x1U
 #define AIE_SHIMPL_CLKCNTR_COLBUF_MASK 0x1U
+#define AIE_SHIMPL_CLKCNTR_NEXTCLK_MASKBIT(1)
+#define AIE_TILE_CLKCNTR_COLBUF_MASK   BIT(0)
+#define AIE_TILE_CLKCNTR_NEXTCLK_MASK  BIT(1)
 
 /*
  * AI engine SHIM reset ID.
@@ -221,10 +224,232 @@ static int aie_reset_shim(struct aie_device *adev, 
struct aie_range *range)
return 0;
 }
 
+static int aie_init_part_clk_state(struct aie_partition *apart)
+{
+   int ret, num_tiles;
+
+   num_tiles = apart->range.size.col * (apart->range.size.row - 1);
+
+   ret = aie_resource_initialize(>cores_clk_state, num_tiles);
+   if (ret) {
+   dev_err(>dev,
+   "failed to initialize cores clock state resource.\n");
+   return ret;
+   }
+
+   ret = aie_resource_initialize(>tiles_inuse, num_tiles);
+   if (ret) {
+   dev_err(>dev,
+   "failed to initialize tiles in use resource.\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static int aie_scan_part_clocks(struct aie_partition *apart)
+{
+   struct aie_device *adev = apart->adev;
+   struct aie_range *range = >range;
+   struct aie_location loc;
+
+   /* Clear the bitmap of cores and memories clock state */
+   aie_resource_put_region(>cores_clk_state, 0,
+   apart->cores_clk_state.total);
+
+   for (loc.col = range->start.col;
+loc.col < range->start.col + range->size.col;
+loc.col++) {
+   for (loc.row = range->start.row;
+loc.row < range->start.row + range->size.row - 1;
+loc.row++) {
+   void __iomem *va;
+   u32 val, nbitpos;
+
+   /*
+* Reading registers of the current tile to see the next
+* tile is clock gated.
+*/
+   nbitpos = loc.col * (range->size.row - 1) + loc.row;
+
+   if (aie_get_tile_type() != AIE_TILE_TYPE_TILE) {
+   /* Checks shim tile for next core tile */
+   va = adev->base +
+aie_cal_regoff(adev, loc,
+   AIE_SHIMPL_CLKCNTR_REGOFF);
+   val = ioread32(va);
+
+   /*
+* check if the clock buffer and the next clock
+* tile is set, if one of them is not set, the
+* tiles of the column are clock gated.
+*/
+   if (!(val & AIE_SHIMPL_CLKCNTR_COLBUF_MASK) ||
+   !(val & AIE_SHIMPL_CLKCNTR_NEXTCLK_MASK))
+   break;
+
+   /* Set next tile in the row clock state on */
+   

Re: [RFC PATCH v3.1 16/27] mmc: sdhci-uhs2: add set_ios()

2020-11-29 Thread AKASHI Takahiro
On Thu, Nov 26, 2020 at 10:17:11AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > This is a sdhci version of mmc's set_ios operation.
> > It covers both UHS-I and UHS-II.
> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/mmc/host/sdhci-uhs2.c | 100 ++
> >  drivers/mmc/host/sdhci-uhs2.h |   1 +
> >  drivers/mmc/host/sdhci.c  |  40 +-
> >  drivers/mmc/host/sdhci.h  |   2 +
> >  4 files changed, 128 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> > index d9e98c097bfe..637464748cc4 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.c
> > +++ b/drivers/mmc/host/sdhci-uhs2.c
> > @@ -263,6 +263,74 @@ void sdhci_uhs2_set_timeout(struct sdhci_host *host, 
> > struct mmc_command *cmd)
> >  }
> >  EXPORT_SYMBOL_GPL(sdhci_uhs2_set_timeout);
> >  
> > +/**
> > + * sdhci_uhs2_clear_set_irqs - set Error Interrupt Status Enable register
> > + * @host:  SDHCI host
> > + * @clear: bit-wise clear mask
> > + * @set:   bit-wise set mask
> > + *
> > + * Set/unset bits in UHS-II Error Interrupt Status Enable register
> > + */
> > +void sdhci_uhs2_clear_set_irqs(struct sdhci_host *host, u32 clear, u32 set)
> > +{
> > +   u32 ier;
> > +
> > +   ier = sdhci_readl(host, SDHCI_UHS2_ERR_INT_STATUS_EN);
> > +   ier &= ~clear;
> > +   ier |= set;
> > +   sdhci_writel(host, ier, SDHCI_UHS2_ERR_INT_STATUS_EN);
> > +   sdhci_writel(host, ier, SDHCI_UHS2_ERR_INT_SIG_EN);
> > +}
> > +EXPORT_SYMBOL_GPL(sdhci_uhs2_clear_set_irqs);
> > +
> > +static void __sdhci_uhs2_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> > +{
> > +   struct sdhci_host *host = mmc_priv(mmc);
> > +   u8 cmd_res, dead_lock;
> > +   u16 ctrl_2;
> > +   unsigned long flags;
> > +
> > +   /* FIXME: why lock? */
> > +   spin_lock_irqsave(>lock, flags);
> > +
> > +   /* UHS2 Timeout Control */
> > +   sdhci_calc_timeout_uhs2(host, _res, _lock);
> > +
> > +   /* change to use calculate value */
> > +   cmd_res |= dead_lock << SDHCI_UHS2_TIMER_CTRL_DEADLOCK_SHIFT;
> > +
> > +   sdhci_uhs2_clear_set_irqs(host,
> > + SDHCI_UHS2_ERR_INT_STATUS_RES_TIMEOUT |
> > + SDHCI_UHS2_ERR_INT_STATUS_DEADLOCK_TIMEOUT,
> > + 0);
> > +   sdhci_writeb(host, cmd_res, SDHCI_UHS2_TIMER_CTRL);
> > +   sdhci_uhs2_clear_set_irqs(host, 0,
> > + SDHCI_UHS2_ERR_INT_STATUS_RES_TIMEOUT |
> > + SDHCI_UHS2_ERR_INT_STATUS_DEADLOCK_TIMEOUT);
> > +
> > +   /* UHS2 timing */
> > +   ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> > +   if (ios->timing == MMC_TIMING_UHS2)
> > +   ctrl_2 |= SDHCI_CTRL_UHS_2 | SDHCI_CTRL_UHS2_INTERFACE_EN;
> > +   else
> > +   ctrl_2 &= ~(SDHCI_CTRL_UHS_2 | SDHCI_CTRL_UHS2_INTERFACE_EN);
> > +   sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> > +
> > +   if (!(host->quirks2 & SDHCI_QUIRK2_PRESET_VALUE_BROKEN))
> > +   sdhci_enable_preset_value(host, true);
> > +
> > +   if (host->ops->set_power)
> > +   host->ops->set_power(host, ios->power_mode, ios->vdd);
> > +   else
> > +   sdhci_set_power(host, ios->power_mode, ios->vdd);
> > +   udelay(100);
> > +
> > +   host->timing = ios->timing;
> > +   sdhci_set_clock(host, host->clock);
> 
> sdhci_set_ios_common() already called ->set_clock() and ->set_power(), so I
> am not really following what is going on here.  Can you explain some more?

To be frank, I don't know. The logic in Intel's (and/or Ben's?)
original code does so.
What I changed is to remove the code of setting (ios->vdd and) ios->vdd2,
which is executed before calling set_power(), in __sdhci_uhs2_set_ios().

So yes, effectively it may be of no use to call set_power() here.

-Takahiro Akashi

> > +
> > +   spin_unlock_irqrestore(>lock, flags);
> > +}
> > +
> >  
> > /*\
> >   * 
> >   *
> >   * MMC callbacks   
> >   *
> > @@ -286,6 +354,37 @@ static int 
> > sdhci_uhs2_start_signal_voltage_switch(struct mmc_host *mmc,
> > return sdhci_start_signal_voltage_switch(mmc, ios);
> >  }
> >  
> > +void sdhci_uhs2_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> > +{
> > +   struct sdhci_host *host = mmc_priv(mmc);
> > +
> > +   if (!(host->version >= SDHCI_SPEC_400) ||
> > +   !(host->mmc->flags & MMC_UHS2_SUPPORT &&
> > + host->mmc->caps & MMC_CAP_UHS2)) {
> > +   sdhci_set_ios(mmc, ios);
> > +   return;
> > +   }
> > +
> > +   if (ios->power_mode == MMC_POWER_UNDEFINED)
> > +   return;
> > +
> > +   if (host->flags & SDHCI_DEVICE_DEAD) {
> > +   if (!IS_ERR(mmc->supply.vmmc) &&
> > +   ios->power_mode == MMC_POWER_OFF)
> > +  

Re: [PATCH v2 4/8] venus: helpers: Calculate properly compressed buffer size

2020-11-29 Thread Stanimir Varbanov



On 11/29/20 8:07 AM, Fritz Koenig wrote:
> On Wed, Nov 11, 2020 at 6:38 AM Stanimir Varbanov
>  wrote:
>>
>> For resolutions below 720p the size of the compressed buffer must
>> be bigger. Correct this by checking the resolution when calculating
>> buffer size and multiply by four.
> 
> I'm confused because the commit message doesn't appear to line up with
> the code.  It says multiply by four here, but the code has by eight.

Yes, it is confusing. I will correct it in next version.

> 
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/platform/qcom/venus/helpers.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/venus/helpers.c 
>> b/drivers/media/platform/qcom/venus/helpers.c
>> index 688e3e3e8362..490c026b58a3 100644
>> --- a/drivers/media/platform/qcom/venus/helpers.c
>> +++ b/drivers/media/platform/qcom/venus/helpers.c
>> @@ -986,6 +986,8 @@ u32 venus_helper_get_framesz(u32 v4l2_fmt, u32 width, 
>> u32 height)
>>
>> if (compressed) {
>> sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
>> +   if (width < 1280 || height < 720)
>> +   sz *= 8;
>> return ALIGN(sz, SZ_4K);
>> }
>>
>> --
>> 2.17.1
>>

-- 
regards,
Stan


[PATCH v3 9/9] misc: xilinx-ai-engine: Add support for servicing error interrupts

2020-11-29 Thread Wendy Liang
From: Nishad Saraf 

AI engine errors events can be routed to generate interrupt. The
errors events routing will be done during AI engine configuration.
At runtime, Linux kernel AI engine driver monitors the interrupt and
backtracks errors events.
As error events from 400 AIE tiles and 50 shim tiles are channeled on
a single interrupt line, backtracking the source the interrupt to an
AIE module is required. To keep the top-half interrupt short,
backtracking is deferred to bottom half by scheduling a task in shared
workqueue.

Signed-off-by: Nishad Saraf 
Signed-off-by: Wendy Liang 
---
 drivers/misc/xilinx-ai-engine/Makefile |   1 +
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  | 121 
 drivers/misc/xilinx-ai-engine/ai-engine-dev.c  |  14 +
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 144 +
 .../misc/xilinx-ai-engine/ai-engine-interrupt.c| 659 +
 drivers/misc/xilinx-ai-engine/ai-engine-part.c |  44 ++
 drivers/misc/xilinx-ai-engine/ai-engine-res.c  |  54 ++
 7 files changed, 1037 insertions(+)
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-interrupt.c

diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
b/drivers/misc/xilinx-ai-engine/Makefile
index 2e67b25..9607ecb 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -9,6 +9,7 @@ xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
   ai-engine-clock.o \
   ai-engine-dev.o \
   ai-engine-dma.o \
+  ai-engine-interrupt.o \
   ai-engine-mem.o \
   ai-engine-part.o \
   ai-engine-res.o \
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index ff721b3..af0f997 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -33,7 +33,10 @@
 #define AIE_SHIMPL_CLKCNTR_REGOFF  0x00036040U
 #define AIE_SHIMPL_COLRESET_REGOFF 0x00036048U
 #define AIE_SHIMPL_RESET_REGOFF0x0003604cU
+#define AIE_SHIMPL_GROUP_ERROR_REGOFF  0x0003450cU
 #define AIE_TILE_CORE_CLKCNTR_REGOFF   0x00036040U
+#define AIE_TILE_CORE_GROUP_ERROR_REGOFF   0x00034510U
+#define AIE_TILE_MEM_GROUP_ERROR_REGOFF0x00014514U
 
 /*
  * Register masks
@@ -93,11 +96,27 @@ static const struct aie_tile_regs aie_kernel_regs[] = {
 .soff = AIE_SHIMPL_CLKCNTR_REGOFF,
 .eoff = AIE_SHIMPL_CLKCNTR_REGOFF,
},
+   /* SHIM group error enable */
+   {.attribute = (AIE_TILE_TYPE_SHIMPL | AIE_TILE_TYPE_SHIMNOC) <<
+ AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_SHIMPL_GROUP_ERROR_REGOFF,
+.eoff = AIE_SHIMPL_GROUP_ERROR_REGOFF,
+   },
/* Tile clock control */
{.attribute = AIE_TILE_TYPE_TILE << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
 .soff = AIE_TILE_CORE_CLKCNTR_REGOFF,
 .eoff = AIE_TILE_CORE_CLKCNTR_REGOFF,
},
+   /* Tile group error for core module */
+   {.attribute = AIE_TILE_TYPE_TILE << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_TILE_CORE_GROUP_ERROR_REGOFF,
+.eoff = AIE_TILE_CORE_GROUP_ERROR_REGOFF,
+   },
+   /* Tile group error for memory module */
+   {.attribute = AIE_TILE_TYPE_TILE << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_TILE_MEM_GROUP_ERROR_REGOFF,
+.eoff = AIE_TILE_MEM_GROUP_ERROR_REGOFF,
+   },
 };
 
 static const struct aie_single_reg_field aie_col_rst = {
@@ -128,6 +147,103 @@ static const struct aie_dma_attr aie_shimdma = {
.bd_len = 0x14U,
 };
 
+static const struct aie_event_attr aie_pl_event = {
+   .bc_event = {
+   .mask = GENMASK(6, 0),
+   .regoff = 0x0U,
+   },
+   .group_error = {
+   .mask = GENMASK(10, 0),
+   .regoff = 0xcU,
+   },
+   .bc_regoff = 0x34010U,
+   .status_regoff = 0x34200U,
+   .group_regoff = 0x34500U,
+   .base_error_event = 62U,
+   .num_broadcasts = 16U,
+   .base_bc_event = 107U,
+   .num_events = 128U,
+};
+
+static const struct aie_event_attr aie_mem_event = {
+   .bc_event = {
+   .mask = GENMASK(6, 0),
+   .regoff = 0x0U,
+   },
+   .group_error = {
+   .mask = GENMASK(13, 0),
+   .regoff = 0x14U,
+   },
+   .bc_regoff = 0x14010U,
+   .status_regoff = 0x14200U,
+   .group_regoff = 0x14500U,
+   .base_error_event = 87U,
+   .num_broadcasts = 16U,
+   .base_bc_event = 107U,
+   .num_events = 128U,
+};
+
+static const struct aie_event_attr aie_core_event = {
+   .bc_event = {
+   .mask = GENMASK(6, 0),
+   .regoff = 0x0U,
+   },
+   

[PATCH v3 4/9] misc: xilinx-ai-engine: expose AI engine tile memories to userspace

2020-11-29 Thread Wendy Liang
There is no concern to have userspace to directly access AI engine
program and data memories. It will be much faster to directly copy
data to and from these memories from userspace.

We choose to use DMA buf for the data and program memory because of the
DMA buf features. DMA buf can share the DMA memory between applications
and different devices, which can benefit on how to share data with AI
engine device in future.

There is one DMA buf per type of memory in an AI engine partition. e.g.
There is one DMA buf for all the tile core program memories in an AI
engine partition. There is another DMA buf for all the tile data
memories in an AI engine partition.

Signed-off-by: Wendy Liang 
Reviewed-by: Hyun Kwon 
---
 drivers/misc/xilinx-ai-engine/Makefile |   1 +
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  |  36 +++
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h |  30 +++
 drivers/misc/xilinx-ai-engine/ai-engine-mem.c  | 275 +
 drivers/misc/xilinx-ai-engine/ai-engine-part.c |  47 
 drivers/misc/xilinx-ai-engine/ai-engine-reset.c|  38 +++
 include/uapi/linux/xlnx-ai-engine.h|  50 
 7 files changed, 477 insertions(+)
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-mem.c

diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
b/drivers/misc/xilinx-ai-engine/Makefile
index 39bec61..2dbed42 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_XILINX_AIE)+= xilinx-aie.o
 
 xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
   ai-engine-dev.o \
+  ai-engine-mem.o \
   ai-engine-part.o \
   ai-engine-res.o \
   ai-engine-reset.o
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index 36127f0..7fce2f00 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -12,10 +12,14 @@
 
 #include "ai-engine-internal.h"
 
+#define KBYTES(n)  ((n) * 1024)
+
 #define AIE_ARRAY_SHIFT30U
 #define AIE_COL_SHIFT  23U
 #define AIE_ROW_SHIFT  18U
 
+#define NUM_MEMS_PER_TILE  2U
+
 /*
  * Registers offsets
  */
@@ -114,6 +118,37 @@ static u32 aie_get_tile_type(struct aie_location *loc)
return AIE_TILE_TYPE_SHIMNOC;
 }
 
+static unsigned int aie_get_mem_info(struct aie_range *range,
+struct aie_part_mem *pmem)
+{
+   unsigned int i;
+
+   if (range->start.row + range->size.row <= 1) {
+   /* SHIM row only, no memories in this range */
+   return 0;
+   }
+   if (!pmem)
+   return NUM_MEMS_PER_TILE;
+
+   for (i = 0; i < NUM_MEMS_PER_TILE; i++) {
+   struct aie_mem *mem = [i].mem;
+
+   memcpy(>range, range, sizeof(*range));
+   if (!mem->range.start.row) {
+   mem->range.start.row = 1;
+   mem->range.size.row--;
+   }
+   }
+   /* Setup tile data memory information */
+   pmem[0].mem.offset = 0;
+   pmem[0].mem.size = KBYTES(32);
+   /* Setup program memory information */
+   pmem[1].mem.offset = 0x2;
+   pmem[1].mem.size = KBYTES(16);
+
+   return NUM_MEMS_PER_TILE;
+}
+
 /**
  * aie_set_shim_reset() - Set AI engine SHIM reset
  * @adev: AI engine device
@@ -170,6 +205,7 @@ static int aie_reset_shim(struct aie_device *adev, struct 
aie_range *range)
 
 static const struct aie_tile_operations aie_ops = {
.get_tile_type = aie_get_tile_type,
+   .get_mem_info = aie_get_mem_info,
.reset_shim = aie_reset_shim,
 };
 
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h 
b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
index 2acd34f..e84610b 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -67,8 +69,30 @@ struct aie_device;
 struct aie_partition;
 
 /**
+ * struct aie_part_mem - AI engine partition memory information structure
+ * @apart: AI engine partition
+ * @dbuf: dmabuf pointer associated with the memory
+ * @mem: memory information of a type of memory
+ * @size: size of the total memories in the partition
+ *
+ * This structure is to keep the information of a type of memory in a
+ * partition. The memory information will be stored in @mem property.
+ * The following information will be keep:
+ *  * memory start address offset within a tile
+ *  * memory size
+ *  * what tiles contain this type of memory
+ */
+struct aie_part_mem {
+   struct aie_partition *apart;
+   struct dma_buf *dbuf;
+   struct aie_mem mem;
+ 

[PATCH v3 2/9] misc: Add Xilinx AI engine device driver

2020-11-29 Thread Wendy Liang
Create AI engine device/partition hierarchical structure.

Each AI engine device can have multiple logical partitions(groups of AI
engine tiles). Each partition is column based and has its own node ID
in the system. AI engine device driver manages its partitions.

Applications can access AI engine partition through the AI engine
partition driver instance. AI engine registers write is moved to kernel
as there are registers in the AI engine array needs privilege
permission.

Signed-off-by: Wendy Liang 
Signed-off-by: Hyun Kwon 
---
 MAINTAINERS|   8 +
 drivers/misc/Kconfig   |  12 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/xilinx-ai-engine/Makefile |  11 +
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  | 115 +
 drivers/misc/xilinx-ai-engine/ai-engine-dev.c  | 452 +++
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 226 ++
 drivers/misc/xilinx-ai-engine/ai-engine-part.c | 498 +
 drivers/misc/xilinx-ai-engine/ai-engine-res.c  | 114 +
 include/uapi/linux/xlnx-ai-engine.h| 107 +
 10 files changed, 1544 insertions(+)
 create mode 100644 drivers/misc/xilinx-ai-engine/Makefile
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-aie.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dev.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-internal.h
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-part.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-res.c
 create mode 100644 include/uapi/linux/xlnx-ai-engine.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2daa6ee..1e36294 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19287,6 +19287,14 @@ T: git https://github.com/Xilinx/linux-xlnx.git
 F: Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
 F: drivers/phy/xilinx/phy-zynqmp.c
 
+XILINX AI ENGINE DRIVER
+M: Wendy Liang 
+S: Supported
+F: Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
+F: drivers/misc/xilinx-ai-engine/
+F: include/linux/xlnx-ai-engine.h
+F: include/uapi/linux/xlnx-ai-engine.h
+
 XILLYBUS DRIVER
 M: Eli Billauer 
 L: linux-kernel@vger.kernel.org
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0..0b8ce4d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -444,6 +444,18 @@ config XILINX_SDFEC
 
  If unsure, say N.
 
+config XILINX_AIE
+   tristate "Xilinx AI engine"
+   depends on ARM64 || COMPILE_TEST
+   help
+ This option enables support for the Xilinx AI engine driver.
+ One Xilinx AI engine device can have multiple partitions (groups of
+ AI engine tiles). Xilinx AI engine device driver instance manages
+ AI engine partitions. User application access its partitions through
+ AI engine partition instance file operations.
+
+ If unsure, say N
+
 config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e..2176b18 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI)   += habanalabs/
 obj-$(CONFIG_UACCE)+= uacce/
 obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
 obj-$(CONFIG_HISI_HIKEY_USB)   += hisi_hikey_usb.o
+obj-$(CONFIG_XILINX_AIE)   += xilinx-ai-engine/
diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
b/drivers/misc/xilinx-ai-engine/Makefile
new file mode 100644
index 000..7827a0a
--- /dev/null
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for Xilinx AI engine device driver
+#
+
+obj-$(CONFIG_XILINX_AIE)   += xilinx-aie.o
+
+xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
+  ai-engine-dev.o \
+  ai-engine-part.o \
+  ai-engine-res.o
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
new file mode 100644
index 000..319260f
--- /dev/null
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx AI Engine driver AIE device specific implementation
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#include 
+
+#include "ai-engine-internal.h"
+
+#define AIE_ARRAY_SHIFT30U
+#define AIE_COL_SHIFT  23U
+#define AIE_ROW_SHIFT  18U
+
+/*
+ * Registers offsets
+ */
+#define AIE_SHIMNOC_L2INTR_MASK_REGOFF 0x00015000U
+#define AIE_SHIMNOC_L2INTR_INTR_REGOFF 0x00015010U
+#define AIE_SHIMNOC_DMA_BD0_ADDRLOW_REGOFF 0x0001d000U
+#define AIE_SHIMNOC_DMA_BD15_PACKET_REGOFF 0x0001d13cU
+#define AIE_SHIMNOC_AXIMM_REGOFF   0x0001e020U
+#define 

[PATCH v3 7/9] misc: xilinx-ai-engine: Add support to request device management services

2020-11-29 Thread Wendy Liang
From: Nishad Saraf 

Platform management services like device control, resets, power
management, etc. are provided by Platform, Loader and Manager(PLM)
through firmware driver APIs. For requesting some of these services,
this change reads AI Engine platform management node ID from DT node.
Some other features like clearing interrupts in the NoC interconnect
might only be valid for particular silicon revisions. For supporting
such silicon specific features, AI Engine driver will query and store
this information in device instance. While at it, this change makes
EEMI operations accessible to all the other source files in the
driver.

Signed-off-by: Nishad Saraf 
Signed-off-by: Wendy Liang 
---
 drivers/misc/xilinx-ai-engine/ai-engine-dev.c  | 25 +-
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h |  6 ++
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-dev.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
index 43f4933..51c3a4f 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,7 +27,8 @@
 
 #include "ai-engine-internal.h"
 
-#define AIE_DEV_MAX(MINORMASK + 1)
+#define AIE_DEV_MAX(MINORMASK + 1)
+#define VERSAL_SILICON_REV_MASKGENMASK(31, 28)
 
 static dev_t aie_major;
 struct class *aie_class;
@@ -322,6 +324,7 @@ static int xilinx_ai_engine_probe(struct platform_device 
*pdev)
 {
struct aie_device *adev;
struct device *dev;
+   u32 idcode, version, pm_reg[2];
int ret;
 
adev = devm_kzalloc(>dev, sizeof(*adev), GFP_KERNEL);
@@ -349,6 +352,26 @@ static int xilinx_ai_engine_probe(struct platform_device 
*pdev)
return ret;
}
 
+   /*
+* AI Engine platform management node ID is required for requesting
+* services from firmware driver.
+*/
+   ret = of_property_read_u32_array(pdev->dev.of_node, "power-domains",
+pm_reg, ARRAY_SIZE(pm_reg));
+   if (ret < 0) {
+   dev_err(>dev,
+   "Failed to read power management information\n");
+   return ret;
+   }
+   adev->pm_node_id = pm_reg[1];
+
+   ret = zynqmp_pm_get_chipid(, );
+   if (ret < 0) {
+   dev_err(>dev, "Failed to get chip ID\n");
+   return ret;
+   }
+   adev->version = FIELD_GET(VERSAL_SILICON_REV_MASK, idcode);
+
dev = >dev;
device_initialize(dev);
dev->class = aie_class;
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h 
b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
index 131d22a..b21b7025 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
@@ -41,6 +41,10 @@
 #define AIE_REGS_ATTR_PERM_MASKGENMASK(15, \
AIE_REGS_ATTR_PERM_SHIFT)
 
+/* Silicon Engineering Sample(ES) revision ID */
+#define VERSAL_ES1_REV_ID  0x0
+#define VERSAL_ES2_REV_ID  0x1
+
 /**
  * struct aie_tile_regs - contiguous range of AI engine register
  *   within an AI engine tile
@@ -173,6 +177,7 @@ struct aie_resource {
  *   while columns are occupied by partitions.
  * @num_kernel_regs: number of kernel only registers range
  * @version: AI engine device version
+ * @pm_node_id: AI Engine platform management node ID
  */
 struct aie_device {
struct list_head partitions;
@@ -193,6 +198,7 @@ struct aie_device {
u32 row_shift;
u32 num_kernel_regs;
int version;
+   u32 pm_node_id;
 };
 
 /**
-- 
2.7.4



[PATCH v3 5/9] misc: xilinx-ai-engine: add setting shim dma bd operation

2020-11-29 Thread Wendy Liang
Add operation to set SHIM DMA buffer descriptor.

The following operations are added to set the buffer descriptors:
* attach DMA buffer which enables AI engine device to access the DMA
  buffer memory
* detach DMA buffer which disables AI engine device to access the DMA
  buffer memory
* set DMA buffer descriptor, which takes buffer descriptor contents
  pointer, the dmabuf fd, and the offset to the start of dmabuf as
  as argument. It validates the dmabuf and the offset and size of the
  buffer. And then it calculates the DMA address of the buffer and set
  the buffer descriptor content to the hardware DMA buffer descriptor.

The main logic to control what's go into the buffer descriptor and which
buffer descriptor to use is in the userspace AI engine library.

Signed-off-by: Wendy Liang 
Reviewed-by: Hyun Kwon 
---
 drivers/misc/xilinx-ai-engine/Makefile |   1 +
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  |  19 +
 drivers/misc/xilinx-ai-engine/ai-engine-dma.c  | 481 +
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h |  45 ++
 drivers/misc/xilinx-ai-engine/ai-engine-part.c |  17 +
 include/uapi/linux/xlnx-ai-engine.h|  44 ++
 6 files changed, 607 insertions(+)
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dma.c

diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
b/drivers/misc/xilinx-ai-engine/Makefile
index 2dbed42..1b743fa 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_XILINX_AIE)+= xilinx-aie.o
 
 xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
   ai-engine-dev.o \
+  ai-engine-dma.o \
   ai-engine-mem.o \
   ai-engine-part.o \
   ai-engine-res.o \
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index 7fce2f00..ac95aff 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -107,6 +107,24 @@ static const struct aie_single_reg_field aie_col_clkbuf = {
.regoff = AIE_SHIMPL_CLKCNTR_REGOFF,
 };
 
+static const struct aie_dma_attr aie_shimdma = {
+   .laddr = {
+   .mask = 0xU,
+   .regoff = 0U,
+   },
+   .haddr = {
+   .mask = 0xU,
+   .regoff = 0x8U,
+   },
+   .buflen = {
+   .mask = 0xU,
+   .regoff = 0x4U,
+   },
+   .bd_regoff = 0x0001d000U,
+   .num_bds = 16,
+   .bd_len = 0x14U,
+};
+
 static u32 aie_get_tile_type(struct aie_location *loc)
 {
if (loc->row)
@@ -232,6 +250,7 @@ int aie_device_init(struct aie_device *adev)
adev->kernel_regs = aie_kernel_regs;
adev->col_rst = _col_rst;
adev->col_clkbuf = _col_clkbuf;
+   adev->shim_dma = _shimdma;
 
/* Get the columns resource */
/* Get number of columns from AI engine memory resource */
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-dma.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-dma.c
new file mode 100644
index 000..863790b
--- /dev/null
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-dma.c
@@ -0,0 +1,481 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx AI Engine driver DMA implementation
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#include "ai-engine-internal.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct aie_dmabuf - AI engine dmabuf information
+ * @attach: dmabuf attachment pointer
+ * @sgt: scatter/gather table
+ * @refs: refcount of the attached aie_dmabuf
+ * @node: list node
+ */
+struct aie_dmabuf {
+   struct dma_buf_attachment *attach;
+   struct sg_table *sgt;
+   refcount_t refs;
+   struct list_head node;
+};
+
+/**
+ * aie_part_find_dmabuf() - find a attached dmabuf
+ * @apart: AI engine partition
+ * @dmabuf: pointer to dmabuf
+ * @return: pointer to AI engine dmabuf struct of the found dmabuf, if dmabuf
+ * is not found, returns NULL.
+ *
+ * This function scans all the attached dmabufs to see the input dmabuf is
+ * in the list. if it is attached, return the corresponding struct aie_dmabuf
+ * pointer.
+ */
+static struct aie_dmabuf *
+aie_part_find_dmabuf(struct aie_partition *apart, struct dma_buf *dmabuf)
+{
+   struct aie_dmabuf *adbuf;
+
+   list_for_each_entry(adbuf, >dbufs, node) {
+   if (dmabuf == adbuf->attach->dmabuf)
+   return adbuf;
+   }
+
+   return NULL;
+}
+
+/**
+ * aie_part_get_dmabuf_da_from_off() - get DMA address from offset to a dmabuf
+ * @apart: AI engine partition
+ * @dmabuf_fd: dmabuf file descriptor
+ * @off: offset to the start of a dmabuf
+ * @len: memory length
+ * @return: dma address, or 0 if @off or @len is invalid, or if 

[PATCH v3 8/9] firmware: xilinx: Add IOCTL support for AIE ISR Clear

2020-11-29 Thread Wendy Liang
From: Izhar Ameer Shaikh 

Latching of AIE NPI Interrupts is present in Versal ES1 Silicon Rev,
however it has been removed from ES2 rev.
As a result on ES1, in order to use the interrupt, a client needs to
request PMC to clear/ack the interrupt.

Provide an EEMI IOCTL to serve the same purpose. Note that, this will
only be applicable for ES1 rev. For ES2 and other non-silicon platforms,
this call will essentially be a NOP in the firmware.

Signed-off-by: Izhar Ameer Shaikh 
Signed-off-by: Wendy Liang 
---
 drivers/firmware/xilinx/zynqmp.c | 14 ++
 include/linux/firmware/xlnx-zynqmp.h |  8 
 2 files changed, 22 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index d08ac82..23e58cc 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -729,6 +729,20 @@ int zynqmp_pm_set_boot_health_status(u32 value)
 }
 
 /**
+ * zynqmp_pm_clear_aie_npi_isr - Clear AI engine NPI interrupt status register
+ * @node:  AI engine node id
+ * @irq_mask:  Mask of AI engine NPI interrupt bit to clear
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_clear_aie_npi_isr(u32 node, u32 irq_mask)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node, IOCTL_AIE_ISR_CLEAR,
+  irq_mask, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_clear_aie_npi_isr);
+
+/**
  * zynqmp_pm_reset_assert - Request setting of reset (1 - assert, 0 - release)
  * @reset: Reset to be configured
  * @assert_flag:   Flag stating should reset be asserted (1) or
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 83ac9ec..defa4ea 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -114,6 +114,8 @@ enum pm_ioctl_id {
IOCTL_READ_PGGS = 15,
/* Set healthy bit value */
IOCTL_SET_BOOT_HEALTH_STATUS = 17,
+   /* AI engine NPI ISR clear */
+   IOCTL_AIE_ISR_CLEAR = 24,
 };
 
 enum pm_query_id {
@@ -355,6 +357,7 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
 int zynqmp_pm_set_boot_health_status(u32 value);
+int zynqmp_pm_clear_aie_npi_isr(u32 node, u32 irq_mask);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -505,6 +508,11 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_clear_aie_npi_isr(u32 node, u32 irq_mask)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.7.4



[PATCH v3 1/9] dt-binding: soc: xilinx: ai-engine: Add AI engine binding

2020-11-29 Thread Wendy Liang
Xilinx AI engine array can be partitioned statically for different
applications. In the device tree, there will be device node for the AI
engine device, and device nodes for the statically configured AI engine
partitions. Each of the statically configured partition has a partition
ID in the system.

Signed-off-by: Wendy Liang 
---
 .../bindings/soc/xilinx/xlnx,ai-engine.yaml| 126 +
 1 file changed, 126 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml

diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml 
b/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
new file mode 100644
index 000..1de5623
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/xilinx/xlnx,ai-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx AI Engine
+
+maintainers:
+  - Wendy Liang 
+
+description: |+
+  The Xilinx AI Engine is a tile processor with many cores (up to 400) that
+  can run in parallel. The data routing between cores is configured through
+  internal switches, and shim tiles interface with external interconnect, such
+  as memory or PL.
+
+properties:
+  compatible:
+const: xlnx,ai-engine-v1.0
+
+  reg:
+description: |
+  Physical base address and length of the device registers.
+  The AI engine address space assigned to Linux is defined by Xilinx
+  platform design tool.
+
+  '#address-cells':
+enum: [2]
+description: |
+  size of cell to describe AI engine range of tiles address.
+  It is the location of the starting tile of the range.
+  As the AI engine tiles are 2D array, the location of a tile
+  is presented as (column, row), the address cell is 2.
+
+  '#size-cells':
+enum: [2]
+description: |
+  size of cell to describe AI engine range of tiles size.
+  As the AI engine tiles are 2D array, the size cell is 2.
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  interrupts:
+maxItems: 3
+
+  interrupt-names:
+description: |
+  Should be "interrupt1", "interrupt2" or "interrupt3".
+
+required:
+  - compatible
+  - reg
+  - '#address-cells'
+  - '#size-cells'
+  - power-domains
+  - interrupt-parent
+  - interrupts
+  - interrupt-names
+
+patternProperties:
+  "^aie_partition@[0-9]+$":
+type: object
+description: |
+  AI engine partition which is a group of column based tiles of the AI
+  engine device. Each AI engine partition is isolated from the other
+  AI engine partitions. An AI engine partition is defined by Xilinx
+  platform design tools. Each partition has a SHIM row and core tiles rows.
+  A SHIM row contains SHIM tiles which are the interface to external
+  components. AXI master can access AI engine registers, push data to and
+  fetch data from AI engine through the SHIM tiles. Core tiles are the
+  compute tiles.
+
+properties:
+  reg:
+description: |
+  It describes the group of tiles of the AI engine partition. It needs
+  to include the SHIM row. The format is defined by the parent AI 
engine
+  device node's '#address-cells' and '#size-cells' properties. e.g. a 
v1
+  AI engine device has 2D tiles array, the first row is SHIM row. A
+  partition which has 50 columns and 8 rows of core tiles and 1 row of
+  SHIM tiles will be presented as <0 0 50 9>.
+
+  label:
+maxItems: 1
+
+  xlnx,partition-id:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+  AI engine partition ID, which is defined by Xilinx platform design
+  tool to identify the AI engine partition in the system.
+
+required:
+  - reg
+  - xlnx,partition-id
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+  - |
+bus {
+  #address-cells = <2>;
+  #size-cells = <2>;
+
+  ai_engine: ai-engine@200 {
+compatible = "xlnx,ai-engine-v1.0";
+reg = <0x200 0x0 0x1 0x0>;
+#address-cells = <2>;
+#size-cells = <2>;
+power-domains = <_firmware 0x18224072>;
+interrupt-parent = <>;
+interrupts = <0x0 0x94 0x4>,
+ <0x0 0x95 0x4>,
+ <0x0 0x96 0x4>;
+interrupt-names = "interrupt1", "interrupt2", "interrupt3";
+
+aie_partition0: aie_partition@0 {
+/* 50 columns and 8 core tile rows + 1 SHIM row */
+reg = <0 0 50 9>;
+xlnx,partition-id = <1>;
+};
+  };
+};
-- 
2.7.4



[PATCH v3 0/9] Xilinx AI engine kernel driver

2020-11-29 Thread Wendy Liang
AI engine is the acceleration engine provided by Xilinx. These engines
provide high compute density for vector-based algorithms, and flexible
custom compute and data movement. It has core tiles for compute and
shim tiles to interface the FPGA fabric.

You can check the AI engine architecture document for more hardware details:
https://www.xilinx.com/support/documentation/architecture-manuals/am009-versal-ai-engine.pdf

This patch series adds a Linux kernel driver to manage the Xilinx AI
engine array device and AI engine partitions (groups of AI engine tiles
dedicated to an application).

v3:
* unlock AIE dev mutex after failed to gain the partition lock in
  errors handing
* replace pointer with __u64 and enum with __u32 in ioctl

v2:
* Fix dtschema check errors
* Fix test bot warning on interrupt implementation. Removed set but
  unused  varaible.
* Fix compilation unused function warning of firmware change in case
  ZynqMP firmware is not configured
* There are other warning on ZynqMP firmware reported from testbot
  which is not introduced by this patch set.
  "[PATCH] firmware: xlnx-zynqmp: fix compilation warning" is submitted
  for those fixes.


Izhar Ameer Shaikh (1):
  firmware: xilinx: Add IOCTL support for AIE ISR Clear

Nishad Saraf (2):
  misc: xilinx-ai-engine: Add support to request device management
services
  misc: xilinx-ai-engine: Add support for servicing error interrupts

Wendy Liang (6):
  dt-binding: soc: xilinx: ai-engine: Add AI engine binding
  misc: Add Xilinx AI engine device driver
  misc: xilinx-ai-engine: Implement AI engine cleanup sequence
  misc: xilinx-ai-engine: expose AI engine tile memories to userspace
  misc: xilinx-ai-engine: add setting shim dma bd operation
  misc: xilinx-ai-engine: add request and release tiles

 .../bindings/soc/xilinx/xlnx,ai-engine.yaml| 126 
 MAINTAINERS|   8 +
 drivers/firmware/xilinx/zynqmp.c   |  14 +
 drivers/misc/Kconfig   |  12 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/xilinx-ai-engine/Makefile |  16 +
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  | 608 +++
 drivers/misc/xilinx-ai-engine/ai-engine-clock.c| 245 
 drivers/misc/xilinx-ai-engine/ai-engine-dev.c  | 496 
 drivers/misc/xilinx-ai-engine/ai-engine-dma.c  | 481 +++
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 519 
 .../misc/xilinx-ai-engine/ai-engine-interrupt.c| 659 +
 drivers/misc/xilinx-ai-engine/ai-engine-mem.c  | 275 +
 drivers/misc/xilinx-ai-engine/ai-engine-part.c | 635 
 drivers/misc/xilinx-ai-engine/ai-engine-res.c  | 219 +++
 drivers/misc/xilinx-ai-engine/ai-engine-reset.c| 159 +
 include/linux/firmware/xlnx-zynqmp.h   |   8 +
 include/uapi/linux/xlnx-ai-engine.h| 238 
 18 files changed, 4719 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
 create mode 100644 drivers/misc/xilinx-ai-engine/Makefile
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-aie.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-clock.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dev.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dma.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-internal.h
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-interrupt.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-mem.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-part.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-res.c
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-reset.c
 create mode 100644 include/uapi/linux/xlnx-ai-engine.h

-- 
2.7.4



[PATCH v3 3/9] misc: xilinx-ai-engine: Implement AI engine cleanup sequence

2020-11-29 Thread Wendy Liang
When AI engine partition is released, that is if no one is using the AI
engine partition, by default, it will cleanup the partition by doing the
following:
* reset the columns
* reset the SHIMs
* clear data and program memory
* gate all the tiles

If user doesn't want the partition is reset when the partition is
released, user can set the control flag to indicate not to reset the
partition when the user requests the partition.

If partition the not to reset partition control flag is set, it will
not execute the above cleanup sequence when the partition is released.

Signed-off-by: Wendy Liang 
Reviewed-by: Hyun Kwon 
---
 drivers/misc/xilinx-ai-engine/Makefile |   3 +-
 drivers/misc/xilinx-ai-engine/ai-engine-aie.c  |  92 
 drivers/misc/xilinx-ai-engine/ai-engine-dev.c  |   2 +
 drivers/misc/xilinx-ai-engine/ai-engine-internal.h |  34 ++
 drivers/misc/xilinx-ai-engine/ai-engine-part.c |   7 +-
 drivers/misc/xilinx-ai-engine/ai-engine-reset.c| 121 +
 include/uapi/linux/xlnx-ai-engine.h|   6 +
 7 files changed, 259 insertions(+), 6 deletions(-)
 create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-reset.c

diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
b/drivers/misc/xilinx-ai-engine/Makefile
index 7827a0a..39bec61 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -8,4 +8,5 @@ obj-$(CONFIG_XILINX_AIE)+= xilinx-aie.o
 xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
   ai-engine-dev.o \
   ai-engine-part.o \
-  ai-engine-res.o
+  ai-engine-res.o \
+  ai-engine-reset.o
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index 319260f..36127f0 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -5,6 +5,9 @@
  * Copyright (C) 2020 Xilinx, Inc.
  */
 
+#include 
+#include 
+#include 
 #include 
 
 #include "ai-engine-internal.h"
@@ -24,9 +27,25 @@
 #define AIE_SHIMPL_L1INTR_MASK_A_REGOFF0x00035000U
 #define AIE_SHIMPL_L1INTR_BLOCK_NORTH_B_REGOFF 0x00035050U
 #define AIE_SHIMPL_CLKCNTR_REGOFF  0x00036040U
+#define AIE_SHIMPL_COLRESET_REGOFF 0x00036048U
 #define AIE_SHIMPL_RESET_REGOFF0x0003604cU
 #define AIE_TILE_CORE_CLKCNTR_REGOFF   0x00036040U
 
+/*
+ * Register masks
+ */
+#define AIE_SHIMPL_SHIMRST_MASK0x1U
+#define AIE_SHIMPL_COLRST_MASK 0x1U
+#define AIE_SHIMPL_CLKCNTR_COLBUF_MASK 0x1U
+
+/*
+ * AI engine SHIM reset ID.
+ * TODO: it should follow the Linux reset framework. The ID should be in the
+ * device tree. However, as versal resets is not ready, we hardcode it in the
+ * driver.
+ */
+#define VERSAL_PM_RST_AIE_SHIM_ID  0xc10405fU
+
 static const struct aie_tile_regs aie_kernel_regs[] = {
/* SHIM AXI MM Config */
{.attribute = AIE_TILE_TYPE_SHIMNOC << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
@@ -49,6 +68,12 @@ static const struct aie_tile_regs aie_kernel_regs[] = {
 .soff = AIE_SHIMPL_L1INTR_MASK_A_REGOFF,
 .eoff = AIE_SHIMPL_L1INTR_BLOCK_NORTH_B_REGOFF,
},
+   /* SHIM column reset */
+   {.attribute = (AIE_TILE_TYPE_SHIMPL | AIE_TILE_TYPE_SHIMNOC) <<
+ AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_SHIMPL_COLRESET_REGOFF,
+.eoff = AIE_SHIMPL_COLRESET_REGOFF,
+   },
/* SHIM reset Enable */
{.attribute = (AIE_TILE_TYPE_SHIMPL | AIE_TILE_TYPE_SHIMNOC) <<
  AIE_REGS_ATTR_TILE_TYPE_SHIFT,
@@ -68,6 +93,16 @@ static const struct aie_tile_regs aie_kernel_regs[] = {
},
 };
 
+static const struct aie_single_reg_field aie_col_rst = {
+   .mask = AIE_SHIMPL_COLRST_MASK,
+   .regoff = AIE_SHIMPL_COLRESET_REGOFF,
+};
+
+static const struct aie_single_reg_field aie_col_clkbuf = {
+   .mask = AIE_SHIMPL_CLKCNTR_COLBUF_MASK,
+   .regoff = AIE_SHIMPL_CLKCNTR_REGOFF,
+};
+
 static u32 aie_get_tile_type(struct aie_location *loc)
 {
if (loc->row)
@@ -79,8 +114,63 @@ static u32 aie_get_tile_type(struct aie_location *loc)
return AIE_TILE_TYPE_SHIMNOC;
 }
 
+/**
+ * aie_set_shim_reset() - Set AI engine SHIM reset
+ * @adev: AI engine device
+ * @range: range of AI engine tiles
+ * @assert: true to set reset, false to unset reset
+ */
+static void aie_set_shim_reset(struct aie_device *adev,
+  struct aie_range *range, bool assert)
+{
+   u32 c;
+   u32 val;
+   struct aie_location loc;
+
+   val = FIELD_PREP(AIE_SHIMPL_SHIMRST_MASK, (assert ? 1 : 0));
+   loc.row = 0;
+   for (c = range->start.col; c < range->start.col + range->size.col;
+c++) {
+  

Re: linux-next: manual merge of the akpm tree with the arm64 tree

2020-11-29 Thread Stephen Rothwell
Hi all,

On Mon, 30 Nov 2020 18:28:40 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/arm64/kernel/mte.c
> 
> between commit:
> 
>   e710c29e0177 ("arm64: mte: make the per-task SCTLR_EL1 field usable 
> elsewhere")
> 
> from the arm64 tree and commit:
> 
>   44a7127eb3a4 ("arm64: mte: add in-kernel MTE helpers")
> 
> from the akpm tree.
> 
> I fixed it up (the former just removed some of the context for what the
> latter added) and can carry the fix as necessary. This is now fixed as
> far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging.  You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.

A couple of the following patches in the akpm tree also conflicted with
the arm64 tree.

-- 
Cheers,
Stephen Rothwell


pgpP6g9nFLeai.pgp
Description: OpenPGP digital signature


Re: [PATCH v5] hwmon: Add driver for STMicroelectronics PM6764 Voltage Regulator

2020-11-29 Thread Charles

On 28/11/2020 上午12:10, Guenter Roeck wrote:

On Fri, Nov 27, 2020 at 09:59:01AM +0800, Charles wrote:

Add the pmbus driver for the STMicroelectronics pm6764 voltage regulator.

the output voltage use the MFR_READ_VOUT 0xD4
vout value returned is linear11

Signed-off-by: Charles Hsu 

This patch (again) didn't make it to any of the mailing lists.
Please try to find out why this is the case. I usually pick up
patches from https://patchwork.kernel.org/project/linux-hwmon/list/,
and may easily miss a patch if I can't find it there.


---

v5:
  - Add MAINTAINERS
  - Add a reference into trivial-devices.yaml
v4:
  - Add pm6764tr to Documentation/hwmon/index.rst.
v3:
  - Add Documentation(Documentation/hwmon/pm6764tr.rst).
  - Fix include order.
v2:
  - Fix formatting.
  - Remove pmbus_do_remove.
  - Change from .probe to .probe_new.
v1:
  - Initial patchset.

---

  .../devicetree/bindings/trivial-devices.yaml  |  2 +
  Documentation/hwmon/index.rst |  1 +
  Documentation/hwmon/pm6764tr.rst  | 33 
  MAINTAINERS   |  7 ++
  drivers/hwmon/pmbus/Kconfig   |  9 +++
  drivers/hwmon/pmbus/Makefile  |  1 +
  drivers/hwmon/pmbus/pm6764tr.c| 76 +++
  7 files changed, 129 insertions(+)
  create mode 100644 Documentation/hwmon/pm6764tr.rst
  create mode 100644 drivers/hwmon/pmbus/pm6764tr.c

diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml 
b/Documentation/devicetree/bindings/trivial-devices.yaml
index ab623ba930d5..cdd7bdb6abbb 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -348,6 +348,8 @@ properties:
- socionext,synquacer-tpm-mmio
  # i2c serial eeprom  (24cxx)
- st,24c256
+# SMBus/I2C Voltage Regulator
+  - st,pm6764tr
  # Ambient Light Sensor with SMBUS/Two Wire Serial Interface
- taos,tsl2550
  # 8-Channels, 12-bit ADC

This, like all devicetre changes, needs to be a separate patch.
Also, please make sure to copy dt maintainers and the dt mailing list
when you send that patch.



Thank you for your suggestions.

I will send that patch as soon as possible.



diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index b797db738225..1bbd05e41de4 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -144,6 +144,7 @@ Hardware Monitoring Kernel Drivers
 pc87360
 pc87427
 pcf8591
+   pm6764tr
 pmbus
 powr1220
 pxe1610
diff --git a/Documentation/hwmon/pm6764tr.rst b/Documentation/hwmon/pm6764tr.rst
new file mode 100644
index ..5e8092e39297
--- /dev/null
+++ b/Documentation/hwmon/pm6764tr.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver pm6764tr
+==
+
+Supported chips:
+
+  * ST PM6764TR
+
+Prefix: 'pm6764tr'
+
+Addresses scanned: -
+
+Datasheet: http://www.st.com/resource/en/data_brief/pm6764.pdf
+
+Authors:
+   
+
+Description:
+
+
+This driver supports the STMicroelectronics PM6764TR chip. The PM6764TR is a 
high
+performance digital controller designed to power Intel’s VR12.5 processors and 
memories.
+

Unrelated side note: I understand this means that you are forced to keep the
datasheet under wraps, which in turn means I can not suggest functionality
improvements since I don't have access to it. If the chip happens to support
per-rail telemetry, you might want to consider adding support for that in a
follow-up patch.


+The device utilizes digital technology to implement all control and power 
management
+functions to provide maximum flexibility and performance. The NVM is embedded 
to store
+custom configurations. The PM6764TR device features up to 4-phase programmable 
operation.
+
+The PM6764TR supports power state transitions featuring VFDE, and programmable 
DPM
+maintaining the best efficiency over all loading conditions without 
compromising transient
+response. The device assures fast and independent protectionagainstload 
overcurrent,

"protectionagainstload" -> "protection against load"


+under/overvoltage and feedback disconnections.
+

Drop empty line at end.


diff --git a/MAINTAINERS b/MAINTAINERS
index 94ac10a153c7..a3fea132c4ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13904,6 +13904,13 @@ M: Logan Gunthorpe 
  S:Maintained
  F:drivers/dma/plx_dma.c

Add empty line.



There is an empty line here,

Should I add one more empty line?



+PM6764TR DRIVER
+M: Charles Hsu 
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/pm6764tr.rst
+F: drivers/hwmon/pmbus/pm6764tr.c
+
  PM-GRAPH UTILITY
  M:"Todd E Brandt" 
  L:linux...@vger.kernel.org
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index a25faf69fce3..9c846facce9f 100644
--- 

Re: linux-next: Fixes tag needs some work in the drivers-x86 tree

2020-11-29 Thread Hans de Goede
Hi Stephen,

On 11/29/20 6:43 PM, Stephen Rothwell wrote:
> Hi all,
> 
> In commit
> 
>   912b341585e3 ("platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x 
> platform configuration")
> 
> Fixes tag
> 
>   Fixes: ef08e14a3 ("platform/x86: mlx-platform: Add support for new msn274x 
> system type")
> 
> has these problem(s):
> 
>   - SHA1 should be at least 12 digits long
> 
> In commit
> 
>   2bf5046bdb64 ("platform/x86: mlx-platform: Remove PSU EEPROM from default 
> platform configuration")
> 
> Fixes tags
> 
>   Fixes: c6acad68e ("platform/mellanox: mlxreg-hotplug: Modify to use a 
> regmap interface")
>   Fixes: ba814fdd0 ("platform/x86: mlx-platform: Use defines for bus 
> assignment")
> 
> have these problem(s):
> 
>   - SHA1 should be at least 12 digits long

Hmm, for some reason checkpatch did not catch these, while AFAIK it will 
complain
about short hashes in the normal part of the commit msg.

Question, how important is it to fix these ? I normally never do forced pushes
to the for-next branch. But if this is considered important to fix I guess I
can make an exception.

> These can be fixed in the future by setting core.abbrev to 12 (or more)
> or (for git v2.11 or later) just making sure it is not set (or set to
> "auto").

Will git rewrite the commit msg when this is set ?  I'm at 2.28 and don't
have core.abbrev set. But I guess this needs to be set in the gitconfig
of the creator of the patch; and this has no impact on "git am" ?

Regards,

Hans



Re: [RFC PATCH v3.1 13/27] mmc: sdhci-uhs2: add set_power() to support vdd2

2020-11-29 Thread Adrian Hunter
On 30/11/20 9:15 am, AKASHI Takahiro wrote:
> On Thu, Nov 26, 2020 at 10:16:27AM +0200, Adrian Hunter wrote:
>> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
>>> This is a UHS-II version of sdhci's set_power operation.
>>> VDD2, as well as VDD, is handled here.
>>>
>>> Signed-off-by: Ben Chuang 
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  drivers/mmc/host/sdhci-uhs2.c | 80 +++
>>>  drivers/mmc/host/sdhci-uhs2.h |  2 +
>>>  drivers/mmc/host/sdhci.c  | 58 +++--
>>>  drivers/mmc/host/sdhci.h  |  2 +
>>>  4 files changed, 119 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
>>> index e2b9743fe17d..2bf78cc4e9ed 100644
>>> --- a/drivers/mmc/host/sdhci-uhs2.c
>>> +++ b/drivers/mmc/host/sdhci-uhs2.c
>>> @@ -98,6 +98,86 @@ void sdhci_uhs2_reset(struct sdhci_host *host, u16 mask)
>>>  }
>>>  EXPORT_SYMBOL_GPL(sdhci_uhs2_reset);
>>>  
>>> +void sdhci_uhs2_set_power(struct sdhci_host *host, unsigned char mode,
>>> + unsigned short vdd)
>>
>> This function isn't used, so let's rename it sdhci_uhs2_set_power_noreg and
>> drop regulator support.
> 
> I have no strong opinion, but here Ben might want to further rework
> the new sdhci_uhs2_set_power_noreg() now that it is almost the same as
> GLI's gl9755_set_power()(, adding a new quirk?).
> 
>>> +{
>>> +   struct mmc_host *mmc = host->mmc;
>>> +   u8 pwr;
>>> +
>>> +   /* FIXME: check if flags & MMC_UHS2_SUPPORT? */
>>> +   if (!(host->mmc->caps & MMC_CAP_UHS2)) {
>>
>> As commented in another patch, please use a helper fn
> 
> As said, I would defer this.
> 
>>> +   sdhci_set_power(host, mode, vdd);
>>> +   return;
>>> +   }
>>> +
>>> +   if (mode != MMC_POWER_OFF) {
>>> +   pwr = sdhci_get_vdd_value(vdd);
>>
>> Simpler to open code this esp. as there are only 2 valid values:
>>
>>  switch (1 << vdd) {
> 
> Can you ignore MMC_VDD_165_195 and MMC_VDD_20_21 here?

They are outside UHS-II spec, but you decide.


Re: [RFC PATCH v3.1 14/27] mmc: sdhci-uhs2: skip signal_voltage_switch()

2020-11-29 Thread AKASHI Takahiro
On Thu, Nov 26, 2020 at 10:16:44AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > For UHS2, the signal voltage is supplied by vdd2 which is already 1.8v,
> > so no voltage switch required.
> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/mmc/host/sdhci-uhs2.c | 26 ++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> > index 2bf78cc4e9ed..1eca89359351 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.c
> > +++ b/drivers/mmc/host/sdhci-uhs2.c
> > @@ -178,6 +178,29 @@ void sdhci_uhs2_set_power(struct sdhci_host *host, 
> > unsigned char mode,
> >  }
> >  EXPORT_SYMBOL_GPL(sdhci_uhs2_set_power);
> >  
> > +/*\
> > + * 
> >   *
> > + * MMC callbacks   
> >   *
> > + * 
> >   *
> > +\*/
> > +
> > +static int sdhci_uhs2_start_signal_voltage_switch(struct mmc_host *mmc,
> > + struct mmc_ios *ios)
> > +{
> > +   struct sdhci_host *host = mmc_priv(mmc);
> > +
> > +   /*
> > +* For UHS2, the signal voltage is supplied by vdd2 which is
> > +* already 1.8v so no voltage switch required.
> > +*/
> > +if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
> > + host->version >= SDHCI_SPEC_400 &&
> > + host->mmc->flags & MMC_UHS2_SUPPORT)
> 
> Could this be the same helper function suggested elsewhere i.e.
> 
>   if (!sdhci_uhs2_mode(host))


ditto. I'd defer the change until some time later.

-Takahiro Akashi

> 
> > +return 0;
> > +
> > +   return sdhci_start_signal_voltage_switch(mmc, ios);
> > +}
> > +
> >  
> > /*\
> >   * 
> >   *
> >   * Driver init/exit
> >   *
> > @@ -186,6 +209,9 @@ EXPORT_SYMBOL_GPL(sdhci_uhs2_set_power);
> >  
> >  static int sdhci_uhs2_host_ops_init(struct sdhci_host *host)
> >  {
> > +   host->mmc_host_ops.start_signal_voltage_switch =
> > +   sdhci_uhs2_start_signal_voltage_switch;
> > +
> > return 0;
> >  }
> >  
> > 
> 


Re: [RFC PATCH v3.1 12/27] mmc: sdhci-uhs2: add reset function

2020-11-29 Thread Adrian Hunter
On 30/11/20 8:20 am, AKASHI Takahiro wrote:
> On Thu, Nov 26, 2020 at 10:16:11AM +0200, Adrian Hunter wrote:
>> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
>>> Sdhci_uhs2_reset() does a UHS-II specific reset operation.
>>>
>>> Signed-off-by: Ben Chuang 
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  drivers/mmc/host/sdhci-uhs2.c | 49 +++
>>>  drivers/mmc/host/sdhci-uhs2.h |  1 +
>>>  drivers/mmc/host/sdhci.c  |  3 ++-
>>>  drivers/mmc/host/sdhci.h  |  1 +
>>>  4 files changed, 53 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
>>> index 08905ed081fb..e2b9743fe17d 100644
>>> --- a/drivers/mmc/host/sdhci-uhs2.c
>>> +++ b/drivers/mmc/host/sdhci-uhs2.c
>>> @@ -10,6 +10,7 @@
>>>   *  Author: AKASHI Takahiro 
>>>   */
>>>  
>>> +#include 
>>>  #include 
>>>  
>>>  #include "sdhci.h"
>>> @@ -49,6 +50,54 @@ void sdhci_uhs2_dump_regs(struct sdhci_host *host)
>>>  }
>>>  EXPORT_SYMBOL_GPL(sdhci_uhs2_dump_regs);
>>>  
>>> +/*\
>>> + * 
>>>   *
>>> + * Low level functions 
>>>   *
>>> + * 
>>>   *
>>> +\*/
>>> +
>>> +/**
>>> + * sdhci_uhs2_reset - invoke SW reset
>>> + * @host: SDHCI host
>>> + * @mask: Control mask
>>> + *
>>> + * Invoke SW reset, depending on a bit in @mask and wait for completion.
>>> + */
>>> +void sdhci_uhs2_reset(struct sdhci_host *host, u16 mask)
>>> +{
>>> +   unsigned long timeout;
>>> +
>>> +   if (!(host->mmc->caps & MMC_CAP_UHS2))
>>
>> Please make a helper so this can be like:
>>
>>  if (!sdhci_uhs2_mode(host))
>>
>> The capability will be always present for hosts that support UHS2, but not
>> all cards support UHS2 mode.  I suggest just adding a bool to struct
>> sdhci_host to keep track of when the host is in UHS2 mode.
> 
> Given the fact that UHS-2 host may (potentially) support a topology like
> a ring, this kind of status should be attributed to a card (structure)
> rather than a host.

It is very unlikely we would ever need to support that, so don't let it make
things more complicated.


Re: [PATCH 2/3] powerpc/pseries/hotplug-cpu: fix memleak in dlpar_cpu_add_by_count

2020-11-29 Thread Qinglang Miao




在 2020/11/30 9:51, Michael Ellerman 写道:

Qinglang Miao  writes:

kfree(cpu_drcs) should be called when it fails to perform
of_find_node_by_path("/cpus") in dlpar_cpu_add_by_count,
otherwise there would be a memleak.

In fact, the patch a0ff72f9f5a7 ought to remove kfree in
find_dlpar_cpus_to_add rather than dlpar_cpu_add_by_count.
I guess there might be a mistake when apply that one.

Fixes: a0ff72f9f5a7 ("powerpc/pseries/hotplug-cpu: Remove double free in error 
path")
Reported-by: Hulk Robot 
Signed-off-by: Qinglang Miao 
---
  arch/powerpc/platforms/pseries/hotplug-cpu.c | 1 +
  1 file changed, 1 insertion(+)


This is already fixed in my next by:

   a40fdaf1420d ("Revert "powerpc/pseries/hotplug-cpu: Remove double free in error 
path"")

cheers'Revert' sounds resonable to this one, glad to know that.


diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c 
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index f2837e33b..4bb1c9f2b 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -743,6 +743,7 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
parent = of_find_node_by_path("/cpus");
if (!parent) {
pr_warn("Could not find CPU root node in device tree\n");
+   kfree(cpu_drcs);
return -1;
}
  
--

2.23.0

.



[PATCH] fs: iomap: Replace bio_add_page with __bio_add_page in iomap_add_to_ioend

2020-11-29 Thread chenlei0x
From: Lei Chen 

iomap_add_to_ioend append page on wpc->ioend->io_bio. If io_bio is full,
iomap_chain_bio will allocate a new bio. So when bio_add_page is called,
pages is guaranteed to be appended into wpc->ioend->io_bio. So we do not
need to check if page can be merged. Thus it's a faster way to directly
call __bio_add_page.

Signed-off-by: Lei Chen 
---
 fs/iomap/buffered-io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 10cc797..7a0631a 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1310,7 +1310,7 @@ static void iomap_writepage_end_bio(struct bio *bio)
wpc->ioend->io_bio =
iomap_chain_bio(wpc->ioend->io_bio);
}
-   bio_add_page(wpc->ioend->io_bio, page, len, poff);
+   __bio_add_page(wpc->ioend->io_bio, page, len, poff);
}
 
wpc->ioend->io_size += len;
-- 
1.8.3.1



linux-next: manual merge of the akpm tree with the arm64 tree

2020-11-29 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/arm64/kernel/mte.c

between commit:

  e710c29e0177 ("arm64: mte: make the per-task SCTLR_EL1 field usable 
elsewhere")

from the arm64 tree and commit:

  44a7127eb3a4 ("arm64: mte: add in-kernel MTE helpers")

from the akpm tree.

I fixed it up (the former just removed some of the context for what the
latter added) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpMC0lyjk49N.pgp
Description: OpenPGP digital signature


Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side

2020-11-29 Thread Shenming Lu
On 2020/11/24 21:12, Shenming Lu wrote:
> On 2020/11/24 16:44, Marc Zyngier wrote:
>> On 2020-11-24 08:10, Shenming Lu wrote:
>>> On 2020/11/23 17:27, Marc Zyngier wrote:
 On 2020-11-23 06:54, Shenming Lu wrote:
> From: Zenghui Yu 
>
> When setting the forwarding path of a VLPI, it is more consistent to

 I'm not sure it is more consistent. It is a *new* behaviour, because it 
 only
 matters for migration, which has been so far unsupported.
>>>
>>> Alright, consistent may not be accurate...
>>> But I have doubt that whether there is really no need to transfer the
>>> pending states
>>> from kvm'vgic to VPT in set_forwarding regardless of migration, and the 
>>> similar
>>> for unset_forwarding.
>>
>> If you have to transfer that state outside of the a save/restore, it means 
>> that
>> you have missed the programming of the PCI endpoint. This is an established
>> restriction that the MSI programming must occur *after* the translation has
>> been established using MAPI/MAPTI (see the large comment at the beginning of
>> vgic-v4.c).
>>
>> If you want to revisit this, fair enough. But you will need a lot more than
>> just opportunistically transfer the pending state.
> 
> Thanks, I will look at what you mentioned.
> 
>>
>>>

> also transfer the pending state from irq->pending_latch to VPT (especially
> in migration, the pending states of VLPIs are restored into kvm’s vgic
> first). And we currently send "INT+VSYNC" to trigger a VLPI to pending.
>
> Signed-off-by: Zenghui Yu 
> Signed-off-by: Shenming Lu 
> ---
>  arch/arm64/kvm/vgic/vgic-v4.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
> index b5fa73c9fd35..cc3ab9cea182 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -418,6 +418,18 @@ int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int 
> virq,
>  irq->host_irq    = virq;
>  atomic_inc(>vlpi_count);
>
> +    /* Transfer pending state */
> +    ret = irq_set_irqchip_state(irq->host_irq,
> +    IRQCHIP_STATE_PENDING,
> +    irq->pending_latch);
> +    WARN_RATELIMIT(ret, "IRQ %d", irq->host_irq);
> +
> +    /*
> + * Let it be pruned from ap_list later and don't bother
> + * the List Register.
> + */
> +    irq->pending_latch = false;

 It occurs to me that calling into irq_set_irqchip_state() for a large
 number of interrupts can take a significant amount of time. It is also
 odd that you dump the VPT with the VPE unmapped, but rely on the VPE
 being mapped for the opposite operation.

 Shouldn't these be symmetric, all performed while the VPE is unmapped?
 It would also save a lot of ITS traffic.

>>>
>>> My thought was to use the existing interface directly without unmapping...
>>>
>>> If you want to unmap the vPE and poke the VPT here, as I said in the cover
>>> letter, set/unset_forwarding might also be called when all devices are 
>>> running
>>> at normal run time, in which case the unmapping of the vPE is not allowed...
>>
>> No, I'm suggesting that you don't do anything here, but instead as a 
>> by-product
>> of restoring the ITS tables. What goes wrong if you use the
>> KVM_DEV_ARM_ITS_RESTORE_TABLE backend instead?
> 
> There is an issue if we do it in the restoring of the ITS tables: the 
> transferring
> of the pending state needs the irq to be marked as hw before, which is done 
> by the
> pass-through device, but the configuring of the forwarding path of the VLPI 
> depends
> on the restoring of the vgic first... It is a circular dependency.
> 

Hi Marc,

We are pondering over this problem these days, but still don't get a good 
solution...
Could you give us some advice on this?

Or could we move the restoring of the pending states (include the sync from 
guest
RAM and the transfer to HW) to the GIC VM state change handler, which is 
completely
corresponding to save_pending_tables (more symmetric?) and don't expose GICv4...

Thanks,
Shenming

>>
>>> Another possible solution is to add a new dedicated interface to QEMU
>>> to transfer
>>> these pending states to HW in GIC VM state change handler corresponding to
>>> save_pending_tables?
>>
>> Userspace has no way to know we use GICv4, and I intend to keep it
>> completely out of the loop. The API is already pretty tortuous, and
>> I really don't want to add any extra complexity to it.
>>
>> Thanks,
>>
>>     M.


Re: [RFC PATCH v3.1 13/27] mmc: sdhci-uhs2: add set_power() to support vdd2

2020-11-29 Thread AKASHI Takahiro
On Thu, Nov 26, 2020 at 10:16:27AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > This is a UHS-II version of sdhci's set_power operation.
> > VDD2, as well as VDD, is handled here.
> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/mmc/host/sdhci-uhs2.c | 80 +++
> >  drivers/mmc/host/sdhci-uhs2.h |  2 +
> >  drivers/mmc/host/sdhci.c  | 58 +++--
> >  drivers/mmc/host/sdhci.h  |  2 +
> >  4 files changed, 119 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> > index e2b9743fe17d..2bf78cc4e9ed 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.c
> > +++ b/drivers/mmc/host/sdhci-uhs2.c
> > @@ -98,6 +98,86 @@ void sdhci_uhs2_reset(struct sdhci_host *host, u16 mask)
> >  }
> >  EXPORT_SYMBOL_GPL(sdhci_uhs2_reset);
> >  
> > +void sdhci_uhs2_set_power(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd)
> 
> This function isn't used, so let's rename it sdhci_uhs2_set_power_noreg and
> drop regulator support.

I have no strong opinion, but here Ben might want to further rework
the new sdhci_uhs2_set_power_noreg() now that it is almost the same as
GLI's gl9755_set_power()(, adding a new quirk?).

> > +{
> > +   struct mmc_host *mmc = host->mmc;
> > +   u8 pwr;
> > +
> > +   /* FIXME: check if flags & MMC_UHS2_SUPPORT? */
> > +   if (!(host->mmc->caps & MMC_CAP_UHS2)) {
> 
> As commented in another patch, please use a helper fn

As said, I would defer this.

> > +   sdhci_set_power(host, mode, vdd);
> > +   return;
> > +   }
> > +
> > +   if (mode != MMC_POWER_OFF) {
> > +   pwr = sdhci_get_vdd_value(vdd);
> 
> Simpler to open code this esp. as there are only 2 valid values:
> 
>   switch (1 << vdd) {

Can you ignore MMC_VDD_165_195 and MMC_VDD_20_21 here?

>   case MMC_VDD_29_30..MMC_VDD_30_31:
>   pwr = SDHCI_POWER_300;
>   break;
>   case MMC_VDD_32_33..MMC_VDD_33_34:
>   pwr = SDHCI_POWER_330;
>   break;
>   default:
>   WARN(1, "%s: Invalid vdd %#x\n",
>mmc_hostname(host->mmc), vdd);
>   break;
>   }
> 
> 
> > +   if (!pwr)
> > +   WARN(1, "%s: Invalid vdd %#x\n",
> > +mmc_hostname(host->mmc), vdd);
> > +
> > +   pwr |= SDHCI_VDD2_POWER_180;
> > +   }
> > +
> > +   if (host->pwr == pwr)
> > +   return;
> > +   host ->pwr = pwr;
> > +
> > +   if (pwr == 0) {
> > +   sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> > +
> > +   if (!IS_ERR(host->mmc->supply.vmmc))
> > +   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> > +   if (!IS_ERR_OR_NULL(host->mmc->supply.vmmc2))
> > +   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc2, 0);
> > +
> > +   if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
> 
> Please drop support for legacy quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON

Okay.

> 
> > +   sdhci_runtime_pm_bus_off(host);
> > +   } else {
> > +   if (!IS_ERR(host->mmc->supply.vmmc))
> > +   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> > +   if (!IS_ERR_OR_NULL(host->mmc->supply.vmmc2))
> > +   /* support 1.8v only for now */
> > +   mmc_regulator_set_ocr(mmc, mmc->supply.vmmc2,
> > + fls(MMC_VDD2_165_195) - 1);
> > +
> > +   /*
> > +* Spec says that we should clear the power reg before setting
> > +* a new value. Some controllers don't seem to like this though.
> > +*/
> > +   if (!(host->quirks & SDHCI_QUIRK_SINGLE_POWER_WRITE))
> 
> Please drop support for legacy quirk here and several cases below.  As I
> mentioned in another patch, just put a comment somewhere listing what is
> not supported for UHS2 host controllers.

Okay.

-Takahiro Akashi

> 
> > +   sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> > +
> > +   /*
> > +* At least the Marvell CaFe chip gets confused if we set the
> > +* voltage and set turn on power at the same time, so set the
> > +* voltage first.
> > +*/
> > +   if (host->quirks & SDHCI_QUIRK_NO_SIMULT_VDD_AND_POWER)
> > +   sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
> > +
> > +   /* vdd first */
> > +   pwr |= SDHCI_POWER_ON;
> > +   sdhci_writeb(host, pwr & 0xf, SDHCI_POWER_CONTROL);
> > +   mdelay(5);
> > +
> > +   pwr |= SDHCI_VDD2_POWER_ON;
> > +   sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
> > +   mdelay(5);
> > +
> > +   if (host->quirks2 & 

Re: [PATCH v4 3/3] arm: dts: ls1021a: fix rcpm failed to claim resource

2020-11-29 Thread Shawn Guo
On Mon, Nov 02, 2020 at 03:26:52PM +0800, Ran Wang wrote:
> The range of dcfg reg is wrong, which overlap with other device,
> such as rcpm. This issue causing rcpm driver failed to claim
> reg resource when calling devm_ioremap_resource().
> 
> Signed-off-by: Ran Wang 
> Acked-by: Li Yang 

Applied, thanks.


Re: [PATCH v4 2/3] arm: dts: ls1021a: fix flextimer failed to wake system

2020-11-29 Thread Shawn Guo
On Mon, Nov 02, 2020 at 03:26:51PM +0800, Ran Wang wrote:
> The data of property 'fsl,rcpm-wakeup' is not corrcet, which causing
> RCPM driver incorrectly program register IPPDEXPCR1, then flextimer is
> wrongly clock gated during system suspend, can't send interrupt to
> wake.
> 
> Signed-off-by: Ran Wang 
> Acked-by: Li Yang 

Applied, thanks.


linux-next: build warnings after merge of the tip tree

2020-11-29 Thread Stephen Rothwell
Hi all,

After merging the tip tree, today's linux-next build (htmldocs) produced
these warnings:

Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected 
indentation.
Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected 
indentation.
Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING: Unexpected 
indentation.

Introduced by commit

  7ac2f1017115 ("x86/platform/uv: Update ABI documentation of 
/sys/firmware/sgi_uv/")

-- 
Cheers,
Stephen Rothwell


pgpJtQmSDKAaD.pgp
Description: OpenPGP digital signature


Re: [PATCH V1] block: Fix use-after-free while iterating over requests

2020-11-29 Thread Hannes Reinecke

On 11/26/20 5:49 PM, John Garry wrote:

On 26/11/2020 16:27, Bart Van Assche wrote:

On 11/26/20 7:02 AM, Pradeep P V K wrote:

Observes below crash while accessing (use-after-free) request queue
member of struct request.

191.784789:   <2> Unable to handle kernel paging request at virtual
address ff81429a4440
...
191.786174:   <2> CPU: 3 PID: 213 Comm: kworker/3:1H Tainted: G S
O  5.4.61-qgki-debug-ge45de39 #1
...
191.786226:   <2> Workqueue: kblockd blk_mq_timeout_work
191.786242:   <2> pstate: 20c5 (nzCv daif +PAN +UAO)
191.786261:   <2> pc : bt_for_each+0x114/0x1a4
191.786274:   <2> lr : bt_for_each+0xe0/0x1a4
...
191.786494:   <2> Call trace:
191.786507:   <2>  bt_for_each+0x114/0x1a4
191.786519:   <2>  blk_mq_queue_tag_busy_iter+0x60/0xd4
191.786532:   <2>  blk_mq_timeout_work+0x54/0xe8
191.786549:   <2>  process_one_work+0x2cc/0x568
191.786562:   <2>  worker_thread+0x28c/0x518
191.786577:   <2>  kthread+0x160/0x170
191.786594:   <2>  ret_from_fork+0x10/0x18
191.786615:   <2> Code: 0b080148 f9404929 f8685921 b4fffe01 (f9400028)
191.786630:   <2> ---[ end trace 0f1f51d79ab3f955 ]---
191.786643:   <2> Kernel panic - not syncing: Fatal exception

Fix this by updating the freed request with NULL.
This could avoid accessing the already free request from other
contexts while iterating over the requests.

Signed-off-by: Pradeep P V K 
---
  block/blk-mq.c | 1 +
  block/blk-mq.h | 1 +
  2 files changed, 2 insertions(+)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 55bcee5..9996cb1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -492,6 +492,7 @@ static void __blk_mq_free_request(struct request 
*rq)

  blk_crypto_free_request(rq);
  blk_pm_mark_last_busy(rq);
+    hctx->tags->rqs[rq->tag] = NULL;
  rq->mq_hctx = NULL;
  if (rq->tag != BLK_MQ_NO_TAG)
  blk_mq_put_tag(hctx->tags, ctx, rq->tag);
diff --git a/block/blk-mq.h b/block/blk-mq.h
index a52703c..8747bf1 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -224,6 +224,7 @@ static inline int __blk_mq_active_requests(struct 
blk_mq_hw_ctx *hctx)

  static inline void __blk_mq_put_driver_tag(struct blk_mq_hw_ctx *hctx,
 struct request *rq)
  {
+    hctx->tags->rqs[rq->tag] = NULL;
  blk_mq_put_tag(hctx->tags, rq->mq_ctx, rq->tag);
  rq->tag = BLK_MQ_NO_TAG;


Is this perhaps a block driver bug instead of a block layer core bug? If
this would be a block layer core bug, it would have been reported before.


Isn't this the same issue which as been reported many times:

https://lore.kernel.org/linux-block/20200820180335.3109216-1-ming@redhat.com/ 



https://lore.kernel.org/linux-block/8376443a-ec1b-0cef-8244-ed584b96f...@huawei.com/ 



But I never saw a crash, just kasan report.

And if that above were a concern, I would have thought one would need to 
use a WRITE_ONCE() here; otherwise we might have a race condition where 
other CPUs still see the old value, no?


Cheers,

Hannes
--
Dr. Hannes ReineckeKernel Storage Architect
h...@suse.de  +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer


Re: [PATCH] crypto: ecrdsa - use subsys_initcall instead of module_init

2020-11-29 Thread Tianjia Zhang




On 11/30/20 10:24 AM, Herbert Xu wrote:

On Mon, Nov 30, 2020 at 10:21:56AM +0800, Tianjia Zhang wrote:



That is true only if there are non-generic implementations of
the algorithms, which is not the case here.  Please explain the
real reason why this is needed.


This is a generic algorithm, the author Vitaly Chikunov has also confirmed
it, please consider this patch again.


As I said, the generic algorithm only needs to be loaded early *if*
there are non-generic implementations.

Cheers,



For ecrdsa, there is no reason to advance the initialization to 
subsys_init, this is just to make code clean up to have algorithm 
initialization uniform with other implementations.


It’s just that I think that in the commit c4741b230597 ("crypto: run 
initcalls for generic implementations earlier"), the modification to 
ecrdsa happened to be omitted, because from the point of commit time, it 
was submitted at the same time as the ecrdsa commits, and it may happen 
to be omitted for ecrdsa.


Best regards,
Tianjia


[PATCH] arm64: dts: qcom: sdm845: Add gpi dma node

2020-11-29 Thread Vinod Koul
This add the device node for gpi_dma0 and gpi_dma1 instances found in
sdm845.

Signed-off-by: Vinod Koul 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 45 
 1 file changed, 45 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 6465a6653ad9..a6f41678794c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1114,6 +1114,28 @@ opp-12800 {
};
};
 
+   gpi_dma0: dma-controller@80 {
+   #dma-cells = <3>;
+   compatible = "qcom,sdm845-gpi-dma";
+   reg = <0 0x0080 0 0x6>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   dma-channels = <13>;
+   dma-channel-mask = <0xfa>;
+   iommus = <_smmu 0x0016 0x0>;
+   };
+
qupv3_id_0: geniqup@8c {
compatible = "qcom,geni-se-qup";
reg = <0 0x008c 0 0x6000>;
@@ -1454,6 +1476,29 @@ uart7: serial@89c000 {
};
};
 
+   gpi_dma1: dma-controller@0xa0 {
+   #dma-cells = <3>;
+   compatible = "qcom,sdm845-gpi-dma";
+   reg = <0 0x00a0 0 0x6>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   dma-channels = <13>;
+   dma-channel-mask = <0xfa>;
+   iommus = <_smmu 0x06d6 0x0>;
+   status = "disabled";
+   };
+
qupv3_id_1: geniqup@ac {
compatible = "qcom,geni-se-qup";
reg = <0 0x00ac 0 0x6000>;
-- 
2.26.2



general protection fault in l2cap_chan_timeout

2020-11-29 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:fa02fcd9 Merge tag 'media/v5.10-2' of git://git.kernel.org..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14a36fa550
kernel config:  https://syzkaller.appspot.com/x/.config?x=7be70951fca93701
dashboard link: https://syzkaller.appspot.com/bug?extid=e7edf1d784c283324076
compiler:   clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)

Unfortunately, I don't have any reproducer for this issue yet.

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

general protection fault, probably for non-canonical address 
0xdc5a:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x02d0-0x02d7]
CPU: 1 PID: 16756 Comm: kworker/1:8 Not tainted 5.10.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: events l2cap_chan_timeout
RIP: 0010:__mutex_lock_common+0x9b/0x2f20 kernel/locking/mutex.c:938
Code: 8a bc 24 28 01 00 00 83 3d 01 69 0f 06 00 75 34 48 8b 44 24 08 48 8d 78 
60 48 89 f8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 05 e8 ba 
7f 77 f8 48 8b 44 24 08 48 39 40 60 0f 85
RSP: 0018:c9000245fb78 EFLAGS: 00010206
RAX: 005a RBX: 8880708d8110 RCX: dc00
RDX:  RSI:  RDI: 02d0
RBP:  R08: 8876a063 R09: 
R10: fbfff1a1c3ee R11:  R12: 
R13: dc00 R14:  R15: 8880b9d33c00
FS:  () GS:8880b9d0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffde459fd3c CR3: 186a5000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __mutex_lock kernel/locking/mutex.c:1103 [inline]
 mutex_lock_nested+0x1a/0x20 kernel/locking/mutex.c:1118
 l2cap_chan_timeout+0x53/0x280 net/bluetooth/l2cap_core.c:422
 process_one_work+0x789/0xfc0 kernel/workqueue.c:2272
 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2418
 kthread+0x39a/0x3c0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Modules linked in:
---[ end trace c01f537d4b85904a ]---
RIP: 0010:__mutex_lock_common+0x9b/0x2f20 kernel/locking/mutex.c:938
Code: 8a bc 24 28 01 00 00 83 3d 01 69 0f 06 00 75 34 48 8b 44 24 08 48 8d 78 
60 48 89 f8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 05 e8 ba 
7f 77 f8 48 8b 44 24 08 48 39 40 60 0f 85
RSP: 0018:c9000245fb78 EFLAGS: 00010206
RAX: 005a RBX: 8880708d8110 RCX: dc00
RDX:  RSI:  RDI: 02d0
RBP:  R08: 8876a063 R09: 
R10: fbfff1a1c3ee R11:  R12: 
R13: dc00 R14:  R15: 8880b9d33c00
FS:  () GS:8880b9d0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fbbcfa32740 CR3: 6d47f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.


Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

2020-11-29 Thread Eli Cohen
On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:
> On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > We should not try to use the VF MAC address as that is used by the
> > regular (e.g. mlx5_core) NIC implementation. Instead, use a random
> > generated MAC address.
> > 
> > Suggested by: Cindy Lu 
> > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 
> > devices")
> > Signed-off-by: Eli Cohen 
> 
> I didn't realise it's possible to use VF in two ways
> with and without vdpa.

Using a VF you can create quite a few resources, e.g. send queues
recieve queues, virtio_net queues etc. So you can possibly create
several instances of vdpa net devices and nic net devices.

> Could you include a bit more description on the failure
> mode?

Well, using the MAC address of the nic vport is wrong since that is the
MAC of the regular NIC implementation of mlx5_core.

> Is switching to a random mac for such an unusual
> configuration really justified?

Since I can't use the NIC's MAC address, I have two options:
1. To get the MAC address as was chosen by the user administering the
   NIC. This should invoke the set_config callback. Unfortunately this
   is not implemented yet.

2. Use a random MAC address. This is OK since if (1) is implemented it
   can always override this random configuration.

> It looks like changing a MAC could break some guests,
> can it not?
>

No, it will not. The current version of mlx5 VDPA does not allow regular
NIC driver and VDPA to co-exist. I have patches ready that enable that
from steering point of view. I will post them here once other patches on
which they depend will be merged.

https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
 
> > ---
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 1fa6fcac8299..80d06d958b8b 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -1955,10 +1955,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
> > if (err)
> > goto err_mtu;
> >  
> > -   err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, config->mac);
> > -   if (err)
> > -   goto err_mtu;
> > -
> > +   eth_random_addr(config->mac);
> > mvdev->vdev.dma_dev = mdev->device;
> > err = mlx5_vdpa_alloc_resources(>mvdev);
> > if (err)
> > -- 
> > 2.26.2
> 


[PATCH v1 3/3] dt-bindings: panel: Add bindings for MRB2801

2020-11-29 Thread mdurnev
From: Mikhail Durnev 

Add binding for Ronbo MRB2801 display module.

This binding is for display panels using an Ilitek ILI9341 controller in
parallel mode.

Signed-off-by: Mikhail Durnev 
---
 .../devicetree/bindings/display/ronbo,mrb2801.txt  | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt

diff --git a/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt 
b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
new file mode 100644
index 000..db1a861e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
@@ -0,0 +1,42 @@
+MRB2801 display panel
+
+This binding is for display panels using an Ilitek ILI9341 controller in
+parallel mode.
+
+Required properties:
+- compatible:  "ronbo,mrb2801"
+- dc-gpios:D/C pin
+- wr-gpios:W/R pin
+- db-gpios:8 or 16 DB pins
+- reset-gpios: Reset pin
+- wr-up-down-delays:   Delays in ns for changing W/R from down to up and from 
up to down
+
+Optional properties:
+- backlight:   phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   mrb2801{
+   compatible = "ronbo,mrb2801";
+   db-gpios = < 17 0>, /* DB0 */
+  < 18 0>, /* DB1 */
+  < 27 0>, /* DB2 */
+  < 22 0>, /* DB3 */
+  < 23 0>, /* DB4 */
+  < 24 0>, /* DB5 */
+  < 25 0>, /* DB6 */
+  <  4 0>, /* DB7 */
+  < 14 0>, /* DB8 */
+  < 15 0>, /* DB9 */
+  <  5 0>, /* DB10 */
+  <  6 0>, /* DB11 */
+  < 13 0>, /* DB12 */
+  < 19 0>, /* DB13 */
+  < 26 0>, /* DB14 */
+  < 12 0>; /* DB15 */
+   dc-gpios = < 16 0>; /* D/C */
+   wr-gpios = < 20 0>; /* W/R */
+   wr-up-down-delays = <10 51>;
+   reset-gpios = < 21 0>; /* RST */
+   backlight = <>;
+   };
-- 
2.7.4



[PATCH v1 0/3] drm/mipi-dbi: Type B bus support, drm/tiny: MRB2801

2020-11-29 Thread mdurnev
From: Mikhail Durnev 

Hi All,

This patch series is aiming at extending the mipi-dbi bus driver
to support Intel 8080 type parallel bus (Type B) over GPIO and
adding a new driver for ILI9341 display panels with 8- or 16-bit
parallel interface.

It was tested with the MRB2801 display module [1] that had
a connector compatible with the ALIENTEK STM32 development board.
The module was connected to Raspberry Pi 3 via GPIO pins.

The parallel bus is implemented partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.
The RD pin of the display has to always receive the logic high
signal to make sure the data bus pins from the dislay side are
always in the high impedance state. Otherwise the display module
as well as the GPIO controller of the host can be damaged.
To be on the safe side I recommend using protective resistors
for all GPIO pins conneced to DB pins of the display. Resistors
of 10 kOhms are just fine for RPi 3. The WR and DC pins may not
work well with 10K resistors. Although there is no need to protect
them, you can try using 1K resistors if you want.

Bit banging is used to transmit data over the parallel bus from
host to display. There are two numbers that contol timings. They
should be defined in the device tree via the wr-up-down-delays
property. The first number is related to the write control pulse
duration, and the second number is related to the write cycle
duration. For ILI9341, the write pulse cannot be shorter than 15 ns,
and the write duration cannot be shorter than 66 ns. Delays of
10 and 51 ns respectively allow to meet the specifications on
RPi 3. Faster machines may need values closer to 15 and 66.

[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801

Mikhail Durnev (3):
  drm/mipi-dbi: Add support for Type B
  drm/tiny: Add driver for ili9341 with parallel bus
  dt-bindings: panel: Add bindings for MRB2801

 .../devicetree/bindings/display/ronbo,mrb2801.txt  |  42 +++
 drivers/gpu/drm/drm_mipi_dbi.c | 116 -
 drivers/gpu/drm/tiny/Kconfig   |  13 +
 drivers/gpu/drm/tiny/Makefile  |   1 +
 drivers/gpu/drm/tiny/ili9341_gpio.c| 290 +
 include/drm/drm_mipi_dbi.h |  30 ++-
 6 files changed, 490 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
 create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c

-- 
2.7.4



[PATCH v1 2/3] drm/tiny: Add driver for ili9341 with parallel bus

2020-11-29 Thread mdurnev
From: Mikhail Durnev 

MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.

It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.

[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801

Signed-off-by: Mikhail Durnev 
---
 drivers/gpu/drm/tiny/Kconfig|  13 ++
 drivers/gpu/drm/tiny/Makefile   |   1 +
 drivers/gpu/drm/tiny/ili9341_gpio.c | 290 
 3 files changed, 304 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c

diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f..e48e268 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -66,6 +66,19 @@ config TINYDRM_ILI9341
 
  If M is selected the module will be called ili9341.
 
+config TINYDRM_ILI9341_GPIO
+   tristate "DRM support for ILI9341 display panels with parallel bus 
interface over GPIO"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_MIPI_DBI
+   select BACKLIGHT_CLASS_DEVICE
+   help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * MRB2801 2.8" 240x320 TFT
+
+ If M is selected the module will be called ili9341_gpio.
+
 config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5..1ad2c0d 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_GM12U320)  += gm12u320.o
 obj-$(CONFIG_TINYDRM_HX8357D)  += hx8357d.o
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
+obj-$(CONFIG_TINYDRM_ILI9341_GPIO) += ili9341_gpio.o
 obj-$(CONFIG_TINYDRM_ILI9486)  += ili9486.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
diff --git a/drivers/gpu/drm/tiny/ili9341_gpio.c 
b/drivers/gpu/drm/tiny/ili9341_gpio.c
new file mode 100644
index 000..de8a63b8
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9341_gpio.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels with parallel bus interface
+ *
+ * Copyright 2020 Mikhail Durnev 
+ *
+ * Based on ili9341.c:
+ * Copyright 2018 David Lechner 
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD  0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL   0xe0
+#define ILI9341_NGAMCTRL   0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL   0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+   struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+   struct mipi_dbi *dbi = >dbi;
+   u8 addr_mode;
+   int ret, idx;
+
+   if (!drm_dev_enter(pipe->crtc.dev, ))
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   ret = mipi_dbi_poweron_conditional_reset(dbidev);
+   if (ret < 0)
+   goto out_exit;
+   if (ret == 1)
+   goto out_enable;
+
+   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+   mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+   mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+   mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+   mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+   mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+   mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+   /* Power Control */
+   mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x23);
+   mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x10);
+   /* VCOM */
+   mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x3e, 0x28);
+   mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0x86);
+
+   /* Memory Access 

[PATCH v1 1/3] drm/mipi-dbi: Add support for Type B

2020-11-29 Thread mdurnev
From: Mikhail Durnev 

Intel 8080 type (Type B) parallel bus over GPIO.

The parallel bus is implemented partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.

It is enough to support only write operations to initialize displays
and output video data. The bus driver returns EOPNOTSUPP for all read
operations requested through a display driver.

Bit banging is used to transmit data over the parallel bus from host
to display. There are two numbers that contol timings: wr_up_delay
and wr_down_delay. They should be provided by the display driver.
The first number is related to the write control pulse duration, and
the second number is related to the write cycle duration that can
be found in the specification of the display.

Signed-off-by: Mikhail Durnev 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 116 -
 include/drm/drm_mipi_dbi.h |  30 ++-
 2 files changed, 144 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd..5dedc59 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -61,7 +61,7 @@
  *3. 8-bit with the Data/Command signal as a separate D/CX pin
  *
  * Currently mipi_dbi only supports Type C options 1 and 3 with
- * mipi_dbi_spi_init().
+ * mipi_dbi_spi_init() and Type B with mipi_dbi_gpio_init().
  */
 
 #define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
@@ -1158,6 +1158,120 @@ EXPORT_SYMBOL(mipi_dbi_spi_transfer);
 
 #endif /* CONFIG_SPI */
 
+/*
+ * This function implements data transfer only from host to display.
+ */
+static void mipi_dbi_gpio_transfer(struct mipi_dbi *dbi, u16 data)
+{
+   unsigned long ldata = data;
+
+   /*
+* Set W/R to low to start transfer.
+* Set DB bits with provided data when W/R is low.
+*/
+   gpiod_set_value_cansleep(dbi->wr, 0);
+   gpiod_set_array_value_cansleep(dbi->db->ndescs, dbi->db->desc,
+  dbi->db->info, );
+
+   /*
+* The bus usually needs additional delay.
+*/
+   ndelay(dbi->wr_up_delay);
+
+   /*
+* Set W/R to high to indicate that DB lines are set.
+*/
+   gpiod_set_value_cansleep(dbi->wr, 1);
+
+   /*
+* The connected display needs some time to read the data.
+*/
+   ndelay(dbi->wr_down_delay);
+}
+
+static int mipi_dbi_gpio_command(struct mipi_dbi *dbi, u8 *cmd,
+   u8 *par, size_t num)
+{
+   int i;
+
+   /*
+* Read commands are not currently supported.
+*/
+   if (mipi_dbi_command_is_read(dbi, *cmd))
+   return -EOPNOTSUPP;
+
+   MIPI_DBI_DEBUG_COMMAND(*cmd, par, num);
+
+   gpiod_set_value_cansleep(dbi->dc, 0);
+   mipi_dbi_gpio_transfer(dbi, (u16)*cmd);
+   gpiod_set_value_cansleep(dbi->dc, 1);
+
+   if (dbi->db->ndescs == 16 &&
+   (*cmd == MIPI_DCS_WRITE_MEMORY_START ||
+*cmd == MIPI_DCS_WRITE_MEMORY_CONTINUE)) {
+   /*
+* Only a couple of commands supports 16-bit transfer.
+*/
+   for (i = 0; i < num; i += 2) {
+   u16 data = *(u16 *)[i];
+
+   if (dbi->swap_bytes)
+   data = (data >> 8) | (data << 8);
+
+   mipi_dbi_gpio_transfer(dbi, data);
+   }
+   } else {
+   for (i = 0; i < num; i++) {
+   /*
+* Other commands ignore most significant bits.
+*/
+   mipi_dbi_gpio_transfer(dbi, (u16)par[i]);
+   }
+   }
+
+   return 0;
+}
+
+/**
+ * mipi_dbi_gpio_init - Initialize MIPI DBI Type B interface implemented via 
GPIO
+ * @dbi: MIPI DBI structure to initialize
+ * @dc: D/C gpio
+ * @wr: W/R gpio
+ * @db: DB gpios
+ * @wr_up_delay: Delay after setting DB and before changing W/R from low to 
high
+ * @wr_down_delay: Delay after changing W/R from low to high
+ *
+ * This function sets _dbi->command, enables _dbi->read_commands for 
the
+ * usual read commands. It should be followed by a call to mipi_dbi_dev_init() 
or
+ * a driver-specific init.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_gpio_init(struct mipi_dbi *dbi, struct gpio_desc *dc,
+ struct gpio_desc *wr, struct gpio_descs *db,
+ unsigned long wr_up_delay, unsigned long wr_down_delay)
+{
+   dbi->spi = NULL; /* Type B uses GPIO lines rather than SPI */
+
+   dbi->read_commands = mipi_dbi_dcs_read_commands;
+   dbi->command = mipi_dbi_gpio_command;
+
+   dbi->dc = dc;
+   dbi->wr = wr;
+   

Re: [PATCH v2 1/5] USB: gadget: f_rndis: fix bitrate for SuperSpeed and above

2020-11-29 Thread Peter Chen
On 20-11-27 15:05:55, Greg Kroah-Hartman wrote:
> From: Will McVicker 
> 
> Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate
> defined by commit 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed 
> descriptors
> for CDC NCM").
> 
> Cc: Felipe Balbi 
> Cc: EJ Hsu 
> Cc: Peter Chen 
> Cc: stable 
> Signed-off-by: Will McVicker 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/usb/gadget/function/f_rndis.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/f_rndis.c 
> b/drivers/usb/gadget/function/f_rndis.c
> index 9534c8ab62a8..0739b05a0ef7 100644
> --- a/drivers/usb/gadget/function/f_rndis.c
> +++ b/drivers/usb/gadget/function/f_rndis.c
> @@ -87,8 +87,10 @@ static inline struct f_rndis *func_to_rndis(struct 
> usb_function *f)
>  /* peak (theoretical) bulk transfer rate in bits-per-second */
>  static unsigned int bitrate(struct usb_gadget *g)
>  {
> + if (gadget_is_superspeed(g) && g->speed >= USB_SPEED_SUPER_PLUS)
> + return 425000U;

Is tested value or spec defined value?

>   if (gadget_is_superspeed(g) && g->speed == USB_SPEED_SUPER)
> - return 13 * 1024 * 8 * 1000 * 8;
> + return 375000U;

13 * 1024 * 8 * 1000 * 8 = 851,968,000, how 375000U is calculated?

>   else if (gadget_is_dualspeed(g) && g->speed == USB_SPEED_HIGH)
>   return 13 * 512 * 8 * 1000 * 8;
>   else
> -- 
> 2.29.2
> 

-- 

Thanks,
Peter Chen

Re: [PATCH v9 2/2] Add Intel LGM SoC DMA support.

2020-11-29 Thread Reddy, MallikarjunaX

Hi Vinod,

Thanks for your valuable comments. My reply inline.

On 11/26/2020 12:50 PM, Vinod Koul wrote:

On 25-11-20, 18:39, Reddy, MallikarjunaX wrote:


desc needs to be configure for each dma channel and the remapped address of
the IGP & EGP is desc base adress.

Why should this address not passed as src_addr/dst_addr?

src_addr/dst_addr is the data pointer. Data pointer indicates address
pointer of data buffer.

ldma_chan_desc_cfg() carries the descriptor address.

The descriptor list entry contains the data pointer, which points to the
data section in the memory.

So we should not use src_addr/dst_addr as desc base address.

Okay sounds reasonable. why is this using in API here?

descriptor base address needs to be write into the dma register (DMA_CDBA).

Why cant descriptor be allocated by damenegine driver, passed to client
as we normally do in prep_* callbacks ? Why do you need a custom API

1)
client needs to set the descriptor base address and also number of 
descriptors used in the descriptor list.
reg DMA_CDBA used to configure descriptor base address and reg DMA_CDLEN 
used to configure number of descriptors used in the descriptor list.


In case of (ver > DMA_VER22) all descriptor fields and data pointer will 
be set by client, so we just need to write desc base and num desc length 
in to corresponding registers from the driver side.


dma_async_tx_descriptor * data is not really needed from driver to 
client side , so i am not planned to return 'struct 
dma_async_tx_descriptor *'.


because of this reason i used custom API (return -Ve for error and ZERO 
for success) instead of standard dmaengine_prep_slave_sg() callback 
(return 'struct dma_async_tx_descriptor *' descriptor)


2)
We can also use the dmaengine_prep_slave_sg( ) to pass desc base addr & 
desc number from client.
In that case we have to use (sg)->dma_address as desc base address and 
(sg)->length as desc length.


dmaengine prep_* callback return 'struct dma_async_tx_descriptor *, this 
can be used on client side as to check  prep_* callback SUCCESS/FAIL.


Example:
/* code snippet */

static struct dma_async_tx_descriptor *
ldma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
  unsigned int sglen, enum dma_transfer_direction dir,
  unsigned long flags, void *context)
{

.

    if (d->ver > DMA_VER22)
        return ldma_chan_desc_cfg(chan, sgl->dma_address, sglen);

.

}

static struct dma_async_tx_descriptor *
ldma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base, int 
desc_num)

{
    struct ldma_chan *c = to_ldma_chan(chan);
    struct ldma_dev *d = to_ldma_dev(c->vchan.chan.device);
        struct dma_async_tx_descriptor *tx;
    struct dw2_desc_sw *ds;

    if (!desc_num) {
    dev_err(d->dev, "Channel %d must allocate descriptor 
first\n",

    c->nr);
    return NULL;
    }

    if (desc_num > DMA_MAX_DESC_NUM) {
    dev_err(d->dev, "Channel %d descriptor number out of 
range %d\n",

    c->nr, desc_num);
    return NULL;
    }

    ldma_chan_desc_hw_cfg(c, desc_base, desc_num);
    c->flags |= DMA_HW_DESC;
    c->desc_cnt = desc_num;
    c->desc_phys = desc_base;

    ds = kzalloc(sizeof(*ds), GFP_NOWAIT);
    if (!ds)
    return NULL;

    tx = >vdesc.tx;
    dma_async_tx_descriptor_init(tx, chan);

    return tx;
}
Please let me know if this is OK, So that i will include in the next patch.




[PATCH v10 7/7] i3c: master: mastership handover, defslvs processing in cdns controller driver

2020-11-29 Thread Parshuram Thombare
Added I3C bus mastership handover and DEFSLVS message handling
code to Cadence's I3C master controller driver.

Signed-off-by: Parshuram Thombare 
---
 drivers/i3c/master/i3c-master-cdns.c |  329 +++---
 1 files changed, 306 insertions(+), 23 deletions(-)

diff --git a/drivers/i3c/master/i3c-master-cdns.c 
b/drivers/i3c/master/i3c-master-cdns.c
index f1d6d68..ff07862 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -160,6 +160,7 @@
 #define SLV_IMR0x48
 #define SLV_ICR0x4c
 #define SLV_ISR0x50
+#define SLV_INT_DEFSLVSBIT(21)
 #define SLV_INT_TM BIT(20)
 #define SLV_INT_ERROR  BIT(19)
 #define SLV_INT_EVENT_UP   BIT(18)
@@ -192,7 +193,7 @@
 #define SLV_STATUS1_HJ_DIS BIT(18)
 #define SLV_STATUS1_MR_DIS BIT(17)
 #define SLV_STATUS1_PROT_ERR   BIT(16)
-#define SLV_STATUS1_DA(x)  (((s) & GENMASK(15, 9)) >> 9)
+#define SLV_STATUS1_DA(s)  (((s) & GENMASK(15, 9)) >> 9)
 #define SLV_STATUS1_HAS_DA BIT(8)
 #define SLV_STATUS1_DDR_RX_FULLBIT(7)
 #define SLV_STATUS1_DDR_TX_FULLBIT(6)
@@ -397,6 +398,9 @@ struct cdns_i3c_data {
 
 struct cdns_i3c_master {
struct work_struct hj_work;
+   struct work_struct mr_yield_work;
+   struct work_struct defslvs_work;
+   struct completion mr_done;
struct i3c_master_controller base;
u32 free_rr_slots;
unsigned int maxdevs;
@@ -416,6 +420,7 @@ struct cdns_i3c_master {
struct cdns_i3c_master_caps caps;
unsigned long i3c_scl_lim;
const struct cdns_i3c_data *devdata;
+   u8 mr_addr;
 };
 
 static inline struct cdns_i3c_master *
@@ -1182,10 +1187,6 @@ static int cdns_i3c_master_do_daa(struct 
i3c_master_controller *m)
 
cdns_i3c_master_upd_i3c_scl_lim(master);
 
-   /* Unmask Hot-Join and Mastership request interrupts. */
-   i3c_master_enec_locked(m, I3C_BROADCAST_ADDR,
-  I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR);
-
return 0;
 }
 
@@ -1208,21 +1209,21 @@ static int cdns_i3c_master_bus_init(struct 
i3c_master_controller *m)
struct cdns_i3c_master *master = to_cdns_i3c_master(m);
unsigned long pres_step, sysclk_rate, max_i2cfreq;
struct i3c_bus *bus = i3c_master_get_bus(m);
-   u32 ctrl, prescl0, prescl1, pres, low;
+   u32 ctrl, prescl0, prescl1, pres, low, bus_mode;
struct i3c_device_info info = { };
int ret, ncycles;
 
switch (bus->mode) {
case I3C_BUS_MODE_PURE:
-   ctrl = CTRL_PURE_BUS_MODE;
+   bus_mode = CTRL_PURE_BUS_MODE;
break;
 
case I3C_BUS_MODE_MIXED_FAST:
-   ctrl = CTRL_MIXED_FAST_BUS_MODE;
+   bus_mode = CTRL_MIXED_FAST_BUS_MODE;
break;
 
case I3C_BUS_MODE_MIXED_SLOW:
-   ctrl = CTRL_MIXED_SLOW_BUS_MODE;
+   bus_mode = CTRL_MIXED_SLOW_BUS_MODE;
break;
 
default:
@@ -1253,7 +1254,6 @@ static int cdns_i3c_master_bus_init(struct 
i3c_master_controller *m)
bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5);
 
prescl0 |= PRESCL_CTRL0_I2C(pres);
-   writel(prescl0, master->regs + PRESCL_CTRL0);
 
/* Calculate OD and PP low. */
pres_step = 10 / (bus->scl_rate.i3c * 4);
@@ -1261,7 +1261,6 @@ static int cdns_i3c_master_bus_init(struct 
i3c_master_controller *m)
if (ncycles < 0)
ncycles = 0;
prescl1 = PRESCL_CTRL1_OD_LOW(ncycles);
-   writel(prescl1, master->regs + PRESCL_CTRL1);
 
/* Get an address for the master. */
ret = i3c_master_get_free_addr(m, 0);
@@ -1279,13 +1278,21 @@ static int cdns_i3c_master_bus_init(struct 
i3c_master_controller *m)
if (ret)
return ret;
 
+   ctrl = readl(master->regs + CTRL);
+   if (ctrl & CTRL_DEV_EN)
+   cdns_i3c_master_disable(master);
+   writel(prescl0, master->regs + PRESCL_CTRL0);
+   writel(prescl1, master->regs + PRESCL_CTRL1);
+   ctrl &= ~CTRL_BUS_MODE_MASK;
+   ctrl |= bus_mode | CTRL_HALT_EN | CTRL_MCS_EN;
/*
 * Enable Hot-Join, and, when a Hot-Join request happens, disable all
 * events coming from this device.
 *
 * We will issue ENTDAA afterwards from the threaded IRQ handler.
 */
-   ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN | CTRL_MCS_EN;
+   if (!m->secondary)
+   ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC;
 
/*
 * Configure data hold delay based on device-specific data.
@@ -1358,6 +1365,7 @@ static void cdns_i3c_master_handle_ibi(struct 
cdns_i3c_master *master,
 
 static void cnds_i3c_master_demux_ibis(struct cdns_i3c_master 

Re: [PATCH] arm64: dts: qcom: c630: Expose LID events

2020-11-29 Thread Shawn Guo
On Wed, Nov 25, 2020 at 12:08:38AM -0600, Bjorn Andersson wrote:
> The LID state can be read from GPIO 124 and the "tablet mode" from GPIO
> 95, expose these to the system using gpio-keys and mark the falling edge
> of the LID state as a wakeup-source - to wake the system from suspend.
> 
> Signed-off-by: Bjorn Andersson 

Acked-by: Shawn Guo 


Re: [RFC PATCH v3.1 12/27] mmc: sdhci-uhs2: add reset function

2020-11-29 Thread AKASHI Takahiro
On Thu, Nov 26, 2020 at 10:16:11AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > Sdhci_uhs2_reset() does a UHS-II specific reset operation.
> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/mmc/host/sdhci-uhs2.c | 49 +++
> >  drivers/mmc/host/sdhci-uhs2.h |  1 +
> >  drivers/mmc/host/sdhci.c  |  3 ++-
> >  drivers/mmc/host/sdhci.h  |  1 +
> >  4 files changed, 53 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> > index 08905ed081fb..e2b9743fe17d 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.c
> > +++ b/drivers/mmc/host/sdhci-uhs2.c
> > @@ -10,6 +10,7 @@
> >   *  Author: AKASHI Takahiro 
> >   */
> >  
> > +#include 
> >  #include 
> >  
> >  #include "sdhci.h"
> > @@ -49,6 +50,54 @@ void sdhci_uhs2_dump_regs(struct sdhci_host *host)
> >  }
> >  EXPORT_SYMBOL_GPL(sdhci_uhs2_dump_regs);
> >  
> > +/*\
> > + * 
> >   *
> > + * Low level functions 
> >   *
> > + * 
> >   *
> > +\*/
> > +
> > +/**
> > + * sdhci_uhs2_reset - invoke SW reset
> > + * @host: SDHCI host
> > + * @mask: Control mask
> > + *
> > + * Invoke SW reset, depending on a bit in @mask and wait for completion.
> > + */
> > +void sdhci_uhs2_reset(struct sdhci_host *host, u16 mask)
> > +{
> > +   unsigned long timeout;
> > +
> > +   if (!(host->mmc->caps & MMC_CAP_UHS2))
> 
> Please make a helper so this can be like:
> 
>   if (!sdhci_uhs2_mode(host))
> 
> The capability will be always present for hosts that support UHS2, but not
> all cards support UHS2 mode.  I suggest just adding a bool to struct
> sdhci_host to keep track of when the host is in UHS2 mode.

Given the fact that UHS-2 host may (potentially) support a topology like
a ring, this kind of status should be attributed to a card (structure)
rather than a host.

I'm asking Ben to modify the way how the current mode be managed
in both 'core' side and 'host' side.
That is why I marked "TODO" in many places to check the mode.

So I'd defer the change until his rework be done.


> > +   return;
> > +
> > +   sdhci_writew(host, mask, SDHCI_UHS2_SW_RESET);
> > +
> > +   if (mask & SDHCI_UHS2_SW_RESET_FULL) {
> > +   host->clock = 0;
> > +   /* Reset-all turns off SD Bus Power */
> > +   if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
> 
> I would prefer not to support any legacy quirks that we do not need right
> now.  Just be sure to add a comment somewhere listing which quirks are not
> supported for UHS2 host controllers.

No strong opinion. I'd defer to you.

> > +   sdhci_runtime_pm_bus_off(host);
> > +   }
> > +
> > +   /* Wait max 100 ms */
> > +   timeout = 1;
> > +
> > +   /* hw clears the bit when it's done */
> > +   while (sdhci_readw(host, SDHCI_UHS2_SW_RESET) & mask) {
> 
> This kind of loop can now be done with read_poll_timeout_atomic(sdhci_readw,
> ..., host, SDHCI_UHS2_SW_RESET)

Okay.

-Takahiro Akashi

> > +   if (timeout == 0) {
> > +   pr_err("%s: %s: Reset 0x%x never completed.\n",
> > +  __func__, mmc_hostname(host->mmc), (int)mask);
> > +   pr_err("%s: clean reset bit\n",
> > +  mmc_hostname(host->mmc));
> > +   sdhci_writeb(host, 0, SDHCI_UHS2_SW_RESET);
> > +   return;
> > +   }
> > +   timeout--;
> > +   udelay(10);
> > +   }
> > +}
> > +EXPORT_SYMBOL_GPL(sdhci_uhs2_reset);
> > +
> >  
> > /*\
> >   * 
> >   *
> >   * Driver init/exit
> >   *
> > diff --git a/drivers/mmc/host/sdhci-uhs2.h b/drivers/mmc/host/sdhci-uhs2.h
> > index b9529d32b58d..7bb7a0d67109 100644
> > --- a/drivers/mmc/host/sdhci-uhs2.h
> > +++ b/drivers/mmc/host/sdhci-uhs2.h
> > @@ -210,5 +210,6 @@
> >  struct sdhci_host;
> >  
> >  void sdhci_uhs2_dump_regs(struct sdhci_host *host);
> > +void sdhci_uhs2_reset(struct sdhci_host *host, u16 mask);
> >  
> >  #endif /* __SDHCI_UHS2_H */
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index d4a57e8c9bb8..af336bdb4305 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -195,13 +195,14 @@ static void sdhci_runtime_pm_bus_on(struct sdhci_host 
> > *host)
> > pm_runtime_get_noresume(host->mmc->parent);
> >  }
> >  
> > -static void sdhci_runtime_pm_bus_off(struct sdhci_host 

[PATCH v10 6/7] i3c: master: sysfs key for acquire bus

2020-11-29 Thread Parshuram Thombare
Added support to acquire I3C bus through sysfs interface.

Signed-off-by: Parshuram Thombare 
---
 drivers/i3c/master.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index c01ba00..beb7495 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -581,6 +581,23 @@ static ssize_t i2c_scl_frequency_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(i2c_scl_frequency);
 
+static ssize_t i3c_acquire_bus_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct i3c_master_controller *master = dev_to_i3cmaster(dev);
+   int ret;
+
+   i3c_bus_normaluse_lock(>bus);
+   ret = i3c_master_acquire_bus(master);
+   i3c_bus_normaluse_unlock(>bus);
+   if (!ret)
+   i3c_master_enable_mr_events(master);
+
+   return ret ?: count;
+}
+static DEVICE_ATTR_WO(i3c_acquire_bus);
+
 static struct attribute *i3c_masterdev_attrs[] = {
_attr_mode.attr,
_attr_current_master.attr,
@@ -591,6 +608,7 @@ static ssize_t i2c_scl_frequency_show(struct device *dev,
_attr_pid.attr,
_attr_dynamic_address.attr,
_attr_hdrcap.attr,
+   _attr_i3c_acquire_bus.attr,
NULL,
 };
 ATTRIBUTE_GROUPS(i3c_masterdev);
-- 
1.7.1



[PATCH v10 5/7] i3c: master: add defslvs processing

2020-11-29 Thread Parshuram Thombare
Added defslvs processing code to the I3C master subsystem.

Signed-off-by: Parshuram Thombare 
---
 drivers/i3c/master.c   |   68 ++-
 include/linux/i3c/master.h |7 
 2 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 51ef706..c01ba00 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -2172,7 +2172,7 @@ int i3c_master_add_i3c_dev_locked(struct 
i3c_master_controller *master,
else
expected_dyn_addr = newdev->info.dyn_addr;
 
-   if (newdev->info.dyn_addr != expected_dyn_addr) {
+   if (!master->secondary && newdev->info.dyn_addr != expected_dyn_addr) {
/*
 * Try to apply the expected dynamic address. If it fails, keep
 * the address assigned by the master.
@@ -2867,12 +2867,20 @@ int i3c_secondary_master_register(struct 
i3c_master_controller *master,
  struct device *parent,
  const struct i3c_master_controller_ops *ops)
 {
-   int ret;
+   int ret, sz;
 
ret = i3c_master_init(master, parent, ops, true);
if (ret)
return ret;
 
+   sz = sizeof(struct i3c_ccc_dev_desc) * I3C_BUS_MAX_DEVS;
+   master->defslvs_data.devs = devm_kzalloc(>dev, sz,
+GFP_KERNEL);
+   if (!master->defslvs_data.devs) {
+   ret = -ENOMEM;
+   goto err_cleanup_bus;
+   }
+
ret = device_add(>dev);
if (ret)
goto err_cleanup_bus;
@@ -2905,6 +2913,62 @@ int i3c_secondary_master_register(struct 
i3c_master_controller *master,
 }
 EXPORT_SYMBOL_GPL(i3c_secondary_master_register);
 
+static int
+i3c_master_populate_bus(struct i3c_master_controller *master, u8 dyn_addr)
+{
+   struct i3c_dev_desc *olddev;
+   struct i3c_ccc_dev_desc *desc;
+   int ret, slot;
+
+   i3c_bus_for_each_i3cdev(>bus, olddev)
+   i3c_master_put_i3c_addrs(olddev);
+
+   master->this->info.dyn_addr = dyn_addr;
+   i3c_master_get_i3c_addrs(master->this);
+
+   desc = master->defslvs_data.devs;
+   for (slot = 1; slot < master->defslvs_data.ndevs; slot++) {
+   ret = i3c_master_add_i3c_dev_locked(master,
+   desc[slot].dyn_addr);
+   if (ret)
+   break;
+   }
+
+   return ret;
+}
+
+/**
+ * i3c_master_process_defslvs() - process I3C device list received in
+ * DEFSLVS for device plug/unplug and address change.
+ * @m: I3C master object
+ * @dyn_addr: Current dynamic address of this device
+ *
+ * This function may sleep, so should not be called in the atomic context.
+ */
+int i3c_master_process_defslvs(struct i3c_master_controller *m, u8 dyn_addr)
+{
+   int ret;
+
+   i3c_bus_normaluse_lock(>bus);
+   ret = i3c_master_acquire_bus(m);
+   i3c_bus_normaluse_unlock(>bus);
+   if (ret)
+   return ret;
+
+   i3c_bus_maintenance_lock(>bus);
+   ret = i3c_master_populate_bus(m, dyn_addr);
+   i3c_bus_maintenance_unlock(>bus);
+   if (!ret) {
+   i3c_bus_normaluse_lock(>bus);
+   i3c_master_register_new_i3c_devs(m);
+   i3c_bus_normaluse_unlock(>bus);
+   }
+   i3c_master_enable_mr_events(m);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_process_defslvs);
+
 /**
  * i3c_master_unregister() - unregister an I3C master
  * @master: master used to send frames on the bus
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
index 77c0422..835f823 100644
--- a/include/linux/i3c/master.h
+++ b/include/linux/i3c/master.h
@@ -478,6 +478,8 @@ struct i3c_master_controller_ops {
  * in a thread context. Typical examples are Hot Join processing which
  * requires taking the bus lock in maintenance, which in turn, can only
  * be done from a sleep-able context
+ * @defslvs_data: list used to pass i3c device list received in DEFSLVS 
message,
+ * from DEFSLVS controller driver to I3C core
  *
  * A  i3c_master_controller has to be registered to the I3C subsystem
  * through i3c_master_register(). None of  i3c_master_controller fields
@@ -497,6 +499,10 @@ struct i3c_master_controller {
} boardinfo;
struct i3c_bus bus;
struct workqueue_struct *wq;
+   struct {
+   u32 ndevs;
+   struct i3c_ccc_dev_desc *devs;
+   } defslvs_data;
 };
 
 /**
@@ -523,6 +529,7 @@ struct i3c_master_controller {
 
 void i3c_master_yield_bus(struct i3c_master_controller *m,
  u8 sec_mst_dyn_addr);
+int i3c_master_process_defslvs(struct i3c_master_controller *m, u8 dyn_addr);
 int i3c_master_do_i2c_xfers(struct i3c_master_controller *master,
const struct i2c_msg *xfers,
int nxfers);
-- 

Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"

2020-11-29 Thread Shawn Guo
On Tue, Nov 24, 2020 at 12:57:43PM -0600, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA processing on the Lenovo Yoga C630")'.
> 
> Signed-off-by: Bjorn Andersson 

Acked-by: Shawn Guo 


[PATCH v10 4/7] i3c: master: add mastership handover support

2020-11-29 Thread Parshuram Thombare
Added mastership acquire and yield functions.

Signed-off-by: Parshuram Thombare 
---
 drivers/i3c/master.c   |  183 +---
 include/linux/i3c/master.h |6 ++
 2 files changed, 177 insertions(+), 12 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index af0630a..51ef706 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -44,6 +44,16 @@ static void i3c_bus_maintenance_lock(struct i3c_bus *bus)
 }
 
 /**
+ * i3c_bus_maintenance_downgrade_lock - Downgrade maintenance lock to
+ * normaluse lock.
+ * @bus: I3C bus to take the lock on
+ */
+static void i3c_bus_maintenance_downgrade_lock(struct i3c_bus *bus)
+{
+   downgrade_write(>lock);
+}
+
+/**
  * i3c_bus_maintenance_unlock - Release the bus lock after a maintenance
  *   operation
  * @bus: I3C bus to release the lock on
@@ -451,6 +461,59 @@ static int i3c_bus_init(struct i3c_bus *i3cbus)
[I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
 };
 
+static int i3c_master_enable_mr_events(struct i3c_master_controller *master)
+{
+   int ret;
+
+   master->ops->enable_mr_events(master);
+   i3c_bus_maintenance_lock(>bus);
+   ret = i3c_master_enec_locked(master, I3C_BROADCAST_ADDR,
+I3C_CCC_EVENT_MR | I3C_CCC_EVENT_HJ);
+   i3c_bus_maintenance_unlock(>bus);
+
+   return ret;
+}
+
+/**
+ * i3c_master_acquire_bus() - acquire I3C bus mastership
+ * @m: I3C master object
+ *
+ * This function may sleep.
+ * It is expected to be called with normaluse_lock.
+ */
+static int i3c_master_acquire_bus(struct i3c_master_controller *m)
+{
+   int ret = 0;
+
+   /*
+* Request mastership needs maintenance(write) lock. So, to avoid
+* deadlock, release normaluse(read) lock, which is expected to be
+* held before calling this function.
+* normaluse(read) lock is expected to be held before calling
+* this function to avoid race with maintenance activities
+* like DEFSLVS processing etc
+*/
+   i3c_bus_normaluse_unlock(>bus);
+   i3c_bus_maintenance_lock(>bus);
+
+   if (m->this && m->this == m->bus.cur_master) {
+   i3c_master_disec_locked(m, I3C_BROADCAST_ADDR,
+   I3C_CCC_EVENT_MR |
+   I3C_CCC_EVENT_HJ);
+   goto mr_req_done;
+   }
+
+   ret = m->ops->request_mastership(m);
+   if (ret)
+   goto mr_req_done;
+
+   m->bus.cur_master = m->this;
+
+mr_req_done:
+   i3c_bus_maintenance_downgrade_lock(>bus);
+   return ret;
+}
+
 static ssize_t mode_show(struct device *dev,
 struct device_attribute *da,
 char *buf)
@@ -476,11 +539,12 @@ static ssize_t current_master_show(struct device *dev,
   char *buf)
 {
struct i3c_bus *i3cbus = dev_to_i3cbus(dev);
-   ssize_t ret;
+   ssize_t ret = 0;
 
i3c_bus_normaluse_lock(i3cbus);
-   ret = sprintf(buf, "%d-%llx\n", i3cbus->id,
- i3cbus->cur_master->info.pid);
+   if (i3cbus->cur_master)
+   ret = sprintf(buf, "%d-%llx\n", i3cbus->id,
+ i3cbus->cur_master->info.pid);
i3c_bus_normaluse_unlock(i3cbus);
 
return ret;
@@ -690,6 +754,33 @@ static int i3c_master_send_ccc_cmd_locked(struct 
i3c_master_controller *master,
return 0;
 }
 
+static int i3c_master_get_accmst_locked(struct i3c_master_controller *master,
+   u8 addr)
+{
+   struct i3c_ccc_getaccmst *accmst;
+   struct i3c_ccc_cmd_dest dest;
+   struct i3c_ccc_cmd cmd;
+   int ret;
+
+   accmst = i3c_ccc_cmd_dest_init(, addr, sizeof(*accmst));
+   if (!accmst)
+   return -ENOMEM;
+
+   i3c_ccc_cmd_init(, true, I3C_CCC_GETACCMST, , 1);
+
+   ret = i3c_master_send_ccc_cmd_locked(master, );
+   if (ret)
+   goto out;
+
+   if (dest.payload.len != sizeof(*accmst))
+   ret = -EIO;
+
+out:
+   i3c_ccc_cmd_dest_cleanup();
+
+   return ret;
+}
+
 static struct i2c_dev_desc *
 i3c_master_find_i2c_dev_by_addr(const struct i3c_master_controller *master,
u16 addr)
@@ -1582,10 +1673,6 @@ int i3c_master_set_info(struct i3c_master_controller 
*master,
if (!i3c_bus_dev_addr_is_avail(>bus, info->dyn_addr))
return -EINVAL;
 
-   if (I3C_BCR_DEVICE_ROLE(info->bcr) == I3C_BCR_I3C_MASTER &&
-   master->secondary)
-   return -EINVAL;
-
if (master->this)
return -EINVAL;
 
@@ -1594,7 +1681,9 @@ int i3c_master_set_info(struct i3c_master_controller 
*master,
return PTR_ERR(i3cdev);
 
master->this = i3cdev;
-   master->bus.cur_master = master->this;
+
+   if (!master->secondary)
+   

[PATCH v10 3/7] i3c: master: add i3c_secondary_master_register

2020-11-29 Thread Parshuram Thombare
add i3c_secondary_master_register which is used
to register secondary masters.

Signed-off-by: Parshuram Thombare 
---
 drivers/i3c/master.c   |  154 +++-
 include/linux/i3c/master.h |3 +
 2 files changed, 156 insertions(+), 1 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 56e8fe4..af0630a 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1797,6 +1797,90 @@ static int i3c_primary_master_bus_init(struct 
i3c_master_controller *master)
return ret;
 }
 
+/**
+ * i3c_secondary_master_bus_init() - initialize an I3C bus for secondary
+ * master
+ * @master: secondary master initializing the bus
+ *
+ * This function does
+ *
+ * 1. Attach I2C devs to the master
+ *
+ * 2. Call _master_controller_ops->bus_init() method to initialize
+ *the master controller. That's usually where the bus mode is selected
+ *(pure bus or mixed fast/slow bus)
+ *
+ * Once this is done, I2C devices should be usable.
+ *
+ * Return: a 0 in case of success, an negative error code otherwise.
+ */
+static int i3c_secondary_master_bus_init(struct i3c_master_controller *master)
+{
+   enum i3c_addr_slot_status status;
+   struct i2c_dev_boardinfo *i2cboardinfo;
+   struct i2c_dev_desc *i2cdev;
+   int ret;
+
+   /*
+* First attach all devices with static definitions provided by the
+* FW.
+*/
+   list_for_each_entry(i2cboardinfo, >boardinfo.i2c, node) {
+   status = i3c_bus_get_addr_slot_status(>bus,
+ i2cboardinfo->base.addr);
+   if (status != I3C_ADDR_SLOT_FREE) {
+   ret = -EBUSY;
+   goto err_detach_devs;
+   }
+
+   i3c_bus_set_addr_slot_status(>bus,
+i2cboardinfo->base.addr,
+I3C_ADDR_SLOT_I2C_DEV);
+
+   i2cdev = i3c_master_alloc_i2c_dev(master, i2cboardinfo);
+   if (IS_ERR(i2cdev)) {
+   ret = PTR_ERR(i2cdev);
+   goto err_detach_devs;
+   }
+
+   ret = i3c_master_attach_i2c_dev(master, i2cdev);
+   if (ret) {
+   i3c_master_free_i2c_dev(i2cdev);
+   goto err_detach_devs;
+   }
+   }
+
+   /*
+* Now execute the controller specific ->bus_init() routine, which
+* might configure its internal logic to match the bus limitations.
+*/
+   ret = master->ops->bus_init(master);
+   if (ret)
+   goto err_detach_devs;
+
+   /*
+* The master device should have been instantiated in ->bus_init(),
+* complain if this was not the case.
+*/
+   if (!master->this) {
+   dev_err(>dev,
+   "master_set_info() was not called in ->bus_init()\n");
+   ret = -EINVAL;
+   goto err_bus_cleanup;
+   }
+
+   return 0;
+
+err_bus_cleanup:
+   if (master->ops->bus_cleanup)
+   master->ops->bus_cleanup(master);
+
+err_detach_devs:
+   i3c_master_detach_free_devs(master);
+
+   return ret;
+}
+
 static void i3c_master_bus_cleanup(struct i3c_master_controller *master)
 {
if (master->ops->bus_cleanup)
@@ -2514,7 +2598,10 @@ static int i3c_master_init(struct i3c_master_controller 
*master,
goto err_put_dev;
}
 
-   ret = i3c_primary_master_bus_init(master);
+   if (secondary)
+   ret = i3c_secondary_master_bus_init(master);
+   else
+   ret = i3c_primary_master_bus_init(master);
if (ret)
goto err_destroy_wq;
 
@@ -2595,6 +2682,71 @@ int i3c_primary_master_register(struct 
i3c_master_controller *master,
 EXPORT_SYMBOL_GPL(i3c_primary_master_register);
 
 /**
+ * i3c_secondary_master_register() - register an I3C secondary master
+ * @master: master used to send frames on the bus
+ * @parent: the parent device (the one that provides this I3C master
+ * controller)
+ * @ops: the master controller operations
+ *
+ * This function does minimal required initialization for secondary
+ * master, rest functionality like creating and registering I2C
+ * and I3C devices is done in defslvs processing.
+ *
+ *  i3c_secondary_master_register() does following things -
+ * - creates and initializes the I3C bus
+ * - populates the bus with static I2C devs if @parent->of_node is not
+ *   NULL
+ *   initialization
+ * - allocate memory for defslvs_data.devs, which is used to receive
+ *   defslvs list
+ * - create I3C device representing this master
+ * - registers the I2C adapter and all I2C devices
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_secondary_master_register(struct i3c_master_controller *master,
+ struct 

[PATCH v10 2/7] i3c: master: use i3c_master_register only for main master

2020-11-29 Thread Parshuram Thombare
Removed last argument 'secondary' and restructured i3c_master_register
to move code that can be common to i3c_secondary_master_register
to separate function i3c_master_init.

Signed-off-by: Parshuram Thombare 
---
 drivers/i3c/master.c   |   78 +++-
 drivers/i3c/master/dw-i3c-master.c |4 +-
 drivers/i3c/master/i3c-master-cdns.c   |4 +-
 drivers/i3c/master/mipi-i3c-hci/core.c |4 +-
 include/linux/i3c/master.h |7 +--
 5 files changed, 56 insertions(+), 41 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index b61bf53..56e8fe4 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1637,7 +1637,7 @@ static void i3c_master_detach_free_devs(struct 
i3c_master_controller *master)
 }
 
 /**
- * i3c_master_bus_init() - initialize an I3C bus
+ * i3c_primary_master_bus_init() - initialize an I3C bus
  * @master: main master initializing the bus
  *
  * This function is following all initialisation steps described in the I3C
@@ -1668,7 +1668,7 @@ static void i3c_master_detach_free_devs(struct 
i3c_master_controller *master)
  *
  * Return: a 0 in case of success, an negative error code otherwise.
  */
-static int i3c_master_bus_init(struct i3c_master_controller *master)
+static int i3c_primary_master_bus_init(struct i3c_master_controller *master)
 {
enum i3c_addr_slot_status status;
struct i2c_dev_boardinfo *i2cboardinfo;
@@ -2441,31 +2441,10 @@ static int i3c_master_check_ops(const struct 
i3c_master_controller_ops *ops)
return 0;
 }
 
-/**
- * i3c_master_register() - register an I3C master
- * @master: master used to send frames on the bus
- * @parent: the parent device (the one that provides this I3C master
- * controller)
- * @ops: the master controller operations
- * @secondary: true if you are registering a secondary master. Will return
- *-ENOTSUPP if set to true since secondary masters are not yet
- *supported
- *
- * This function takes care of everything for you:
- *
- * - creates and initializes the I3C bus
- * - populates the bus with static I2C devs if @parent->of_node is not
- *   NULL
- * - registers all I3C devices added by the controller during bus
- *   initialization
- * - registers the I2C adapter and all I2C devices
- *
- * Return: 0 in case of success, a negative error code otherwise.
- */
-int i3c_master_register(struct i3c_master_controller *master,
-   struct device *parent,
-   const struct i3c_master_controller_ops *ops,
-   bool secondary)
+static int i3c_master_init(struct i3c_master_controller *master,
+  struct device *parent,
+  const struct i3c_master_controller_ops *ops,
+  bool secondary)
 {
unsigned long i2c_scl_rate = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
struct i3c_bus *i3cbus = i3c_master_get_bus(master);
@@ -2535,10 +2514,49 @@ int i3c_master_register(struct i3c_master_controller 
*master,
goto err_put_dev;
}
 
-   ret = i3c_master_bus_init(master);
+   ret = i3c_primary_master_bus_init(master);
if (ret)
goto err_destroy_wq;
 
+   return 0;
+
+err_destroy_wq:
+   destroy_workqueue(master->wq);
+
+err_put_dev:
+   put_device(>dev);
+
+   return ret;
+}
+
+/**
+ * i3c_primary_master_register() - register an I3C master
+ * @master: master used to send frames on the bus
+ * @parent: the parent device (the one that provides this I3C master
+ * controller)
+ * @ops: the master controller operations
+ *
+ * This function takes care of everything for you:
+ *
+ * - creates and initializes the I3C bus
+ * - populates the bus with static I2C devs if @parent->of_node is not
+ *   NULL
+ * - registers all I3C devices added by the controller during bus
+ *   initialization
+ * - registers the I2C adapter and all I2C devices
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_primary_master_register(struct i3c_master_controller *master,
+   struct device *parent,
+   const struct i3c_master_controller_ops *ops)
+{
+   int ret;
+
+   ret = i3c_master_init(master, parent, ops, false);
+   if (ret)
+   return ret;
+
ret = device_add(>dev);
if (ret)
goto err_cleanup_bus;
@@ -2568,15 +2586,13 @@ int i3c_master_register(struct i3c_master_controller 
*master,
 err_cleanup_bus:
i3c_master_bus_cleanup(master);
 
-err_destroy_wq:
destroy_workqueue(master->wq);
 
-err_put_dev:
put_device(>dev);
 
return ret;
 }
-EXPORT_SYMBOL_GPL(i3c_master_register);
+EXPORT_SYMBOL_GPL(i3c_primary_master_register);
 
 /**
  * i3c_master_unregister() - unregister an I3C master
diff --git a/drivers/i3c/master/dw-i3c-master.c 
b/drivers/i3c/master/dw-i3c-master.c
index 

[PATCH v10 1/7] i3c: master: master initialization flow document

2020-11-29 Thread Parshuram Thombare
Document describing master initialization, mastership handover
and DEFSLVS handling processes.

Signed-off-by: Parshuram Thombare 
---
 Documentation/driver-api/i3c/index.rst |1 +
 .../driver-api/i3c/master-initialization-flow.rst  |  187 
 2 files changed, 188 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/driver-api/i3c/master-initialization-flow.rst

diff --git a/Documentation/driver-api/i3c/index.rst 
b/Documentation/driver-api/i3c/index.rst
index 783d6da..604f1c5 100644
--- a/Documentation/driver-api/i3c/index.rst
+++ b/Documentation/driver-api/i3c/index.rst
@@ -9,3 +9,4 @@ I3C subsystem
protocol
device-driver-api
master-driver-api
+   master-initialization-flow
diff --git a/Documentation/driver-api/i3c/master-initialization-flow.rst 
b/Documentation/driver-api/i3c/master-initialization-flow.rst
new file mode 100644
index 000..e02b90d
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-initialization-flow.rst
@@ -0,0 +1,187 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+I3C Master Initialization Flow
+==
+
+.. kernel-render:: DOT
+   :alt: I3C Master Initialization digraph
+   :caption: I3C Master Initialization Flow
+
+   digraph master_init {
+   ranksep=.25; size="35,35";
+   subgraph cluster_0 {
+   style=dashed
+   x0[shape=ellipse, label="I3C driver probe", style="filled"]
+   x1[shape=diamond, label="Secondary Master ?"]
+   a1[shape=box, label="Do I3C master controller specific 
initialization"]
+   b1[shape=box, label="Do I3C master controller specific 
initialization,\n
+   except enabling the DEFSLVS interrupt."]
+   a2[shape=box, label="Call i3c_primary_master_register"]
+   b2[shape=box, label="Call i3c_secondary_master_register"]
+   x0->x1;
+   x1->a1[label="No"];
+   x1->b1[label="Yes"];
+   a1->a2; b1->b2;
+   }
+
+   subgraph cluster_1 {
+   style=dashed
+   label="Current Master";
+   a3[shape=ellipse, label="i3c_primary_master_register", 
style="filled"]
+   a4[shape=box, label="Initialize I3C master controller object."]
+   a5[shape=box, label="Create I2C objects for devices in DTS and add 
to I2C list."]
+   a6[shape=box, label="Set appropriate bus mode based on I2C devices 
information."]
+   a7[shape=box, label="Create a work queue."]
+   a8[shape=box, label="Call i3c_primary_master_bus_init"]
+   a19[shape=box, label="Add I3C object representing this master to 
the system."]
+   a20[shape=box, label="Expose our I3C bus as an I2C adapter so that 
I2C devices\n
+   are exposed through the I2C subsystem."]
+   a21[shape=box, label="Register all I3C devices."]
+   a22[shape=box, label="Broadcast ENEC MR, HJ message."]
+   a3->a4->a5->a6->a7->a8; a19->a20->a21->a22;
+   a8->a19[style="invisible"];
+   }
+
+   subgraph cluster_2 {
+   style=dashed
+   label="Current Master";
+   a9[shape=ellipse, label="i3c_primary_master_bus_init", 
style="filled"]
+   a10[shape=box, label="Call bus_init to do controller specific bus 
initialization\n
+   and enabling the controller."]
+   a11[shape=box, label="Create I3C object representing the master and 
add it to\n
+   the I3C device list."]
+   a12[shape=box, label="Set current master to the object created to 
represent I3C\n
+   master device."]
+   a13[shape=box, label="Reset all dynamic address that may have been 
assigned before."]
+   a14[shape=box, label="Disable all slave events before starting 
DAA."]
+   a15[shape=box, label="Pre-assign dynamic address and retrieve 
device information."]
+   a16[shape=box, label="Do dynamic address assignment to all I3C 
devices currenly\n
+   present on the bus."]
+   a17[shape=box, label="Create I3C objects representing devices found 
during DAA."]
+   a18[shape=box, label="Send DEFSVLS message containing information 
about all\n
+   known I3C and I2C devices."]
+   a9->a10->a11->a12->a13->a14->a15->a16->a17->a18;
+   }
+
+   subgraph cluster_3 {
+   style=dashed
+   label="Current Master";
+   h1[shape=ellipse, label="MR request interrupt", style="filled"]
+   h2[shape=box, label="Bottom half i3c_master_yield_bus"]
+   h1->h2;
+   }
+
+   subgraph cluster_4 {
+   style=dashed
+   label="Current Master";
+   i1[shape=ellipse, label="i3c_master_yield_bus", style="filled"]
+   i2[shape=box, label="Check if this device is still a master to 
handle a case of\n
+   multiple MR requests from different devices at a same time."]
+   i3[shape=box, label="Broadcast DISEC MR, HJ message.\n
+   

Re: [PATCH 2/3] usb: dwc2: enable FS/LS PHY clock select on STM32MP15 FS OTG

2020-11-29 Thread Minas Harutyunyan
On 11/23/2020 1:01 PM, Amelie Delaunay wrote:
> When the core is in FS host mode, using the FS transceiver, and a Low-Speed
> device is connected, transceiver clock is 6Mhz.
> So, to support Low-Speed devices, enable support of FS/LS Low Power mode,
> so that the PHY supplies a 6 MHz clock during Low-Speed mode.
> 
> Signed-off-by: Amelie Delaunay 

Acked-by: Minas Harutyunyan 

> ---
>   drivers/usb/dwc2/params.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 0df693319f0a..9e5dd7f3f2f6 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -179,6 +179,8 @@ static void dwc2_set_stm32mp15_fsotg_params(struct 
> dwc2_hsotg *hsotg)
>   p->activate_stm_id_vb_detection = true;
>   p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>   p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
> + p->host_support_fs_ls_low_power = true;
> + p->host_ls_low_power_phy_clk = true;
>   }
>   
>   static void dwc2_set_stm32mp15_hsotg_params(struct dwc2_hsotg *hsotg)
> 



Re: [PATCH 3/3] usb: dwc2: disable Link Power Management on STM32MP15 HS OTG

2020-11-29 Thread Minas Harutyunyan
On 11/23/2020 1:01 PM, Amelie Delaunay wrote:
> Link Power Management (LPM) on STM32MP15 OTG HS encounters instabilities
> with some Host controllers. OTG core fails to exit L1 state in 200us:
> "dwc2 4900.usb-otg: Failed to exit L1 sleep state in 200us."
> Then the device is still not enumerated.
> 
> To avoid this issue, disable Link Power Management on STM32MP15 HS OTG.
> 
> Signed-off-by: Amelie Delaunay 

Acked-by: Minas Harutyunyan 

> ---
>   drivers/usb/dwc2/params.c | 4 
>   1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 9e5dd7f3f2f6..92df3d620f7d 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -194,6 +194,10 @@ static void dwc2_set_stm32mp15_hsotg_params(struct 
> dwc2_hsotg *hsotg)
>   p->host_perio_tx_fifo_size = 256;
>   p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>   p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
> + p->lpm = false;
> + p->lpm_clock_gating = false;
> + p->besl = false;
> + p->hird_threshold_en = false;
>   }
>   
>   const struct of_device_id dwc2_of_match_table[] = {
> 



[PATCH v10 0/7] I3C mastership handover support

2020-11-29 Thread Parshuram Thombare
Main changes between v9 and v10 are:
- Fix build failure reported by kernel test robot

Main changes between v8 and v9 are:
- Fix NULL dereference issue in current_master_show when
  cat'ing sysfs key current_master for secondary master
  before primary master gets initialized.

Main changes between v7 and v8 are:
- Document format changed from table to DOT diagram
- Appropriate names for few functions
- Moved mastership request process entirely to the driver
- Reuse of i3c_master_add_i3c_dev_locked in core defslvs
  processing

Main changes between v6 and v7 are:
- Added separate functions for main and secondary
  master initialization
- Secondary master initialization don't wait for
  DEFSLSVS.
- Change to use I2C device information from DTS,
  and corresponding changes in controller driver
  and I3C core DEFSLVS processing to ignore I2C
  devices received in DEFSLVS
- Reverted bus_init split
- Fixed formatting issues in document

Main changes between v5 and v6 are:
- Moved populate_bus() hook to master subsystem code.
- For secondary master initialization i3c_master_register
  spawan separate threads, as secondary master may have to
  wait for DEFSLVS and bus mastership.
- Populate bus info is based on DEFSLVS data and take care
  of hot plugged / unplugged I3C devices.
- Split bus_init into bus_init and master_set_info callbacks
- Moved mastership aquire and handover to separate state 
  machines.
- Added DEFSLVS processing code.
- Moved back all locks in side the subsystem code.
- Secondary mastership support to Cadence I3C master
  controller driver
- Sysfs key 'i3c_acquire_bus' to acauire bus.
- NULL check for pool pointer in i3c_generic_ibi_free_pool.

Main changes between v4 and v5 are:
- Add populate_bus() hook
- Split i3c_master_register into init and register pair
- Split device information retrieval, let add partialy discovered devices
- Make i3c_master_set_info private
- Add separate function to register secondary master
- Reworked secondary master register in CDNS driver
- Export i3c_bus_set_mode

Main changes between v3 and v4 are:
- Reworked acquire bus ownership
- Refactored the code

Main changes between v2 and v3 are:
- Added DEFSLVS devices are registered from master driver
- Reworked I2C registering on secondary master side
- Reworked Mastership event is enabled/disabled globally (for all devices)

Main changes between initial version and v2 are:
- Reworked devices registration on secondary master side
- Reworked mastership event disabling/enabling
- Reworked bus locking during mastership takeover process
- Added DEFSLVS devices registration during initialization
- Fixed style issues

Parshuram Thombare (7):
  i3c: master: master initialization flow document
  i3c: master: use i3c_master_register only for main master
  i3c: master: add i3c_secondary_master_register
  i3c: master: add mastership handover support
  i3c: master: add defslvs processing
  i3c: master: sysfs key for acquire bus
  i3c: master: mastership handover, defslvs processing in cdns
controller driver

 Documentation/driver-api/i3c/index.rst |1 +
 .../driver-api/i3c/master-initialization-flow.rst  |  187 
 drivers/i3c/master.c   |  497 ++--
 drivers/i3c/master/dw-i3c-master.c |4 +-
 drivers/i3c/master/i3c-master-cdns.c   |  329 -
 drivers/i3c/master/mipi-i3c-hci/core.c |4 +-
 include/linux/i3c/master.h |   23 +-
 7 files changed, 970 insertions(+), 75 deletions(-)
 create mode 100644 Documentation/driver-api/i3c/master-initialization-flow.rst



Re: [PATCH 1/3] usb: dwc2: set ahbcfg parameter for STM32MP15 OTG HS and FS

2020-11-29 Thread Minas Harutyunyan
On 11/23/2020 1:01 PM, Amelie Delaunay wrote:
> STM32MP15 ahbcfg register default value sets Burst length/type (HBSTLEN)
> to Single (32-bit accesses on AHB), which is not recommended, according
> to STM32MP157 Reference manual [1].
> This patch sets Burst length/type (HBSTLEN) so that bus transactions
> target 16x32 bit accesses. This improves OTG controller performance.
> 
> [1] 
> https://urldefense.com/v3/__https://www.st.com/resource/en/reference_manual/dm00327659.pdf__;!!A4F2R9G_pg!J1HTs3kobvYfS453htoIdnxhej4_os5Y5xwMfRtfhptE_QSeVw3O1mozY-v4AvE$
>  , p.3149
> 
> Signed-off-by: Amelie Delaunay 

Acked-by: Minas Harutyunyan 

> ---
>   drivers/usb/dwc2/params.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 267543c3dc38..0df693319f0a 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -177,6 +177,7 @@ static void dwc2_set_stm32mp15_fsotg_params(struct 
> dwc2_hsotg *hsotg)
>   p->i2c_enable = false;
>   p->activate_stm_fs_transceiver = true;
>   p->activate_stm_id_vb_detection = true;
> + p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>   p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
>   }
>   
> @@ -189,6 +190,7 @@ static void dwc2_set_stm32mp15_hsotg_params(struct 
> dwc2_hsotg *hsotg)
>   p->host_rx_fifo_size = 440;
>   p->host_nperio_tx_fifo_size = 256;
>   p->host_perio_tx_fifo_size = 256;
> + p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>   p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
>   }
>   
> 



Re: [PATCH v2 5/5] USB: gadget: f_fs: remove likely/unlikely

2020-11-29 Thread Peter Chen
On 20-11-27 15:05:59, Greg Kroah-Hartman wrote:
> They are used way too often in this file, in some ways that are actually
> wrong.  Almost all of these are already known by the compiler and CPU so
> just remove them all as none of these should be on any "hot paths" where
> it actually matters.
> 
> Cc: Felipe Balbi 
> Reported-by: Peter Chen 
> Signed-off-by: Greg Kroah-Hartman 

Reviewed-by: Peter Chen 

> ---
>  drivers/usb/gadget/function/f_fs.c | 179 ++---
>  1 file changed, 89 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index a34a7c96a1ab..9047b20b6715 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -296,11 +296,11 @@ static int __ffs_ep0_queue_wait(struct ffs_data *ffs, 
> char *data, size_t len)
>   reinit_completion(>ep0req_completion);
>  
>   ret = usb_ep_queue(ffs->gadget->ep0, req, GFP_ATOMIC);
> - if (unlikely(ret < 0))
> + if (ret < 0)
>   return ret;
>  
>   ret = wait_for_completion_interruptible(>ep0req_completion);
> - if (unlikely(ret)) {
> + if (ret) {
>   usb_ep_dequeue(ffs->gadget->ep0, req);
>   return -EINTR;
>   }
> @@ -337,7 +337,7 @@ static ssize_t ffs_ep0_write(struct file *file, const 
> char __user *buf,
>  
>   /* Acquire mutex */
>   ret = ffs_mutex_lock(>mutex, file->f_flags & O_NONBLOCK);
> - if (unlikely(ret < 0))
> + if (ret < 0)
>   return ret;
>  
>   /* Check state */
> @@ -345,7 +345,7 @@ static ssize_t ffs_ep0_write(struct file *file, const 
> char __user *buf,
>   case FFS_READ_DESCRIPTORS:
>   case FFS_READ_STRINGS:
>   /* Copy data */
> - if (unlikely(len < 16)) {
> + if (len < 16) {
>   ret = -EINVAL;
>   break;
>   }
> @@ -360,7 +360,7 @@ static ssize_t ffs_ep0_write(struct file *file, const 
> char __user *buf,
>   if (ffs->state == FFS_READ_DESCRIPTORS) {
>   pr_info("read descriptors\n");
>   ret = __ffs_data_got_descs(ffs, data, len);
> - if (unlikely(ret < 0))
> + if (ret < 0)
>   break;
>  
>   ffs->state = FFS_READ_STRINGS;
> @@ -368,11 +368,11 @@ static ssize_t ffs_ep0_write(struct file *file, const 
> char __user *buf,
>   } else {
>   pr_info("read strings\n");
>   ret = __ffs_data_got_strings(ffs, data, len);
> - if (unlikely(ret < 0))
> + if (ret < 0)
>   break;
>  
>   ret = ffs_epfiles_create(ffs);
> - if (unlikely(ret)) {
> + if (ret) {
>   ffs->state = FFS_CLOSING;
>   break;
>   }
> @@ -381,7 +381,7 @@ static ssize_t ffs_ep0_write(struct file *file, const 
> char __user *buf,
>   mutex_unlock(>mutex);
>  
>   ret = ffs_ready(ffs);
> - if (unlikely(ret < 0)) {
> + if (ret < 0) {
>   ffs->state = FFS_CLOSING;
>   return ret;
>   }
> @@ -495,7 +495,7 @@ static ssize_t __ffs_ep0_read_events(struct ffs_data 
> *ffs, char __user *buf,
>   spin_unlock_irq(>ev.waitq.lock);
>   mutex_unlock(>mutex);
>  
> - return unlikely(copy_to_user(buf, events, size)) ? -EFAULT : size;
> + return copy_to_user(buf, events, size) ? -EFAULT : size;
>  }
>  
>  static ssize_t ffs_ep0_read(struct file *file, char __user *buf,
> @@ -514,7 +514,7 @@ static ssize_t ffs_ep0_read(struct file *file, char 
> __user *buf,
>  
>   /* Acquire mutex */
>   ret = ffs_mutex_lock(>mutex, file->f_flags & O_NONBLOCK);
> - if (unlikely(ret < 0))
> + if (ret < 0)
>   return ret;
>  
>   /* Check state */
> @@ -536,7 +536,7 @@ static ssize_t ffs_ep0_read(struct file *file, char 
> __user *buf,
>  
>   case FFS_NO_SETUP:
>   n = len / sizeof(struct usb_functionfs_event);
> - if (unlikely(!n)) {
> + if (!n) {
>   ret = -EINVAL;
>   break;
>   }
> @@ -567,9 +567,9 @@ static ssize_t ffs_ep0_read(struct file *file, char 
> __user *buf,
>  
>   spin_unlock_irq(>ev.waitq.lock);
>  
> - if (likely(len)) {
> + if (len) {
>   data = kmalloc(len, GFP_KERNEL);
> - if (unlikely(!data)) {
> + if (!data) {
>   ret = -ENOMEM;
>   goto done_mutex;
>   }
> @@ -586,7 +586,7 @@ static ssize_t ffs_ep0_read(struct 

Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack

2020-11-29 Thread kernel test robot
Hi Topi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on aae5ab854e38151e69f261dbf0e3b7e396403178]

url:
https://github.com/0day-ci/linux/commits/Topi-Miettinen/mm-Optional-full-ASLR-for-mmap-mremap-vdso-and-stack/20201130-051703
base:aae5ab854e38151e69f261dbf0e3b7e396403178
config: x86_64-randconfig-a002-20201130 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
f502b14d40e751fe00afc493ef0d08f196524886)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/c06384c5cecf700db214c69a4565c41a4c4fad82
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Topi-Miettinen/mm-Optional-full-ASLR-for-mmap-mremap-vdso-and-stack/20201130-051703
git checkout c06384c5cecf700db214c69a4565c41a4c4fad82
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

   arch/x86/entry/vdso/vma.c:38:19: warning: no previous prototype for function 
'arch_get_vdso_data' [-Wmissing-prototypes]
   struct vdso_data *arch_get_vdso_data(void *vvar_page)
 ^
   arch/x86/entry/vdso/vma.c:38:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
   struct vdso_data *arch_get_vdso_data(void *vvar_page)
   ^
   static 
>> arch/x86/entry/vdso/vma.c:382:9: warning: cast to 'void *' from smaller 
>> integer type 'int' [-Wint-to-void-pointer-cast]
   if (!IS_ERR_VALUE(ret))
^
   include/linux/err.h:22:49: note: expanded from macro 'IS_ERR_VALUE'
   #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
   
^
   include/linux/compiler.h:48:41: note: expanded from macro 'unlikely'
   #  define unlikely(x)   (__branch_check__(x, 0, __builtin_constant_p(x)))
~^~
   include/linux/compiler.h:33:34: note: expanded from macro '__branch_check__'
   __r = __builtin_expect(!!(x), expect);  \
 ^
>> arch/x86/entry/vdso/vma.c:382:9: warning: cast to 'void *' from smaller 
>> integer type 'int' [-Wint-to-void-pointer-cast]
   if (!IS_ERR_VALUE(ret))
^
   include/linux/err.h:22:49: note: expanded from macro 'IS_ERR_VALUE'
   #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
   
^
   include/linux/compiler.h:48:68: note: expanded from macro 'unlikely'
   #  define unlikely(x)   (__branch_check__(x, 0, __builtin_constant_p(x)))
^~~
   include/linux/compiler.h:35:19: note: expanded from macro '__branch_check__'
expect, is_constant);  \
^~~
   3 warnings generated.

vim +382 arch/x86/entry/vdso/vma.c

   364  
   365  static int map_vdso_randomized(const struct vdso_image *image)
   366  {
   367  unsigned long addr;
   368  
   369  if (randomize_va_space == 3) {
   370  /*
   371   * Randomize vdso address.
   372   */
   373  int i = MAX_RANDOM_VDSO_RETRIES;
   374  
   375  do {
   376  int ret;
   377  
   378  /* Try a few times to find a free area */
   379  addr = arch_mmap_rnd();
   380  
   381  ret = map_vdso(image, addr);
 > 382  if (!IS_ERR_VALUE(ret))
   383  return ret;
   384  } while (--i >= 0);
   385  
   386  /* Give up and try the less random way */
   387  }
   388  addr = vdso_addr(current->mm->start_stack, 
image->size-image->sym_vvar_start);
   389  
   390  return map_vdso(image, addr);
   391  }
   392  #endif
   393  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: [PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build

2020-11-29 Thread kernel test robot
Hi Sergey,

I love your patch! Perhaps something to improve:

[auto build test WARNING on hch-configfs/for-next]
[also build test WARNING on linux/master linus/master v5.10-rc6 next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sergey-Senozhatsky/posix_acl-h-define-missing-ACL-functions-on-non-posix-acl-build/20201130-095018
base:   git://git.infradead.org/users/hch/configfs.git for-next
config: s390-randconfig-r005-20201130 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
dfcf1acf13226be0f599a7ab6b395b66dc9545d6)
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 s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# 
https://github.com/0day-ci/linux/commit/377ebc564d08d21a4bc83fecc7f1238e342823d1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sergey-Senozhatsky/posix_acl-h-define-missing-ACL-functions-on-non-posix-acl-build/20201130-095018
git checkout 377ebc564d08d21a4bc83fecc7f1238e342823d1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

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

All warnings (new ones prefixed by >>):

   In file included from fs/overlayfs/super.c:16:
   In file included from include/linux/posix_acl_xattr.h:15:
   include/linux/posix_acl.h:121:19: error: static declaration of 
'set_posix_acl' follows non-static declaration
   static inline int set_posix_acl(struct inode *inode, int type,
 ^
   include/linux/posix_acl.h:72:12: note: previous declaration is here
   extern int set_posix_acl(struct inode *, int, struct posix_acl *);
  ^
>> include/linux/posix_acl.h:127:55: warning: omitting the parameter name in a 
>> function definition is a C2x extension [-Wc2x-extensions]
   static inline int posix_acl_update_mode(struct inode *, umode_t *,
 ^
   include/linux/posix_acl.h:127:66: warning: omitting the parameter name in a 
function definition is a C2x extension [-Wc2x-extensions]
   static inline int posix_acl_update_mode(struct inode *, umode_t *,
^
   include/linux/posix_acl.h:128:25: warning: omitting the parameter name in a 
function definition is a C2x extension [-Wc2x-extensions]
   struct posix_acl **)
  ^
   3 warnings and 1 error generated.

vim +127 include/linux/posix_acl.h

   126  
 > 127  static inline int posix_acl_update_mode(struct inode *, umode_t *,
   128  struct posix_acl **)
   129  {
   130  return 0;
   131  }
   132  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


[PATCH v2] arm64: dts: meson-sm1: fix typo in opp table

2020-11-29 Thread Dongjin Kim
The freqency 151200 should be 15.

Signed-off-by: Dongjin Kim 
---

Change in v2:
  - wrong fix in the previous patch.

https://patchwork.kernel.org/project/linux-amlogic/patch/20201130054221.GA25448@anyang-linuxfactory-or-kr/
 

---
 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
index 71317f5aada1..c309517abae3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -130,7 +130,7 @@
opp-microvolt = <79>;
};
 
-   opp-151200 {
+   opp-15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <80>;
};
-- 
2.17.1



[PATCH] riscv/mm: Prevent kernel module access user-space memory without uaccess routines

2020-11-29 Thread Eric Lin
In the page fault handler, an access to user-space memory
without get/put_user() or copy_from/to_user() routines is
not resolved properly. Like arm and other architectures,
we need to let it die earlier in page fault handler.

Signed-off-by: Eric Lin 
Cc: Alan Kao 
---
 arch/riscv/mm/fault.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 3c8b9e433c67..a452cfa266a2 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -232,6 +232,9 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
if (user_mode(regs))
flags |= FAULT_FLAG_USER;
 
+   if (!user_mode(regs) && addr < TASK_SIZE && unlikely(!(regs->status & 
SR_SUM)))
+   die(regs, "Accessing user space memory without uaccess 
routines\n");
+
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr);
 
if (cause == EXC_STORE_PAGE_FAULT)
-- 
2.17.0



Re: [PATCH 0/3] clear_warn_once: add timed interval resetting

2020-11-29 Thread Sergey Senozhatsky
On (20/11/27 17:13), Petr Mladek wrote:
> 
> + Move clear_warn_once from debugfs to a location that is always
>   available. For example, into /proc

Or a printk module param, which user-space can write to from crontab?
Hmm, but this has potential of becoming another /proc/sys/vm/drop_caches
though.

-ss


Re: [PATCH] arm64: dts: qcom: c630: Re-enable apps_smmu

2020-11-29 Thread Shawn Guo
On Tue, Nov 24, 2020 at 12:44:14PM -0600, Bjorn Andersson wrote:
> Re-enable the apps_smmu now that the arm-smmu driver supports stream
> mapping handoff from firmware.
> 
> Signed-off-by: Bjorn Andersson 

Acked-by: Shawn Guo 

> ---
>  arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts 
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index d03ca3190746..f5b98845fa90 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -232,11 +232,6 @@ vreg_lvs2a_1p8: lvs2 {
>   };
>  };
>  
> -_smmu {
> - /* TODO: Figure out how to survive booting with this enabled */
> - status = "disabled";
> -};
> -
>  _pas {
>   firmware-name = "qcom/LENOVO/81JL/qccdsp850.mbn";
>   status = "okay";
> -- 
> 2.29.2
> 


Re: [PATCH 2/3] thermal: int340x: Indicate userspace usage

2020-11-29 Thread Kai-Heng Feng



> On Nov 30, 2020, at 13:29, Srinivas Pandruvada 
>  wrote:
> 
> On Sun, 2020-11-29 at 01:54 +0800, Kai-Heng Feng wrote:
>> The device isn't present under ACPI ThermalZone, and there's a
>> dedicated
>> userspace daemon for this thermal device.
>> 
>> Let thermal core know it shouldn't handle trips to avoid surprising
>> thermal shutdown.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 1 +
>> .../thermal/intel/int340x_thermal/int340x_thermal_zone.c| 6 +---
>> --
>> 2 files changed, 2 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
>> b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
>> index 0966551cbaaa..2002bc96eb3c 100644
>> --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
>> +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
>> @@ -439,6 +439,7 @@ static struct thermal_zone_device_ops
>> int3400_thermal_ops = {
>> static struct thermal_zone_params int3400_thermal_params = {
>>  .governor_name = "user_space",
>>  .no_hwmon = true,
>> +.userspace = true,
> I am copied on only this patch, so I don't know what is this attribute?
> I think it is new.

Ok. The first one doesn't seem to be sent out correctly.

Series resent.

> 
>> };
>> 
>> static void int3400_setup_gddv(struct int3400_thermal_priv *priv)
>> diff --git
>> a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
>> b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
>> index 6e479deff76b..a103eb42ef2d 100644
>> --- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
>> +++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
>> @@ -208,6 +208,7 @@ EXPORT_SYMBOL_GPL(int340x_thermal_read_trips);
>> static struct thermal_zone_params int340x_thermal_params = {
>>  .governor_name = "user_space",
>>  .no_hwmon = true,
>> +.userspace = true,
>> };
>> 
>> struct int34x_thermal_zone *int340x_thermal_zone_add(struct
>> acpi_device *adev,
>> @@ -259,14 +260,9 @@ struct int34x_thermal_zone
>> *int340x_thermal_zone_add(struct acpi_device *adev,
>>  ret = PTR_ERR(int34x_thermal_zone->zone);
>>  goto err_thermal_zone;
>>  }
>> -ret = thermal_zone_device_enable(int34x_thermal_zone->zone);
>> -if (ret)
>> -goto err_enable;
> 
> What is the effect of this?
> The INT340X zones don't need to poll for temperature. When HW notifies
> then user space gets notified via user space governor. Not sure if the
> not enabling break that path.

thermal_zone_device_disable()
  thermal_notify_tz_disable()
thermal_genl_send_event(THERMAL_GENL_EVENT_TZ_DISABLE, )

I think it doesn't affect user_space governor.

Kai-Heng

> 
> Thanks,
> Srinivas
> 
>> 
>>  return int34x_thermal_zone;
>> 
>> -err_enable:
>> -thermal_zone_device_unregister(int34x_thermal_zone->zone);
>> err_thermal_zone:
>>  acpi_lpat_free_conversion_table(int34x_thermal_zone-
>>> lpat_table);
>>  kfree(int34x_thermal_zone->aux_trips);



[PATCH v2 2/2] RISC-V: sifive_l2_cache: Update L2 cache driver to support SiFive FU740

2020-11-29 Thread Yash Shah
SiFive FU740 has 4 ECC interrupt sources as compared to 3 in FU540.
Update the L2 cache controller driver to support this additional
interrupt in case of FU740-C000 chip.

Signed-off-by: Yash Shah 
---
 drivers/soc/sifive/sifive_l2_cache.c | 49 +++-
 1 file changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/sifive/sifive_l2_cache.c 
b/drivers/soc/sifive/sifive_l2_cache.c
index 44d7e19..4e5e841 100644
--- a/drivers/soc/sifive/sifive_l2_cache.c
+++ b/drivers/soc/sifive/sifive_l2_cache.c
@@ -17,6 +17,10 @@
 #define SIFIVE_L2_DIRECCFIX_HIGH 0x104
 #define SIFIVE_L2_DIRECCFIX_COUNT 0x108
 
+#define SIFIVE_L2_DIRECCFAIL_LOW 0x120
+#define SIFIVE_L2_DIRECCFAIL_HIGH 0x124
+#define SIFIVE_L2_DIRECCFAIL_COUNT 0x128
+
 #define SIFIVE_L2_DATECCFIX_LOW 0x140
 #define SIFIVE_L2_DATECCFIX_HIGH 0x144
 #define SIFIVE_L2_DATECCFIX_COUNT 0x148
@@ -29,7 +33,7 @@
 #define SIFIVE_L2_WAYENABLE 0x08
 #define SIFIVE_L2_ECCINJECTERR 0x40
 
-#define SIFIVE_L2_MAX_ECCINTR 3
+#define SIFIVE_L2_MAX_ECCINTR 4
 
 static void __iomem *l2_base;
 static int g_irq[SIFIVE_L2_MAX_ECCINTR];
@@ -37,6 +41,7 @@ static struct riscv_cacheinfo_ops l2_cache_ops;
 
 enum {
DIR_CORR = 0,
+   DIR_UNCORR,
DATA_CORR,
DATA_UNCORR,
 };
@@ -93,6 +98,7 @@ static void l2_config_read(void)
 
 static const struct of_device_id sifive_l2_ids[] = {
{ .compatible = "sifive,fu540-c000-ccache" },
+   { .compatible = "sifive,fu740-c000-ccache" },
{ /* end of table */ },
 };
 
@@ -155,6 +161,15 @@ static irqreturn_t l2_int_handler(int irq, void *device)
atomic_notifier_call_chain(_err_chain, SIFIVE_L2_ERR_TYPE_CE,
   "DirECCFix");
}
+   if (irq == g_irq[DIR_UNCORR]) {
+   add_h = readl(l2_base + SIFIVE_L2_DIRECCFAIL_HIGH);
+   add_l = readl(l2_base + SIFIVE_L2_DIRECCFAIL_LOW);
+   /* Reading this register clears the DirFail interrupt sig */
+   readl(l2_base + SIFIVE_L2_DIRECCFAIL_COUNT);
+   atomic_notifier_call_chain(_err_chain, SIFIVE_L2_ERR_TYPE_UE,
+  "DirECCFail");
+   panic("L2CACHE: DirFail @ 0x%08X.%08X\n", add_h, add_l);
+   }
if (irq == g_irq[DATA_CORR]) {
add_h = readl(l2_base + SIFIVE_L2_DATECCFIX_HIGH);
add_l = readl(l2_base + SIFIVE_L2_DATECCFIX_LOW);
@@ -179,9 +194,9 @@ static irqreturn_t l2_int_handler(int irq, void *device)
 
 static int __init sifive_l2_init(void)
 {
+   int i, k, rc, intr_num, offset = 0;
struct device_node *np;
struct resource res;
-   int i, rc;
 
np = of_find_matching_node(NULL, sifive_l2_ids);
if (!np)
@@ -194,11 +209,33 @@ static int __init sifive_l2_init(void)
if (!l2_base)
return -ENOMEM;
 
-   for (i = 0; i < SIFIVE_L2_MAX_ECCINTR; i++) {
-   g_irq[i] = irq_of_parse_and_map(np, i);
-   rc = request_irq(g_irq[i], l2_int_handler, 0, "l2_ecc", NULL);
+   intr_num = of_property_count_u32_elems(np, "interrupts");
+   if (!intr_num) {
+   pr_err("L2CACHE: no interrupts property\n");
+   return -ENODEV;
+   }
+
+   /*
+* Only FU540 have 3 interrupts. Rest all other variants have
+* 4 interrupts (+dirfail). Therefore offset is required to skip
+* 'dirfail' interrupt entry in case of FU540
+*/
+   if (of_device_is_compatible(np, "sifive,fu540-c000-ccache"))
+   offset = 1;
+
+   g_irq[0] = irq_of_parse_and_map(np, 0);
+   rc = request_irq(g_irq[0], l2_int_handler, 0, "l2_ecc", NULL);
+   if (rc) {
+   pr_err("L2CACHE: Could not request IRQ %d\n", g_irq[0]);
+   return rc;
+   }
+
+   for (i = 1; i < intr_num; i++) {
+   k = i + offset;
+   g_irq[k] = irq_of_parse_and_map(np, i);
+   rc = request_irq(g_irq[k], l2_int_handler, 0, "l2_ecc", NULL);
if (rc) {
-   pr_err("L2CACHE: Could not request IRQ %d\n", g_irq[i]);
+   pr_err("L2CACHE: Could not request IRQ %d\n", g_irq[k]);
return rc;
}
}
-- 
2.7.4



[PATCH v2 1/2] RISC-V: Update l2 cache DT documentation to add support for SiFive FU740

2020-11-29 Thread Yash Shah
The L2 cache controller in SiFive FU740 has 4 ECC interrupt sources as
compared to 3 in FU540. Update the DT documentation accordingly with
"compatible" and "interrupt" property changes.

Signed-off-by: Yash Shah 
---
Changes in v2:
- Changes as per Rob Herring's request on v1
---
 .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 35 --
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml 
b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
index efc0198..749265c 100644
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
+++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
@@ -27,6 +27,7 @@ select:
   items:
 - enum:
 - sifive,fu540-c000-ccache
+- sifive,fu740-c000-ccache
 
   required:
 - compatible
@@ -34,7 +35,9 @@ select:
 properties:
   compatible:
 items:
-  - const: sifive,fu540-c000-ccache
+  - enum:
+  - sifive,fu540-c000-ccache
+  - sifive,fu740-c000-ccache
   - const: cache
 
   cache-block-size:
@@ -53,9 +56,15 @@ properties:
 
   interrupts:
 description: |
-  Must contain entries for DirError, DataError and DataFail signals.
+  Must contain 3 entries for FU540 (DirError, DataError and DataFail) or 4
+  entries for other chips (DirError, DirFail, DataError, DataFail signals)
 minItems: 3
-maxItems: 3
+maxItems: 4
+items:
+  - description: DirError interrupt
+  - description: DirFail interrupt
+  - description: DataError interrupt
+  - description: DataFail interrupt
 
   reg:
 maxItems: 1
@@ -67,6 +76,26 @@ properties:
   The reference to the reserved-memory for the L2 Loosely Integrated 
Memory region.
   The reserved memory node should be defined as per the bindings in 
reserved-memory.txt.
 
+if:
+  properties:
+compatible:
+  contains:
+const: sifive,fu540-c000-ccache
+
+then:
+  properties:
+interrupts:
+  description: |
+Must contain entries for DirError, DataError and DataFail signals.
+  maxItems: 3
+
+else:
+  properties:
+interrupts:
+  description: |
+Must contain entries for DirError, DirFail, DataError, DataFail 
signals.
+  minItems: 4
+
 additionalProperties: false
 
 required:
-- 
2.7.4



Re: [PATCH v3 4/6] drivers: hv: vmbus: Fix checkpatch SPLIT_STRING

2020-11-29 Thread Stephen Hemminger
On Sun, 29 Nov 2020 08:51:47 -0800
"Michael Kelley"  wrote:

> From: Matheus Castello  Sent: Tuesday, November
> 24, 2020 7:29 PM
> > 
> > Checkpatch emits WARNING: quoted string split across lines.
> > To keep the code clean and with the 80 column length indentation the
> > check and registration code for kmsg_dump_register has been transferred
> > to a new function hv_kmsg_dump_register.
> > 
> > Signed-off-by: Matheus Castello 
> > ---
> > This is the V3 of patch 4 of the series "Add improvements suggested by
> > checkpatch for vmbus_drv" with the changes suggested by Michael Kelley  
> and
> > Joe Perches. Thanks!
> > ---
> >  drivers/hv/vmbus_drv.c | 35 ---
> >  1 file changed, 20 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > index 61d28c743263..edcc419ba328 100644
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -1387,6 +1387,24 @@ static struct kmsg_dumper hv_kmsg_dumper = {
> > .dump = hv_kmsg_dump,
> >  };
> > 
> > +static void hv_kmsg_dump_register(void)
> > +{
> > +   int ret;
> > +
> > +   hv_panic_page = (void *)hv_alloc_hyperv_zeroed_page();

I know you just copy/pasted the original code, but one other thing.

Doesn't it already return void *?
arch/x86/include/asm/mshyperv.h:void *hv_alloc_hyperv_zeroed_page(void);

> > +   if (!hv_panic_page) {
> > +   pr_err("Hyper-V: panic message page memory allocation  
> failed\n");
> > +   return;
> > +   }
> > +
> > +   ret = kmsg_dump_register(_kmsg_dumper);
> > +   if (ret) {
> > +   pr_err("Hyper-V: kmsg dump register error 0x%x\n", ret);
> > +   hv_free_hyperv_page((unsigned long)hv_panic_page);
> > +   hv_panic_page = NULL;
> > +   }
> > +}
> > +
> >  static struct ctl_table_header *hv_ctl_table_hdr;
> > 
> >  /*
> > @@ -1477,21 +1495,8 @@ static int vmbus_bus_init(void)
> >  * capability is supported by the hypervisor.
> >  */
> > hv_get_crash_ctl(hyperv_crash_ctl);
> > -   if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG) {
> > -   hv_panic_page = (void  
> *)hv_alloc_hyperv_zeroed_page();
> > -   if (hv_panic_page) {
> > -   ret = kmsg_dump_register(_kmsg_dumper);
> > -   if (ret) {
> > -   pr_err("Hyper-V: kmsg dump  
> register "
> > -   "error 0x%x\n", ret);
> > -   hv_free_hyperv_page(
> > -   (unsigned long)hv_panic_page);
> > -   hv_panic_page = NULL;
> > -   }
> > -   } else
> > -   pr_err("Hyper-V: panic message page memory  
> "
> > -   "allocation failed");
> > -   }
> > +   if (hyperv_crash_ctl & HV_CRASH_CTL_CRASH_NOTIFY_MSG)
> > +   hv_kmsg_dump_register();
> > 
> > register_die_notifier(_die_block);
> > }
> > --
> > 2.29.2  
> 
> Reviewed-by: Michael Kelley 
> 



[PATCH] arm64: dts: meson-sm1: fix typo in opp table

2020-11-29 Thread Dongjin Kim
The freqency 15 should be 151200 in 'opp-15'

Signed-off-by: Dongjin Kim 
---
 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
index 71317f5aada1..aba1214c4d09 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -131,7 +131,7 @@
};
 
opp-151200 {
-   opp-hz = /bits/ 64 <15>;
+   opp-hz = /bits/ 64 <151200>;
opp-microvolt = <80>;
};
 
-- 
2.17.1



[PATCH] usb: xhci-mtk: fix unreleased bandwidth data

2020-11-29 Thread Ikjoon Jang
xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
to handle its own sw bandwidth managements and stores bandwidth data
into internal table every time add_endpoint() is called,
so when one endpoint's bandwidth allocation fails, all earlier
endpoints from same interface still remain at the table.

This patch adds two more hooks from check_bandwidth() and
reset_bandwidth(), so mtk-xhci can releases all remaining
allocations in reset_bandwidth().

Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
Signed-off-by: Ikjoon Jang 
---

 drivers/usb/host/xhci-mtk-sch.c | 163 
 drivers/usb/host/xhci-mtk.h |  13 +++
 drivers/usb/host/xhci.c |   9 ++
 3 files changed, 123 insertions(+), 62 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index 45c54d56ecbd..6fdc7be29420 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -49,9 +49,11 @@ static int is_fs_or_ls(enum usb_device_speed speed)
 * so the bandwidth domain array is organized as follow for simplification:
 * SSport0-OUT, SSport0-IN, ..., SSportX-OUT, SSportX-IN, HSport0, ..., HSportY
 */
-static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
-   struct usb_host_endpoint *ep)
+static struct mu3h_sch_bw_info *get_bw_info(struct xhci_hcd_mtk *mtk,
+struct usb_device *udev,
+struct usb_host_endpoint *ep)
 {
+   struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
struct xhci_virt_device *virt_dev;
int bw_index;
 
@@ -67,7 +69,7 @@ static int get_bw_index(struct xhci_hcd *xhci, struct 
usb_device *udev,
bw_index = virt_dev->real_port + xhci->usb3_rhub.num_ports - 1;
}
 
-   return bw_index;
+   return >sch_array[bw_index];
 }
 
 static u32 get_esit(struct xhci_ep_ctx *ep_ctx)
@@ -172,7 +174,6 @@ static struct mu3h_sch_ep_info *create_sch_ep(struct 
usb_device *udev,
struct usb_host_endpoint *ep, struct xhci_ep_ctx *ep_ctx)
 {
struct mu3h_sch_ep_info *sch_ep;
-   struct mu3h_sch_tt *tt = NULL;
u32 len_bw_budget_table;
size_t mem_size;
 
@@ -190,15 +191,6 @@ static struct mu3h_sch_ep_info *create_sch_ep(struct 
usb_device *udev,
if (!sch_ep)
return ERR_PTR(-ENOMEM);
 
-   if (is_fs_or_ls(udev->speed)) {
-   tt = find_tt(udev);
-   if (IS_ERR(tt)) {
-   kfree(sch_ep);
-   return ERR_PTR(-ENOMEM);
-   }
-   }
-
-   sch_ep->sch_tt = tt;
sch_ep->ep = ep;
 
return sch_ep;
@@ -375,10 +367,10 @@ static void update_bus_bw(struct mu3h_sch_bw_info *sch_bw,
}
 }
 
-static int check_sch_tt(struct usb_device *udev,
-   struct mu3h_sch_ep_info *sch_ep, u32 offset)
+static int check_sch_tt(struct mu3h_sch_tt *tt,
+   struct mu3h_sch_ep_info *sch_ep,
+   u32 offset)
 {
-   struct mu3h_sch_tt *tt = sch_ep->sch_tt;
u32 extra_cs_count;
u32 fs_budget_start;
u32 start_ss, last_ss;
@@ -448,10 +440,9 @@ static int check_sch_tt(struct usb_device *udev,
return 0;
 }
 
-static void update_sch_tt(struct usb_device *udev,
-   struct mu3h_sch_ep_info *sch_ep)
+static void update_sch_tt(struct mu3h_sch_tt *tt,
+ struct mu3h_sch_ep_info *sch_ep)
 {
-   struct mu3h_sch_tt *tt = sch_ep->sch_tt;
u32 base, num_esit;
int i, j;
 
@@ -463,6 +454,7 @@ static void update_sch_tt(struct usb_device *udev,
}
 
list_add_tail(_ep->tt_endpoint, >ep_list);
+   sch_ep->sch_tt = tt;
 }
 
 static int check_sch_bw(struct usb_device *udev,
@@ -476,22 +468,28 @@ static int check_sch_bw(struct usb_device *udev,
u32 bw_boundary;
u32 min_num_budget;
u32 min_cs_count;
+   struct mu3h_sch_tt *tt = NULL;
bool tt_offset_ok = false;
int ret;
 
-   esit = sch_ep->esit;
+   if (is_fs_or_ls(udev->speed)) {
+   tt = find_tt(udev);
+   if (IS_ERR(tt))
+   return -ENOMEM;
+   }
 
/*
 * Search through all possible schedule microframes.
 * and find a microframe where its worst bandwidth is minimum.
 */
+   esit = sch_ep->esit;
min_bw = ~0;
min_index = 0;
min_cs_count = sch_ep->cs_count;
min_num_budget = sch_ep->num_budget_microframes;
for (offset = 0; offset < esit; offset++) {
if (is_fs_or_ls(udev->speed)) {
-   ret = check_sch_tt(udev, sch_ep, offset);
+   ret = check_sch_tt(tt, sch_ep, offset);
if (ret)
continue;
else
@@ -529,10 +527,11 @@ static int check_sch_bw(struct usb_device *udev,
 
if 

Re: [PATCH v2 05/15] usb: misc: emi26: update to use usb_control_msg_send()

2020-11-29 Thread kernel test robot
Hi Anant,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on balbi-usb/testing/next 
peter.chen-usb/ci-for-usb-next v5.10-rc6 next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Anant-Thazhemadam/drivers-usb-misc-update-to-use-usb_control_msg_-send-recv/20201130-093816
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: m68k-allmodconfig (attached as .config)
compiler: m68k-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://github.com/0day-ci/linux/commit/bd85eb79b555200026380c4f93e83c4a667564e5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Anant-Thazhemadam/drivers-usb-misc-update-to-use-usb_control_msg_-send-recv/20201130-093816
git checkout bd85eb79b555200026380c4f93e83c4a667564e5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

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

All warnings (new ones prefixed by >>):

   drivers/usb/misc/emi26.c: In function 'emi26_load_firmware':
>> drivers/usb/misc/emi26.c:201:1: warning: the frame size of 1040 bytes is 
>> larger than 1024 bytes [-Wframe-larger-than=]
 201 | }
 | ^

vim +201 drivers/usb/misc/emi26.c

^1da177e4c3f415 Linus Torvalds 2005-04-16   60  
^1da177e4c3f415 Linus Torvalds 2005-04-16   61  static int 
emi26_load_firmware (struct usb_device *dev)
^1da177e4c3f415 Linus Torvalds 2005-04-16   62  {
ae93a55bf948753 David Woodhouse2008-05-30   63  const struct firmware 
*loader_fw = NULL;
ae93a55bf948753 David Woodhouse2008-05-30   64  const struct firmware 
*bitstream_fw = NULL;
ae93a55bf948753 David Woodhouse2008-05-30   65  const struct firmware 
*firmware_fw = NULL;
ae93a55bf948753 David Woodhouse2008-05-30   66  const struct 
ihex_binrec *rec;
b412284b9698456 Greg Kroah-Hartman 2012-04-20   67  int err = -ENOMEM;
^1da177e4c3f415 Linus Torvalds 2005-04-16   68  int i;
^1da177e4c3f415 Linus Torvalds 2005-04-16   69  __u32 addr; /* 
Address to write */
bd85eb79b555200 Anant Thazhemadam  2020-11-30   70  __u8 buf[FW_LOAD_SIZE];
^1da177e4c3f415 Linus Torvalds 2005-04-16   71  
ae93a55bf948753 David Woodhouse2008-05-30   72  err = 
request_ihex_firmware(_fw, "emi26/loader.fw", >dev);
ae93a55bf948753 David Woodhouse2008-05-30   73  if (err)
ae93a55bf948753 David Woodhouse2008-05-30   74  goto nofw;
ae93a55bf948753 David Woodhouse2008-05-30   75  
ae93a55bf948753 David Woodhouse2008-05-30   76  err = 
request_ihex_firmware(_fw, "emi26/bitstream.fw",
ae93a55bf948753 David Woodhouse2008-05-30   77  
>dev);
ae93a55bf948753 David Woodhouse2008-05-30   78  if (err)
ae93a55bf948753 David Woodhouse2008-05-30   79  goto nofw;
ae93a55bf948753 David Woodhouse2008-05-30   80  
ae93a55bf948753 David Woodhouse2008-05-30   81  err = 
request_ihex_firmware(_fw, "emi26/firmware.fw",
ae93a55bf948753 David Woodhouse2008-05-30   82  
>dev);
ae93a55bf948753 David Woodhouse2008-05-30   83  if (err) {
ae93a55bf948753 David Woodhouse2008-05-30   84  nofw:
fd3f1917e345d85 Greg Kroah-Hartman 2008-08-14   85  
dev_err(>dev, "%s - request_firmware() failed\n",
fd3f1917e345d85 Greg Kroah-Hartman 2008-08-14   86  
__func__);
ae93a55bf948753 David Woodhouse2008-05-30   87  goto wraperr;
ae93a55bf948753 David Woodhouse2008-05-30   88  }
ae93a55bf948753 David Woodhouse2008-05-30   89  
^1da177e4c3f415 Linus Torvalds 2005-04-16   90  /* Assert reset (stop 
the CPU in the EMI) */
^1da177e4c3f415 Linus Torvalds 2005-04-16   91  err = 
emi26_set_reset(dev,1);
b412284b9698456 Greg Kroah-Hartman 2012-04-20   92  if (err < 0)
^1da177e4c3f415 Linus Torvalds 2005-04-16   93  goto wraperr;
^1da177e4c3f415 Linus Torvalds 2005-04-16   94  
ae93a55bf948753 David Woodhouse2008-05-30   95  rec = (const struct 
ihex_binrec *)loader_fw->data;
^1da177e4c3f415 Linus Torvalds 2005-04-16   96  /* 1. We need to put 
the loader for the FPGA into the EZ-USB */
ae93a55bf948753 David Woodhouse2008-05-30   97  while (rec) {
ae93a55bf948753 David Woodhouse2008-05-30   98  err = 
emi26_writememory(dev, be32_to_cpu(rec->addr),
ae93a55bf948753 

[PATCH 3/3] thermal: intel: intel_pch_thermal: Indicate userspace usage

2020-11-29 Thread Kai-Heng Feng
The device isn't present under ACPI ThermalZone, and there's a dedicated
userspace daemon for this thermal device.

Let thermal core know it shouldn't handle trips to avoid surprising
thermal shutdown.

Signed-off-by: Kai-Heng Feng 
---
 drivers/thermal/intel/intel_pch_thermal.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/intel/intel_pch_thermal.c 
b/drivers/thermal/intel/intel_pch_thermal.c
index 3b813ebb6ca1..e55e6318d733 100644
--- a/drivers/thermal/intel/intel_pch_thermal.c
+++ b/drivers/thermal/intel/intel_pch_thermal.c
@@ -270,6 +270,10 @@ static struct thermal_zone_device_ops tzd_ops = {
.get_trip_temp = pch_get_trip_temp,
 };
 
+static struct thermal_zone_params tzd_params = {
+   .userspace = true,
+};
+
 enum board_ids {
board_hsw,
board_wpt,
@@ -346,21 +350,16 @@ static int intel_pch_thermal_probe(struct pci_dev *pdev,
goto error_cleanup;
 
ptd->tzd = thermal_zone_device_register(bi->name, nr_trips, 0, ptd,
-   _ops, NULL, 0, 0);
+   _ops, _params, 0, 0);
if (IS_ERR(ptd->tzd)) {
dev_err(>dev, "Failed to register thermal zone %s\n",
bi->name);
err = PTR_ERR(ptd->tzd);
goto error_cleanup;
}
-   err = thermal_zone_device_enable(ptd->tzd);
-   if (err)
-   goto err_unregister;
 
return 0;
 
-err_unregister:
-   thermal_zone_device_unregister(ptd->tzd);
 error_cleanup:
iounmap(ptd->hw_base);
 error_release:
-- 
2.29.2



[PATCH 2/3] thermal: int340x: Indicate userspace usage

2020-11-29 Thread Kai-Heng Feng
The device isn't present under ACPI ThermalZone, and there's a dedicated
userspace daemon for this thermal device.

Let thermal core know it shouldn't handle trips to avoid surprising
thermal shutdown.

Signed-off-by: Kai-Heng Feng 
---
 drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 1 +
 .../thermal/intel/int340x_thermal/int340x_thermal_zone.c| 6 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c 
b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
index 0966551cbaaa..2002bc96eb3c 100644
--- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
@@ -439,6 +439,7 @@ static struct thermal_zone_device_ops int3400_thermal_ops = 
{
 static struct thermal_zone_params int3400_thermal_params = {
.governor_name = "user_space",
.no_hwmon = true,
+   .userspace = true,
 };
 
 static void int3400_setup_gddv(struct int3400_thermal_priv *priv)
diff --git a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c 
b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
index 6e479deff76b..a103eb42ef2d 100644
--- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
+++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
@@ -208,6 +208,7 @@ EXPORT_SYMBOL_GPL(int340x_thermal_read_trips);
 static struct thermal_zone_params int340x_thermal_params = {
.governor_name = "user_space",
.no_hwmon = true,
+   .userspace = true,
 };
 
 struct int34x_thermal_zone *int340x_thermal_zone_add(struct acpi_device *adev,
@@ -259,14 +260,9 @@ struct int34x_thermal_zone 
*int340x_thermal_zone_add(struct acpi_device *adev,
ret = PTR_ERR(int34x_thermal_zone->zone);
goto err_thermal_zone;
}
-   ret = thermal_zone_device_enable(int34x_thermal_zone->zone);
-   if (ret)
-   goto err_enable;
 
return int34x_thermal_zone;
 
-err_enable:
-   thermal_zone_device_unregister(int34x_thermal_zone->zone);
 err_thermal_zone:
acpi_lpat_free_conversion_table(int34x_thermal_zone->lpat_table);
kfree(int34x_thermal_zone->aux_trips);
-- 
2.29.2



[PATCH] venus: core: add support to dump FW region

2020-11-29 Thread Dikshita Agarwal
Add support to dump video FW region during FW crash
using devcoredump helpers.

Signed-off-by: Dikshita Agarwal 
---
 drivers/media/platform/qcom/venus/core.c | 47 
 1 file changed, 47 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
index 6103aaf..01a0cfe 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -7,8 +7,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +24,48 @@
 #include "firmware.h"
 #include "pm_helpers.h"
 
+static int subsystem_dump(struct venus_core *core)
+{
+   struct device_node *node;
+   struct device *dev;
+   struct resource r;
+   void *mem_va;
+   size_t mem_size;
+   void *data;
+   int ret;
+
+   dev = core->dev;
+   node = of_parse_phandle(dev->of_node, "memory-region", 0);
+   if (!node)
+   return -EINVAL;
+
+   ret = of_address_to_resource(node, 0, );
+   if (ret)
+   goto err_put_node;
+
+   mem_size = resource_size();
+
+   mem_va = memremap(r.start, mem_size, MEMREMAP_WC);
+   if (!mem_va) {
+   ret = -ENOMEM;
+   goto err_put_node;
+   }
+
+   data = vmalloc(mem_size);
+   if (!data) {
+   ret = -EINVAL;
+   goto err_unmap;
+   }
+
+   memcpy(data, mem_va, mem_size);
+
+   dev_coredumpv(dev, data, mem_size, GFP_KERNEL);
+err_unmap:
+   memunmap(mem_va);
+err_put_node:
+   of_node_put(node);
+   return ret;
+}
 static void venus_event_notify(struct venus_core *core, u32 event)
 {
struct venus_inst *inst;
@@ -67,6 +111,9 @@ static void venus_sys_error_handler(struct work_struct *work)
 
venus_shutdown(core);
 
+   dev_warn(core->dev, "dumping FW region!\n");
+   subsystem_dump(core);
+
pm_runtime_put_sync(core->dev);
 
while (core->pmdomains[0] && pm_runtime_active(core->pmdomains[0]))
-- 
2.7.4



[PATCH 1/3] thermal: core: Add indication for userspace usage

2020-11-29 Thread Kai-Heng Feng
We are seeing thermal shutdown on Intel based mobile workstations, the
shutdown happens during the first trip handle in
thermal_zone_device_register():
kernel: thermal thermal_zone15: critical temperature reached (101 C), shutting 
down

However, we shouldn't do a thermal shutdown here, since
1) We may want to use a dedicated daemon, Intel's thermald in this case,
to handle thermal shutdown.

2) For ACPI based system, _CRT doesn't mean shutdown unless it's inside
ThermalZone. ACPI Spec, 11.4.4 _CRT (Critical Temperature):
"... If this object it present under a device, the device’s driver
evaluates this object to determine the device’s critical cooling
temperature trip point. This value may then be used by the device’s
driver to program an internal device temperature sensor trip point."

So a "critical trip" here merely means we should take a more aggressive
cooling method.

So add an indication to let thermal core know it should leave thermal
device to userspace to handle.

Signed-off-by: Kai-Heng Feng 
---
 drivers/thermal/thermal_core.c | 3 +++
 include/linux/thermal.h| 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index c6d74bc1c90b..6561e3767529 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1477,6 +1477,9 @@ thermal_zone_device_register(const char *type, int trips, 
int mask,
goto unregister;
}
 
+   if (tz->tzp && tz->tzp->userspace)
+   thermal_zone_device_disable(tz);
+
mutex_lock(_list_lock);
list_add_tail(>node, _tz_list);
mutex_unlock(_list_lock);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index d07ea27e72a9..e8e8fac78fc8 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -247,6 +247,8 @@ struct thermal_zone_params {
 */
bool no_hwmon;
 
+   bool userspace;
+
int num_tbps;   /* Number of tbp entries */
struct thermal_bind_params *tbp;
 
-- 
2.29.2



Re: [PATCH 2/3] thermal: int340x: Indicate userspace usage

2020-11-29 Thread Srinivas Pandruvada
On Sun, 2020-11-29 at 01:54 +0800, Kai-Heng Feng wrote:
> The device isn't present under ACPI ThermalZone, and there's a
> dedicated
> userspace daemon for this thermal device.
> 
> Let thermal core know it shouldn't handle trips to avoid surprising
> thermal shutdown.
> 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 1 +
>  .../thermal/intel/int340x_thermal/int340x_thermal_zone.c| 6 +---
> --
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> index 0966551cbaaa..2002bc96eb3c 100644
> --- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
> @@ -439,6 +439,7 @@ static struct thermal_zone_device_ops
> int3400_thermal_ops = {
>  static struct thermal_zone_params int3400_thermal_params = {
>   .governor_name = "user_space",
>   .no_hwmon = true,
> + .userspace = true,
I am copied on only this patch, so I don't know what is this attribute?
I think it is new.

>  };
>  
>  static void int3400_setup_gddv(struct int3400_thermal_priv *priv)
> diff --git
> a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> index 6e479deff76b..a103eb42ef2d 100644
> --- a/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> +++ b/drivers/thermal/intel/int340x_thermal/int340x_thermal_zone.c
> @@ -208,6 +208,7 @@ EXPORT_SYMBOL_GPL(int340x_thermal_read_trips);
>  static struct thermal_zone_params int340x_thermal_params = {
>   .governor_name = "user_space",
>   .no_hwmon = true,
> + .userspace = true,
>  };
>  
>  struct int34x_thermal_zone *int340x_thermal_zone_add(struct
> acpi_device *adev,
> @@ -259,14 +260,9 @@ struct int34x_thermal_zone
> *int340x_thermal_zone_add(struct acpi_device *adev,
>   ret = PTR_ERR(int34x_thermal_zone->zone);
>   goto err_thermal_zone;
>   }
> - ret = thermal_zone_device_enable(int34x_thermal_zone->zone);
> - if (ret)
> - goto err_enable;

What is the effect of this?
The INT340X zones don't need to poll for temperature. When HW notifies
then user space gets notified via user space governor. Not sure if the
not enabling break that path.

Thanks,
Srinivas

>  
>   return int34x_thermal_zone;
>  
> -err_enable:
> - thermal_zone_device_unregister(int34x_thermal_zone->zone);
>  err_thermal_zone:
>   acpi_lpat_free_conversion_table(int34x_thermal_zone-
> >lpat_table);
>   kfree(int34x_thermal_zone->aux_trips);



RE: [v10] i2c: imx: support slave mode for imx I2C driver

2020-11-29 Thread Biwen Li (OSS)

> >
> > The patch supports slave mode for imx I2C driver
> >
> > Signed-off-by: Biwen Li 
> 
> Thank you for your work!
> 
> Acked-by: Oleksij Rempel 

> 
> @Wolfram, Christian Eggers I2SR_IAL patches should go before this one.
Hi Wolfram,

Any progress?

Regards,
Biwen Li
> 
> > ---
> > Change in v10:
> > - totally remove CONFIG_I2C_SLAVE
> > - replace api with i2c_imx_clart_irq()
> > - remove robust code
> > - place pm_runtime_get in i2c_imx_slave_init()
> >   to i2c_imx_reg_slave()
> > - apply the patch on top of this patch set:
> >   [PATCH v6 0/3] i2c: imx: Fix handling of arbitration loss
> >   https://lkml.org/lkml/2020/10/9/407
> >
> > Change in v9:
> > - remove #ifdef after select I2C_SLAVE by default
> >
> > Change in v8:
> > - fix build issue
> >
> > Change in v7:
> > - support auto switch mode between master and slave
> > - enable interrupt when idle in slave mode
> > - remove #ifdef
> >
> > Change in v6:
> > - delete robust logs and comments
> > - not read status register again in master isr.
> >
> > Change in v5:
> > - fix a bug that cannot determine in what mode(master mode or
> >   slave mode)
> >
> > Change in v4:
> > - add MACRO CONFIG_I2C_SLAVE to fix compilation issue
> >
> > Change in v3:
> > - support layerscape and i.mx platform
> >
> > Change in v2:
> > - remove MACRO CONFIG_I2C_SLAVE
> >
> >  drivers/i2c/busses/Kconfig   |   1 +
> >  drivers/i2c/busses/i2c-imx.c | 219
> > +++
> >  2 files changed, 196 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index a97a9d058198..e2ad62481f25 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -675,6 +675,7 @@ config I2C_IMG
> >  config I2C_IMX
> > tristate "IMX I2C interface"
> > depends on ARCH_MXC || ARCH_LAYERSCAPE || COLDFIRE
> > +   select I2C_SLAVE
> > help
> >   Say Y here if you want to use the IIC bus controller on
> >   the Freescale i.MX/MXC, Layerscape or ColdFire processors.
> > diff --git a/drivers/i2c/busses/i2c-imx.c
> > b/drivers/i2c/busses/i2c-imx.c index e6f8d6e45a15..a8e8af57e33f 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -17,6 +17,7 @@
> >   * Copyright (C) 2008 Darius Augulis 
> >   *
> >   * Copyright 2013 Freescale Semiconductor, Inc.
> > + * Copyright 2020 NXP
> >   *
> >   */
> >
> > @@ -73,6 +74,11 @@
> >  #define IMX_I2C_I2SR   0x03/* i2c status */
> >  #define IMX_I2C_I2DR   0x04/* i2c transfer data */
> >
> > +/*
> > + * All of the layerscape series SoCs support IBIC register.
> > + */
> > +#define IMX_I2C_IBIC   0x05/* i2c bus interrupt config */
> > +
> >  #define IMX_I2C_REGSHIFT   2
> >  #define VF610_I2C_REGSHIFT 0
> >
> > @@ -91,6 +97,7 @@
> >  #define I2CR_MSTA  0x20
> >  #define I2CR_IIEN  0x40
> >  #define I2CR_IEN   0x80
> > +#define IBIC_BIIE  0x80 /* Bus idle interrupt enable */
> >
> >  /* register bits different operating codes definition:
> >   * 1) I2SR: Interrupt flags clear operation differ between SoCs:
> > @@ -201,6 +208,7 @@ struct imx_i2c_struct {
> > struct pinctrl_state *pinctrl_pins_gpio;
> >
> > struct imx_i2c_dma  *dma;
> > +   struct i2c_client   *slave;
> >  };
> >
> >  static const struct imx_i2c_hwdata imx1_i2c_hwdata = { @@ -265,6
> > +273,11 @@ static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx)
> > return i2c_imx->hwdata->devtype == IMX1_I2C;  }
> >
> > +static inline int is_vf610_i2c(struct imx_i2c_struct *i2c_imx) {
> > +   return i2c_imx->hwdata->devtype == VF610_I2C; }
> > +
> >  static inline void imx_i2c_write_reg(unsigned int val,
> > struct imx_i2c_struct *i2c_imx, unsigned int reg)  { @@ -277,6
> > +290,27 @@ static inline unsigned char imx_i2c_read_reg(struct
> imx_i2c_struct *i2c_imx,
> > return readb(i2c_imx->base + (reg << i2c_imx->hwdata->regshift));  }
> >
> > +static void i2c_imx_clear_irq(struct imx_i2c_struct *i2c_imx,
> > +unsigned int bits) {
> > +   unsigned int temp;
> > +
> > +   /*
> > +* i2sr_clr_opcode is the value to clear all interrupts. Here we want to
> > +* clear only , so we write ~i2sr_clr_opcode with just 
> > +* toggled. This is required because i.MX needs W0C and Vybrid uses W1C.
> > +*/
> > +   temp = ~i2c_imx->hwdata->i2sr_clr_opcode ^ bits;
> > +   imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2SR); }
> > +
> > +/* Set up i2c controller register and i2c status register to default
> > +value. */ static void i2c_imx_reset_regs(struct imx_i2c_struct
> > +*i2c_imx) {
> > +   imx_i2c_write_reg(i2c_imx->hwdata->i2cr_ien_opcode ^ I2CR_IEN,
> > + i2c_imx, IMX_I2C_I2CR);
> > +   i2c_imx_clear_irq(i2c_imx, I2SR_IIF | I2SR_IAL); }
> > +
> >  /* Functions for DMA support */
> >  static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
> >

Re: [PATCH] hwmon: corsair-psu: update supported devices

2020-11-29 Thread Wilken Gottwalt
On Sun, 29 Nov 2020 13:59:33 -0800
Guenter Roeck  wrote:

> On Sun, Nov 29, 2020 at 04:54:43PM +0100, Wilken Gottwalt wrote:
> > On Sun, 29 Nov 2020 05:00:49 -0800
> > Guenter Roeck  wrote:
> > 
> > > On Sun, Nov 29, 2020 at 07:36:18AM +0100, Wilken Gottwalt wrote:
> > > > On Sat, 28 Nov 2020 17:21:40 -0300
> > > > Jonas Malaco  wrote:
> > > > 
> > > > > On Sat, Nov 28, 2020 at 7:35 AM Wilken Gottwalt
> > > > >  wrote:
> > > > > >
> > > > > > On Sat, 28 Nov 2020 02:37:38 -0300
> > > > > > Jonas Malaco  wrote:
> > > > > >
> > > > > > > On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Adds support for another Corsair PSUs series: AX760i, AX860i, 
> > > > > > > > AX1200i,
> > > > > > > > AX1500i and AX1600i. The first 3 power supplies are supported 
> > > > > > > > through
> > > > > > > > the Corsair Link USB Dongle which is some kind of USB/Serial/TTL
> > > > > > > > converter especially made for the COM ports of these power 
> > > > > > > > supplies.
> > > > > > > > There are 3 known revisions of these adapters. The AX1500i 
> > > > > > > > power supply
> > > > > > > > has revision 3 built into the case and AX1600i is the only one 
> > > > > > > > in that
> > > > > > > > series, which has an unique usb hid id like the RM/RX series.
> > > > > > >
> > > > > > > Can I ask what AXi power supplies were tested?
> > > > > > >
> > > > > > > I ask because, based on the user-space implementations I am aware 
> > > > > > > of,
> > > > > > > the AXi dongle protocol appears to be different from the RMi/HXi 
> > > > > > > series.
> > > > > >
> > > > > > I was not able to test this against the AX power supplies, they are 
> > > > > > really
> > > > > > hard to find (and are far to expensive). But I went through all 
> > > > > > these tools
> > > > > > and stuck to the most common commands, which all 3 series support. 
> > > > > > Not every
> > > > > > series supports all commands (there also seem to be different 
> > > > > > firmwares in
> > > > > > the micro-conrollers). But this is fine, some sensors will show up 
> > > > > > as N/A.
> > > > > > Even my HX850i does not support all commands covered in this driver.
> > > > > 
> > > > > I think the similarities come from all using wrappers over the PMBus
> > > > > interface to the voltage controller.  But I am not sure the wrapping
> > > > > protocols are identical.
> > > > > 
> > > > > For example, cpsumon shows significantly more things going on during a
> > > > > read than what is needed for the RMi/HXi series.[1]
> > > > > 
> > > > > [1] 
> > > > > https://github.com/ka87/cpsumon/blob/fd639684d7f9/libcpsumon/src/cpsumon.c#L213-L231
> > > > > 
> > > > > 
> > > > > >
> > > > > > > AXi dongle:
> > > > > > >  - https://github.com/ka87/cpsumon
> > > > > >
> > > > > > This tool made me to consider including the AX series, because it 
> > > > > > uses some
> > > > > > of the same commands on the AX760i, AX860i, AX1200i and AX1500i. 
> > > > > > But it is
> > > > > > a usb-serial tool only. But it was nice to know, that the commands 
> > > > > > are mostly
> > > > > > the same. I left out all the commands for configuring, PCIe power 
> > > > > > rails,
> > > > > > efficiency and others which do not really belong into hwmon.
> > > > > >
> > > > > > > RMi/HXi:
> > > > > > >  - https://github.com/jonasmalacofilho/liquidctl
> > > > > > >  - https://github.com/audiohacked/OpenCorsairLink
> > > > > >
> > > > > > This tool made me include the AX series, because it uses the rmi 
> > > > > > protocol
> > > > > > component for the rmi driver (RM/HX series) and the corsair dongles.
> > > > > 
> > > > > The corsairlink_driver_dongle has no implementations for reading 
> > > > > sensor
> > > > > data (compare that with the corsairlink_driver_rmi).[2][3]  There is
> > > > > also no code that actually tries to read (write) from (to) the device
> > > > > using that dongle driver.[4]
> > > > > 
> > > > > I also looked at a few of the issues, and all of the ones I read
> > > > > mentioned AXi support being under development, and the hypothesis of 
> > > > > the
> > > > > AXi series being compatible with the RMi/HXi code still remaining to 
> > > > > be
> > > > > confirmed.
> > > > > 
> > > > > [2]
> > > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/dongle.c#L33-L39
> > > > > [3]
> > > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/rmi.c#L33-L57
> > > > > [4] 
> > > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/main.c#L106
> > > > > 
> > > > > 
> > > > > >
> > > > > > >  - https://github.com/notaz/corsairmi
> > > > > >
> > > > > > This one covers only some HX/RM PSUs, but is uses the rawhid access 
> > > > > > which
> > > > > > made me looking up the actual usb chips/bridges Corsair uses.
> > > > > >
> > > > > > >
> > > > > > > One additional concern is that the non-HID AXi dongles may only 
> > > > > > > have bulk
> > > > > > > USB endpoints, and this is a 

Re: [RFC PATCH v3.1 09/27] mmc: sdhci: add UHS-II related definitions in headers

2020-11-29 Thread AKASHI Takahiro
On Thu, Nov 26, 2020 at 10:15:29AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > Add UHS-II related definitions in shdci.h and sdhci-uhs2.h.
> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/mmc/host/sdhci-uhs2.h | 210 ++
> >  drivers/mmc/host/sdhci.h  |  73 +++-
> >  2 files changed, 282 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/mmc/host/sdhci-uhs2.h
> > 
> > diff --git a/drivers/mmc/host/sdhci-uhs2.h b/drivers/mmc/host/sdhci-uhs2.h
> > new file mode 100644
> > index ..3b157df9c89c
> > --- /dev/null
> > +++ b/drivers/mmc/host/sdhci-uhs2.h
> > @@ -0,0 +1,210 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + *  linux/drivers/mmc/host/sdhci-uhs2.h - Secure Digital Host Controller
> > + *  Interface driver
> > + *
> > + * Header file for Host Controller UHS2 related registers and I/O 
> > accessors.
> > + *
> > + *  Copyright (C) 2014 Intel Corp, All Rights Reserved.
> > + */
> > +#ifndef __SDHCI_UHS2_H
> > +#define __SDHCI_UHS2_H
> > +
> > +#include 
> > +
> > +/*
> > + * UHS-II Controller registers
> > + * 0x74 preset in sdhci.h
> > + * 0x80
> > + * 0x84-0xB4
> > + * 0xB8-0xCF
> > + * 0xE0-0xE7
> > + */
> > +/* UHS2 */
> > +#define SDHCI_UHS2_BLOCK_SIZE  0x80
> > +#define  SDHCI_UHS2_MAKE_BLKSZ(dma, blksz) \
> > +   dma) & 0x7) << 12) | ((blksz) & 0xFFF))
> > +
> > +#define SDHCI_UHS2_BLOCK_COUNT 0x84
> > +
> > +#define SDHCI_UHS2_CMD_PACKET  0x88
> > +#define  SDHCI_UHS2_CMD_PACK_MAX_LEN   20
> > +
> > +#define SDHCI_UHS2_TRANS_MODE  0x9C
> > +#define  SDHCI_UHS2_TRNS_DMA   BIT(0)
> > +#define  SDHCI_UHS2_TRNS_BLK_CNT_ENBIT(1)
> > +#define  SDHCI_UHS2_TRNS_DATA_TRNS_WRT BIT(4)
> > +#define  SDHCI_UHS2_TRNS_BLK_BYTE_MODE BIT(5)
> > +#define  SDHCI_UHS2_TRNS_RES_R5BIT(6)
> > +#define  SDHCI_UHS2_TRNS_RES_ERR_CHECK_EN  BIT(7)
> > +#define  SDHCI_UHS2_TRNS_RES_INT_DIS   BIT(8)
> > +#define  SDHCI_UHS2_TRNS_WAIT_EBSY BIT(14)
> > +#define  SDHCI_UHS2_TRNS_2L_HD BIT(15)
> > +
> > +#define SDHCI_UHS2_COMMAND 0x9E
> > +#define  SDHCI_UHS2_COMMAND_SUB_CMD0x0004
> > +#define  SDHCI_UHS2_COMMAND_DATA   0x0020
> > +#define  SDHCI_UHS2_COMMAND_TRNS_ABORT 0x0040
> > +#define  SDHCI_UHS2_COMMAND_CMD12  0x0080
> > +#define  SDHCI_UHS2_COMMAND_DORMANT0x00C0
> > +#define  SDHCI_UHS2_COMMAND_PACK_LEN_MASK  GENMASK(12,8)
> > +#define  SDHCI_UHS2_COMMAND_PACK_LEN_SHIFT 8
> > +
> > +#define SDHCI_UHS2_RESPONSE0xA0
> > +#define  SDHCI_UHS2_RESPONSE_MAX_LEN   20
> > +
> > +#define SDHCI_UHS2_MSG_SELECT  0xB4
> > +#define SDHCI_UHS2_MSG_SELECT_CURR 0x0
> > +#define SDHCI_UHS2_MSG_SELECT_ONE  0x1
> > +#define SDHCI_UHS2_MSG_SELECT_TWO  0x2
> > +#define SDHCI_UHS2_MSG_SELECT_THREE0x3
> > +
> > +#define SDHCI_UHS2_MSG 0xB8
> > +
> > +#define SDHCI_UHS2_DEV_INT_STATUS  0xBC
> > +
> > +#define SDHCI_UHS2_DEV_SELECT  0xBE
> > +#define SDHCI_UHS2_DEV_SELECT_DEV_SEL_MASK GENMASK(3,0)
> > +#define SDHCI_UHS2_DEV_SELECT_INT_MSG_EN   BIT(7)
> > +
> > +#define SDHCI_UHS2_DEV_INT_CODE0xBF
> > +
> > +#define SDHCI_UHS2_SW_RESET0xC0
> > +#define SDHCI_UHS2_SW_RESET_FULL   0x0001
> > +#define SDHCI_UHS2_SW_RESET_SD 0x0002
> > +
> > +#define SDHCI_UHS2_TIMER_CTRL  0xC2
> > +#define SDHCI_UHS2_TIMER_CTRL_DEADLOCK_SHIFT   4
> > +
> > +#define SDHCI_UHS2_ERR_INT_STATUS  0xC4
> > +#define SDHCI_UHS2_ERR_INT_STATUS_EN   0xC8
> > +#define SDHCI_UHS2_ERR_INT_SIG_EN  0xCC
> > +#define SDHCI_UHS2_ERR_INT_STATUS_HEADER   BIT(0)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_RES  BIT(1)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_RETRY_EXPBIT(2)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_CRC  BIT(3)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_FRAMEBIT(4)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_TID  BIT(5)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_UNRECOVERBIT(7)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_EBUSYBIT(8)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_ADMA BIT(15)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_RES_TIMEOUT  BIT(16)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_DEADLOCK_TIMEOUT BIT(17)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_VENDOR   BIT(27)
> > +#define SDHCI_UHS2_ERR_INT_STATUS_MASK \
> > +   (SDHCI_UHS2_ERR_INT_STATUS_HEADER | \
> > +   SDHCI_UHS2_ERR_INT_STATUS_RES | \
> > +   SDHCI_UHS2_ERR_INT_STATUS_RETRY_EXP |   \
> > +   SDHCI_UHS2_ERR_INT_STATUS_CRC | \
> > +   SDHCI_UHS2_ERR_INT_STATUS_FRAME |   \
> > +   SDHCI_UHS2_ERR_INT_STATUS_TID | \
> > +   SDHCI_UHS2_ERR_INT_STATUS_UNRECOVER |   \
> > +   SDHCI_UHS2_ERR_INT_STATUS_EBUSY |   \
> > +   SDHCI_UHS2_ERR_INT_STATUS_ADMA |\
> > +   

Re: [RFC PATCH v3.1 08/27] mmc: sdhci: add a kernel configuration for enabling UHS-II support

2020-11-29 Thread AKASHI Takahiro
On Thu, Nov 26, 2020 at 10:14:36AM +0200, Adrian Hunter wrote:
> On 6/11/20 4:27 am, AKASHI Takahiro wrote:
> > This kernel configuration, CONFIG_MMC_SDHCI_UHS2, will be used
> > in the following commits to indicate UHS-II specific code in sdhci
> > controllers.
> 
> This patch needs to be combined with a patch that actually uses the config.

Earlier is better. So the patch #10/27 would be the best.

-Takahiro Akashi

> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/mmc/host/Kconfig | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 31481c9fcc2e..5ca9ac03db40 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -89,6 +89,15 @@ config MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
> >  
> >   This is the case for the Nintendo Wii SDHCI.
> >  
> > +config MMC_SDHCI_UHS2
> > +   tristate "UHS2 support on SDHCI controller"
> > +   depends on MMC_SDHCI
> > +   help
> > + This option is selected by SDHCI controller drivers that want to
> > + support UHS2-capable devices.
> > +
> > + If you have a controller with this feature, say Y or M here.
> > +
> >  config MMC_SDHCI_PCI
> > tristate "SDHCI support on PCI bus"
> > depends on MMC_SDHCI && PCI
> > 
> 


Re: [PATCH] ARM: dts: mvebu: Add device tree for ATL-x530 Board

2020-11-29 Thread Baruch Siach
Hi Aryan,

[ Dropped Jason's bouncing address from Cc ]

On Mon, Nov 30 2020, Aryan Srivastava wrote:
> Add device tree file for x530 board. This has an Armada 385 SoC. Has
> NAND-flash for user storage and SPI for booting. Covers majority of x530
> and GS980MX variants.
>
> Signed-off-by: Aryan Srivastava 
> Reviewed-by: Chris Packham 
> ---
>  arch/arm/boot/dts/armada-385-atl-x530.dts | 235 ++

You need to add this .dts to Makefile for it to build with the rest.

baruch

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

2020-11-29 Thread Randy Dunlap
On 11/27/20 4:32 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:418baf2c Linux 5.10-rc5
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=171555b950
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b81aff78c272da44
> dashboard link: https://syzkaller.appspot.com/bug?extid=3fd34060f26e766536ff
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3fd34060f26e76653...@syzkaller.appspotmail.com
> 
> BFS-fs: bfs_fill_super(): loop5 is unclean, continuing
> BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 
> inodes, the real maximum is 511, mounting anyway
> BFS-fs: bfs_fill_super(): Last block not available on loop5: 120
> BFS-fs: bfs_fill_super(): loop5 is unclean, continuing
> BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 
> inodes, the real maximum is 511, mounting anyway
> BFS-fs: bfs_fill_super(): Last block not available on loop5: 120
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 

Hi,
Can you provide the BFS image file that is being mounted?
(./file0 I think.)

-- 
~Randy



Re: [PATCH 1/2] mm/debug_vm_pgtable/basic: Add validation for dirtiness after write protect

2020-11-29 Thread Anshuman Khandual



On 11/27/20 3:14 PM, Catalin Marinas wrote:
> On Fri, Nov 27, 2020 at 09:22:24AM +0100, Christophe Leroy wrote:
>> Le 27/11/2020 à 06:06, Anshuman Khandual a écrit :
>>> This adds validation tests for dirtiness after write protect conversion for
>>> each page table level. This is important for platforms such as arm64 that
>>> removes the hardware dirty bit while making it an write protected one. This
>>> also fixes pxx_wrprotect() related typos in the documentation file.
>>
>>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>>> index c05d9dcf7891..a5be11210597 100644
>>> --- a/mm/debug_vm_pgtable.c
>>> +++ b/mm/debug_vm_pgtable.c
>>> @@ -70,6 +70,7 @@ static void __init pte_basic_tests(unsigned long pfn, 
>>> pgprot_t prot)
>>> WARN_ON(pte_young(pte_mkold(pte_mkyoung(pte;
>>> WARN_ON(pte_dirty(pte_mkclean(pte_mkdirty(pte;
>>> WARN_ON(pte_write(pte_wrprotect(pte_mkwrite(pte;
>>> +   WARN_ON(pte_dirty(pte_wrprotect(pte)));
>>
>> Wondering what you are testing here exactly.
>>
>> Do you expect that if PTE has the dirty bit, it gets cleared by 
>> pte_wrprotect() ?
>>
>> Powerpc doesn't do that, it only clears the RW bit but the dirty bit remains
>> if it is set, until you call pte_mkclean() explicitely.
> 
> Arm64 has an unusual way of setting a hardware dirty "bit", it actually
> clears the PTE_RDONLY bit. The pte_wrprotect() sets the PTE_RDONLY bit
> back and we can lose the dirty information. Will found this and posted
> patches to fix the arm64 pte_wprotect() to set a software PTE_DIRTY if
> !PTE_RDONLY (we do this for ptep_set_wrprotect() already). My concern
> was that we may inadvertently make a fresh/clean pte dirty with such
> change, hence the suggestion for the test.
> 
> That said, I think we also need a test in the other direction,
> pte_wrprotect() should preserve any dirty information:
> 
>   WARN_ON(!pte_dirty(pte_wrprotect(pte_mkdirty(pte;

This seems like a generic enough principle which all platforms should
adhere to. But the proposed test WARN_ON(pte_dirty(pte_wrprotect(pte)))
might fail on some platforms if the page table entry came in as a dirty
one and pte_wrprotect() is not expected to alter the dirty state.

Instead, should we just add the following two tests, which would ensure
that pte_wrprotect() never alters the dirty state of a page table entry.

WARN_ON(!pte_dirty(pte_wrprotect(pte_mkdirty(pte;
WARN_ON(pte_dirty(pte_wrprotect(pte_mkclean(pte;

> 
> If pte_mkwrite() makes a pte truly writable and potentially dirty, we
> could also add a test as below. However, I think that's valid for arm64,
> other architectures with a separate hardware dirty bit would fail this:
> 
>   WARN_ON(!pte_dirty(pte_wrprotect(pte_mkwrite(pte;

Right.


Re: [ANNOUNCE] [CFP] Call for Sessions - linux.conf.au Online 2021 Kernel Miniconf

2020-11-29 Thread Andrew Donnellan

On 30/11/20 2:46 pm, Andrew Donnellan wrote:

On 30/11/20 2:38 pm, CRISTIAN ANDRES VARGAS GONZALEZ wrote:
 > More info: https://lca-kernel.ozlabs.org/2021-cfs.html 


Hi, this link no working. :c


Ugh, let me fix my TLS setup. In the meantime, try plain old unencrypted 
HTTP: http://lca-kernel.ozlabs.org/2021-cfs.html


Thanks for reporting!


Should be all fixed.

--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited


[PATCH 2/2] ASoC: bindings: fsl-asoc-card: add compatible string for si476x codec

2020-11-29 Thread Shengjiu Wang
The si476x codec is used for FM radio function on i.MX6
auto board.

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt 
b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index f339be62e7e4..90d9e9d81624 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -40,6 +40,8 @@ The compatible list for this generic sound card currently:
 
  "fsl,imx-audio-tlv320aic32x4"
 
+ "fsl,imx-audio-si476x"
+
 Required properties:
 
   - compatible : Contains one of entries in the compatible list.
-- 
2.27.0



[PATCH 1/2] ASoC: fsl-asoc-card: Add support for si476x codec

2020-11-29 Thread Shengjiu Wang
The si476x codec is used for FM radio function on i.MX6
auto board, it only supports recording function.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl-asoc-card.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index a2dd3b6b7fec..f62f81ceab0d 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -131,6 +131,13 @@ static const struct snd_soc_dapm_route audio_map_tx[] = {
{"CPU-Playback",  NULL, "ASRC-Playback"},
 };
 
+static const struct snd_soc_dapm_route audio_map_rx[] = {
+   /* 1st half -- Normal DAPM routes */
+   {"CPU-Capture",  NULL, "Capture"},
+   /* 2nd half -- ASRC DAPM routes */
+   {"ASRC-Capture",  NULL, "CPU-Capture"},
+};
+
 /* Add all possible widgets into here without being redundant */
 static const struct snd_soc_dapm_widget fsl_asoc_card_dapm_widgets[] = {
SND_SOC_DAPM_LINE("Line Out Jack", NULL),
@@ -653,6 +660,11 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
priv->cpu_priv.slot_width = 32;
priv->card.dapm_routes = audio_map_tx;
priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx);
+   } else if (of_device_is_compatible(np, "fsl,imx-audio-si476x")) {
+   codec_dai_name = "si476x-codec";
+   priv->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS;
+   priv->card.dapm_routes = audio_map_rx;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_rx);
} else {
dev_err(>dev, "unknown Device Tree compatible\n");
ret = -EINVAL;
@@ -869,6 +881,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
{ .compatible = "fsl,imx-audio-wm8960", },
{ .compatible = "fsl,imx-audio-mqs", },
{ .compatible = "fsl,imx-audio-wm8524", },
+   { .compatible = "fsl,imx-audio-si476x", },
{}
 };
 MODULE_DEVICE_TABLE(of, fsl_asoc_card_dt_ids);
-- 
2.27.0



linux-next: manual merge of the tip tree with the pci tree

2020-11-29 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/pci/i386.c

between commit:

  ace091d17272 ("x86/PCI: Fix kernel-doc markup")

from the pci tree and commit:

  638920a66a17 ("x86/PCI: Make a kernel-doc comment a normal one")

from the tip tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpzAcg3rDXKS.pgp
Description: OpenPGP digital signature


Re: [PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build

2020-11-29 Thread Randy Dunlap
On 11/29/20 7:37 PM, Sergey Senozhatsky wrote:
> A quick question, shouldn't there be dummy definitions for
> the EXPORT_SYMBOL-s? So that external modules can be modprobed
> and used.
> 
> Some of posix_acl exported symbols have dummy definitions,
> others don't.
> 
> E.g. posix_acl_create() is exported symbol and it's defined for
> both FS_POSIX_ACL and !FS_POSIX_ACL. While exported set_posix_acl()
> is defined only for FS_POSIX_ACL config.

Hi,

Currently CONFIG_FS_POSIX_ACL differences seem to be handled in
each source file as needed:

fs/inode.c:#ifdef CONFIG_FS_POSIX_ACL
fs/inode.c:#ifdef CONFIG_FS_POSIX_ACL
fs/namei.c:#ifdef CONFIG_FS_POSIX_ACL
fs/overlayfs/dir.c: if (!IS_ENABLED(CONFIG_FS_POSIX_ACL) || !acl)
fs/overlayfs/inode.c:   if (!IS_ENABLED(CONFIG_FS_POSIX_ACL) || 
!IS_POSIXACL(realinode))
fs/overlayfs/inode.c:#ifdef CONFIG_FS_POSIX_ACL
fs/overlayfs/super.c:#ifdef CONFIG_FS_POSIX_ACL
fs/xattr.c:#ifdef CONFIG_FS_POSIX_ACL
include/linux/evm.h:#ifdef CONFIG_FS_POSIX_ACL
include/linux/fs.h:#ifdef CONFIG_FS_POSIX_ACL
include/linux/posix_acl.h:#ifdef CONFIG_FS_POSIX_ACL
include/linux/posix_acl.h:#endif /* CONFIG_FS_POSIX_ACL */
include/linux/posix_acl_xattr.h:#ifdef CONFIG_FS_POSIX_ACL

However, I have no objection to your patch.

I am adding Andreas & Al for their viewpoints.


> ---
> 
> diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
> index 90797f1b421d..8a6c77a69761 100644
> --- a/include/linux/posix_acl.h
> +++ b/include/linux/posix_acl.h
> @@ -59,19 +59,19 @@ posix_acl_release(struct posix_acl *acl)
>  
>  /* posix_acl.c */
>  
> +extern int posix_acl_permission(struct inode *, const struct posix_acl *, 
> int);
> +
> +extern struct posix_acl *get_posix_acl(struct inode *, int);
> +
> +#ifdef CONFIG_FS_POSIX_ACL
>  extern void posix_acl_init(struct posix_acl *, int);
>  extern struct posix_acl *posix_acl_alloc(int, gfp_t);
> -extern int posix_acl_valid(struct user_namespace *, const struct posix_acl 
> *);
> -extern int posix_acl_permission(struct inode *, const struct posix_acl *, 
> int);
> -extern struct posix_acl *posix_acl_from_mode(umode_t, gfp_t);
>  extern int posix_acl_equiv_mode(const struct posix_acl *, umode_t *);
> +extern struct posix_acl *posix_acl_from_mode(umode_t, gfp_t);
>  extern int __posix_acl_create(struct posix_acl **, gfp_t, umode_t *);
>  extern int __posix_acl_chmod(struct posix_acl **, gfp_t, umode_t);
> -
> -extern struct posix_acl *get_posix_acl(struct inode *, int);
>  extern int set_posix_acl(struct inode *, int, struct posix_acl *);
> -
> -#ifdef CONFIG_FS_POSIX_ACL
> +extern int posix_acl_valid(struct user_namespace *, const struct posix_acl 
> *);
>  extern int posix_acl_chmod(struct inode *, umode_t);
>  extern int posix_acl_create(struct inode *, umode_t *, struct posix_acl **,
>   struct posix_acl **);
> @@ -91,18 +91,61 @@ static inline void cache_no_acl(struct inode *inode)
>   inode->i_acl = NULL;
>   inode->i_default_acl = NULL;
>  }
> +
> +struct posix_acl *get_acl(struct inode *inode, int type);
>  #else
> +static inline void posix_acl_init(struct posix_acl *, int)
> +{
> +}
> +
> +static inline struct posix_acl *posix_acl_alloc(int, gfp_t)
> +{
> + return NULL;
> +}
> +
> +static inline int posix_acl_valid(struct user_namespace *,
> +   const struct posix_acl *)
> +{
> + return 0;
> +}
> +
> +static inline int posix_acl_equiv_mode(const struct posix_acl *, umode_t *)
> +{
> + return 0;
> +}
> +
> +static inline struct posix_acl *posix_acl_from_mode(umode_t, gfp_t)
> +{
> + return NULL;
> +}
> +
>  static inline int posix_acl_chmod(struct inode *inode, umode_t mode)
>  {
>   return 0;
>  }
>  
> +static inline int set_posix_acl(struct inode *, int, struct posix_acl *)
> +{
> + return 0;
> +}
> +
>  #define simple_set_acl   NULL
>  
>  static inline int simple_acl_create(struct inode *dir, struct inode *inode)
>  {
>   return 0;
>  }
> +
> +static inline int __posix_acl_create(struct posix_acl **, gfp_t, umode_t *)
> +{
> + return 0;
> +}
> +
> +static inline int __posix_acl_chmod(struct posix_acl **, gfp_t, umode_t)
> +{
> + return 0;
> +}
> +
>  static inline void cache_no_acl(struct inode *inode)
>  {
>  }
> @@ -117,8 +160,38 @@ static inline int posix_acl_create(struct inode *inode, 
> umode_t *mode,
>  static inline void forget_all_cached_acls(struct inode *inode)
>  {
>  }
> +
> +static inline struct posix_acl *get_cached_acl(struct inode *inode, int type)
> +{
> + return NULL;
> +}
> +
> +static inline struct posix_acl *get_cached_acl_rcu(struct inode *inode,
> +int type)
> +{
> + return NULL;
> +}
> +
> +static inline void set_cached_acl(struct inode *inode, int type,
> +   struct posix_acl *acl)
> +{
> +}
> +
> +static inline void forget_cached_acl(struct inode *inode, int type)
> +{
> +}
> +
> +static inline struct posix_acl 

Re: [PATCH v2 06/15] usb: misc: emi62: update to use usb_control_msg_send()

2020-11-29 Thread kernel test robot
Hi Anant,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on balbi-usb/testing/next 
peter.chen-usb/ci-for-usb-next v5.10-rc6 next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Anant-Thazhemadam/drivers-usb-misc-update-to-use-usb_control_msg_-send-recv/20201130-093816
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: h8300-randconfig-s032-20201130 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-170-g3bc348f6-dirty
# 
https://github.com/0day-ci/linux/commit/a9e2333efa48de6856185ec35c82b659ff1c1215
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Anant-Thazhemadam/drivers-usb-misc-update-to-use-usb_control_msg_-send-recv/20201130-093816
git checkout a9e2333efa48de6856185ec35c82b659ff1c1215
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=h8300 

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

All warnings (new ones prefixed by >>):

   drivers/usb/misc/emi62.c: In function 'emi62_load_firmware':
>> drivers/usb/misc/emi62.c:213:1: warning: the frame size of 1048 bytes is 
>> larger than 1024 bytes [-Wframe-larger-than=]
 213 | }
 | ^

vim +213 drivers/usb/misc/emi62.c

^1da177e4c3f415 Linus Torvalds 2005-04-16   68  
^1da177e4c3f415 Linus Torvalds 2005-04-16   69  static int 
emi62_load_firmware (struct usb_device *dev)
^1da177e4c3f415 Linus Torvalds 2005-04-16   70  {
b8e24bfabb03527 David Woodhouse2008-05-30   71  const struct firmware 
*loader_fw = NULL;
b8e24bfabb03527 David Woodhouse2008-05-30   72  const struct firmware 
*bitstream_fw = NULL;
b8e24bfabb03527 David Woodhouse2008-05-30   73  const struct firmware 
*firmware_fw = NULL;
b8e24bfabb03527 David Woodhouse2008-05-30   74  const struct 
ihex_binrec *rec;
e9a527dae346c0a Greg Kroah-Hartman 2012-04-20   75  int err = -ENOMEM;
^1da177e4c3f415 Linus Torvalds 2005-04-16   76  int i;
^1da177e4c3f415 Linus Torvalds 2005-04-16   77  __u32 addr; /* 
Address to write */
a9e2333efa48de6 Anant Thazhemadam  2020-11-30   78  __u8 buf[FW_LOAD_SIZE];
^1da177e4c3f415 Linus Torvalds 2005-04-16   79  
^1da177e4c3f415 Linus Torvalds 2005-04-16   80  dev_dbg(>dev, 
"load_firmware\n");
^1da177e4c3f415 Linus Torvalds 2005-04-16   81  
b8e24bfabb03527 David Woodhouse2008-05-30   82  err = 
request_ihex_firmware(_fw, "emi62/loader.fw", >dev);
b8e24bfabb03527 David Woodhouse2008-05-30   83  if (err)
b8e24bfabb03527 David Woodhouse2008-05-30   84  goto nofw;
b8e24bfabb03527 David Woodhouse2008-05-30   85  
b8e24bfabb03527 David Woodhouse2008-05-30   86  err = 
request_ihex_firmware(_fw, "emi62/bitstream.fw",
b8e24bfabb03527 David Woodhouse2008-05-30   87  
>dev);
b8e24bfabb03527 David Woodhouse2008-05-30   88  if (err)
b8e24bfabb03527 David Woodhouse2008-05-30   89  goto nofw;
b8e24bfabb03527 David Woodhouse2008-05-30   90  
b8e24bfabb03527 David Woodhouse2008-05-30   91  err = 
request_ihex_firmware(_fw, FIRMWARE_FW, >dev);
b8e24bfabb03527 David Woodhouse2008-05-30   92  if (err) {
b8e24bfabb03527 David Woodhouse2008-05-30   93  nofw:
b8e24bfabb03527 David Woodhouse2008-05-30   94  goto wraperr;
b8e24bfabb03527 David Woodhouse2008-05-30   95  }
b8e24bfabb03527 David Woodhouse2008-05-30   96  
^1da177e4c3f415 Linus Torvalds 2005-04-16   97  /* Assert reset (stop 
the CPU in the EMI) */
^1da177e4c3f415 Linus Torvalds 2005-04-16   98  err = 
emi62_set_reset(dev,1);
e9a527dae346c0a Greg Kroah-Hartman 2012-04-20   99  if (err < 0)
^1da177e4c3f415 Linus Torvalds 2005-04-16  100  goto wraperr;
^1da177e4c3f415 Linus Torvalds 2005-04-16  101  
b8e24bfabb03527 David Woodhouse2008-05-30  102  rec = (const struct 
ihex_binrec *)loader_fw->data;
b8e24bfabb03527 David Woodhouse2008-05-30  103  
^1da177e4c3f415 Linus Torvalds 2005-04-16  104  /* 1. We need to put 
the loader for the FPGA into the EZ-USB */
b8e24bfabb03527 David Woodhouse2008-05-30  105  while (rec) {
b8e24bfabb03527 David Woodhouse2008-05-30  106  err = 
emi62_writememory(dev, 

Re: [ANNOUNCE] [CFP] Call for Sessions - linux.conf.au Online 2021 Kernel Miniconf

2020-11-29 Thread Andrew Donnellan

On 30/11/20 2:38 pm, CRISTIAN ANDRES VARGAS GONZALEZ wrote:
 > More info: https://lca-kernel.ozlabs.org/2021-cfs.html 


Hi, this link no working. :c


Ugh, let me fix my TLS setup. In the meantime, try plain old unencrypted 
HTTP: http://lca-kernel.ozlabs.org/2021-cfs.html


Thanks for reporting!


Andrew

--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited


Re: [PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build

2020-11-29 Thread Sergey Senozhatsky
A quick question, shouldn't there be dummy definitions for
the EXPORT_SYMBOL-s? So that external modules can be modprobed
and used.

Some of posix_acl exported symbols have dummy definitions,
others don't.

E.g. posix_acl_create() is exported symbol and it's defined for
both FS_POSIX_ACL and !FS_POSIX_ACL. While exported set_posix_acl()
is defined only for FS_POSIX_ACL config.

---

diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
index 90797f1b421d..8a6c77a69761 100644
--- a/include/linux/posix_acl.h
+++ b/include/linux/posix_acl.h
@@ -59,19 +59,19 @@ posix_acl_release(struct posix_acl *acl)
 
 /* posix_acl.c */
 
+extern int posix_acl_permission(struct inode *, const struct posix_acl *, int);
+
+extern struct posix_acl *get_posix_acl(struct inode *, int);
+
+#ifdef CONFIG_FS_POSIX_ACL
 extern void posix_acl_init(struct posix_acl *, int);
 extern struct posix_acl *posix_acl_alloc(int, gfp_t);
-extern int posix_acl_valid(struct user_namespace *, const struct posix_acl *);
-extern int posix_acl_permission(struct inode *, const struct posix_acl *, int);
-extern struct posix_acl *posix_acl_from_mode(umode_t, gfp_t);
 extern int posix_acl_equiv_mode(const struct posix_acl *, umode_t *);
+extern struct posix_acl *posix_acl_from_mode(umode_t, gfp_t);
 extern int __posix_acl_create(struct posix_acl **, gfp_t, umode_t *);
 extern int __posix_acl_chmod(struct posix_acl **, gfp_t, umode_t);
-
-extern struct posix_acl *get_posix_acl(struct inode *, int);
 extern int set_posix_acl(struct inode *, int, struct posix_acl *);
-
-#ifdef CONFIG_FS_POSIX_ACL
+extern int posix_acl_valid(struct user_namespace *, const struct posix_acl *);
 extern int posix_acl_chmod(struct inode *, umode_t);
 extern int posix_acl_create(struct inode *, umode_t *, struct posix_acl **,
struct posix_acl **);
@@ -91,18 +91,61 @@ static inline void cache_no_acl(struct inode *inode)
inode->i_acl = NULL;
inode->i_default_acl = NULL;
 }
+
+struct posix_acl *get_acl(struct inode *inode, int type);
 #else
+static inline void posix_acl_init(struct posix_acl *, int)
+{
+}
+
+static inline struct posix_acl *posix_acl_alloc(int, gfp_t)
+{
+   return NULL;
+}
+
+static inline int posix_acl_valid(struct user_namespace *,
+ const struct posix_acl *)
+{
+   return 0;
+}
+
+static inline int posix_acl_equiv_mode(const struct posix_acl *, umode_t *)
+{
+   return 0;
+}
+
+static inline struct posix_acl *posix_acl_from_mode(umode_t, gfp_t)
+{
+   return NULL;
+}
+
 static inline int posix_acl_chmod(struct inode *inode, umode_t mode)
 {
return 0;
 }
 
+static inline int set_posix_acl(struct inode *, int, struct posix_acl *)
+{
+   return 0;
+}
+
 #define simple_set_acl NULL
 
 static inline int simple_acl_create(struct inode *dir, struct inode *inode)
 {
return 0;
 }
+
+static inline int __posix_acl_create(struct posix_acl **, gfp_t, umode_t *)
+{
+   return 0;
+}
+
+static inline int __posix_acl_chmod(struct posix_acl **, gfp_t, umode_t)
+{
+   return 0;
+}
+
 static inline void cache_no_acl(struct inode *inode)
 {
 }
@@ -117,8 +160,38 @@ static inline int posix_acl_create(struct inode *inode, 
umode_t *mode,
 static inline void forget_all_cached_acls(struct inode *inode)
 {
 }
+
+static inline struct posix_acl *get_cached_acl(struct inode *inode, int type)
+{
+   return NULL;
+}
+
+static inline struct posix_acl *get_cached_acl_rcu(struct inode *inode,
+  int type)
+{
+   return NULL;
+}
+
+static inline void set_cached_acl(struct inode *inode, int type,
+ struct posix_acl *acl)
+{
+}
+
+static inline void forget_cached_acl(struct inode *inode, int type)
+{
+}
+
+static inline struct posix_acl *get_acl(struct inode *inode, int type)
+{
+   return NULL;
+}
+
+static inline int posix_acl_update_mode(struct inode *, umode_t *,
+   struct posix_acl **)
+{
+   return 0;
+}
 #endif /* CONFIG_FS_POSIX_ACL */
 
-struct posix_acl *get_acl(struct inode *inode, int type);
 
 #endif  /* __LINUX_POSIX_ACL_H */


Re: [PATCH v2 17/17] vdpa: split vdpasim to core and net modules

2020-11-29 Thread Jason Wang



On 2020/11/26 下午10:49, Stefano Garzarella wrote:

From: Max Gurtovoy

Introduce new vdpa_sim_net and vdpa_sim (core) drivers. This is a
preparation for adding a vdpa simulator module for block devices.

Signed-off-by: Max Gurtovoy
[sgarzare: various cleanups/fixes]
Signed-off-by: Stefano Garzarella
---
v2:
- Fixed "warning: variable 'dev' is used uninitialized" reported by
   'kernel test robot' and Dan Carpenter
- rebased on top of other changes (dev_attr, get_config(), notify(), etc.)
- left batch_mapping module parameter in the core [Jason]

v1:
- Removed unused headers
- Removed empty module_init() module_exit()
- Moved vdpasim_is_little_endian() in vdpa_sim.h
- Moved vdpasim16_to_cpu/cpu_to_vdpasim16() in vdpa_sim.h
- Added vdpasim*_to_cpu/cpu_to_vdpasim*() also for 32 and 64
- Replaced 'select VDPA_SIM' with 'depends on VDPA_SIM' since selected
   option can not depend on other [Jason]
---
  drivers/vdpa/vdpa_sim/vdpa_sim.h | 103 +
  drivers/vdpa/vdpa_sim/vdpa_sim.c | 222 +--
  drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 171 +
  drivers/vdpa/Kconfig |  13 +-
  drivers/vdpa/vdpa_sim/Makefile   |   1 +
  5 files changed, 290 insertions(+), 220 deletions(-)
  create mode 100644 drivers/vdpa/vdpa_sim/vdpa_sim.h
  create mode 100644 drivers/vdpa/vdpa_sim/vdpa_sim_net.c



Looks good, consider there are some still some questions left. I will 
probably ack for the next version.


Thanks



Re: [PATCH v2 16/17] vdpa_sim: split vdpasim_virtqueue's iov field in out_iov and in_iov

2020-11-29 Thread Jason Wang



On 2020/11/26 下午10:49, Stefano Garzarella wrote:

vringh_getdesc_iotlb() manages 2 iovs for writable and readable
descriptors. This is very useful for the block device, where for
each request we have both types of descriptor.

Let's split the vdpasim_virtqueue's iov field in out_iov and
in_iov to use them with vringh_getdesc_iotlb().

We are using VIRTIO terminology for "out" (readable by the device)
and "in" (writable by the device) descriptors.

Signed-off-by: Stefano Garzarella 
---
v2:
- used VIRTIO terminology [Stefan]
---



Acked-by: Jason Wang 



  drivers/vdpa/vdpa_sim/vdpa_sim.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index f5f41f20ee0b..f8ee261ef4ae 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -33,7 +33,8 @@ u8 macaddr_buf[ETH_ALEN];
  
  struct vdpasim_virtqueue {

struct vringh vring;
-   struct vringh_kiov iov;
+   struct vringh_kiov in_iov;
+   struct vringh_kiov out_iov;
unsigned short head;
bool ready;
u64 desc_addr;
@@ -197,12 +198,12 @@ static void vdpasim_net_work(struct work_struct *work)
  
  	while (true) {

total_write = 0;
-   err = vringh_getdesc_iotlb(>vring, >iov, NULL,
+   err = vringh_getdesc_iotlb(>vring, >out_iov, NULL,
   >head, GFP_ATOMIC);
if (err <= 0)
break;
  
-		err = vringh_getdesc_iotlb(>vring, NULL, >iov,

+   err = vringh_getdesc_iotlb(>vring, NULL, >in_iov,
   >head, GFP_ATOMIC);
if (err <= 0) {
vringh_complete_iotlb(>vring, txq->head, 0);
@@ -210,13 +211,13 @@ static void vdpasim_net_work(struct work_struct *work)
}
  
  		while (true) {

-   read = vringh_iov_pull_iotlb(>vring, >iov,
+   read = vringh_iov_pull_iotlb(>vring, >out_iov,
 vdpasim->buffer,
 PAGE_SIZE);
if (read <= 0)
break;
  
-			write = vringh_iov_push_iotlb(>vring, >iov,

+   write = vringh_iov_push_iotlb(>vring, >in_iov,
  vdpasim->buffer, read);
if (write <= 0)
break;




[RFC V2 1/3] mm/hotplug: Prevalidate the address range being added with platform

2020-11-29 Thread Anshuman Khandual
This introduces memhp_range_allowed() which can be called in various memory
hotplug paths to prevalidate the address range which is being added, with
the platform. Then memhp_range_allowed() calls memhp_get_pluggable_range()
which provides applicable address range depending on whether linear mapping
is required or not. For ranges that require linear mapping, it calls a new
arch callback arch_get_mappable_range() which the platform can override. So
the new callback, in turn provides the platform an opportunity to configure
acceptable memory hotplug address ranges in case there are constraints.

This mechanism will help prevent platform specific errors deep down during
hotplug calls. This drops now redundant check_hotplug_memory_addressable()
check in __add_pages().

Cc: David Hildenbrand 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 include/linux/memory_hotplug.h |  2 +
 mm/memory_hotplug.c| 77 +-
 mm/memremap.c  |  6 ++-
 3 files changed, 64 insertions(+), 21 deletions(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 551093b74596..047a711ab76a 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -70,6 +70,8 @@ typedef int __bitwise mhp_t;
  */
 #define MEMHP_MERGE_RESOURCE   ((__force mhp_t)BIT(0))
 
+bool memhp_range_allowed(u64 start, u64 size, bool need_mapping);
+
 /*
  * Extended parameters for memory hotplug:
  * altmap: alternative allocator for memmap array (optional)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 63b2e46b6555..9dd9db01985d 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -107,6 +107,9 @@ static struct resource *register_memory_resource(u64 start, 
u64 size,
if (strcmp(resource_name, "System RAM"))
flags |= IORESOURCE_SYSRAM_DRIVER_MANAGED;
 
+   if (!memhp_range_allowed(start, size, 1))
+   return ERR_PTR(-E2BIG);
+
/*
 * Make sure value parsed from 'mem=' only restricts memory adding
 * while booting, so that memory hotplug won't be impacted. Please
@@ -284,22 +287,6 @@ static int check_pfn_span(unsigned long pfn, unsigned long 
nr_pages,
return 0;
 }
 
-static int check_hotplug_memory_addressable(unsigned long pfn,
-   unsigned long nr_pages)
-{
-   const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
-
-   if (max_addr >> MAX_PHYSMEM_BITS) {
-   const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS + 1)) - 1;
-   WARN(1,
-"Hotplugged memory exceeds maximum addressable address, 
range=%#llx-%#llx, maximum=%#llx\n",
-(u64)PFN_PHYS(pfn), max_addr, max_allowed);
-   return -E2BIG;
-   }
-
-   return 0;
-}
-
 /*
  * Reasonably generic function for adding memory.  It is
  * expected that archs that support memory hotplug will
@@ -317,10 +304,6 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned 
long nr_pages,
if (WARN_ON_ONCE(!params->pgprot.pgprot))
return -EINVAL;
 
-   err = check_hotplug_memory_addressable(pfn, nr_pages);
-   if (err)
-   return err;
-
if (altmap) {
/*
 * Validate altmap is within bounds of the total request
@@ -1824,4 +1807,58 @@ int offline_and_remove_memory(int nid, u64 start, u64 
size)
return rc;
 }
 EXPORT_SYMBOL_GPL(offline_and_remove_memory);
+
+/*
+ * Platforms should define arch_get_mappable_range() that provides
+ * maximum possible addressable physical memory range for which the
+ * linear mapping could be created. The platform returned address
+ * range must adhere to these following semantics.
+ *
+ * - range.start <= range.end
+ * - Range includes both end points [range.start..range.end]
+ *
+ * There is also a fallback definition provided here, allowing the
+ * entire possible physical address range in case any platform does
+ * not define arch_get_mappable_range().
+ */
+struct range __weak arch_get_mappable_range(void)
+{
+   struct range memhp_range = {
+   .start = 0UL,
+   .end = -1ULL,
+   };
+   return memhp_range;
+}
+
+static inline struct range memhp_get_pluggable_range(bool need_mapping)
+{
+   const u64 max_phys = (1ULL << (MAX_PHYSMEM_BITS + 1)) - 1;
+   struct range memhp_range;
+
+   if (need_mapping) {
+   memhp_range = arch_get_mappable_range();
+   if (memhp_range.start > max_phys) {
+   memhp_range.start = 0;
+   memhp_range.end = 0;
+   }
+   memhp_range.end = min_t(u64, memhp_range.end, max_phys);
+   } else {
+   memhp_range.start = 0;
+   memhp_range.end = max_phys;
+   }
+   return memhp_range;
+}
+
+bool memhp_range_allowed(u64 start, 

[RFC V2 3/3] s390/mm: Define arch_get_mappable_range()

2020-11-29 Thread Anshuman Khandual
This overrides arch_get_mappabble_range() on s390 platform and drops now
redundant similar check in vmem_add_mapping(). This compensates by adding
a new check __segment_load() to preserve the existing functionality.

Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: David Hildenbrand 
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 arch/s390/mm/extmem.c |  5 +
 arch/s390/mm/vmem.c   | 13 +
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/s390/mm/extmem.c b/arch/s390/mm/extmem.c
index 5060956b8e7d..cc055a78f7b6 100644
--- a/arch/s390/mm/extmem.c
+++ b/arch/s390/mm/extmem.c
@@ -337,6 +337,11 @@ __segment_load (char *name, int do_nonshared, unsigned 
long *addr, unsigned long
goto out_free_resource;
}
 
+   if (seg->end + 1 > VMEM_MAX_PHYS || seg->end + 1 < seg->start_addr) {
+   rc = -ERANGE;
+   goto out_resource;
+   }
+
rc = vmem_add_mapping(seg->start_addr, seg->end - seg->start_addr + 1);
if (rc)
goto out_resource;
diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
index b239f2ba93b0..06dddcc0ce06 100644
--- a/arch/s390/mm/vmem.c
+++ b/arch/s390/mm/vmem.c
@@ -532,14 +532,19 @@ void vmem_remove_mapping(unsigned long start, unsigned 
long size)
mutex_unlock(_mutex);
 }
 
+struct range arch_get_mappable_range(void)
+{
+   struct range memhp_range;
+
+   memhp_range.start = 0;
+   memhp_range.end =  VMEM_MAX_PHYS;
+   return memhp_range;
+}
+
 int vmem_add_mapping(unsigned long start, unsigned long size)
 {
int ret;
 
-   if (start + size > VMEM_MAX_PHYS ||
-   start + size < start)
-   return -ERANGE;
-
mutex_lock(_mutex);
ret = vmem_add_range(start, size);
if (ret)
-- 
2.20.1



[RFC V2 2/3] arm64/mm: Define arch_get_mappable_range()

2020-11-29 Thread Anshuman Khandual
This overrides arch_get_mappable_range() on arm64 platform which will be
used with recently added generic framework. It drops inside_linear_region()
and subsequent check in arch_add_memory() which are no longer required.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: David Hildenbrand 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 arch/arm64/mm/mmu.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ca692a815731..49ec8f2838f2 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1444,16 +1444,19 @@ static void __remove_pgd_mapping(pgd_t *pgdir, unsigned 
long start, u64 size)
free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
 }
 
-static bool inside_linear_region(u64 start, u64 size)
+struct range arch_get_mappable_range(void)
 {
+   struct range memhp_range;
+
/*
 * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
 * accommodating both its ends but excluding PAGE_END. Max physical
 * range which can be mapped inside this linear mapping range, must
 * also be derived from its end points.
 */
-   return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
-  (start + size - 1) <= __pa(PAGE_END - 1);
+   memhp_range.start = __pa(_PAGE_OFFSET(vabits_actual));
+   memhp_range.end =  __pa(PAGE_END - 1);
+   return memhp_range;
 }
 
 int arch_add_memory(int nid, u64 start, u64 size,
@@ -1461,11 +1464,6 @@ int arch_add_memory(int nid, u64 start, u64 size,
 {
int ret, flags = 0;
 
-   if (!inside_linear_region(start, size)) {
-   pr_err("[%llx %llx] is outside linear mapping region\n", start, 
start + size);
-   return -EINVAL;
-   }
-
if (rodata_full || debug_pagealloc_enabled())
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
-- 
2.20.1



[RFC V2 0/3] mm/hotplug: Pre-validate the address range with platform

2020-11-29 Thread Anshuman Khandual
This series adds a mechanism allowing platforms to weigh in and prevalidate
incoming address range before proceeding further with the memory hotplug.
This helps prevent potential platform errors for the given address range,
down the hotplug call chain, which inevitably fails the hotplug itself.

This mechanism was suggested by David Hildenbrand during another discussion
with respect to a memory hotplug fix on arm64 platform.

https://lore.kernel.org/linux-arm-kernel/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/

This mechanism focuses on the addressibility aspect and not [sub] section
alignment aspect. Hence check_hotplug_memory_range() and check_pfn_span()
have been left unchanged. Wondering if all these can still be unified in
an expanded memhp_range_allowed() check, that can be called from multiple
memory hot add and remove paths.

This series applies on v5.10-rc6 and has been slightly tested on arm64.
But looking for some early feedback here.

Changes in RFC V2:

Incorporated all review feedbacks from David.

- Added additional range check in __segment_load() on s390 which was lost
- Changed is_private init in pagemap_range()
- Moved the framework into mm/memory_hotplug.c
- Made arch_get_addressable_range() a __weak function
- Renamed arch_get_addressable_range() as arch_get_mappable_range()
- Callback arch_get_mappable_range() only handles range requiring linear mapping
- Merged multiple memhp_range_allowed() checks in register_memory_resource()
- Replaced WARN() with pr_warn() in memhp_range_allowed()
- Replaced error return code ERANGE with E2BIG

Changes in RFC V1:

https://lore.kernel.org/linux-mm/1606098529-7907-1-git-send-email-anshuman.khand...@arm.com/

Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: David Hildenbrand 
Cc: Andrew Morton 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org

Anshuman Khandual (3):
  mm/hotplug: Prevalidate the address range being added with platform
  arm64/mm: Define arch_get_mappable_range()
  s390/mm: Define arch_get_mappable_range()

 arch/arm64/mm/mmu.c| 14 +++
 arch/s390/mm/extmem.c  |  5 +++
 arch/s390/mm/vmem.c| 13 --
 include/linux/memory_hotplug.h |  2 +
 mm/memory_hotplug.c| 77 +-
 mm/memremap.c  |  6 ++-
 6 files changed, 84 insertions(+), 33 deletions(-)

-- 
2.20.1



Re: [PATCH v2 13/17] vdpa_sim: set vringh notify callback

2020-11-29 Thread Jason Wang



On 2020/11/26 下午10:49, Stefano Garzarella wrote:

Instead of calling the vq callback directly, we can leverage the
vringh_notify() function, adding vdpasim_vq_notify() and setting it
in the vringh notify callback.

Suggested-by: Jason Wang 
Signed-off-by: Stefano Garzarella 
---
  drivers/vdpa/vdpa_sim/vdpa_sim.c | 21 +
  1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 8b87ce0485b6..4327efd6d41e 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -120,6 +120,17 @@ static struct vdpasim *dev_to_sim(struct device *dev)
return vdpa_to_sim(vdpa);
  }
  
+static void vdpasim_vq_notify(struct vringh *vring)

+{
+   struct vdpasim_virtqueue *vq =
+   container_of(vring, struct vdpasim_virtqueue, vring);
+
+   if (!vq->cb)
+   return;
+
+   vq->cb(vq->private);
+}
+
  static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx)
  {
struct vdpasim_virtqueue *vq = >vqs[idx];
@@ -131,6 +142,8 @@ static void vdpasim_queue_ready(struct vdpasim *vdpasim, 
unsigned int idx)
  (uintptr_t)vq->driver_addr,
  (struct vring_used *)
  (uintptr_t)vq->device_addr);
+
+   vq->vring.notify = vdpasim_vq_notify;



Do we need to clear notify during reset?

Other looks good.



  }
  
  static void vdpasim_vq_reset(struct vdpasim *vdpasim,

@@ -220,10 +233,10 @@ static void vdpasim_net_work(struct work_struct *work)
smp_wmb();
  
  		local_bh_disable();

-   if (txq->cb)
-   txq->cb(txq->private);
-   if (rxq->cb)
-   rxq->cb(rxq->private);
+   if (vringh_need_notify_iotlb(>vring) > 0)
+   vringh_notify(>vring);
+   if (vringh_need_notify_iotlb(>vring) > 0)
+   vringh_notify(>vring);
local_bh_enable();
  
  		if (++pkts > 4) {




Re: [PATCH v2 12/17] vdpa_sim: add get_config callback in vdpasim_dev_attr

2020-11-29 Thread Jason Wang



On 2020/11/26 下午10:49, Stefano Garzarella wrote:

The get_config callback can be used by the device to fill the
config structure.
The callback will be invoked in vdpasim_get_config() before copying
bytes into caller buffer.

Move vDPA-net config updates from vdpasim_set_features() in the
new vdpasim_net_get_config() callback.

Signed-off-by: Stefano Garzarella 
---
  drivers/vdpa/vdpa_sim/vdpa_sim.c | 33 +++-
  1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index c07ddf6af720..8b87ce0485b6 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -58,6 +58,8 @@ struct vdpasim_virtqueue {
  #define VDPASIM_NET_FEATURES  (VDPASIM_FEATURES | \
 (1ULL << VIRTIO_NET_F_MAC))
  
+struct vdpasim;

+
  struct vdpasim_dev_attr {
u64 supported_features;
size_t config_size;
@@ -65,6 +67,7 @@ struct vdpasim_dev_attr {
u32 id;
  
  	work_func_t work_fn;

+   void (*get_config)(struct vdpasim *vdpasim, void *config);
  };
  
  /* State of each vdpasim device */

@@ -520,8 +523,6 @@ static u64 vdpasim_get_features(struct vdpa_device *vdpa)
  static int vdpasim_set_features(struct vdpa_device *vdpa, u64 features)
  {
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
-   struct virtio_net_config *config =
-   (struct virtio_net_config *)vdpasim->config;
  
  	/* DMA mapping must be done by driver */

if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
@@ -529,15 +530,6 @@ static int vdpasim_set_features(struct vdpa_device *vdpa, 
u64 features)
  
  	vdpasim->features = features & vdpasim->dev_attr.supported_features;
  
-	/* We generally only know whether guest is using the legacy interface

-* here, so generally that's the earliest we can set config fields.
-* Note: We actually require VIRTIO_F_ACCESS_PLATFORM above which
-* implies VIRTIO_F_VERSION_1, but let's not try to be clever here.
-*/
-
-   config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
-   config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
-   memcpy(config->mac, macaddr_buf, ETH_ALEN);
  
  	return 0;

  }
@@ -593,8 +585,12 @@ static void vdpasim_get_config(struct vdpa_device *vdpa, 
unsigned int offset,
  {
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
  
-	if (offset + len < vdpasim->dev_attr.config_size)

-   memcpy(buf, vdpasim->config + offset, len);
+   if (offset + len > vdpasim->dev_attr.config_size)
+   return;
+
+   vdpasim->dev_attr.get_config(vdpasim, vdpasim->config);
+
+   memcpy(buf, vdpasim->config + offset, len);
  }



I wonder how much value we can get from vdpasim->config consider we've 
already had get_config() method.


Is it possible to copy to the buffer directly here?

Thanks


  
  static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,

@@ -737,6 +733,16 @@ static const struct vdpa_config_ops 
vdpasim_batch_config_ops = {
.free   = vdpasim_free,
  };
  
+static void vdpasim_net_get_config(struct vdpasim *vdpasim, void *config)

+{
+   struct virtio_net_config *net_config =
+   (struct virtio_net_config *)config;
+
+   net_config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
+   net_config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
+   memcpy(net_config->mac, macaddr_buf, ETH_ALEN);
+}
+
  static int __init vdpasim_dev_init(void)
  {
struct vdpasim_dev_attr dev_attr = {};
@@ -745,6 +751,7 @@ static int __init vdpasim_dev_init(void)
dev_attr.supported_features = VDPASIM_NET_FEATURES;
dev_attr.nvqs = VDPASIM_VQ_NUM;
dev_attr.config_size = sizeof(struct virtio_net_config);
+   dev_attr.get_config = vdpasim_net_get_config;
dev_attr.work_fn = vdpasim_net_work;
  
  	vdpasim_dev = vdpasim_create(_attr);




[v3 10/11] arm64: dts: lx2160ardb: fix interrupt line for RTC node

2020-11-29 Thread Biwen Li
From: Biwen Li 

Fix interrupt line for RTC node on lx2160ardb

Signed-off-by: Biwen Li 
---
Change in v3:
- none

Change in v2:
- none

 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 54fe8cd3a711..f3bab76797fb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -2,7 +2,7 @@
 //
 // Device Tree file for LX2160ARDB
 //
-// Copyright 2018 NXP
+// Copyright 2018-2020 NXP
 
 /dts-v1/;
 
@@ -151,8 +151,8 @@
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
-   // IRQ10_B
-   interrupts = <0 150 0x4>;
+   /* IRQ_RTC_B -> IRQ08, active low */
+   interrupts-extended = < 8 IRQ_TYPE_LEVEL_LOW>;
};
 };
 
-- 
2.17.1



[v3 11/11] dt-bindings: interrupt-controller: update bindings for supporting more SoCs

2020-11-29 Thread Biwen Li
From: Biwen Li 

Update bindings for Layerscape external irqs,
support more SoCs(LS1043A, LS1046A, LS1088A,
LS208xA, LX216xA)

Signed-off-by: Biwen Li 
---
Change in v3:
- remove robust information

Change in v2:
- update reg property
- update compatible property

 .../bindings/interrupt-controller/fsl,ls-extirq.txt   | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
index f0ad7801e8cf..4d47df1a5c91 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
@@ -1,6 +1,7 @@
 * Freescale Layerscape external IRQs
 
-Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
+Some Layerscape SOCs (LS1021A, LS1043A, LS1046A
+LS1088A, LS208xA, LX216xA) support inverting
 the polarity of certain external interrupt lines.
 
 The device node must be a child of the node representing the
@@ -8,12 +9,15 @@ Supplemental Configuration Unit (SCFG).
 
 Required properties:
 - compatible: should be "fsl,-extirq", e.g. "fsl,ls1021a-extirq".
+  "fsl,ls1043a-extirq": for LS1043A, LS1046A.
+  "fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA.
 - #interrupt-cells: Must be 2. The first element is the index of the
   external interrupt line. The second element is the trigger type.
 - #address-cells: Must be 0.
 - interrupt-controller: Identifies the node as an interrupt controller
 - reg: Specifies the Interrupt Polarity Control Register (INTPCR) in
-  the SCFG.
+  the SCFG or the External Interrupt Control Register (IRQCR) in
+  the ISC.
 - interrupt-map: Specifies the mapping from external interrupts to GIC
   interrupts.
 - interrupt-map-mask: Must be <0x 0>.
-- 
2.17.1



[v3 09/11] arm64: dts: lx2160a: add DT node for external interrupt lines

2020-11-29 Thread Biwen Li
From: Biwen Li 

Add device-tree node for external interrupt lines IRQ0-IRQ11.

Signed-off-by: Biwen Li 
---
Change in v3:
- none

Change in v2:
- none

 .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index d247e4228d60..095298a84f4e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -664,6 +664,37 @@
little-endian;
};
 
+   isc: syscon@1f7 {
+   compatible = "fsl,lx2160a-isc", "syscon";
+   reg = <0x0 0x1f7 0x0 0x1>;
+   little-endian;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x1f7 0x1>;
+
+   extirq: interrupt-controller@14 {
+   compatible = "fsl,lx2160a-extirq", 
"fsl,ls1088a-extirq";
+   #interrupt-cells = <2>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0x14 4>;
+   interrupt-map =
+   <0 0  GIC_SPI 0 
IRQ_TYPE_LEVEL_HIGH>,
+   <1 0  GIC_SPI 1 
IRQ_TYPE_LEVEL_HIGH>,
+   <2 0  GIC_SPI 2 
IRQ_TYPE_LEVEL_HIGH>,
+   <3 0  GIC_SPI 3 
IRQ_TYPE_LEVEL_HIGH>,
+   <4 0  GIC_SPI 4 
IRQ_TYPE_LEVEL_HIGH>,
+   <5 0  GIC_SPI 5 
IRQ_TYPE_LEVEL_HIGH>,
+   <6 0  GIC_SPI 6 
IRQ_TYPE_LEVEL_HIGH>,
+   <7 0  GIC_SPI 7 
IRQ_TYPE_LEVEL_HIGH>,
+   <8 0  GIC_SPI 8 
IRQ_TYPE_LEVEL_HIGH>,
+   <9 0  GIC_SPI 9 
IRQ_TYPE_LEVEL_HIGH>,
+   <10 0  GIC_SPI 10 
IRQ_TYPE_LEVEL_HIGH>,
+   <11 0  GIC_SPI 11 
IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-map-mask = <0x 0x0>;
+   };
+   };
+
tmu: tmu@1f8 {
compatible = "fsl,qoriq-tmu";
reg = <0x0 0x1f8 0x0 0x1>;
-- 
2.17.1



  1   2   3   4   >