Re: [RFC PATCH v3] sched/fair: select idle cpu from idle cpumask for task wakeup
On Wed, 21 Oct 2020 at 17:05, Aubrey Li wrote:
>
> From: Aubrey Li
>
> Added idle cpumask to track idle cpus in sched domain. When a CPU
> enters idle, its corresponding bit in the idle cpumask will be set,
> and when the CPU exits idle, its bit will be cleared.
>
> When a task wakes up to select an idle cpu, scanning idle cpumask
> has low cost than scanning all the cpus in last level cache domain,
> especially when the system is heavily loaded.
>
> v2->v3:
> - change setting idle cpumask to every idle entry, otherwise schbench
> has a regression of 99th percentile latency.
> - change clearing idle cpumask to nohz_balancer_kick(), so updating
> idle cpumask is ratelimited in the idle exiting path.
> - set SCHED_IDLE cpu in idle cpumask to allow it as a wakeup target.
>
> v1->v2:
> - idle cpumask is updated in the nohz routines, by initializing idle
> cpumask with sched_domain_span(sd), nohz=off case remains the original
> behavior.
>
> Cc: Mel Gorman
> Cc: Vincent Guittot
> Cc: Qais Yousef
> Cc: Valentin Schneider
> Cc: Jiang Biao
> Cc: Tim Chen
> Signed-off-by: Aubrey Li
> ---
> include/linux/sched/topology.h | 13 ++
> kernel/sched/fair.c| 45 +-
> kernel/sched/idle.c| 1 +
> kernel/sched/sched.h | 1 +
> kernel/sched/topology.c| 3 ++-
> 5 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
> index fb11091129b3..43a641d26154 100644
> --- a/include/linux/sched/topology.h
> +++ b/include/linux/sched/topology.h
> @@ -65,8 +65,21 @@ struct sched_domain_shared {
> atomic_tref;
> atomic_tnr_busy_cpus;
> int has_idle_cores;
> + /*
> +* Span of all idle CPUs in this domain.
> +*
> +* NOTE: this field is variable length. (Allocated dynamically
> +* by attaching extra space to the end of the structure,
> +* depending on how many CPUs the kernel has booted up with)
> +*/
> + unsigned long idle_cpus_span[];
> };
>
> +static inline struct cpumask *sds_idle_cpus(struct sched_domain_shared *sds)
> +{
> + return to_cpumask(sds->idle_cpus_span);
> +}
> +
> struct sched_domain {
> /* These fields must be setup */
> struct sched_domain __rcu *parent; /* top domain must be null
> terminated */
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6b3b59cc51d6..088d1995594f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6023,6 +6023,38 @@ void __update_idle_core(struct rq *rq)
> rcu_read_unlock();
> }
>
> +static DEFINE_PER_CPU(bool, cpu_idle_state);
> +/*
> + * Update cpu idle state and record this information
> + * in sd_llc_shared->idle_cpus_span.
> + */
> +void update_idle_cpumask(struct rq *rq, bool idle_state)
> +{
> + struct sched_domain *sd;
> + int cpu = cpu_of(rq);
> +
> + /*
> +* No need to update idle cpumask if the state
> +* does not change.
> +*/
> + if (per_cpu(cpu_idle_state, cpu) == idle_state)
> + return;
> +
> + per_cpu(cpu_idle_state, cpu) = idle_state;
> +
> + rcu_read_lock();
> +
> + sd = rcu_dereference(per_cpu(sd_llc, cpu));
> + if (!sd || !sd->shared)
> + goto unlock;
> + if (idle_state)
> + cpumask_set_cpu(cpu, sds_idle_cpus(sd->shared));
> + else
> + cpumask_clear_cpu(cpu, sds_idle_cpus(sd->shared));
> +unlock:
> + rcu_read_unlock();
> +}
> +
> /*
> * Scan the entire LLC domain for idle cores; this dynamically switches off
> if
> * there are no idle cores left in the system; tracked through
> @@ -6136,7 +6168,12 @@ static int select_idle_cpu(struct task_struct *p,
> struct sched_domain *sd, int t
>
> time = cpu_clock(this);
>
> - cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> + /*
> +* sched_domain_shared is set only at shared cache level,
> +* this works only because select_idle_cpu is called with
> +* sd_llc.
> +*/
> + cpumask_and(cpus, sds_idle_cpus(sd->shared), p->cpus_ptr);
>
> for_each_cpu_wrap(cpu, cpus, target) {
> if (!--nr)
> @@ -10070,6 +10107,12 @@ static void nohz_balancer_kick(struct rq *rq)
> if (unlikely(rq->idle_balance))
> return;
>
> + /* The CPU is not in idle, update idle cpumask */
> + if (unlikely(sched_idle_cpu(cpu))) {
> + /* Allow SCHED_IDLE cpu as a wakeup target */
> + update_idle_cpumask(rq, true);
> + } else
> + update_idle_cpumask(rq, false);
update_idle_cpumask(rq, sched_idle_cpu(cpu)); ?
> /*
> * We may be recently in ticked or tickless idle mode. At the first
> * busy tick after returning from idle, we will update the busy stats.
> diff --git
Re: [PATCH v3 2/6] mm/migrate: move migrate_vma_collect_skip()
Looks good: Reviewed-by: Christoph Hellwig
[PATCH] net/ethernet: update ret when ptp_clock is ERROR
We always have to update the value of ret, otherwise the
error value may be the previous one.
Signed-off-by: Wang Qing
---
drivers/net/ethernet/ti/am65-cpts.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/am65-cpts.c
b/drivers/net/ethernet/ti/am65-cpts.c
index 75056c1..b77ff61
--- a/drivers/net/ethernet/ti/am65-cpts.c
+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -1001,8 +1001,7 @@ struct am65_cpts *am65_cpts_create(struct device *dev,
void __iomem *regs,
if (IS_ERR_OR_NULL(cpts->ptp_clock)) {
dev_err(dev, "Failed to register ptp clk %ld\n",
PTR_ERR(cpts->ptp_clock));
- if (!cpts->ptp_clock)
- ret = -ENODEV;
+ ret = cpts->ptp_clock ? cpts->ptp_clock : (-ENODEV);
goto refclk_disable;
}
cpts->phc_index = ptp_clock_index(cpts->ptp_clock);
--
2.7.4
Re: [PATCH v3 1/6] mm/thp: add prep_transhuge_device_private_page()
On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote:
> +extern void prep_transhuge_device_private_page(struct page *page);
No need for the extern.
> +static inline void prep_transhuge_device_private_page(struct page *page)
> +{
> +}
Is the code to call this even reachable if THP support is configured
out? If not just declaring it unconditionally and letting dead code
elimination do its job might be a tad cleaner.
> +void prep_transhuge_device_private_page(struct page *page)
I think a kerneldoc comment explaining what this function is useful for
would be helpful.
Re: [PATCH v3 2/6] mm/migrate: move migrate_vma_collect_skip()
On Thu, Nov 05, 2020 at 04:51:43PM -0800, Ralph Campbell wrote: > Move the definition of migrate_vma_collect_skip() to make it callable > by migrate_vma_collect_hole(). This helps make the next patch easier > to read. > > Signed-off-by: Ralph Campbell Looks good, Reviewed-by: Christoph Hellwig
[PATCH] RISC-V: Add missing jump label initialization
The jump_label_init() should be called from setup_arch() very
early for proper functioning of jump label support.
Fixes: ebc00dde8a97 ("riscv: Add jump-label implementation")
Cc: sta...@vger.kernel.org
Signed-off-by: Anup Patel
---
arch/riscv/kernel/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index c424cc6dd833..117f3212a8e4 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -75,6 +75,7 @@ void __init setup_arch(char **cmdline_p)
*cmdline_p = boot_command_line;
early_ioremap_setup();
+ jump_label_init();
parse_early_param();
efi_init();
--
2.25.1
Re: [PATCH 0/2] Adding I2C support to RX6110 RTC
Hi Alex, On 2020-11-05 23:14, Alexandre Belloni wrote: Hello Claudius! It has been a while ;) yeah, lots of downstream stuff for me :/ On 04/11/2020 11:26:27+0100, Claudius Heine wrote: Hi, this patch introduces I2C support to the RX6110 RTC driver and also adds an ACPI identifier to it. Since we are also pushing the coreboot changes for the ACPI table upstream in parallel, we are free to name this ACPI entry however we like it seems. So any feedback on that would be welcome ;) I don't care too much about ACPI so if you are really looking for advice there, I guess you should ask seom of the ACPI guys (but I guess you are free to choose whatever you want). As Henning said, we are also getting feedback from the coreboot people. See you hopefully soon again, when all this sitting at home is over. regards, Claudius
Re: [PATCH v1 15/18] of: property: Update implementation of add_links() to create fwnode links
On Thu, Nov 05, 2020 at 11:41:20PM -0800, Saravana Kannan wrote:
> On Thu, Nov 5, 2020 at 11:22 PM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Nov 05, 2020 at 03:25:56PM -0800, Saravana Kannan wrote:
> > > On Thu, Nov 5, 2020 at 1:41 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Wed, Nov 04, 2020 at 03:23:52PM -0800, Saravana Kannan wrote:
> > > > > The semantics of add_links() has changed from creating device link
> > > > > between devices to creating fwnode links between fwnodes. So, update
> > > > > the
> > > > > implementation of add_links() to match the new semantics.
> > > > >
> > > > > Signed-off-by: Saravana Kannan
> > > > > ---
> > > > > drivers/of/property.c | 150
> > > > > --
> > > > > 1 file changed, 41 insertions(+), 109 deletions(-)
> > > > >
> > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > index 408a7b5f06a9..86303803f1b3 100644
> > > > > --- a/drivers/of/property.c
> > > > > +++ b/drivers/of/property.c
> > > > > @@ -1038,33 +1038,9 @@ static bool of_is_ancestor_of(struct
> > > > > device_node *test_ancestor,
> > > > > }
> > > > >
> > > > > /**
> > > > > - * of_get_next_parent_dev - Add device link to supplier from
> > > > > supplier phandle
> > > > > - * @np: device tree node
> > > > > - *
> > > > > - * Given a device tree node (@np), this function finds its closest
> > > > > ancestor
> > > > > - * device tree node that has a corresponding struct device.
> > > > > - *
> > > > > - * The caller of this function is expected to call put_device() on
> > > > > the returned
> > > > > - * device when they are done.
> > > > > - */
> > > > > -static struct device *of_get_next_parent_dev(struct device_node *np)
> > > > > -{
> > > > > - struct device *dev = NULL;
> > > > > -
> > > > > - of_node_get(np);
> > > > > - do {
> > > > > - np = of_get_next_parent(np);
> > > > > - if (np)
> > > > > - dev = get_dev_from_fwnode(>fwnode);
> > > > > - } while (np && !dev);
> > > > > - of_node_put(np);
> > > > > - return dev;
> > > > > -}
> > > > > -
> > > > > -/**
> > > > > - * of_link_to_phandle - Add device link to supplier from supplier
> > > > > phandle
> > > > > - * @dev: consumer device
> > > > > - * @sup_np: phandle to supplier device tree node
> > > > > + * of_link_to_phandle - Add fwnode link to supplier from supplier
> > > > > phandle
> > > > > + * @con_np: consumer device tree node
> > > > > + * @sup_np: supplier device tree node
> > > > > *
> > > > > * Given a phandle to a supplier device tree node (@sup_np), this
> > > > > function
> > > > > * finds the device that owns the supplier device tree node and
> > > > > creates a
> > > > > @@ -1074,16 +1050,14 @@ static struct device
> > > > > *of_get_next_parent_dev(struct device_node *np)
> > > > > * cases, it returns an error.
> > > > > *
> > > > > * Returns:
> > > > > - * - 0 if link successfully created to supplier
> > > > > - * - -EAGAIN if linking to the supplier should be reattempted
> > > > > + * - 0 if fwnode link successfully created to supplier
> > > > > * - -EINVAL if the supplier link is invalid and should not be
> > > > > created
> > > > > - * - -ENODEV if there is no device that corresponds to the supplier
> > > > > phandle
> > > > > + * - -ENODEV if struct device will never be create for supplier
> > > > > */
> > > > > -static int of_link_to_phandle(struct device *dev, struct device_node
> > > > > *sup_np,
> > > > > - u32 dl_flags)
> > > > > +static int of_link_to_phandle(struct device_node *con_np,
> > > > > + struct device_node *sup_np)
> > > > > {
> > > > > - struct device *sup_dev, *sup_par_dev;
> > > > > - int ret = 0;
> > > > > + struct device *sup_dev;
> > > > > struct device_node *tmp_np = sup_np;
> > > > >
> > > > > of_node_get(sup_np);
> > > > > @@ -1106,7 +1080,8 @@ static int of_link_to_phandle(struct device
> > > > > *dev, struct device_node *sup_np,
> > > > > }
> > > > >
> > > > > if (!sup_np) {
> > > > > - dev_dbg(dev, "Not linking to %pOFP - No device\n",
> > > > > tmp_np);
> > > > > + pr_debug("Not linking %pOFP to %pOFP - No device\n",
> > > > > + con_np, tmp_np);
> > > >
> > > > Who is calling this function without a valid dev pointer?
> > >
> > > Sorry, I plan to delete the "dev" parameter as it's not really used
> > > anywhere. I'm trying to do that without causing build time errors and
> > > making the series into digestible small patches.
> > >
> > > I can do the deletion of the parameter as a Patch 19/19. Will that work?
> >
> > That's fine, but why get rid of dev? The driver core works on these
> > things, and we want errors/messages/warnings to spit out what device is
> > causing those issues. It is fine to drag around a struct device pointer
> > just for messages, that's to be expected, and is good.
Re: [PATCH v21 18/19] mm/lru: introduce the relock_page_lruvec function
在 2020/11/5 下午4:55, Alex Shi 写道:
> From: Alexander Duyck
update the patch on page_memcg() change:
>From 6c142eb582e7d0dbf473572ad092eca07ab75221 Mon Sep 17 00:00:00 2001
From: Alexander Duyck
Date: Tue, 26 May 2020 17:31:15 +0800
Subject: [PATCH v21 18/19] mm/lru: introduce the relock_page_lruvec function
Use this new function to replace repeated same code, no func change.
When testing for relock we can avoid the need for RCU locking if we simply
compare the page pgdat and memcg pointers versus those that the lruvec is
holding. By doing this we can avoid the extra pointer walks and accesses of
the memory cgroup.
In addition we can avoid the checks entirely if lruvec is currently NULL.
Signed-off-by: Alexander Duyck
Signed-off-by: Alex Shi
Acked-by: Hugh Dickins
Acked-by: Johannes Weiner
Cc: Johannes Weiner
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Andrey Ryabinin
Cc: Matthew Wilcox
Cc: Mel Gorman
Cc: Konstantin Khlebnikov
Cc: Hugh Dickins
Cc: Tejun Heo
Cc: linux-kernel@vger.kernel.org
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
---
include/linux/memcontrol.h | 52 ++
mm/mlock.c | 11 +-
mm/swap.c | 33 +++--
mm/vmscan.c| 12 ++-
4 files changed, 62 insertions(+), 46 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 6ecb08ff4ad1..8c57d6335ee4 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -660,6 +660,22 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
mem_cgroup *memcg,
struct lruvec *mem_cgroup_page_lruvec(struct page *, struct pglist_data *);
+static inline bool lruvec_holds_page_lru_lock(struct page *page,
+ struct lruvec *lruvec)
+{
+ pg_data_t *pgdat = page_pgdat(page);
+ const struct mem_cgroup *memcg;
+ struct mem_cgroup_per_node *mz;
+
+ if (mem_cgroup_disabled())
+ return lruvec == >__lruvec;
+
+ mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
+ memcg = page_memcg(page) ? : root_mem_cgroup;
+
+ return lruvec->pgdat == pgdat && mz->memcg == memcg;
+}
+
struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm);
@@ -1221,6 +1237,14 @@ static inline struct lruvec
*mem_cgroup_page_lruvec(struct page *page,
return >__lruvec;
}
+static inline bool lruvec_holds_page_lru_lock(struct page *page,
+ struct lruvec *lruvec)
+{
+ pg_data_t *pgdat = page_pgdat(page);
+
+ return lruvec == >__lruvec;
+}
+
static inline struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *memcg)
{
return NULL;
@@ -1663,6 +1687,34 @@ static inline void unlock_page_lruvec_irqrestore(struct
lruvec *lruvec,
spin_unlock_irqrestore(>lru_lock, flags);
}
+/* Don't lock again iff page's lruvec locked */
+static inline struct lruvec *relock_page_lruvec_irq(struct page *page,
+ struct lruvec *locked_lruvec)
+{
+ if (locked_lruvec) {
+ if (lruvec_holds_page_lru_lock(page, locked_lruvec))
+ return locked_lruvec;
+
+ unlock_page_lruvec_irq(locked_lruvec);
+ }
+
+ return lock_page_lruvec_irq(page);
+}
+
+/* Don't lock again iff page's lruvec locked */
+static inline struct lruvec *relock_page_lruvec_irqsave(struct page *page,
+ struct lruvec *locked_lruvec, unsigned long *flags)
+{
+ if (locked_lruvec) {
+ if (lruvec_holds_page_lru_lock(page, locked_lruvec))
+ return locked_lruvec;
+
+ unlock_page_lruvec_irqrestore(locked_lruvec, *flags);
+ }
+
+ return lock_page_lruvec_irqsave(page, flags);
+}
+
#ifdef CONFIG_CGROUP_WRITEBACK
struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb);
diff --git a/mm/mlock.c b/mm/mlock.c
index ab164a675c25..55b3b3672977 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -277,16 +277,7 @@ static void __munlock_pagevec(struct pagevec *pvec, struct
zone *zone)
* so we can spare the get_page() here.
*/
if (TestClearPageLRU(page)) {
- struct lruvec *new_lruvec;
-
- new_lruvec = mem_cgroup_page_lruvec(page,
- page_pgdat(page));
- if (new_lruvec != lruvec) {
- if (lruvec)
- unlock_page_lruvec_irq(lruvec);
- lruvec = lock_page_lruvec_irq(page);
- }
-
+ lruvec = relock_page_lruvec_irq(page, lruvec);
[PATCH] net: usb: fix spelling typo in cdc_ncm.c
Actually, withing should be within.
Signed-off-by: Wang Qing
---
drivers/net/usb/cdc_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index e04f588..746353c
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1317,7 +1317,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff
*skb, __le32 sign)
break;
}
- /* calculate frame number withing this NDP */
+ /* calculate frame number within this NDP */
if (ctx->is_ndp16) {
ndplen = le16_to_cpu(ndp.ndp16->wLength);
index = (ndplen - sizeof(struct usb_cdc_ncm_ndp16)) /
sizeof(struct usb_cdc_ncm_dpe16) - 1;
--
2.7.4
RE: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver
Hi C, Thanks for your reply. > -Original Message- > From: Cédric Le Goater > Sent: Thursday, November 5, 2020 10:09 PM > To: Chin-Ting Kuo ; broo...@kernel.org; > robh...@kernel.org; j...@jms.id.au; and...@aj.id.au; bbrezil...@kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-asp...@lists.ozlabs.org; linux-...@vger.kernel.org > Cc: BMC-SW > Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller > driver > > Hello Chin-Ting, > > Thanks for this driver. It's much cleaner than the previous and we should try > adding support for the AST2500 SoC also. I guess we can keep the old driver > for the AST2400 which has a different register layout. > I will also add AST2500 part into next patch version. > On the patchset, I think we should split this patch in three : > > - basic support > - AHB window calculation depending on the flash size > - read training support Oaky, it is more clear. > We should avoid magic values when setting registers. This is confusing and > defines are much better. Okay, it will be modified at next patch. > AST2500 support will be a bit challenging because HW does not allow > to configure a 128MB AHB window, max is 120MB This is a bug and the work > around is to use user mode for the remaining 8MB. Something to keep in > mind. This is why there is a "min_decode_sz" element in "aspeed_spi_info" struct. Thanks for your reminder. Some replies for the comments below. > I gave it a try on QEMU. It looks good. When I can revive my EVB, I will do > the > same. > > More comments below, > > Thanks, > > C. > > > On 11/5/20 1:03 PM, Chin-Ting Kuo wrote: > > Add driver for ASPEED BMC FMC/SPI memory controller which supports > > spi-mem interface. > > > > There are three SPI memory controllers embedded in an ASPEED SoC. > > Each of them can connect to two or three SPI NOR flashes. The first > > SPI memory controller is also named as Firmware Memory Controller > > (FMC), which is similar to SPI memory controller. After device AC on, > > MCU ROM can fetch device boot code from FMC CS 0. Thus, there exists > > additional registers for boot process control in FMC. > > > > ASPEED SPI memory controller supports single, dual and quad mode for > > SPI NOR flash. It also supports two types of command mode, user mode > > and command read/write mode. User mode is traditional pure SPI > > operations where all transmission is controlled by CPU. Contrarily, > > with command read/write mode, SPI controller can send command and > > address automatically when CPU read/write related remapped address. > > > > Besides, different wafer processes of SPI NOR flash result in > > different signal response time. This phenomenon will be enlarged when > > SPI clock frequency increases. ASPEED SPI memory controller provides a > > mechanism for timing compensation in order to satisfy various SPI NOR > > flash parts and PCB layout. > > > > Signed-off-by: Chin-Ting Kuo > > --- > > v2: Fix sparse warnings reported by kernel test robot . > > v3: Fix build warnings with x86 allmodconfig. > > > > drivers/spi/Kconfig | 10 + > > drivers/spi/Makefile | 1 + > > drivers/spi/spi-aspeed.c | 969 > > +++ > > 3 files changed, 980 insertions(+) > > create mode 100644 drivers/spi/spi-aspeed.c > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index > > 5cff60de8e83..c848f2f7b694 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -70,6 +70,16 @@ config SPI_AR934X > > This enables support for the SPI controller present on the > > Qualcomm Atheros AR934X/QCA95XX SoCs. > > > > +config SPI_ASPEED > > + tristate "ASPEED FMC/SPI Memory Controller" > > + depends on OF && HAS_IOMEM && (ARCH_ASPEED || COMPILE_TEST) > > We will need to do something about the other driver. For the moment, we can > select both but that won't be the case anymore when we add > AST2500 support. > Yes, maybe, "!SPI_ASPEED_SMC" should be added and also add "!SPI_ASPEED" for the other driver. Thanks for reminder. > > + help > > + Enable driver for ASPEED FMC/SPI Memory Controller. > > + > > + This driver is not a generic pure SPI driver, which > > + is especially designed for spi-mem framework with > > + SPI NOR flash direct read and write features. > > + > > config SPI_ATH79 > > tristate "Atheros AR71XX/AR724X/AR913X SPI controller driver" > > depends on ATH79 || COMPILE_TEST > > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index > > 6fea5821662e..9e62c650fca0 100644 > > --- a/drivers/spi/Makefile > > +++ b/drivers/spi/Makefile > > @@ -17,6 +17,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST) += > spi-loopback-test.o > > obj-$(CONFIG_SPI_ALTERA) += spi-altera.o > > obj-$(CONFIG_SPI_AR934X) += spi-ar934x.o > > obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o > > +obj-$(CONFIG_SPI_ASPEED) += spi-aspeed.o > >
Re:Re: [PATCH] usb: Assign NULL to phy that may be returned
>> Assign initial values to local variables that may be returned
>>
>> Signed-off-by: Wang Qing
>
>Your subject, and body of text, seem to have 2 "odd" characters in it,
>please fix up.
>
>Also, your subject and changelog body here are identical, please be much
>more verbose in the body explaining why you are doing something, not
>just what you are doing.
>
>And your subject line should also match other patches for this file, and
>have "usb: phy: ..." in the beginning.
Yeah, I got it.
>
>> ---
>> drivers/usb/phy/phy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
>> index b47285f..de21967
>> --- a/drivers/usb/phy/phy.c
>> +++ b/drivers/usb/phy/phy.c
>> @@ -59,7 +59,7 @@ static struct usb_phy *__usb_find_phy(struct list_head
>> *list,
>>
>> static struct usb_phy *__of_usb_find_phy(struct device_node *node)
>> {
>> -struct usb_phy *phy;
>> +struct usb_phy *phy = NULL;
>
>Why isn't the compiler complaining about this today? Are you sure this
>is needed?
Sorry, I didn't look at it carefully, because __usb_find_phy has an initial
value,
and I was affected.. You don't need to modify it, In fact.
thanks,
Wang Qing
>
>thanks,
>
>greg k-h
Re: [PATCH v21 17/19] mm/lru: replace pgdat lru_lock with lruvec lock
在 2020/11/5 下午9:43, Alex Shi 写道:
>
> 在 2020/11/5 下午4:55, Alex Shi 写道:
>> /**
>> + * lock_page_lruvec - lock and return lruvec for a given page.
>> + * @page: the page
>> + *
>> + * This series functions should be used in either conditions:
>> + * PageLRU is cleared or unset
>> + * or page is locked.
> or page->_refcount is zero.
> Ops, here is a typo, we need to add back above line.
> so the patch updated here:
Sorry for aother miss, linux-next removed the page.mem_cgroup,
replace it to memcg_data and get by page_memcg(). Hence this and next
patch needs update for this:
>From 84e69f892119d99612e9668e3fe47a3922bafff1 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Tue, 18 Aug 2020 16:44:21 +0800
Subject: [PATCH v21 17/19] mm/lru: replace pgdat lru_lock with lruvec lock
This patch moves per node lru_lock into lruvec, thus bring a lru_lock for
each of memcg per node. So on a large machine, each of memcg don't
have to suffer from per node pgdat->lru_lock competition. They could go
fast with their self lru_lock.
After move memcg charge before lru inserting, page isolation could
serialize page's memcg, then per memcg lruvec lock is stable and could
replace per node lru lock.
In func isolate_migratepages_block, compact_unlock_should_abort and
lock_page_lruvec_irqsave are open coded to work with compact_control.
Also add a debug func in locking which may give some clues if there are
sth out of hands.
Daniel Jordan's testing show 62% improvement on modified readtwice case
on his 2P * 10 core * 2 HT broadwell box.
https://lore.kernel.org/lkml/20200915165807.kpp7uhiw7l3lo...@ca-dmjordan1.us.oracle.com/
On a large machine with memcg enabled but not used, the page's lruvec
seeking pass a few pointers, that may lead to lru_lock holding time
increase and a bit regression.
Hugh Dickins helped on the patch polish, thanks!
Signed-off-by: Alex Shi
Acked-by: Hugh Dickins
Cc: Rong Chen
Cc: Hugh Dickins
Cc: Andrew Morton
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Yang Shi
Cc: Matthew Wilcox
Cc: Konstantin Khlebnikov
Cc: Tejun Heo
Cc: linux-kernel@vger.kernel.org
Cc: linux...@kvack.org
Cc: cgro...@vger.kernel.org
---
include/linux/memcontrol.h | 58 +++
include/linux/mmzone.h | 3 +-
mm/compaction.c| 56 ++
mm/huge_memory.c | 11 ++---
mm/memcontrol.c| 78 --
mm/mlock.c | 22 ++---
mm/mmzone.c| 1 +
mm/page_alloc.c| 1 -
mm/swap.c | 116 ++---
mm/vmscan.c| 55 ++---
10 files changed, 275 insertions(+), 126 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 0f4dd7829fb2..6ecb08ff4ad1 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -666,6 +666,19 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
mem_cgroup *memcg,
struct mem_cgroup *get_mem_cgroup_from_page(struct page *page);
+struct lruvec *lock_page_lruvec(struct page *page);
+struct lruvec *lock_page_lruvec_irq(struct page *page);
+struct lruvec *lock_page_lruvec_irqsave(struct page *page,
+ unsigned long *flags);
+
+#ifdef CONFIG_DEBUG_VM
+void lruvec_memcg_debug(struct lruvec *lruvec, struct page *page);
+#else
+static inline void lruvec_memcg_debug(struct lruvec *lruvec, struct page *page)
+{
+}
+#endif
+
static inline
struct mem_cgroup *mem_cgroup_from_css(struct cgroup_subsys_state *css){
return css ? container_of(css, struct mem_cgroup, css) : NULL;
@@ -1233,6 +1246,31 @@ static inline void mem_cgroup_put(struct mem_cgroup
*memcg)
{
}
+static inline struct lruvec *lock_page_lruvec(struct page *page)
+{
+ struct pglist_data *pgdat = page_pgdat(page);
+
+ spin_lock(>__lruvec.lru_lock);
+ return >__lruvec;
+}
+
+static inline struct lruvec *lock_page_lruvec_irq(struct page *page)
+{
+ struct pglist_data *pgdat = page_pgdat(page);
+
+ spin_lock_irq(>__lruvec.lru_lock);
+ return >__lruvec;
+}
+
+static inline struct lruvec *lock_page_lruvec_irqsave(struct page *page,
+ unsigned long *flagsp)
+{
+ struct pglist_data *pgdat = page_pgdat(page);
+
+ spin_lock_irqsave(>__lruvec.lru_lock, *flagsp);
+ return >__lruvec;
+}
+
static inline struct mem_cgroup *
mem_cgroup_iter(struct mem_cgroup *root,
struct mem_cgroup *prev,
@@ -1476,6 +1514,10 @@ static inline void count_memcg_page_event(struct page
*page,
void count_memcg_event_mm(struct mm_struct *mm, enum vm_event_item idx)
{
}
+
+static inline void lruvec_memcg_debug(struct lruvec *lruvec, struct page *page)
+{
+}
#endif /* CONFIG_MEMCG */
/* idx can be of type enum memcg_stat_item or node_stat_item */
@@ -1605,6 +1647,22 @@ static inline struct lruvec *parent_lruvec(struct lruvec
*lruvec)
Re: [PATCH 4/7] devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
On 06-11-20, 16:48, Chanwoo Choi wrote: > On 11/6/20 4:46 PM, Chanwoo Choi wrote: > > It seems that this patch depends on first patch. > > So, need to be merged to one git repository. > > > > Instead of applying it to devfreq.git, > > Acked-by: Chanwoo Choi > > > > Also, need to add 'PM /' prefix to patch title > in order to keep the same format with already merged devfreq patches. > - 'PM / devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument' Done, thanks. -- viresh
Re: [PATCH 10/20] input: mouse: synaptics: Place braces around empty if() body
On Thu, 2020-11-05 at 23:26 -0800, Dmitry Torokhov wrote:
> On Wed, Nov 04, 2020 at 04:24:17PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/input/mouse/synaptics.c: In function ‘synaptics_process_packet’:
> > drivers/input/mouse/synaptics.c:1110:6: warning: suggest braces around
> > empty body in an ‘if’ statement [-Wempty-body]
[]
> > diff --git a/drivers/input/mouse/synaptics.c
> > b/drivers/input/mouse/synaptics.c
[]
> > @@ -1106,8 +1106,9 @@ static void synaptics_process_packet(struct psmouse
> > *psmouse)
> > num_fingers = hw.w + 2;
> > break;
> > case 2:
> > - if (SYN_MODEL_PEN(info->model_id))
> > + if (SYN_MODEL_PEN(info->model_id)) {
> > ; /* Nothing, treat a pen as a single
> > finger */
> > + }
>
> This gives me:
>
> WARNING: braces {} are not necessary for single statement blocks
>
> from checkpatch.
As the entire case 2 is effectively a noop, why not just comment it better
and remove the if (SYN_MODEL_PEN(...)) test altogether.
Re: [PATCH] riscv: uaccess: fix __put_kernel_nofault()
On Sun, 01 Nov 2020 23:30:52 PST (-0800), changbin...@gmail.com wrote:
The copy_from_kernel_nofault() is broken on riscv because the 'dst' and
'src' are mistakenly reversed in __put_kernel_nofault() macro.
copy_to_kernel_nofault:
...
0xffe0003159b8 <+30>:sd a4,0(a1) # a1 aka 'src'
Fixes: d464118cdc ("riscv: implement __get_kernel_nofault and
__put_user_nofault")
Signed-off-by: Changbin Du
Cc: Christoph Hellwig
---
arch/riscv/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h
index c47e6b35c551..824b2c9da75b 100644
--- a/arch/riscv/include/asm/uaccess.h
+++ b/arch/riscv/include/asm/uaccess.h
@@ -476,7 +476,7 @@ do {
\
do { \
long __kr_err; \
\
- __put_user_nocheck(*((type *)(dst)), (type *)(src), __kr_err); \
+ __put_user_nocheck(*((type *)(src)), (type *)(dst), __kr_err); \
if (unlikely(__kr_err)) \
goto err_label; \
} while (0)
Thanks, this is on fixes.
Re: [PATCH] thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
On 05-11-20, 19:19, zhuguangqin...@gmail.com wrote:
> From: zhuguangqing
Maybe fix your name in your email client or git config? It should be
Zhuguangqing (with first letter in CAPITAL) and maybe add a second
name also (surname) in case you want/have it.
> If state has not changed successfully and we updated cpufreq_state,
> next time when the new state is equal to cpufreq_state (not changed
> successfully last time), we will return directly and miss a
> freq_qos_update_request() that should have been.
>
> Signed-off-by: zhuguangqing
Please find and add below details as well, they are helpful in fixing
the stable kernels.
Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq
limits")
Cc: v5.4+ # v5.4+
> ---
> drivers/thermal/cpufreq_cooling.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/cpufreq_cooling.c
> b/drivers/thermal/cpufreq_cooling.c
> index cc2959f22f01..00dc26c33899 100644
> --- a/drivers/thermal/cpufreq_cooling.c
> +++ b/drivers/thermal/cpufreq_cooling.c
> @@ -438,13 +438,12 @@ static int cpufreq_set_cur_state(struct
> thermal_cooling_device *cdev,
> if (cpufreq_cdev->cpufreq_state == state)
> return 0;
>
> - cpufreq_cdev->cpufreq_state = state;
> -
> frequency = get_state_freq(cpufreq_cdev, state);
>
> ret = freq_qos_update_request(_cdev->qos_req, frequency);
>
Now that you are going to resend it anyways, drop this blank line as
well and mention that in the commit log.
> if (ret > 0) {
> + cpufreq_cdev->cpufreq_state = state;
> cpus = cpufreq_cdev->policy->cpus;
> max_capacity = arch_scale_cpu_capacity(cpumask_first(cpus));
> capacity = frequency * max_capacity;
Good catch Zhuguangqing. Thanks.
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH v1 17/18] driver core: Add helper functions to convert fwnode links to device links
On Thu, Nov 5, 2020 at 11:23 PM Greg Kroah-Hartman wrote: > > On Thu, Nov 05, 2020 at 03:32:05PM -0800, Saravana Kannan wrote: > > On Thu, Nov 5, 2020 at 1:43 AM Greg Kroah-Hartman > > wrote: > > > > > > On Wed, Nov 04, 2020 at 03:23:54PM -0800, Saravana Kannan wrote: > > > > Add helper functions __fw_devlink_link_to_consumers() and > > > > __fw_devlink_link_to_suppliers() that convert fwnode links to device > > > > links. > > > > > > > > __fw_devlink_link_to_consumers() is for creating: > > > > - Device links between a newly added device and all its consumer devices > > > > that have been added to driver core. > > > > - Proxy SYNC_STATE_ONLY device links between the newly added device and > > > > the parent devices of all its consumers that have not been added to > > > > driver core yet. > > > > > > > > __fw_devlink_link_to_suppliers() is for creating: > > > > - Device links between a newly added device and all its supplier devices > > > > - Proxy SYNC_STATE_ONLY device links between the newly added device and > > > > all the supplier devices of its child device nodes. > > > > > > > > Signed-off-by: Saravana Kannan > > > > > > Did you just add build warnings with these static functions that no one > > > calls? > > > > The next patch in this series uses it. I'm just splitting it up into a > > separate patch so that it's digestible and I can provide more details > > in the commit text. > > But you can not add build warnings, you know this :) I know I can't break the build because that'll screw git bisect. But I thought warning that's fixed later in the series might be okay if it helps readability. I know now :) > > > Couple of options: > > 1. Drop the static in this patch and add it back when it's used in patch > > 18/18. > > 2. Drop the commit text and squash this with 18/18 if you think the > > function documentation is clear enough and it won't make patch 18/18 > > too hard to review. > > It is hard to review new functions when you do not see them being used, > otherwise you have to flip back and forth between patches, which is > difficult. > > Add the functions, and use them, in the same patch. Otherwise we have > no idea _HOW_ you are using them, or even if you end up using them at > all. Sounds good. I'll squash them. -Saravana
Re: [RFC PATCH 0/2] mm: fix OOMs for binding workloads to movable zone only node
On Fri 06-11-20 12:32:44, Huang, Ying wrote: > Michal Hocko writes: > > > On Thu 05-11-20 09:40:28, Feng Tang wrote: > >> On Wed, Nov 04, 2020 at 09:53:43AM +0100, Michal Hocko wrote: > >> > >> > > > As I've said in reply to your second patch. I think we can make the > >> > > > oom > >> > > > killer behavior more sensible in this misconfigured cases but I do > >> > > > not > >> > > > think we want break the cpuset isolation for such a configuration. > >> > > > >> > > Do you mean we skip the killing and just let the allocation fail? We've > >> > > checked the oom killer code first, when the oom happens, both DRAM > >> > > node and unmovable node have lots of free memory, and killing process > >> > > won't improve the situation. > >> > > >> > We already do skip oom killer and fail for lowmem allocation requests > >> > already. > >> > This is similar in some sense. Another option would be to kill the > >> > allocating context which will have less corner cases potentially because > >> > some allocation failures might be unexpected. > >> > >> Yes, this can avoid the helpless oom killing to kill a good process(no > >> memory pressure at all) > >> > >> And I think the important thing is to judge whether this usage (binding > >> docker like workload to unmovable node) is a valid case :) > > > > I am confused. Why wouldbe an unmovable node a problem. Movable > > allocations can be satisfied from the Zone Normal just fine. It is other > > way around that is a problem. > > > >> Initially, I thought it invalid too, but later think it still makes some > >> sense for the 2 cases: > >> * user want to bind his workload to one node(most of user space > >> memory) to avoid cross-node traffic, and that node happens to > >> be configured as unmovable > > > > See above > > > >> * one small DRAM node + big PMEM node, and memory latency insensitive > >> workload could be bound to the cheaper unmovable PMEM node > > > > Please elaborate some more. As long as you have movable and normal nodes > > then this should be possible with a deal of care - most notably the > > movable:kernel ratio memory shouldn't be too big. > > > > Besides that why does PMEM node have to be MOVABLE only in the first > > place? > > The performance of PMEM is much worse than that of DRAM. If we found > that some pages on PMEM are accessed frequently (hot), we may want to > move them to DRAM to optimize the system performance. If the unmovable > pages are allocated on PMEM and hot, it's possible that we cannot move > the pages to DRAM unless rebooting the system. So we think we should > make the PMEM nodes to be MOVABLE only. That is fair but then you really need a fallback node too. So this is mere optimization rather than a fundamental restriction. -- Michal Hocko SUSE Labs
Re: [PATCH 16/19] gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant kernel-doc header
On Thu, 05 Nov 2020, Sam Ravnborg wrote: > Hi Lee. > > On Thu, Nov 05, 2020 at 02:45:14PM +, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_SRGB_THROUGH' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_SRGB_ALIGNED' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_SRGB_DUMMY_320X240' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_SRGB_DUMMY_360X240' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_DISABLED_1' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_PRGB_THROUGH' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_PRGB_ALIGNED' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_YUV_640X320_YCBCR' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_YUV_720X360_YCBCR' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_DISABLED_2' not described in enum 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_ITU_R_BT656_720X360_YCBCR' not described in enum > > 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_ITU_R_BT656_640X320_YCBCR' not described in enum > > 'ili9322_input' > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value > > 'ILI9322_INPUT_UNKNOWN' not described in enum 'ili9322_input' > > > > Cc: Thierry Reding > > Cc: Sam Ravnborg > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Linus Walleij > > Cc: dri-de...@lists.freedesktop.org > > Signed-off-by: Lee Jones > > Applied to drm-misc-next. Thanks for all these Sam. Any idea what happens to the other patches? Do they go in via a different Maintainer? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1 15/18] of: property: Update implementation of add_links() to create fwnode links
On Thu, Nov 5, 2020 at 11:22 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Nov 05, 2020 at 03:25:56PM -0800, Saravana Kannan wrote:
> > On Thu, Nov 5, 2020 at 1:41 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Wed, Nov 04, 2020 at 03:23:52PM -0800, Saravana Kannan wrote:
> > > > The semantics of add_links() has changed from creating device link
> > > > between devices to creating fwnode links between fwnodes. So, update the
> > > > implementation of add_links() to match the new semantics.
> > > >
> > > > Signed-off-by: Saravana Kannan
> > > > ---
> > > > drivers/of/property.c | 150 --
> > > > 1 file changed, 41 insertions(+), 109 deletions(-)
> > > >
> > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > index 408a7b5f06a9..86303803f1b3 100644
> > > > --- a/drivers/of/property.c
> > > > +++ b/drivers/of/property.c
> > > > @@ -1038,33 +1038,9 @@ static bool of_is_ancestor_of(struct device_node
> > > > *test_ancestor,
> > > > }
> > > >
> > > > /**
> > > > - * of_get_next_parent_dev - Add device link to supplier from supplier
> > > > phandle
> > > > - * @np: device tree node
> > > > - *
> > > > - * Given a device tree node (@np), this function finds its closest
> > > > ancestor
> > > > - * device tree node that has a corresponding struct device.
> > > > - *
> > > > - * The caller of this function is expected to call put_device() on the
> > > > returned
> > > > - * device when they are done.
> > > > - */
> > > > -static struct device *of_get_next_parent_dev(struct device_node *np)
> > > > -{
> > > > - struct device *dev = NULL;
> > > > -
> > > > - of_node_get(np);
> > > > - do {
> > > > - np = of_get_next_parent(np);
> > > > - if (np)
> > > > - dev = get_dev_from_fwnode(>fwnode);
> > > > - } while (np && !dev);
> > > > - of_node_put(np);
> > > > - return dev;
> > > > -}
> > > > -
> > > > -/**
> > > > - * of_link_to_phandle - Add device link to supplier from supplier
> > > > phandle
> > > > - * @dev: consumer device
> > > > - * @sup_np: phandle to supplier device tree node
> > > > + * of_link_to_phandle - Add fwnode link to supplier from supplier
> > > > phandle
> > > > + * @con_np: consumer device tree node
> > > > + * @sup_np: supplier device tree node
> > > > *
> > > > * Given a phandle to a supplier device tree node (@sup_np), this
> > > > function
> > > > * finds the device that owns the supplier device tree node and
> > > > creates a
> > > > @@ -1074,16 +1050,14 @@ static struct device
> > > > *of_get_next_parent_dev(struct device_node *np)
> > > > * cases, it returns an error.
> > > > *
> > > > * Returns:
> > > > - * - 0 if link successfully created to supplier
> > > > - * - -EAGAIN if linking to the supplier should be reattempted
> > > > + * - 0 if fwnode link successfully created to supplier
> > > > * - -EINVAL if the supplier link is invalid and should not be created
> > > > - * - -ENODEV if there is no device that corresponds to the supplier
> > > > phandle
> > > > + * - -ENODEV if struct device will never be create for supplier
> > > > */
> > > > -static int of_link_to_phandle(struct device *dev, struct device_node
> > > > *sup_np,
> > > > - u32 dl_flags)
> > > > +static int of_link_to_phandle(struct device_node *con_np,
> > > > + struct device_node *sup_np)
> > > > {
> > > > - struct device *sup_dev, *sup_par_dev;
> > > > - int ret = 0;
> > > > + struct device *sup_dev;
> > > > struct device_node *tmp_np = sup_np;
> > > >
> > > > of_node_get(sup_np);
> > > > @@ -1106,7 +1080,8 @@ static int of_link_to_phandle(struct device *dev,
> > > > struct device_node *sup_np,
> > > > }
> > > >
> > > > if (!sup_np) {
> > > > - dev_dbg(dev, "Not linking to %pOFP - No device\n",
> > > > tmp_np);
> > > > + pr_debug("Not linking %pOFP to %pOFP - No device\n",
> > > > + con_np, tmp_np);
> > >
> > > Who is calling this function without a valid dev pointer?
> >
> > Sorry, I plan to delete the "dev" parameter as it's not really used
> > anywhere. I'm trying to do that without causing build time errors and
> > making the series into digestible small patches.
> >
> > I can do the deletion of the parameter as a Patch 19/19. Will that work?
>
> That's fine, but why get rid of dev? The driver core works on these
> things, and we want errors/messages/warnings to spit out what device is
> causing those issues. It is fine to drag around a struct device pointer
> just for messages, that's to be expected, and is good.
In general I agree. If the fwnode being parsed is related to the dev,
it's nice to have the dev name in the logs.
But in this instance I feel it's analogous to printing the PID that's
parsing the fwnode -- kinda irrelevant. The device in question can
appear very random and it'll just cause more confusion than be of help
Re: [PATCH 03/19] gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused
On Thu, 05 Nov 2020, Ahmad Fatoum wrote:
> Hello Lee,
>
> On 11/5/20 3:45 PM, Lee Jones wrote:
> > In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
> > as a container for state->crtcs[i].new_state, but is not utilised in
> > this use-case. We cannot simply delete the variable, so here we tell
> > the compiler that we're intentionally discarding the read value.
>
> for_each_oldnew_crtc_in_state already (void) casts the drm_crtc and the old
> drm_crtc_state to silence unused-but-set-variable warning. Should we maybe
> (void) cast the new crtc_state as well?
>From what I saw, it only void casts the ones which aren't assigned.
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/imx/ipuv3-plane.c: In function ‘ipu_planes_assign_pre’:
> > drivers/gpu/drm/imx/ipuv3-plane.c:746:42: warning: variable ‘crtc_state’
> > set but not used [-Wunused-but-set-variable]
> >
> > Cc: Philipp Zabel
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Shawn Guo
> > Cc: Sascha Hauer
> > Cc: Pengutronix Kernel Team
> > Cc: Fabio Estevam
> > Cc: NXP Linux Team
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index 8a4235d9d9f1e..acc0a3ce4992f 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -743,7 +743,7 @@ bool ipu_plane_atomic_update_pending(struct drm_plane
> > *plane)
> > int ipu_planes_assign_pre(struct drm_device *dev,
> > struct drm_atomic_state *state)
> > {
> > - struct drm_crtc_state *old_crtc_state, *crtc_state;
> > + struct drm_crtc_state *old_crtc_state, __always_unused *crtc_state;
> > struct drm_plane_state *plane_state;
> > struct ipu_plane_state *ipu_state;
> > struct ipu_plane *ipu_plane;
> >
>
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: syscon: Add syscon_regmap_lookup_by_phandle_optional() function.
On 27/10/2020 22:11, Enric Balletbo i Serra wrote:
This adds syscon_regmap_lookup_by_phandle_optional() function to get an
optional regmap.
It behaves the same as syscon_regmap_lookup_by_phandle() except where
there is no regmap phandle. In this case, instead of returning -ENODEV,
the function returns NULL. This makes error checking simpler when the
regmap phandle is optional.
Suggested-by: Nicolas Boichat
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
---
drivers/mfd/syscon.c | 13 +
include/linux/mfd/syscon.h | 11 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca465794ea9c..60c5c2b194cc 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -255,6 +255,19 @@ struct regmap *syscon_regmap_lookup_by_phandle_args(struct
device_node *np,
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle_args);
+struct regmap *syscon_regmap_lookup_by_phandle_optional(struct device_node *np,
+ const char *property)
+{
+ struct regmap *regmap;
+
+ regmap = syscon_regmap_lookup_by_phandle(np, property);
+ if (IS_ERR(regmap) && PTR_ERR(regmap) == -ENODEV)
+ return NULL;
+
+ return regmap;
+}
+EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle_optional);
+
static int syscon_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 7f20e9b502a5..a1fe8aedced2 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -28,6 +28,9 @@ extern struct regmap *syscon_regmap_lookup_by_phandle_args(
const char *property,
int arg_count,
unsigned int *out_args);
+extern struct regmap *syscon_regmap_lookup_by_phandle_optional(
+ struct device_node *np,
+ const char *property);
#else
static inline struct regmap *device_node_to_regmap(struct device_node *np)
{
@@ -59,6 +62,14 @@ static inline struct regmap
*syscon_regmap_lookup_by_phandle_args(
{
return ERR_PTR(-ENOTSUPP);
}
+
+static inline struct regmap *syscon_regmap_lookup_by_phandle_optional(
+ struct device_node *np,
+ const char *property)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
#endif
#endif /* __LINUX_MFD_SYSCON_H__ */
[PATCH V2] selftests/cgroup: Fix build on older distros
On older distros struct clone_args does not have a cgroup member,
leading to build errors:
cgroup_util.c: In function 'clone_into_cgroup':
cgroup_util.c:343:4: error: 'struct clone_args' has no member named 'cgroup'
cgroup_util.c:346:33: error: invalid application of 'sizeof' to incomplete
type 'struct clone_args'
But the selftests already have a locally defined version of the
structure which is up to date, called __clone_args.
So use __clone_args which fixes the error.
Signed-off-by: Michael Ellerman
Signed-off-by: Sachin Sant >
Acked-by: Christian Brauner
---
V2: Replace all instances of clone_args by __clone_args
---
diff --git a/a/tools/testing/selftests/cgroup/cgroup_util.c
b/b/tools/testing/selftests/cgroup/cgroup_util.c
index 05853b0..0270146 100644
--- a/a/tools/testing/selftests/cgroup/cgroup_util.c
+++ b/b/tools/testing/selftests/cgroup/cgroup_util.c
@@ -337,13 +337,13 @@ pid_t clone_into_cgroup(int cgroup_fd)
#ifdef CLONE_ARGS_SIZE_VER2
pid_t pid;
- struct clone_args args = {
+ struct __clone_args args = {
.flags = CLONE_INTO_CGROUP,
.exit_signal = SIGCHLD,
.cgroup = cgroup_fd,
};
- pid = sys_clone3(, sizeof(struct clone_args));
+ pid = sys_clone3(, sizeof(struct __clone_args));
/*
* Verify that this is a genuine test failure:
* ENOSYS -> clone3() not available
Re: [PATCH 10/20] input: mouse: synaptics: Place braces around empty if() body
On Thu, 05 Nov 2020, Dmitry Torokhov wrote:
> Hi Lee,
>
> On Wed, Nov 04, 2020 at 04:24:17PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/input/mouse/synaptics.c: In function ‘synaptics_process_packet’:
> > drivers/input/mouse/synaptics.c:1110:6: warning: suggest braces around
> > empty body in an ‘if’ statement [-Wempty-body]
> >
> > Cc: Dmitry Torokhov
> > Cc: Henrik Rydberg
> > Cc: Peter Osterlund
> > Cc: Stefan Gmeiner
> > Cc: "C. Scott Ananian"
> > Cc: Bruce Kalk
> > Cc: this to
> > Cc: linux-in...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/input/mouse/synaptics.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/mouse/synaptics.c
> > b/drivers/input/mouse/synaptics.c
> > index 82577095e175e..07835939d83b9 100644
> > --- a/drivers/input/mouse/synaptics.c
> > +++ b/drivers/input/mouse/synaptics.c
> > @@ -1106,8 +1106,9 @@ static void synaptics_process_packet(struct psmouse
> > *psmouse)
> > num_fingers = hw.w + 2;
> > break;
> > case 2:
> > - if (SYN_MODEL_PEN(info->model_id))
> > + if (SYN_MODEL_PEN(info->model_id)) {
> > ; /* Nothing, treat a pen as a single
> > finger */
> > + }
>
> This gives me:
>
> WARNING: braces {} are not necessary for single statement blocks
>
> from checkpatch.
Yes, because checkpatch just sees it as a normal single statement,
rather than an empty one. It complains about macros that can be
compiled out too, which is even more dangerous.
GCC wins this one though, as it *knows* it's an empty statement.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: lockdep: possible irq lock inversion dependency detected (trig->leddev_list_lock)
On Mon, Nov 02, 2020 at 10:09:28AM +0100, Andrea Righi wrote:
> On Mon, Nov 02, 2020 at 09:56:58AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > I'm getting the following lockdep splat (see below).
> > > > >
> > > > > Apparently this warning starts to be reported after applying:
> > > > >
> > > > > e918188611f0 ("locking: More accurate annotations for read_lock()")
> > > > >
> > > > > It looks like a false positive to me, but it made me think a bit and
> > > > > IIUC there can be still a potential deadlock, even if the deadlock
> > > > > scenario is a bit different than what lockdep is showing.
> > > > >
> > > > > In the assumption that read-locks are recursive only in_interrupt()
> > > > > context (as stated in e918188611f0), the following scenario can still
> > > > > happen:
> > > > >
> > > > > CPU0 CPU1
> > > > >
> > > > > read_lock(>leddev_list_lock);
> > > > >
> > > > > write_lock(>leddev_list_lock);
> > > > >
> > > > > kbd_bh()
> > > > >-> read_lock(>leddev_list_lock);
> > > > >
> > > > > *** DEADLOCK ***
> > > > >
> > > > > The write-lock is waiting on CPU1 and the second read_lock() on CPU0
> > > > > would be blocked by the write-lock *waiter* on CPU1 => deadlock.
> > > > >
> > > >
> > > > No, this is not a deadlock, as a write-lock waiter only blocks
> > > > *non-recursive* readers, so since the read_lock() in kbd_bh() is called
> > > > in soft-irq (which in_interrupt() returns true), so it's a recursive
> > > > reader and won't get blocked by the write-lock waiter.
> > >
> > > That's right, I was missing that in_interrupt() returns true also from
> > > soft-irq context.
> > >
> > > > > In that case we could prevent this deadlock condition using a
> > > > > workqueue
> > > > > to call kbd_propagate_led_state() instead of calling it directly from
> > > > > kbd_bh() (even if lockdep would still report the false positive).
> > > > >
> > > >
> > > > The deadlock senario reported by the following splat is:
> > > >
> > > >
> > > > CPU 0: CPU 1:
> > > > CPU 2:
> > > > - -
> > > > -
> > > > led_trigger_event():
> > > > read_lock(>leddev_list_lock);
> > > >
> > > > ata_hsm_qs_complete():
> > > >
> > > > spin_lock_irqsave(>lock);
> > > >
> > > > write_lock(>leddev_list_lock);
> > > > ata_port_freeze():
> > > > ata_do_link_abort():
> > > > ata_qc_complete():
> > > > ledtrig_disk_activity():
> > > >
> > > > led_trigger_blink_oneshot():
> > > >
> > > > read_lock(>leddev_list_lock);
> > > > // ^ not in
> > > > in_interrupt() context, so could get blocked by CPU 2
> > > >
> > > > ata_bmdma_interrupt():
> > > > spin_lock_irqsave(>lock);
> > > >
> > > > , where CPU 0 is blocked by CPU 1 because of the spin_lock_irqsave() in
> > > > ata_bmdma_interrupt() and CPU 1 is blocked by CPU 2 because of the
> > > > read_lock() in led_trigger_blink_oneshot() and CPU 2 is blocked by CPU 0
> > > > because of an arbitrary writer on >leddev_list_lock.
> > > >
> > > > So I don't think it's false positive, but I might miss something
> > > > obvious, because I don't know what the code here actually does ;-)
> > >
> > > With the CPU2 part it all makes sense now and lockdep was right. :)
> > >
> > > At this point I think we could just schedule a separate work to do the
> > > led trigger and avoid calling it with host->lock held and that should
> > > prevent the deadlock. I'll send a patch to do that.
> >
> > Let's... not do that, unless we have no choice.
> >
> > Would it help if leddev_list_lock used _irqsave() locking?
>
> Using read_lock_irqsave/irqrestore() in led_trigger_event() would be
> enough to prevent the deadlock. If it's an acceptable solution I can
> send a patch (already tested it and lockdep doesn't complain :)).
Any comment on
https://lore.kernel.org/lkml/20201102104152.GG9930@xps-13-7390/?
Thanks,
-Andrea
[PATCH v2] mfd: htc-i2cpld: Add the missed i2c_put_adapter() in htcpld_register_chip_i2c()
htcpld_register_chip_i2c() misses to call i2c_put_adapter() in an error
path. Add the missed function call to fix it.
Fixes: 6048a3dd2371 ("mfd: Add HTCPLD driver")
Signed-off-by: Jing Xiangfeng
---
v2:
- add the tag Fixes
---
drivers/mfd/htc-i2cpld.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/htc-i2cpld.c b/drivers/mfd/htc-i2cpld.c
index 247f9849e54a..417b0355d904 100644
--- a/drivers/mfd/htc-i2cpld.c
+++ b/drivers/mfd/htc-i2cpld.c
@@ -346,6 +346,7 @@ static int htcpld_register_chip_i2c(
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_READ_BYTE_DATA)) {
dev_warn(dev, "i2c adapter %d non-functional\n",
pdata->i2c_adapter_id);
+ i2c_put_adapter(adapter);
return -EINVAL;
}
@@ -360,6 +361,7 @@ static int htcpld_register_chip_i2c(
/* I2C device registration failed, contineu with the next */
dev_warn(dev, "Unable to add I2C device for 0x%x\n",
plat_chip_data->addr);
+ i2c_put_adapter(adapter);
return PTR_ERR(client);
}
--
2.17.1
Re: [PATCH 06/20] include: input: elan-i2c-ids: Mark 'elan_acpi_id' as __maybe_unused
On Thu, 05 Nov 2020, Dmitry Torokhov wrote:
> On Thu, Nov 05, 2020 at 09:13:05AM +, Lee Jones wrote:
> > On Wed, 04 Nov 2020, Dmitry Torokhov wrote:
> >
> > > Hi Lee,
> > >
> > > On Wed, Nov 04, 2020 at 04:24:13PM +, Lee Jones wrote:
> > > > Some drivers which include 'elan-i2c-ids.h' make use of
> > > > 'elan_acpi_id', but not all do. Tell the compiler that this is
> > > > expected behaviour.
> > > >
> > > > Fixes the following W=1 kernel build warning(s):
> > > >
> > > > include/linux/input/elan-i2c-ids.h:26:36: warning: ‘elan_acpi_id’
> > > > defined but not used [-Wunused-const-variable=]
> > > >
> > > > Cc: Dmitry Torokhov
> > > > Cc: duson...@emc.com.tw
> > > > Cc: KT Liao
> > > > Cc: linux-in...@vger.kernel.org
> > > > Signed-off-by: Lee Jones
> > > > ---
> > > > include/linux/input/elan-i2c-ids.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/linux/input/elan-i2c-ids.h
> > > > b/include/linux/input/elan-i2c-ids.h
> > > > index 520858d126808..b6976d99b6b75 100644
> > > > --- a/include/linux/input/elan-i2c-ids.h
> > > > +++ b/include/linux/input/elan-i2c-ids.h
> > > > @@ -23,7 +23,7 @@
> > > >
> > > > #include
> > > >
> > > > -static const struct acpi_device_id elan_acpi_id[] = {
> > > > +static const struct acpi_device_id __maybe_unused elan_acpi_id[] = {
> > > > { "ELAN", 0 },
> > > > { "ELAN0100", 0 },
> > > > { "ELAN0600", 0 },
> > >
> > > I think I'd prefer something like this instead:
> > >
> > > diff --git a/drivers/input/mouse/elan_i2c_core.c
> > > b/drivers/input/mouse/elan_i2c_core.c
> > > index c599e21a8478..65d21a050cea 100644
> > > --- a/drivers/input/mouse/elan_i2c_core.c
> > > +++ b/drivers/input/mouse/elan_i2c_core.c
> > > @@ -34,7 +34,6 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > #include
> > >
> > > @@ -1413,6 +1412,7 @@ static const struct i2c_device_id elan_id[] = {
> > > MODULE_DEVICE_TABLE(i2c, elan_id);
> > >
> > > #ifdef CONFIG_ACPI
> > > +#include
> > > MODULE_DEVICE_TABLE(acpi, elan_acpi_id);
> > > #endif
> >
> > Moving an #include file to the bottom of a source file, really?
> >
> > I can do as you wish, but it's a pretty 'interesting' solution. :)
>
> I see absolutely nothing wrong with it, and if you check kernel sources
> you will see #includes used this way.
>
> What is your concern?
I guess just the unfamiliarity of it.
It's the first time I've seen such a solution.
Will fix.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [RFC PATCH 0/3] Add Microchip PolarFire Soc Support
On Thu, Nov 5, 2020 at 11:14 PM Palmer Dabbelt wrote: > > On Wed, 28 Oct 2020 16:27:56 PDT (-0700), Atish Patra wrote: > > This series adds minimal support for Microchip Polar Fire Soc Icicle kit. > > It is rebased on v5.10-rc1 and depends on clock support. > > Only MMC and ethernet drivers are enabled via this series. > > The idea here is to add the foundational patches so that other drivers > > can be added to on top of this. > > > > This series has been tested on Qemu and Polar Fire Soc Icicle kit. > > The following qemu series is necessary to test it on Qemu. > > > > The series can also be found at the following github repo. > > > > I noticed the latest version of mmc driver[2] hangs on the board with > > the latest clock driver. That's why, I have tested with the old clock > > driver available in the above github repo. > > OK, I guess that's why it's an RFC? > Yes. The latest clock/pcie driver did not work for me. I might have missed something in DT. The idea for RFC is so that anybody who wants to try the latest kernel on a polarfire board has a meaningful way to test it. > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html > > [2] https://www.spinics.net/lists/devicetree/msg383626.html > > Looks like this one hasn't been merged yet. IDK if something is broken with > my > mail client but I'm not seeing any github repos. If this depends on > not-yet-merged drivers then it's certainly RFC material, but aside from the DT > stuff (which should be straight-forward) it seems fine to me. > I think it makes sense to take this series once the clock driver is merged at least. > Since you posted this an an RFC I'm going to assume you're going to re-spin > it. > Yes. There are some feedbacks on DT which I will fix in v2. > Thanks! > > > > > Atish Patra (3): > > RISC-V: Add Microchip PolarFire SoC kconfig option > > RISC-V: Initial DTS for Microchip ICICLE board > > RISC-V: Enable Microchip PolarFire ICICLE SoC > > > > arch/riscv/Kconfig.socs | 7 + > > arch/riscv/boot/dts/Makefile | 1 + > > arch/riscv/boot/dts/microchip/Makefile| 2 + > > .../microchip/microchip-icicle-kit-a000.dts | 313 ++ > > arch/riscv/configs/defconfig | 4 + > > 5 files changed, 327 insertions(+) > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile > > create mode 100644 > > arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish
Re: [PATCH -next v3 1/2] watchdog: Fix potential dereferencing of null pointer
在 2020/11/5 22:26, Guenter Roeck 写道:
> On Thu, Nov 05, 2020 at 12:38:47PM +, Wang Wensheng wrote:
>> A reboot notifier, which stops the WDT by calling the stop hook without
>> any check, would be registered when we set WDOG_STOP_ON_REBOOT flag.
>>
>> Howerer we allow the WDT driver to omit the stop hook since commit
>> "d0684c8a93549" ("watchdog: Make stop function optional") and provide
>> a module parameter for user that controls the WDOG_STOP_ON_REBOOT flag
>> in commit 9232c80659e94 ("watchdog: Add stop_on_reboot parameter to
>> control reboot policy"). Together that commits make user potential to
>> insert a watchdog driver that don't provide a stop hook but with the
>> stop_on_reboot parameter set, then dereferencing of null pointer occurs
>> on system reboot.
>>
>> Check the stop hook before registering the reboot notifier to fix the
>> issue.
>>
>> Fixes: d0684c8a9354 ("watchdog: Make stop function optional")
>> Signed-off-by: Wang Wensheng
>> ---
>> drivers/watchdog/watchdog_core.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/watchdog/watchdog_core.c
>> b/drivers/watchdog/watchdog_core.c
>> index 423844757812..945ab38b14b8 100644
>> --- a/drivers/watchdog/watchdog_core.c
>> +++ b/drivers/watchdog/watchdog_core.c
>> @@ -267,8 +267,15 @@ static int __watchdog_register_device(struct
>> watchdog_device *wdd)
>> }
>>
>> if (test_bit(WDOG_STOP_ON_REBOOT, >status)) {
>> -wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
>> +if (!wdd->ops->stop) {
>> +pr_err("watchdog%d: Cannot support stop_on_reboot\n",
>> +wdd->id);
>> +watchdog_dev_unregister(wdd);
>> +ida_simple_remove(_ida, id);
>> +return -EINVAL;
>> +}
>
> The problem with this is that setting the "stop_on_reboot" module parameter
> would now prevent the watchdog from being loaded, which isn't really
> desirable and might go unnoticed. I think the initial check should be
> above, with the "Mandatory operations" check, and
> if (stop_on_reboot != -1) {
> should be extended to
> if (stop_on_reboot != -1 && wdd->ops->stop) {
>
> or possibly more fancy:
>
> if (stop_on_reboot != -1) {
> if (stop_on_reboot) {
> if (!wdd->ops->stop)
> pr_warn("watchdog%d: stop_on_reboot not
> supported\n", wdd->id);
> else
> set_bit(WDOG_STOP_ON_REBOOT, >status);
> } else {
> clear_bit(WDOG_STOP_ON_REBOOT, >status);
> }
> }
>
> Thanks,
> Guenter
Now the divergence is that should we stop the registering process and
return error when the STOP_ON_REBOOT flag is set but the driver doesn't
support it. The flag is set in two scenes.
Firstly,the driver that should provide the stop hook may set the flag
staticlly, and it is a bug of the driver if it set the flag but without
a stop hook. Then giving an error shall be more striking.
Secondly, the user can change the flag using module parameter. Is it
reasonable to just ignore the STOP_ON_REBOOT flag and give a warning
when the user truely want it? And under this circumstance a warning is
easier to get unnoticed than an error.
I prefer to stop the registering process and return an error in those
two scenes.
Thanks
>
>>
>> +wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
>> ret = register_reboot_notifier(>reboot_nb);
>> if (ret) {
>> pr_err("watchdog%d: Cannot register reboot notifier
>> (%d)\n",
>> --
>> 2.25.0
>>
>
Re: [PATCH v3 2/2] usb: typec: Expose Product Type VDOs via sysfs
On Wed, Nov 04, 2020 at 09:49:17AM -0800, Prashant Malani wrote: > Hi All, > > Was wondering if there were any comments on v3 of this series? Sorry to keep you waiting with this... I'm still wondering if the patch 2/2 is what we should use. Right now I don't have really any better ideas. But give the rest of the week to think about this. thanks, -- heikki
[PATCH v1 4/4] i2c: stm32f7: Make usage of dev_wakeup_path() helper
From: Patrice Chotard
Make usage of dev_wakeup_path() helper.
Signed-off-by: Patrice Chotard
---
drivers/i2c/busses/i2c-stm32f7.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index f41f51a176a1..9aa8e65b511e 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -2322,7 +2322,7 @@ static int stm32f7_i2c_suspend(struct device *dev)
i2c_mark_adapter_suspended(_dev->adap);
- if (!device_may_wakeup(dev) && !dev->power.wakeup_path) {
+ if (!device_may_wakeup(dev) && !device_wakeup_path(dev)) {
ret = stm32f7_i2c_regs_backup(i2c_dev);
if (ret < 0) {
i2c_mark_adapter_resumed(_dev->adap);
@@ -2341,7 +2341,7 @@ static int stm32f7_i2c_resume(struct device *dev)
struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev);
int ret;
- if (!device_may_wakeup(dev) && !dev->power.wakeup_path) {
+ if (!device_may_wakeup(dev) && !device_wakeup_path(dev)) {
ret = pm_runtime_force_resume(dev);
if (ret < 0)
return ret;
--
2.17.1
[PATCH v1 0/4] PM: Add dev_wakeup_path() helper
From: Patrice Chotard Add dev_wakeup_path() helper to avoid to spread dev->power.wakeup_path test in drivers. Cc: amelie.delau...@st.com, erwan_le...@st.com, fabrice.gasn...@st.com, alexandre.tor...@st.com, alain.vol...@st.com, pierre-yves.mord...@st.com *** BLURB HERE *** Patrice Chotard (4): PM / wakeup: Add dev_wakeup_path() helper PM: domains: Make usage of device_wakeup_path() helper PM: core: Make usage of device_wakeup_path() helper i2c: stm32f7: Make usage of dev_wakeup_path() helper drivers/base/power/domain.c | 4 ++-- drivers/base/power/main.c| 4 ++-- drivers/i2c/busses/i2c-stm32f7.c | 4 ++-- include/linux/pm_wakeup.h| 10 ++ 4 files changed, 16 insertions(+), 6 deletions(-) -- 2.17.1
Re: [PATCH 4/7] devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
On 11/6/20 4:46 PM, Chanwoo Choi wrote:
> On 11/6/20 4:42 PM, Chanwoo Choi wrote:
>> Hi Viresh,
>>
>> On 11/6/20 4:03 PM, Viresh Kumar wrote:
>>> The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
>>> there is no need for us to carry the extra check. Drop them.
>>>
>>> Signed-off-by: Viresh Kumar
>>> ---
>>> drivers/devfreq/exynos-bus.c | 12
>>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 1e684a448c9e..143fd58ec3dc 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -158,10 +158,8 @@ static void exynos_bus_exit(struct device *dev)
>>>
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> - if (bus->opp_table) {
>>> - dev_pm_opp_put_regulators(bus->opp_table);
>>> - bus->opp_table = NULL;
>>> - }
>>> + dev_pm_opp_put_regulators(bus->opp_table);
>>> + bus->opp_table = NULL;
>>> }
>>>
>>> static void exynos_bus_passive_exit(struct device *dev)
>>> @@ -444,10 +442,8 @@ static int exynos_bus_probe(struct platform_device
>>> *pdev)
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> err_reg:
>>> - if (!passive) {
>>> - dev_pm_opp_put_regulators(bus->opp_table);
>>> - bus->opp_table = NULL;
>>> - }
>>> + dev_pm_opp_put_regulators(bus->opp_table);
>>> + bus->opp_table = NULL;
>>>
>>> return ret;
>>> }
>>>
>>
>> Applied it. Thanks.
>>
>
> It seems that this patch depends on first patch.
> So, need to be merged to one git repository.
>
> Instead of applying it to devfreq.git,
> Acked-by: Chanwoo Choi
>
Also, need to add 'PM /' prefix to patch title
in order to keep the same format with already merged devfreq patches.
- 'PM / devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument'
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH v1 1/4] PM / wakeup: Add dev_wakeup_path() helper
From: Patrice Chotard
Add dev_wakeup_path() helper to avoid to spread
dev->power.wakeup_path test in drivers.
In case CONFIG_PM_SLEEP is not set, wakeup_path is not defined,
dev_wakeup_path() is returning false.
Signed-off-by: Patrice Chotard
---
include/linux/pm_wakeup.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index aa3da6611533..196a157456aa 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -84,6 +84,11 @@ static inline bool device_may_wakeup(struct device *dev)
return dev->power.can_wakeup && !!dev->power.wakeup;
}
+static inline bool device_wakeup_path(struct device *dev)
+{
+ return dev->power.wakeup_path;
+}
+
static inline void device_set_wakeup_path(struct device *dev)
{
dev->power.wakeup_path = true;
@@ -174,6 +179,11 @@ static inline bool device_may_wakeup(struct device *dev)
return dev->power.can_wakeup && dev->power.should_wakeup;
}
+static inline bool device_wakeup_path(struct device *dev)
+{
+ return false;
+}
+
static inline void device_set_wakeup_path(struct device *dev) {}
static inline void __pm_stay_awake(struct wakeup_source *ws) {}
--
2.17.1
[PATCH v1 2/4] PM: domains: Make usage of device_wakeup_path() helper
From: Patrice Chotard Make usage of dev_wakeup_path() helper. Signed-off-by: Patrice Chotard --- drivers/base/power/domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index 743268996336..e0894ef8457c 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1142,7 +1142,7 @@ static int genpd_finish_suspend(struct device *dev, bool poweroff) if (ret) return ret; - if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd)) + if (device_wakeup_path(dev) && genpd_is_active_wakeup(genpd)) return 0; if (genpd->dev_ops.stop && genpd->dev_ops.start && @@ -1196,7 +1196,7 @@ static int genpd_resume_noirq(struct device *dev) if (IS_ERR(genpd)) return -EINVAL; - if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd)) + if (device_wakeup_path(dev) && genpd_is_active_wakeup(genpd)) return pm_generic_resume_noirq(dev); genpd_lock(genpd); -- 2.17.1
[PATCH v1 3/4] PM: core: Make usage of device_wakeup_path() helper
From: Patrice Chotard
Make usage of dev_wakeup_path() helper.
Signed-off-by: Patrice Chotard
---
drivers/base/power/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index c7ac49042cee..921c5b2ec30a 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1359,7 +1359,7 @@ static void dpm_propagate_wakeup_to_parent(struct device
*dev)
spin_lock_irq(>power.lock);
- if (dev->power.wakeup_path && !parent->power.ignore_children)
+ if (device_wakeup_path(dev) && !parent->power.ignore_children)
parent->power.wakeup_path = true;
spin_unlock_irq(>power.lock);
@@ -1627,7 +1627,7 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
goto Complete;
/* Avoid direct_complete to let wakeup_path propagate. */
- if (device_may_wakeup(dev) || dev->power.wakeup_path)
+ if (device_may_wakeup(dev) || device_wakeup_path(dev))
dev->power.direct_complete = false;
if (dev->power.direct_complete) {
--
2.17.1
Re: [PATCH 4/7] devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
On 11/6/20 4:42 PM, Chanwoo Choi wrote:
> Hi Viresh,
>
> On 11/6/20 4:03 PM, Viresh Kumar wrote:
>> The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
>> there is no need for us to carry the extra check. Drop them.
>>
>> Signed-off-by: Viresh Kumar
>> ---
>> drivers/devfreq/exynos-bus.c | 12
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>> index 1e684a448c9e..143fd58ec3dc 100644
>> --- a/drivers/devfreq/exynos-bus.c
>> +++ b/drivers/devfreq/exynos-bus.c
>> @@ -158,10 +158,8 @@ static void exynos_bus_exit(struct device *dev)
>>
>> dev_pm_opp_of_remove_table(dev);
>> clk_disable_unprepare(bus->clk);
>> -if (bus->opp_table) {
>> -dev_pm_opp_put_regulators(bus->opp_table);
>> -bus->opp_table = NULL;
>> -}
>> +dev_pm_opp_put_regulators(bus->opp_table);
>> +bus->opp_table = NULL;
>> }
>>
>> static void exynos_bus_passive_exit(struct device *dev)
>> @@ -444,10 +442,8 @@ static int exynos_bus_probe(struct platform_device
>> *pdev)
>> dev_pm_opp_of_remove_table(dev);
>> clk_disable_unprepare(bus->clk);
>> err_reg:
>> -if (!passive) {
>> -dev_pm_opp_put_regulators(bus->opp_table);
>> -bus->opp_table = NULL;
>> -}
>> +dev_pm_opp_put_regulators(bus->opp_table);
>> +bus->opp_table = NULL;
>>
>> return ret;
>> }
>>
>
> Applied it. Thanks.
>
It seems that this patch depends on first patch.
So, need to be merged to one git repository.
Instead of applying it to devfreq.git,
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH] rtc: sc27xx: Remove unnecessary conversion to bool
From: Kaixu Xia Here we could use the '!=' expression to fix the following coccicheck warning: ./drivers/rtc/rtc-sc27xx.c:566:50-55: WARNING: conversion to bool not needed here Reported-by: Tosk Robot Signed-off-by: Kaixu Xia --- drivers/rtc/rtc-sc27xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-sc27xx.c b/drivers/rtc/rtc-sc27xx.c index 36810dd40cd3..6e65f68ea86d 100644 --- a/drivers/rtc/rtc-sc27xx.c +++ b/drivers/rtc/rtc-sc27xx.c @@ -563,7 +563,7 @@ static int sprd_rtc_check_power_down(struct sprd_rtc *rtc) * means the RTC has been powered down, so the RTC time values are * invalid. */ - rtc->valid = val == SPRD_RTC_POWER_RESET_VALUE ? false : true; + rtc->valid = val != SPRD_RTC_POWER_RESET_VALUE; return 0; } -- 2.20.0
Re: [Freedreno] [PATCH v5 3/3] dt-bindings: drm/msm/gpu: Add cooling device support
On 11/5/2020 2:28 AM, Rob Clark wrote: On Wed, Nov 4, 2020 at 12:03 PM Rob Herring wrote: On Fri, 30 Oct 2020 16:17:12 +0530, Akhil P Oommen wrote: Add cooling device support to gpu. A cooling device is bound to a thermal zone to allow thermal mitigation. Signed-off-by: Akhil P Oommen Reviewed-by: Matthias Kaehlcke --- Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++ 1 file changed, 7 insertions(+) Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed. Thanks Rob I've copied over your ack from the previous version.. but yes, it definitely makes my life easier when patch senders do this for me ;-) BR, -R Robh, you Acked v4 after I shared v5 patches!! -Akhil.
Re: [PATCH -V2 2/2] autonuma: Migrate on fault among multiple bound nodes
Mel Gorman writes: > On Wed, Nov 04, 2020 at 01:36:58PM +0800, Huang, Ying wrote: >> But from another point of view, I suggest to remove the constraints of >> MPOL_F_MOF in the future. If the overhead of AutoNUMA isn't acceptable, >> why not just disable AutoNUMA globally via sysctl knob? >> > > Because it's a double edged sword. NUMA Balancing can make a workload > faster while still incurring more overhead than it should -- particularly > when threads are involved rescanning the same or unrelated regions. > Global disabling only really should happen when an application is running > that is the only application on the machine and has full NUMA awareness. Got it. So NUMA Balancing may in generally benefit some workloads but hurt some other workloads on one machine. So we need a method to enable/disable NUMA Balancing for one workload. Previously, this is done via the explicit NUMA policy. If some explicit NUMA policy is specified, NUMA Balancing is disabled for the memory region or the thread. And this can be reverted again for a memory region via MPOL_MF_LAZY. It appears that we lacks MPOL_MF_LAZY for the thread yet. >> > It might still end up being better but I was not aware of a >> > *realistic* workload that binds to multiple nodes >> > deliberately. Generally I expect if an application is binding, it's >> > binding to one local node. >> >> Yes. It's not popular configuration for now. But for the memory >> tiering system with both DRAM and PMEM, the DRAM and PMEM in one socket >> will become 2 NUMA nodes. To avoid too much cross-socket memory >> accessing, but take advantage of both the DRAM and PMEM, the workload >> can be bound to 2 NUMA nodes (DRAM and PMEM). >> > > Ok, that may lead to unpredictable performance as it'll have variable > performance with limited control of the "important" applications that > should use DRAM over PMEM. That's a long road but the step is not > incompatible with the long-term goal. Yes. Ben Widawsky is working on a patchset to make it possible to prefer the remote DRAM instead of the local PMEM as follows, https://lore.kernel.org/linux-mm/20200630212517.308045-1-ben.widaw...@intel.com/ Best Regards, Huang, Ying
Re: [PATCH 4/7] devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
Hi Viresh,
On 11/6/20 4:03 PM, Viresh Kumar wrote:
> The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
> there is no need for us to carry the extra check. Drop them.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/devfreq/exynos-bus.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 1e684a448c9e..143fd58ec3dc 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -158,10 +158,8 @@ static void exynos_bus_exit(struct device *dev)
>
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> - if (bus->opp_table) {
> - dev_pm_opp_put_regulators(bus->opp_table);
> - bus->opp_table = NULL;
> - }
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
> }
>
> static void exynos_bus_passive_exit(struct device *dev)
> @@ -444,10 +442,8 @@ static int exynos_bus_probe(struct platform_device *pdev)
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> err_reg:
> - if (!passive) {
> - dev_pm_opp_put_regulators(bus->opp_table);
> - bus->opp_table = NULL;
> - }
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
>
> return ret;
> }
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 06/20] include: input: elan-i2c-ids: Mark 'elan_acpi_id' as __maybe_unused
On Thu, Nov 05, 2020 at 09:13:05AM +, Lee Jones wrote:
> On Wed, 04 Nov 2020, Dmitry Torokhov wrote:
>
> > Hi Lee,
> >
> > On Wed, Nov 04, 2020 at 04:24:13PM +, Lee Jones wrote:
> > > Some drivers which include 'elan-i2c-ids.h' make use of
> > > 'elan_acpi_id', but not all do. Tell the compiler that this is
> > > expected behaviour.
> > >
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > include/linux/input/elan-i2c-ids.h:26:36: warning: ‘elan_acpi_id’
> > > defined but not used [-Wunused-const-variable=]
> > >
> > > Cc: Dmitry Torokhov
> > > Cc: duson...@emc.com.tw
> > > Cc: KT Liao
> > > Cc: linux-in...@vger.kernel.org
> > > Signed-off-by: Lee Jones
> > > ---
> > > include/linux/input/elan-i2c-ids.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/input/elan-i2c-ids.h
> > > b/include/linux/input/elan-i2c-ids.h
> > > index 520858d126808..b6976d99b6b75 100644
> > > --- a/include/linux/input/elan-i2c-ids.h
> > > +++ b/include/linux/input/elan-i2c-ids.h
> > > @@ -23,7 +23,7 @@
> > >
> > > #include
> > >
> > > -static const struct acpi_device_id elan_acpi_id[] = {
> > > +static const struct acpi_device_id __maybe_unused elan_acpi_id[] = {
> > > { "ELAN", 0 },
> > > { "ELAN0100", 0 },
> > > { "ELAN0600", 0 },
> >
> > I think I'd prefer something like this instead:
> >
> > diff --git a/drivers/input/mouse/elan_i2c_core.c
> > b/drivers/input/mouse/elan_i2c_core.c
> > index c599e21a8478..65d21a050cea 100644
> > --- a/drivers/input/mouse/elan_i2c_core.c
> > +++ b/drivers/input/mouse/elan_i2c_core.c
> > @@ -34,7 +34,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> >
> > @@ -1413,6 +1412,7 @@ static const struct i2c_device_id elan_id[] = {
> > MODULE_DEVICE_TABLE(i2c, elan_id);
> >
> > #ifdef CONFIG_ACPI
> > +#include
> > MODULE_DEVICE_TABLE(acpi, elan_acpi_id);
> > #endif
>
> Moving an #include file to the bottom of a source file, really?
>
> I can do as you wish, but it's a pretty 'interesting' solution. :)
I see absolutely nothing wrong with it, and if you check kernel sources
you will see #includes used this way.
What is your concern?
Thanks.
--
Dmitry
Re: [PATCH 2/3] opp: Allocate the OPP table outside of opp_table_lock
On 02-11-20, 10:51, Viresh Kumar wrote:
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> +/*
> + * We need to make sure that the OPP table for a device doesn't get added
> twice,
> + * if this routine gets called in parallel with the same device pointer.
> + *
> + * The simplest way to enforce that is to perform everything (find existing
> + * table and if not found, create a new one) under the opp_table_lock, so
> only
> + * one creator gets access to the same. But that expands the critical section
> + * under the lock and may end up causing circular dependencies with
> frameworks
> + * like debugfs, interconnect or clock framework as they may be direct or
> + * indirect users of OPP core.
> + *
> + * And for that reason we have to go for a bit tricky implementation here,
> which
> + * uses the opp_tables_busy flag to indicate if another creator is in the
> middle
> + * of adding an OPP table and others should wait for it to finish.
> + */
> static struct opp_table *_opp_get_opp_table(struct device *dev, int index)
> {
> struct opp_table *opp_table;
>
> - /* Hold our table modification lock here */
> +again:
> mutex_lock(_table_lock);
>
> opp_table = _find_opp_table_unlocked(dev);
> if (!IS_ERR(opp_table))
> goto unlock;
>
> + /*
> + * The opp_tables list or an OPP table's dev_list is getting updated by
> + * another user, wait for it to finish.
> + */
> + if (unlikely(opp_tables_busy)) {
> + mutex_unlock(_table_lock);
> + cpu_relax();
> + goto again;
> + }
> +
> + opp_tables_busy = true;
> opp_table = _managed_opp(dev, index);
> +
> + /* Drop the lock to reduce the size of critical section */
> + mutex_unlock(_table_lock);
> +
> if (opp_table) {
> if (!_add_opp_dev(dev, opp_table)) {
> dev_pm_opp_put_opp_table(opp_table);
> opp_table = ERR_PTR(-ENOMEM);
> }
> - goto unlock;
> +
> + mutex_lock(_table_lock);
> + } else {
> + opp_table = _allocate_opp_table(dev, index);
> +
> + mutex_lock(_table_lock);
> + if (!IS_ERR(opp_table))
> + list_add(_table->node, _tables);
> }
>
> - opp_table = _allocate_opp_table(dev, index);
> + opp_tables_busy = false;
And here is a fix that will be merged with this patch while applying. It is
required as _allocate_opp_table() (which calls _find_table_of_opp_np()) isn't
called with the opp_table_lock anymore.
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index c718092757d9..6b7f0066942d 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -112,8 +112,6 @@ static struct opp_table *_find_table_of_opp_np(struct
device_node *opp_np)
struct opp_table *opp_table;
struct device_node *opp_table_np;
- lockdep_assert_held(_table_lock);
-
opp_table_np = of_get_parent(opp_np);
if (!opp_table_np)
goto err;
@@ -121,12 +119,15 @@ static struct opp_table *_find_table_of_opp_np(struct
device_node *opp_np)
/* It is safe to put the node now as all we need now is its address */
of_node_put(opp_table_np);
+ mutex_lock(_table_lock);
list_for_each_entry(opp_table, _tables, node) {
if (opp_table_np == opp_table->np) {
_get_opp_table_kref(opp_table);
+ mutex_unlock(_table_lock);
return opp_table;
}
}
+ mutex_unlock(_table_lock);
err:
return ERR_PTR(-ENODEV);
--
viresh
Re: [PATCH 10/20] input: mouse: synaptics: Place braces around empty if() body
Hi Lee,
On Wed, Nov 04, 2020 at 04:24:17PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/mouse/synaptics.c: In function ‘synaptics_process_packet’:
> drivers/input/mouse/synaptics.c:1110:6: warning: suggest braces around empty
> body in an ‘if’ statement [-Wempty-body]
>
> Cc: Dmitry Torokhov
> Cc: Henrik Rydberg
> Cc: Peter Osterlund
> Cc: Stefan Gmeiner
> Cc: "C. Scott Ananian"
> Cc: Bruce Kalk
> Cc: this to
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/input/mouse/synaptics.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 82577095e175e..07835939d83b9 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1106,8 +1106,9 @@ static void synaptics_process_packet(struct psmouse
> *psmouse)
> num_fingers = hw.w + 2;
> break;
> case 2:
> - if (SYN_MODEL_PEN(info->model_id))
> + if (SYN_MODEL_PEN(info->model_id)) {
> ; /* Nothing, treat a pen as a single
> finger */
> + }
This gives me:
WARNING: braces {} are not necessary for single statement blocks
from checkpatch.
Thanks.
--
Dmitry
Re: [PATCH v2] ath10k: Fix the parsing error in service available event
Doug Anderson writes: >> static int ath10k_wmi_tlv_op_pull_svc_avail(struct ath10k *ar, >> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c >> b/drivers/net/wireless/ath/ath10k/wmi.c >> index 1fa7107..2e4b561 100644 >> --- a/drivers/net/wireless/ath/ath10k/wmi.c >> +++ b/drivers/net/wireless/ath/ath10k/wmi.c >> @@ -5751,8 +5751,9 @@ void ath10k_wmi_event_service_available(struct ath10k >> *ar, struct sk_buff *skb) >> ret); >> } >> >> - ath10k_wmi_map_svc_ext(ar, arg.service_map_ext, ar->wmi.svc_map, >> - __le32_to_cpu(arg.service_map_ext_len)); >> + if (arg.service_map_ext_valid) >> + ath10k_wmi_map_svc_ext(ar, arg.service_map_ext, >> ar->wmi.svc_map, >> + >> __le32_to_cpu(arg.service_map_ext_len)); > > Your new patch still requires the caller to init the > "service_map_ext_valid" to false before calling, but I guess there's > not a whole lot more we can do because we might be parsing more than > one tag. It does seem nice that at least we now have a validity bit > instead of just relying on a non-zero length to be valid. > > It might be nice to have a comment saying that it's up to us to init > "arg.service_map_ext_valid" to false before calling > ath10k_wmi_pull_svc_avail(), but I won't insist. Maybe that's obvious > to everyone but me... It's not obvious to me either. Please add that comment. BTW, for some reason Doug's response didn't get to patchwork: https://patchwork.kernel.org/project/linux-wireless/patch/1603904469-598-1-git-send-email-pill...@codeaurora.org/ Though I do see it in linux-wireless, so most likely this was a temporary glitch in patchwork. But it's just worrisome as nowadays I only check the comments in patchwork before I apply the patch. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v1 17/18] driver core: Add helper functions to convert fwnode links to device links
On Thu, Nov 05, 2020 at 03:32:05PM -0800, Saravana Kannan wrote: > On Thu, Nov 5, 2020 at 1:43 AM Greg Kroah-Hartman > wrote: > > > > On Wed, Nov 04, 2020 at 03:23:54PM -0800, Saravana Kannan wrote: > > > Add helper functions __fw_devlink_link_to_consumers() and > > > __fw_devlink_link_to_suppliers() that convert fwnode links to device > > > links. > > > > > > __fw_devlink_link_to_consumers() is for creating: > > > - Device links between a newly added device and all its consumer devices > > > that have been added to driver core. > > > - Proxy SYNC_STATE_ONLY device links between the newly added device and > > > the parent devices of all its consumers that have not been added to > > > driver core yet. > > > > > > __fw_devlink_link_to_suppliers() is for creating: > > > - Device links between a newly added device and all its supplier devices > > > - Proxy SYNC_STATE_ONLY device links between the newly added device and > > > all the supplier devices of its child device nodes. > > > > > > Signed-off-by: Saravana Kannan > > > > Did you just add build warnings with these static functions that no one > > calls? > > The next patch in this series uses it. I'm just splitting it up into a > separate patch so that it's digestible and I can provide more details > in the commit text. But you can not add build warnings, you know this :) > Couple of options: > 1. Drop the static in this patch and add it back when it's used in patch > 18/18. > 2. Drop the commit text and squash this with 18/18 if you think the > function documentation is clear enough and it won't make patch 18/18 > too hard to review. It is hard to review new functions when you do not see them being used, otherwise you have to flip back and forth between patches, which is difficult. Add the functions, and use them, in the same patch. Otherwise we have no idea _HOW_ you are using them, or even if you end up using them at all. thanks, greg k-h
Re: [PATCH v1 15/18] of: property: Update implementation of add_links() to create fwnode links
On Thu, Nov 05, 2020 at 03:25:56PM -0800, Saravana Kannan wrote:
> On Thu, Nov 5, 2020 at 1:41 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Nov 04, 2020 at 03:23:52PM -0800, Saravana Kannan wrote:
> > > The semantics of add_links() has changed from creating device link
> > > between devices to creating fwnode links between fwnodes. So, update the
> > > implementation of add_links() to match the new semantics.
> > >
> > > Signed-off-by: Saravana Kannan
> > > ---
> > > drivers/of/property.c | 150 --
> > > 1 file changed, 41 insertions(+), 109 deletions(-)
> > >
> > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > index 408a7b5f06a9..86303803f1b3 100644
> > > --- a/drivers/of/property.c
> > > +++ b/drivers/of/property.c
> > > @@ -1038,33 +1038,9 @@ static bool of_is_ancestor_of(struct device_node
> > > *test_ancestor,
> > > }
> > >
> > > /**
> > > - * of_get_next_parent_dev - Add device link to supplier from supplier
> > > phandle
> > > - * @np: device tree node
> > > - *
> > > - * Given a device tree node (@np), this function finds its closest
> > > ancestor
> > > - * device tree node that has a corresponding struct device.
> > > - *
> > > - * The caller of this function is expected to call put_device() on the
> > > returned
> > > - * device when they are done.
> > > - */
> > > -static struct device *of_get_next_parent_dev(struct device_node *np)
> > > -{
> > > - struct device *dev = NULL;
> > > -
> > > - of_node_get(np);
> > > - do {
> > > - np = of_get_next_parent(np);
> > > - if (np)
> > > - dev = get_dev_from_fwnode(>fwnode);
> > > - } while (np && !dev);
> > > - of_node_put(np);
> > > - return dev;
> > > -}
> > > -
> > > -/**
> > > - * of_link_to_phandle - Add device link to supplier from supplier phandle
> > > - * @dev: consumer device
> > > - * @sup_np: phandle to supplier device tree node
> > > + * of_link_to_phandle - Add fwnode link to supplier from supplier phandle
> > > + * @con_np: consumer device tree node
> > > + * @sup_np: supplier device tree node
> > > *
> > > * Given a phandle to a supplier device tree node (@sup_np), this
> > > function
> > > * finds the device that owns the supplier device tree node and creates a
> > > @@ -1074,16 +1050,14 @@ static struct device
> > > *of_get_next_parent_dev(struct device_node *np)
> > > * cases, it returns an error.
> > > *
> > > * Returns:
> > > - * - 0 if link successfully created to supplier
> > > - * - -EAGAIN if linking to the supplier should be reattempted
> > > + * - 0 if fwnode link successfully created to supplier
> > > * - -EINVAL if the supplier link is invalid and should not be created
> > > - * - -ENODEV if there is no device that corresponds to the supplier
> > > phandle
> > > + * - -ENODEV if struct device will never be create for supplier
> > > */
> > > -static int of_link_to_phandle(struct device *dev, struct device_node
> > > *sup_np,
> > > - u32 dl_flags)
> > > +static int of_link_to_phandle(struct device_node *con_np,
> > > + struct device_node *sup_np)
> > > {
> > > - struct device *sup_dev, *sup_par_dev;
> > > - int ret = 0;
> > > + struct device *sup_dev;
> > > struct device_node *tmp_np = sup_np;
> > >
> > > of_node_get(sup_np);
> > > @@ -1106,7 +1080,8 @@ static int of_link_to_phandle(struct device *dev,
> > > struct device_node *sup_np,
> > > }
> > >
> > > if (!sup_np) {
> > > - dev_dbg(dev, "Not linking to %pOFP - No device\n", tmp_np);
> > > + pr_debug("Not linking %pOFP to %pOFP - No device\n",
> > > + con_np, tmp_np);
> >
> > Who is calling this function without a valid dev pointer?
>
> Sorry, I plan to delete the "dev" parameter as it's not really used
> anywhere. I'm trying to do that without causing build time errors and
> making the series into digestible small patches.
>
> I can do the deletion of the parameter as a Patch 19/19. Will that work?
That's fine, but why get rid of dev? The driver core works on these
things, and we want errors/messages/warnings to spit out what device is
causing those issues. It is fine to drag around a struct device pointer
just for messages, that's to be expected, and is good.
> > And the only way it can be NULL is if fwnode is NULL, and as you control
> > the callers to it, how can that be the case?
>
> fwnode represents a generic firmware node. The to_of_node() returns
> NULL if fwnode is not a DT node. So con_np can be NULL if that
> happens. That's why we need a NULL check here. With the current code,
> that can never happen, bit I think it doesn't hurt to check in case
> there's a buggy caller. I don't have a strong opinion - so I can do it
> whichever way.
If it can't happen, no need to check for it :)
thanks,
greg k-h
Re: [PATCH v2] ath10k: Fix the parsing error in service available event
Rakesh Pillai writes: > The wmi service available event has been > extended to contain extra 128 bit for new services > to be indicated by firmware. > > Currently the presence of any optional TLVs in > the wmi service available event leads to a parsing > error with the below error message: > ath10k_snoc 1880.wifi: failed to parse svc_avail tlv: -71 > > The wmi service available event parsing should > not return error for the newly added optional TLV. > Fix this parsing for service available event message. > > Tested-on: WCN3990 hw1.0 SNOC Firmware version missing. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 6/6] platform/chrome: cros_ec_typec: Store cable plug type
On Thu, Nov 05, 2020 at 05:28:03PM -0800, Prashant Malani wrote:
> Use the PD VDO Type C cable plug type macro to retrieve and store the
> cable plug type in the cable descriptor.
>
> Cc: Heikki Krogerus
> Cc: Greg Kroah-Hartman
> Signed-off-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
Where are the first 5 patches in this series?
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_ec_typec.c
> index 5e7f0b4ebbec..0a2a8b0f8115 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -709,6 +709,7 @@ static int cros_typec_handle_sop_prime_disc(struct
> cros_typec_data *typec, int p
> .port = port_num,
> .partner_type = TYPEC_PARTNER_SOP_PRIME,
> };
> + uint32_t cable_plug_type;
u32 please, this isn't userspace code :)
> int ret = 0;
>
> memset(disc, 0, EC_PROTO2_MAX_RESPONSE_SIZE);
> @@ -722,8 +723,26 @@ static int cros_typec_handle_sop_prime_disc(struct
> cros_typec_data *typec, int p
> /* Parse the PD identity data, even if only 0s were returned. */
> cros_typec_parse_pd_identity(>c_identity, disc);
>
> - if (disc->identity_count != 0)
> + if (disc->identity_count != 0) {
> + cable_plug_type = VDO_TYPEC_CABLE_TYPE(port->c_identity.vdo[0]);
> + switch (cable_plug_type) {
> + case CABLE_ATYPE:
> + desc.type = USB_PLUG_TYPE_A;
> + break;
> + case CABLE_BTYPE:
> + desc.type = USB_PLUG_TYPE_B;
> + break;
> + case CABLE_CTYPE:
> + desc.type = USB_PLUG_TYPE_C;
> + break;
> + case CABLE_CAPTIVE:
> + desc.type = USB_PLUG_CAPTIVE;
> + break;
> + default:
> + desc.type = USB_PLUG_NONE;
> + }
> desc.active = PD_IDH_PTYPE(port->c_identity.id_header) ==
> IDH_PTYPE_ACABLE;
> + }
So you save it but what happens with the value?
confused,
greg k-h
Re: [PATCH tip/core/rcu 03/28] locktorture: Track time of last ->writeunlock()
On Thu, 05 Nov 2020, paul...@kernel.org wrote:
From: "Paul E. McKenney"
This commit adds a last_lock_release variable that tracks the time of
the last ->writeunlock() call, which allows easier diagnosing of lock
hangs when using a kernel debugger.
This makes sense to have.
Acked-by: Davidlohr Bueso
Cc: Davidlohr Bueso
Signed-off-by: Paul E. McKenney
---
kernel/locking/locktorture.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 62d215b..316531d 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -60,6 +60,7 @@ static struct task_struct **reader_tasks;
static bool lock_is_write_held;
static bool lock_is_read_held;
+static unsigned long last_lock_release;
struct lock_stress_stats {
long n_lock_fail;
@@ -632,6 +633,7 @@ static int lock_torture_writer(void *arg)
lwsp->n_lock_acquired++;
cxt.cur_ops->write_delay();
lock_is_write_held = false;
+ WRITE_ONCE(last_lock_release, jiffies);
cxt.cur_ops->writeunlock();
stutter_wait("lock_torture_writer");
--
2.9.5
Re: [PATCH] ath10k: Fix the parsing error in service available event
"Rakesh Pillai" writes:
>> > diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
>> b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
>> > index 932266d..3b49e29 100644
>> > --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
>> > +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
>> > @@ -1404,9 +1404,12 @@ static int ath10k_wmi_tlv_svc_avail_parse(struct
>> ath10k *ar, u16 tag, u16 len,
>> > arg->service_map_ext_len = *(__le32 *)ptr;
>> > arg->service_map_ext = ptr + sizeof(__le32);
>> > return 0;
>> > + case WMI_TLV_TAG_FIRST_ARRAY_ENUM:
>> > + return 0;
>>
>> This is at least slightly worrying to me. If I were calling this
>> function, I'd expect that if I didn't get back an error that at least
>> "arg->service_map_ext_len" was filled in. Seems like you should do:
>>
>> case WMI_TLV_TAG_FIRST_ARRAY_ENUM:
>> arg->service_map_ext_len = 0;
>> arg->service_map_ext = NULL;
>> return 0;
>>
>> ...and maybe add a comment about why you're doing that?
>>
>> At the moment things are working OK because
>> ath10k_wmi_event_service_available() happens to init the structure to
>> 0 before calling with:
>>
>> struct wmi_svc_avail_ev_arg arg = {};
>>
>> but it doesn't seem like a great idea to rely on that.
>>
>> That all being said, I'm just a drive-by reviewer and if everyone else
>> likes it the way it is, feel free to ignore my comments.
>
>
> The TLV TAG " WMI_TLV_TAG_STRUCT_SERVICE_AVAILABLE_EVENT" is the first
> and a mandatory TLV in the service available event. The subsequent
> TLVs are optional ones and may or may not be present (based on FW
> versions).
>From ath10k point of view never trust what the firmware sends you. Even
if WMI_TLV_TAG_STRUCT_SERVICE_AVAILABLE_EVENT is a mandatory TLV it
might be missing for whatever reasons. The same is with buffer lengths
etc and always confirm what you are receiving from the firmware.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 05-11-20, 11:24, Rob Clark wrote:
> On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> >
> > On 03-11-20, 08:50, Rob Clark wrote:
> > > sorry, it didn't apply cleanly (which I guess is due to some other
> > > dependencies that need to be picked back to v5.4 product kernel), and
> > > due to some other things I'm in middle of debugging I didn't have time
> > > yet to switch to v5.10-rc or look at what else needs to
> > > cherry-picked..
> > >
> > > If you could, pushing a branch with this patch somewhere would be a
> > > bit easier to work with (ie. fetch && cherry-pick is easier to deal
> > > with than picking things from list)
> >
> > It has been in linux-next for a few days. Here is the HEAD to pick
> > from. There are few patches there since rc1.
> >
> > commit 203e29749cc0 ("opp: Allocate the OPP table outside of
> > opp_table_lock")
> >
>
> sorry for the delay, with that cherry-picked, I'm getting a whole lot of:
Ahh, sorry about that and thanks for reporting it. Here is the fix:
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index c718092757d9..6b7f0066942d 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -112,8 +112,6 @@ static struct opp_table *_find_table_of_opp_np(struct
device_node *opp_np)
struct opp_table *opp_table;
struct device_node *opp_table_np;
- lockdep_assert_held(_table_lock);
-
opp_table_np = of_get_parent(opp_np);
if (!opp_table_np)
goto err;
@@ -121,12 +119,15 @@ static struct opp_table *_find_table_of_opp_np(struct
device_node *opp_np)
/* It is safe to put the node now as all we need now is its address */
of_node_put(opp_table_np);
+ mutex_lock(_table_lock);
list_for_each_entry(opp_table, _tables, node) {
if (opp_table_np == opp_table->np) {
_get_opp_table_kref(opp_table);
+ mutex_unlock(_table_lock);
return opp_table;
}
}
+ mutex_unlock(_table_lock);
err:
return ERR_PTR(-ENODEV);
--
viresh
RE: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC
Hi,
>-Original Message-
>From: Ulf Hansson
>Sent: Tuesday, October 13, 2020 4:42 PM
>To: Zulkifli, Muhammad Husaini
>Cc: Hunter, Adrian ; Michal Simek
>; Shevchenko, Andriy
>; linux-...@vger.kernel.org; Linux ARM
>; Linux Kernel Mailing List ker...@vger.kernel.org>; Raja Subramanian, Lakshmi Bai
>; Wan Mohamad, Wan Ahmad
>Zainie ; Arnd Bergmann
>
>Subject: Re: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for
>Keem Bay SOC
>
>On Fri, 9 Oct 2020 at 19:50, Zulkifli, Muhammad Husaini
> wrote:
>>
>> Hi,
>>
>> >-Original Message-
>> >From: Ulf Hansson
>> >Sent: Friday, October 9, 2020 2:56 PM
>> >To: Zulkifli, Muhammad Husaini
>> >Cc: Hunter, Adrian ; Michal Simek
>> >; Shevchenko, Andriy
>> >; linux-...@vger.kernel.org; Linux ARM
>> >; Linux Kernel Mailing List
>> >; Raja Subramanian, Lakshmi Bai
>> >; Wan Mohamad, Wan Ahmad
>> >Zainie ; Arnd Bergmann
>> >
>> >Subject: Re: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1
>> >support for Keem Bay SOC
>> >
>> >On Thu, 8 Oct 2020 at 19:21, Zulkifli, Muhammad Husaini
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> >-Original Message-
>> >> >From: Ulf Hansson
>> >> >Sent: Thursday, October 8, 2020 11:19 PM
>> >> >To: Zulkifli, Muhammad Husaini
>> >> >
>> >> >Cc: Hunter, Adrian ; Michal Simek
>> >> >; Shevchenko, Andriy
>> >> >; linux-...@vger.kernel.org; Linux
>> >> >ARM ; Linux Kernel Mailing
>> >> >List
>> >> >; Raja Subramanian, Lakshmi Bai
>> >> >; Wan Mohamad, Wan
>Ahmad
>> >> >Zainie ; Arnd Bergmann
>> >> >
>> >> >Subject: Re: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1
>> >> >support for Keem Bay SOC
>> >> >
>> >> >On Thu, 8 Oct 2020 at 12:54, Zulkifli, Muhammad Husaini
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> >-Original Message-
>> >> >> >From: Ulf Hansson
>> >> >> >Sent: Thursday, October 8, 2020 5:28 PM
>> >> >> >To: Zulkifli, Muhammad Husaini
>> >> >> >
>> >> >> >Cc: Hunter, Adrian ; Michal Simek
>> >> >> >; Shevchenko, Andriy
>> >> >> >; linux-...@vger.kernel.org; Linux
>> >> >> >ARM ; Linux Kernel
>> >> >> >Mailing List
>> >> >> >; Raja Subramanian, Lakshmi Bai
>> >> >> >; Wan Mohamad, Wan
>> >Ahmad
>> >> >> >Zainie ; Arnd
>Bergmann
>> >> >> >
>> >> >> >Subject: Re: [PATCH v4 4/4] mmc: sdhci-of-arasan: Enable UHS-1
>> >> >> >support for Keem Bay SOC
>> >> >> >
>> >> >> >On Thu, 8 Oct 2020 at 04:12,
>> >> >> >
>> >> >wrote:
>> >> >> >>
>> >> >> >> From: Muhammad Husaini Zulkifli
>> >> >> >>
>> >> >> >>
>> >> >> >> Voltage switching sequence is needed to support UHS-1 interface.
>> >> >> >> There are 2 places to control the voltage.
>> >> >> >> 1) By setting the AON register using firmware driver calling
>> >> >> >> system-level platform management layer (SMC) to set the register.
>> >> >> >> 2) By controlling the GPIO expander value to drive either
>> >> >> >> 1.8V or 3.3V for power mux input.
>> >> >> >>
>> >> >> >> Signed-off-by: Muhammad Husaini Zulkifli
>> >> >> >>
>> >> >> >> Reviewed-by: Andy Shevchenko
>> >> >> >> Reviewed-by: Adrian Hunter
>> >> >> >> ---
>> >> >> >> drivers/mmc/host/sdhci-of-arasan.c | 126
>> >> >> >> +
>> >> >> >> 1 file changed, 126 insertions(+)
>> >> >> >>
>> >> >> >> diff --git a/drivers/mmc/host/sdhci-of-arasan.c
>> >> >> >> b/drivers/mmc/host/sdhci-of-arasan.c
>> >> >> >> index 46aea6516133..ea2467b0073d 100644
>> >> >> >> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> >> >> >> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> >> >> >> @@ -16,6 +16,7 @@
>> >> >> >> */
>> >> >> >>
>> >> >> >> #include
>> >> >> >> +#include
>> >> >> >> #include #include
>> >> >> >> #include @@ -23,6 +24,7 @@ #include
>> >> >> >> #include #include
>> >> >> >>
>> >> >> >> +#include
>> >> >> >>
>> >> >> >> #include "cqhci.h"
>> >> >> >> #include "sdhci-pltfm.h"
>> >> >> >> @@ -136,6 +138,7 @@ struct sdhci_arasan_clk_data {
>> >> >> >> * @soc_ctl_base: Pointer to regmap for syscon for soc_ctl
>registers.
>> >> >> >> * @soc_ctl_map: Map to get offsets into soc_ctl registers.
>> >> >> >> * @quirks:Arasan deviations from spec.
>> >> >> >> + * @uhs_gpio: Pointer to the uhs gpio.
>> >> >> >> */
>> >> >> >> struct sdhci_arasan_data {
>> >> >> >> struct sdhci_host *host; @@ -150,6 +153,7 @@ struct
>> >> >> >> sdhci_arasan_data {
>> >> >> >> struct regmap *soc_ctl_base;
>> >> >> >> const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
>> >> >> >> unsigned intquirks;
>> >> >> >> + struct gpio_desc *uhs_gpio;
>> >> >> >>
>> >> >> >> /* Controller does not have CD wired and will not function
>> >> >> >> normally without
>> >> >> >*/
>> >> >> >> #define SDHCI_ARASAN_QUIRK_FORCE_CDTESTBIT(0)
>> >> >> >> @@ -361,6 +365,112 @@ static int
>> >> >> >> sdhci_arasan_voltage_switch(struct
>> >> >> >mmc_host *mmc,
>> >> >> >> return -EINVAL;
>> >> >> >> }
>> >> >> >>
>> >> >> >> +static int sdhci_arasan_keembay_voltage_switch(struct
>> >> >> >> +mmc_host
>>
Re: [RFC PATCH 1/3] RISC-V: Add Microchip PolarFire SoC kconfig option
On Wed, 28 Oct 2020 16:27:57 PDT (-0700), Atish Patra wrote: Add Microchip PolarFire kconfig option which selects SoC specific and common drivers that is required for this SoC. Signed-off-by: Atish Patra --- arch/riscv/Kconfig.socs | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs index 8a55f6156661..74d07250ecc5 100644 --- a/arch/riscv/Kconfig.socs +++ b/arch/riscv/Kconfig.socs @@ -22,6 +22,13 @@ config SOC_VIRT help This enables support for QEMU Virt Machine. +config SOC_MICROCHIP_POLARFIRE + bool "Microchip PolarFire SoCs" + select MCHP_CLK_PFSOC + select SIFIVE_PLIC + help + This enables support for Microchip PolarFire SoC platforms. + config SOC_KENDRYTE bool "Kendryte K210 SoC" depends on !MMU Reviewed-by: Palmer Dabbelt
Re: [RFC PATCH 3/3] RISC-V: Enable Microchip PolarFire ICICLE SoC
On Wed, 28 Oct 2020 16:27:59 PDT (-0700), Atish Patra wrote: Enable Microchip PolarFire ICICLE soc config in defconfig. It allows the default upstream kernel to boot on PolarFire ICICLE board. I don't actually have one of these to test on yet. That said, if it boots for you then I don't really see any reason to delay this -- maybe there's some issues floating around, but I don't really see any reason to delay putting this on for-next. I'd even go so far as to say we should take it during the RCs, as so far it's just build/DT stuff. Given that this is currently the only production RISC-V Linux board I don't really any reason not to add it to the defconfigs. Is there a reason this is an RFC? Signed-off-by: Atish Patra --- arch/riscv/configs/defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index d222d353d86d..2660fa05451e 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -16,6 +16,7 @@ CONFIG_EXPERT=y CONFIG_BPF_SYSCALL=y CONFIG_SOC_SIFIVE=y CONFIG_SOC_VIRT=y +CONFIG_SOC_MICROCHIP_POLARFIRE=y CONFIG_SMP=y CONFIG_JUMP_LABEL=y CONFIG_MODULES=y @@ -79,6 +80,9 @@ CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y +CONFIG_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_CADENCE=y CONFIG_MMC=y CONFIG_MMC_SPI=y CONFIG_RTC_CLASS=y Reviewed-by: Palmer Dabbelt
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On Wed, 28 Oct 2020 16:27:58 PDT (-0700), Atish Patra wrote:
Add initial DTS for Microchip ICICLE board having only
essential devcies (clocks, sdhci, ethernet, serial, etc).
This fails `make dtbs_check`. The fu540 fails too, so I guess it's not exactly
fair, though.
Signed-off-by: Atish Patra
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/microchip/Makefile| 2 +
.../microchip/microchip-icicle-kit-a000.dts | 313 ++
3 files changed, 316 insertions(+)
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index ca1f8cbd78c0..3ea94ea0a18a 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
subdir-y += sifive
subdir-y += kendryte
+subdir-y += microchip
obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
diff --git a/arch/riscv/boot/dts/microchip/Makefile
b/arch/riscv/boot/dts/microchip/Makefile
new file mode 100644
index ..55ad77521304
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-icicle-kit-a000.dtb
diff --git a/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
b/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
new file mode 100644
index ..5848920af55c
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ100
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Microchip PolarFire-SoC";
+ compatible = "microchip,polarfire-soc";
+
+ chosen {
+ stdout-path =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = ;
+
+ cpu@0 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <16384>;
+ reg = <0>;
+ riscv,isa = "rv64imac";
+ status = "disabled";
+
+ cpu0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+
+ cpu@1 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <1>;
+ riscv,isa = "rv64imafdc";
+ tlb-split;
+ status = "okay";
+
+ cpu1_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+
+ cpu@2 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <2>;
+ riscv,isa = "rv64imafdc";
+ tlb-split;
+ status = "okay";
+
+ cpu2_intc: interrupt-controller {
+ #interrupt-cells
Re: [RFC PATCH 0/3] Add Microchip PolarFire Soc Support
On Wed, 28 Oct 2020 16:27:56 PDT (-0700), Atish Patra wrote: This series adds minimal support for Microchip Polar Fire Soc Icicle kit. It is rebased on v5.10-rc1 and depends on clock support. Only MMC and ethernet drivers are enabled via this series. The idea here is to add the foundational patches so that other drivers can be added to on top of this. This series has been tested on Qemu and Polar Fire Soc Icicle kit. The following qemu series is necessary to test it on Qemu. The series can also be found at the following github repo. I noticed the latest version of mmc driver[2] hangs on the board with the latest clock driver. That's why, I have tested with the old clock driver available in the above github repo. OK, I guess that's why it's an RFC? [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html [2] https://www.spinics.net/lists/devicetree/msg383626.html Looks like this one hasn't been merged yet. IDK if something is broken with my mail client but I'm not seeing any github repos. If this depends on not-yet-merged drivers then it's certainly RFC material, but aside from the DT stuff (which should be straight-forward) it seems fine to me. Since you posted this an an RFC I'm going to assume you're going to re-spin it. Thanks! Atish Patra (3): RISC-V: Add Microchip PolarFire SoC kconfig option RISC-V: Initial DTS for Microchip ICICLE board RISC-V: Enable Microchip PolarFire ICICLE SoC arch/riscv/Kconfig.socs | 7 + arch/riscv/boot/dts/Makefile | 1 + arch/riscv/boot/dts/microchip/Makefile| 2 + .../microchip/microchip-icicle-kit-a000.dts | 313 ++ arch/riscv/configs/defconfig | 4 + 5 files changed, 327 insertions(+) create mode 100644 arch/riscv/boot/dts/microchip/Makefile create mode 100644 arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
[PATCH] libbpf: Remove unnecessary conversion to bool
From: Kaixu Xia Fix following warning from coccinelle: ./tools/lib/bpf/libbpf.c:1478:43-48: WARNING: conversion to bool not needed here Signed-off-by: Kaixu Xia --- tools/lib/bpf/libbpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 313034117070..fb9625077983 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -1475,7 +1475,7 @@ static int set_kcfg_value_tri(struct extern_desc *ext, void *ext_val, ext->name, value); return -EINVAL; } - *(bool *)ext_val = value == 'y' ? true : false; + *(bool *)ext_val = value == 'y'; break; case KCFG_TRISTATE: if (value == 'y') -- 2.20.0
Re: [PATCH] ath10k: add option for chip-id based BDF selection
Abhishek Kumar wrote: > In some devices difference in chip-id should be enough to pick > the right BDF. Add another support for chip-id based BDF selection. > With this new option, ath10k supports 2 fallback options. > > The board name with chip-id as option looks as follows > board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=320' > > Signed-off-by: Abhishek Kumar > Reviewed-by: Douglas Anderson > Tested-by: Douglas Anderson > Tested-by: Abhishek Kumar There were few checkpatch warnings which I fixed: $ ath10k-check drivers/net/wireless/ath/ath10k/core.c:1501: Alignment should match open parenthesis drivers/net/wireless/ath/ath10k/core.c:1512: line length of 92 exceeds 90 columns drivers/net/wireless/ath/ath10k/core.c:1521: line length of 92 exceeds 90 columns The first one was also what Doug commented. I also added Tested-on tags, thanks for those. The updated patch is in pending branch (soon). But is this patch ok to take now? I didn't quite get the conclusion of the discussion. -- https://patchwork.kernel.org/project/linux-wireless/patch/2020102506.1.Ifbc28707942179f1cefc7491e995814564495270@changeid/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC PATCH 0/2] mm: fix OOMs for binding workloads to movable zone only node
On Thu, Nov 05, 2020 at 05:16:12PM +0100, Michal Hocko wrote: > On Thu 05-11-20 21:43:05, Feng Tang wrote: > > On Thu, Nov 05, 2020 at 02:12:45PM +0100, Michal Hocko wrote: > > > On Thu 05-11-20 21:07:10, Feng Tang wrote: > > > [...] > > > > My debug traces shows it is, and its gfp_mask is 'GFP_KERNEL' > > > > > > Can you provide the full information please? Which node has been > > > requested. Which cpuset the calling process run in and which node has > > > the allocation succeeded from? A bare dump_stack without any further > > > context is not really helpful. > > > > I don't have the same platform as the original report, so I simulated > > one similar setup (with fakenuma and movablecore), which has 2 memory > > nodes: node 0 has DMA0/DMA32/Movable zones, while node 1 has only > > Movable zone. With it, I can got the same error and same oom callstack > > as the original report (as in the cover-letter). > > > > The test command is: > > # docker run -it --rm --cpuset-mems 1 ubuntu:latest bash -c "grep > > Mems_allowed /proc/self/status" > > > > To debug I only added some trace in the __alloc_pages_nodemask(), and > > for the callstack which get the page successfully: > > > > [ 567.510903] Call Trace: > > [ 567.510909] dump_stack+0x74/0x9a > > [ 567.510910] __alloc_pages_nodemask.cold+0x22/0xe5 > > [ 567.510913] alloc_pages_current+0x87/0xe0 > > [ 567.510914] __vmalloc_node_range+0x14c/0x240 > > [ 567.510918] module_alloc+0x82/0xe0 > > [ 567.510921] bpf_jit_alloc_exec+0xe/0x10 > > [ 567.510922] bpf_jit_binary_alloc+0x7a/0x120 > > [ 567.510925] bpf_int_jit_compile+0x145/0x424 > > [ 567.510926] bpf_prog_select_runtime+0xac/0x130 > > As already said this doesn't really tell much without the additional > information. > > > The incomming parameter nodemask is NULL, and the function will first try > > the > > cpuset nodemask (1 here), and the zoneidx is only granted 2, which makes the > > 'ac's preferred zone to be NULL. so it goes into __alloc_pages_slowpath(), > > which will first set the nodemask to 'NULL', and this time it got a > > preferred > > zone: zone DMA32 from node 0, following get_page_from_freelist will allocate > > one page from that zone. > > I do not follow. Both hot and slow paths of the allocator set > ALLOC_CPUSET or emulate it by mems_allowed when cpusets are nebaled > IIRC. This is later enforced in get_page_from_free_list. There are some > exceptions when the allocating process can run away from its cpusets - > e.g. IRQs, OOM victims and few other cases but definitely not a random > allocation. There might be some subtle details that have changed or I > might have forgot but yes, I was confused too. IIUC, the key check inside get_page_from_freelist() is if (cpusets_enabled() && (alloc_flags & ALLOC_CPUSET) && !__cpuset_zone_allowed(zone, gfp_mask)) In our case (kernel page got allocated), the first 2 conditions are true, and for __cpuset_zone_allowed(), the possible place to return true is checking parent cpuset's nodemask cs = nearest_hardwall_ancestor(task_cs(current)); allowed = node_isset(node, cs->mems_allowed); This will override the ALLOC_CPUSET check. Thanks, Feng > -- > Michal Hocko > SUSE Labs
Re: [PATCH v5] cper, apei, mce: Pass x86 CPER through the MCA handling chain
Hi Smita,
Smita Koralahalli writes:
> Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
> errors that occurred in a previous boot. The MCA errors in the BERT are
> reported using the x86 Processor Error Common Platform Error Record (CPER)
> format. Currently, the record prints out the raw MSR values and AMD relies
> on the raw record to provide MCA information.
>
> Extract the raw MSR values of MCA registers from the BERT and feed it into
> the standard mce_log() function through the existing x86/MCA RAS
> infrastructure. This will result in better decoding from the EDAC MCE
> decoder or the default notifier.
>
> The implementation is SMCA specific as the raw MCA register values are
> given in the register offset order of the MCAX address space.
>
> [ Fix a build breakage in patch v1. ]
> Reported-by: kernel test robot
> Signed-off-by: Smita Koralahalli
[...]
> diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-x86.c
> index 2531de49f56c..438ed9eff6d0 100644
> --- a/drivers/firmware/efi/cper-x86.c
> +++ b/drivers/firmware/efi/cper-x86.c
> @@ -2,6 +2,7 @@
> // Copyright (C) 2018, Advanced Micro Devices, Inc.
>
> #include
> +#include
Did you mean to include ?
>
> /*
> * We don't need a "CPER_IA" prefix since these are all locally defined.
> @@ -347,9 +348,13 @@ void cper_print_proc_ia(const char *pfx, const struct
> cper_sec_proc_ia *proc)
> ctx_info->mm_reg_addr);
> }
>
> - printk("%sRegister Array:\n", newpfx);
> - print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, groupsize,
> -(ctx_info + 1), ctx_info->reg_arr_size, 0);
> + if (ctx_info->reg_ctx_type != CTX_TYPE_MSR ||
> + arch_apei_report_x86_error(ctx_info, proc->lapic_id)) {
> + printk("%sRegister Array:\n", newpfx);
> + print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16,
> +groupsize, (ctx_info + 1),
> +ctx_info->reg_arr_size, 0);
> + }
>
> ctx_info = (struct cper_ia_proc_ctx *)((long)ctx_info + size);
> }
With that addressed,
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
[PATCH 6/7] drm/panfrost: dev_pm_opp_put_*() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 8ab025d0035f..97b5abc7c188 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -170,10 +170,8 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
pfdevfreq->opp_of_table_added = false;
}
- if (pfdevfreq->regulators_opp_table) {
- dev_pm_opp_put_regulators(pfdevfreq->regulators_opp_table);
- pfdevfreq->regulators_opp_table = NULL;
- }
+ dev_pm_opp_put_regulators(pfdevfreq->regulators_opp_table);
+ pfdevfreq->regulators_opp_table = NULL;
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
--
2.25.0.rc1.19.g042ed3e048af
[PATCH 7/7] media: venus: dev_pm_opp_put_*() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so there is no need for us to carry the extra check. Drop them. Signed-off-by: Viresh Kumar --- drivers/media/platform/qcom/venus/pm_helpers.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c index 57877eacecf0..e1e9130288ad 100644 --- a/drivers/media/platform/qcom/venus/pm_helpers.c +++ b/drivers/media/platform/qcom/venus/pm_helpers.c @@ -898,8 +898,7 @@ static void core_put_v4(struct device *dev) if (core->has_opp_table) dev_pm_opp_of_remove_table(dev); - if (core->opp_table) - dev_pm_opp_put_clkname(core->opp_table); + dev_pm_opp_put_clkname(core->opp_table); } -- 2.25.0.rc1.19.g042ed3e048af
Re: [PATCH mlx5-next v1 04/11] vdpa/mlx5: Make hardware definitions visible to all mlx5 devices
On Thu, Nov 05, 2020 at 04:36:57PM -0400, Jason Gunthorpe wrote: > On Thu, Nov 05, 2020 at 12:31:52PM -0800, Saeed Mahameed wrote: > > On Sun, 2020-11-01 at 22:15 +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky > > > > > > Move mlx5_vdpa IFC header file to the general include folder, so > > > mlx5_core will be able to reuse it to check if VDPA is supported > > > prior to creating an auxiliary device. > > > > > > > I don't really like this, the whole idea of aux devices is that they > > get to do own logic and hide details, now we are exposing aux > > specific stuff to the bus .. let's figure a way to avoid such > > exposure as we discussed yesterday. > > Not quite, the idea is we get to have a cleaner split between the two > sides. > > The device side is responsible for things centric to the device, like > "does this device actually exists" which is what is_supported is > doing. > > The driver side holds the driver specific logic. > > > is_supported check shouldn't belong to mlx5_core and each aux device > > (en/ib/vdpa) should implement own is_supported op and keep the details > > hidden in the aux driver like it was before this patch. > > No, it really should be in the device side. > > Part of the point here is to properly fix module loading. That means > the core driver must only create devices that can actually have a > driver bound to them because creating a device triggers module > loading. > > For instance we do not want to auto load vdpa modules on every mlx5 > system for no reason, that is not clean at all. Saeed, Jason gave very good example and it is not far from the real life requirement. We have an internal task to make sure that mlx5_vdpa is loaded without any other mlx5_* modules (ib and eth). This series solves it naturally. Thanks > > Jason
[PATCH 5/7] drm/lima: dev_pm_opp_put_*() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index bbe02817721b..e7b7b8dfd792 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -110,15 +110,10 @@ void lima_devfreq_fini(struct lima_device *ldev)
devfreq->opp_of_table_added = false;
}
- if (devfreq->regulators_opp_table) {
- dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
- devfreq->regulators_opp_table = NULL;
- }
-
- if (devfreq->clkname_opp_table) {
- dev_pm_opp_put_clkname(devfreq->clkname_opp_table);
- devfreq->clkname_opp_table = NULL;
- }
+ dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
+ dev_pm_opp_put_clkname(devfreq->clkname_opp_table);
+ devfreq->regulators_opp_table = NULL;
+ devfreq->clkname_opp_table = NULL;
}
int lima_devfreq_init(struct lima_device *ldev)
--
2.25.0.rc1.19.g042ed3e048af
[PATCH 1/7] opp: Allow dev_pm_opp_put_*() APIs to accept NULL opp_table
This allows the callers to drop the unnecessary checks.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index b24f685823ae..9d145bb99a59 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1660,6 +1660,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_set_supported_hw);
*/
void dev_pm_opp_put_supported_hw(struct opp_table *opp_table)
{
+ if (unlikely(!opp_table))
+ return;
+
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON(!list_empty(_table->opp_list));
@@ -1716,6 +1719,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_set_prop_name);
*/
void dev_pm_opp_put_prop_name(struct opp_table *opp_table)
{
+ if (unlikely(!opp_table))
+ return;
+
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON(!list_empty(_table->opp_list));
@@ -1844,6 +1850,9 @@ void dev_pm_opp_put_regulators(struct opp_table
*opp_table)
{
int i;
+ if (unlikely(!opp_table))
+ return;
+
if (!opp_table->regulators)
goto put_opp_table;
@@ -1926,6 +1935,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_set_clkname);
*/
void dev_pm_opp_put_clkname(struct opp_table *opp_table)
{
+ if (unlikely(!opp_table))
+ return;
+
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON(!list_empty(_table->opp_list));
@@ -1981,6 +1993,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_register_set_opp_helper);
*/
void dev_pm_opp_unregister_set_opp_helper(struct opp_table *opp_table)
{
+ if (unlikely(!opp_table))
+ return;
+
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON(!list_empty(_table->opp_list));
@@ -2109,6 +2124,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_attach_genpd);
*/
void dev_pm_opp_detach_genpd(struct opp_table *opp_table)
{
+ if (unlikely(!opp_table))
+ return;
+
/*
* Acquire genpd_virt_dev_lock to make sure virt_dev isn't getting
* used in parallel.
--
2.25.0.rc1.19.g042ed3e048af
[PATCH 4/7] devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
---
drivers/devfreq/exynos-bus.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 1e684a448c9e..143fd58ec3dc 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -158,10 +158,8 @@ static void exynos_bus_exit(struct device *dev)
dev_pm_opp_of_remove_table(dev);
clk_disable_unprepare(bus->clk);
- if (bus->opp_table) {
- dev_pm_opp_put_regulators(bus->opp_table);
- bus->opp_table = NULL;
- }
+ dev_pm_opp_put_regulators(bus->opp_table);
+ bus->opp_table = NULL;
}
static void exynos_bus_passive_exit(struct device *dev)
@@ -444,10 +442,8 @@ static int exynos_bus_probe(struct platform_device *pdev)
dev_pm_opp_of_remove_table(dev);
clk_disable_unprepare(bus->clk);
err_reg:
- if (!passive) {
- dev_pm_opp_put_regulators(bus->opp_table);
- bus->opp_table = NULL;
- }
+ dev_pm_opp_put_regulators(bus->opp_table);
+ bus->opp_table = NULL;
return ret;
}
--
2.25.0.rc1.19.g042ed3e048af
[PATCH 2/7] cpufreq: dt: dev_pm_opp_put_regulators() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so there is no need for us to carry the extra checks. Drop them. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq-dt.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index 66b3db5efb53..5c049428a6f5 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -291,8 +291,7 @@ static int dt_cpufreq_early_init(struct device *dev, int cpu) out: if (priv->have_static_opps) dev_pm_opp_of_cpumask_remove_table(priv->cpus); - if (priv->opp_table) - dev_pm_opp_put_regulators(priv->opp_table); + dev_pm_opp_put_regulators(priv->opp_table); free_cpumask_var(priv->cpus); return ret; } @@ -305,8 +304,7 @@ static void dt_cpufreq_release(void) dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table); if (priv->have_static_opps) dev_pm_opp_of_cpumask_remove_table(priv->cpus); - if (priv->opp_table) - dev_pm_opp_put_regulators(priv->opp_table); + dev_pm_opp_put_regulators(priv->opp_table); free_cpumask_var(priv->cpus); list_del(>node); } -- 2.25.0.rc1.19.g042ed3e048af
[PATCH 0/7] opp: Allow dev_pm_opp_put_*() APIs to accept NULL opp_table
Hello, This patchset updates the dev_pm_opp_put_*() helpers to accept a NULL pointer for the OPP table, in order to allow the callers to drop the unnecessary checks they had to carry. All these must get merged upstream through the OPP tree as there is a hard dependency on the first patch here. Thanks. Viresh Kumar (7): opp: Allow dev_pm_opp_put_*() APIs to accept NULL opp_table cpufreq: dt: dev_pm_opp_put_regulators() accepts NULL argument cpufreq: qcom-cpufreq-nvmem: dev_pm_opp_put_*() accepts NULL argument devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument drm/lima: dev_pm_opp_put_*() accepts NULL argument drm/panfrost: dev_pm_opp_put_*() accepts NULL argument media: venus: dev_pm_opp_put_*() accepts NULL argument drivers/cpufreq/cpufreq-dt.c | 6 ++ drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 ++- drivers/devfreq/exynos-bus.c | 12 drivers/gpu/drm/lima/lima_devfreq.c| 13 - drivers/gpu/drm/panfrost/panfrost_devfreq.c| 6 ++ drivers/media/platform/qcom/venus/pm_helpers.c | 3 +-- drivers/opp/core.c | 18 ++ 7 files changed, 37 insertions(+), 36 deletions(-) -- 2.25.0.rc1.19.g042ed3e048af
[PATCH 3/7] cpufreq: qcom-cpufreq-nvmem: dev_pm_opp_put_*() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra checks. Drop them.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c
b/drivers/cpufreq/qcom-cpufreq-nvmem.c
index d06b37822c3d..747d602f221e 100644
--- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -397,19 +397,19 @@ static int qcom_cpufreq_probe(struct platform_device
*pdev)
free_genpd_opp:
for_each_possible_cpu(cpu) {
- if (IS_ERR_OR_NULL(drv->genpd_opp_tables[cpu]))
+ if (IS_ERR(drv->genpd_opp_tables[cpu]))
break;
dev_pm_opp_detach_genpd(drv->genpd_opp_tables[cpu]);
}
kfree(drv->genpd_opp_tables);
free_opp:
for_each_possible_cpu(cpu) {
- if (IS_ERR_OR_NULL(drv->names_opp_tables[cpu]))
+ if (IS_ERR(drv->names_opp_tables[cpu]))
break;
dev_pm_opp_put_prop_name(drv->names_opp_tables[cpu]);
}
for_each_possible_cpu(cpu) {
- if (IS_ERR_OR_NULL(drv->hw_opp_tables[cpu]))
+ if (IS_ERR(drv->hw_opp_tables[cpu]))
break;
dev_pm_opp_put_supported_hw(drv->hw_opp_tables[cpu]);
}
@@ -430,12 +430,9 @@ static int qcom_cpufreq_remove(struct platform_device
*pdev)
platform_device_unregister(cpufreq_dt_pdev);
for_each_possible_cpu(cpu) {
- if (drv->names_opp_tables[cpu])
- dev_pm_opp_put_supported_hw(drv->names_opp_tables[cpu]);
- if (drv->hw_opp_tables[cpu])
- dev_pm_opp_put_supported_hw(drv->hw_opp_tables[cpu]);
- if (drv->genpd_opp_tables[cpu])
- dev_pm_opp_detach_genpd(drv->genpd_opp_tables[cpu]);
+ dev_pm_opp_put_supported_hw(drv->names_opp_tables[cpu]);
+ dev_pm_opp_put_supported_hw(drv->hw_opp_tables[cpu]);
+ dev_pm_opp_detach_genpd(drv->genpd_opp_tables[cpu]);
}
kfree(drv->names_opp_tables);
--
2.25.0.rc1.19.g042ed3e048af
Re: Question: gadget: How to realize uvc and uac composite function?
On Fri, Nov 06, 2020 at 04:33:13AM +, Tim Li wrote: > This email and any attachments thereto may contain private, confidential, and > privileged material for the sole use of the intended recipient. Any review, > copying, or distribution of this email (or any attachments thereto) by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender immediately and permanently delete the original and any copies of > this email and any attachments thereto. This footer is not compatible with posting on a public Linux mailing list, sorry. Now deleted...
Re: [PATCH] crypto: caam - fix printing on xts fallback allocation error path
On Sun, Nov 01, 2020 at 10:05:53PM +0200, Horia Geantă wrote:
> At the time xts fallback tfm allocation fails the device struct
> hasn't been enabled yet in the caam xts tfm's private context.
>
> Fix this by using the device struct from xts algorithm's private context
> or, when not available, by replacing dev_err with pr_err.
>
> Fixes: 9d9b14dbe077 ("crypto: caam/jr - add fallback for XTS with more than
> 8B IV")
> Fixes: 83e8aa912138 ("crypto: caam/qi - add fallback for XTS with more than
> 8B IV")
> Fixes: 36e2d7cfdcf1 ("crypto: caam/qi2 - add fallback for XTS with more than
> 8B IV")
> Signed-off-by: Horia Geantă
> ---
> drivers/crypto/caam/caamalg.c | 4 ++--
> drivers/crypto/caam/caamalg_qi.c | 4 ++--
> drivers/crypto/caam/caamalg_qi2.c | 3 ++-
> 3 files changed, 6 insertions(+), 5 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/8] crypto: hisilicon/qm - misc clean up
On Sat, Oct 31, 2020 at 05:07:00PM +0800, Weili Qian wrote: > This patchset makes some clean up, please see comments in each patch. > > Weili Qian (8): > crypto: hisilicon/qm - numbers are replaced by macros > crypto: hisilicon/qm - modify the return type of function > crypto: hisilicon/qm - modify the return type of debugfs interface > crypto: hisilicon/qm - modify return type of 'qm_set_sqctype' > crypto: hisilicon/qm - replace 'sprintf' with 'scnprintf' > crypto: hisilicon/qm - split 'qm_qp_ctx_cfg' into smaller pieces > crypto: hisilicon/qm - split 'qm_eq_ctx_cfg' into smaller pieces > crypto: hisilicon/qm - split 'hisi_qm_init' into smaller pieces > > drivers/crypto/hisilicon/hpre/hpre_main.c | 4 +- > drivers/crypto/hisilicon/qm.c | 207 > +++--- > drivers/crypto/hisilicon/qm.h | 2 +- > drivers/crypto/hisilicon/sec2/sec_main.c | 4 +- > drivers/crypto/hisilicon/zip/zip_main.c | 4 +- > 5 files changed, 134 insertions(+), 87 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm/aes-neonbs - fix usage of cbc(aes) fallback
On Wed, Oct 28, 2020 at 11:03:20AM +0200, Horia Geantă wrote:
> Loading the module deadlocks since:
> -local cbc(aes) implementation needs a fallback and
> -crypto API tries to find one but the request_module() resolves back to
> the same module
>
> Fix this by changing the module alias for cbc(aes) and
> using the NEED_FALLBACK flag when requesting for a fallback algorithm.
>
> Fixes: 00b99ad2bac2 ("crypto: arm/aes-neonbs - Use generic cbc encryption
> path")
> Signed-off-by: Horia Geantă
> ---
> arch/arm/crypto/aes-neonbs-glue.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: qat: remove unneeded semicolon
On Tue, Oct 27, 2020 at 12:04:07PM -0700, t...@redhat.com wrote: > From: Tom Rix > > A semicolon is not needed after a switch statement. > > Signed-off-by: Tom Rix > --- > drivers/crypto/qat/qat_common/qat_algs.c | 2 +- > drivers/crypto/qat/qat_common/qat_asym_algs.c | 8 > 2 files changed, 5 insertions(+), 5 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: af_alg - avoid undefined behavior accessing salg_name
On Mon, Oct 26, 2020 at 01:07:15PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
> names") made the kernel start accepting arbitrarily long algorithm names
> in sockaddr_alg. However, the actual length of the salg_name field
> stayed at the original 64 bytes.
>
> This is broken because the kernel can access indices >= 64 in salg_name,
> which is undefined behavior -- even though the memory that is accessed
> is still located within the sockaddr structure. It would only be
> defined behavior if the array were properly marked as arbitrary-length
> (either by making it a flexible array, which is the recommended way
> these days, or by making it an array of length 0 or 1).
>
> We can't simply change salg_name into a flexible array, since that would
> break source compatibility with userspace programs that embed
> sockaddr_alg into another struct, or (more commonly) declare a
> sockaddr_alg like 'struct sockaddr_alg sa = { .salg_name = "foo" };'.
>
> One solution would be to change salg_name into a flexible array only
> when '#ifdef __KERNEL__'. However, that would keep userspace without an
> easy way to actually use the longer algorithm names.
>
> Instead, add a new structure 'sockaddr_alg_new' that has the flexible
> array field, and expose it to both userspace and the kernel.
> Make the kernel use it correctly in alg_bind().
>
> This addresses the syzbot report
> "UBSAN: array-index-out-of-bounds in alg_bind"
> (https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e).
>
> Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com
> Fixes: 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
> names")
> Cc: # v4.12+
> Signed-off-by: Eric Biggers
> ---
> crypto/af_alg.c | 10 +++---
> include/uapi/linux/if_alg.h | 16
> 2 files changed, 23 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: cavium/nitrox: remove unneeded semicolon
On Tue, Oct 27, 2020 at 12:01:25PM -0700, t...@redhat.com wrote: > From: Tom Rix > > A semicolon is not needed after a switch statement. > > Signed-off-by: Tom Rix > --- > drivers/crypto/cavium/nitrox/nitrox_mbx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: caam - enable crypto-engine retry mechanism
On Mon, Oct 26, 2020 at 09:06:26PM +0200, Iuliana Prodan wrote: > Use the new crypto_engine_alloc_init_and_set() function to > initialize crypto-engine and enable retry mechanism. > > Set the maximum size for crypto-engine software queue based on > Job Ring size (JOBR_DEPTH) and a threshold (reserved for the > non-crypto-API requests that are not passed through crypto-engine). > > The callback for do_batch_requests is NULL, since CAAM > doesn't support linked requests. > > Signed-off-by: Iuliana Prodan > --- > Changes since v1: > - add comment for THRESHOLD define; > - update max size for crypto-engine queue. > > drivers/crypto/caam/intern.h | 8 > drivers/crypto/caam/jr.c | 4 +++- > 2 files changed, 11 insertions(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel-sha: remove unneeded break
On Mon, Oct 19, 2020 at 12:36:53PM -0700, t...@redhat.com wrote: > From: Tom Rix > > A break is not needed if it is preceded by a return > > Signed-off-by: Tom Rix > --- > drivers/crypto/atmel-sha.c | 1 - > 1 file changed, 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] kernel/watchdog: Fix watchdog_allowed_mask not used warning
Le 06/11/2020 à 02:50, Santosh Sivaraj a écrit :
Define watchdog_allowed_mask only when SOFTLOCKUP_DETECTOR is enabled.
Fixes: 7feeb9cd4f5b ("watchdog/sysctl: Clean up sysctl variable name space")
Cc: Thomas Gleixner
Cc: Andrew Morton
Reviewed-by: Petr Mladek
Signed-off-by: Santosh Sivaraj
Reviewed-by: Christophe Leroy
---
v2:
Added Petr's reviewed-by from [1] and add fixes tag as suggested by Christophe.
[1]: https://lkml.org/lkml/2020/8/20/1030
kernel/watchdog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 5abb5b22ad13..71109065bd8e 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -44,8 +44,6 @@ int __read_mostly soft_watchdog_user_enabled = 1;
int __read_mostly watchdog_thresh = 10;
static int __read_mostly nmi_watchdog_available;
-static struct cpumask watchdog_allowed_mask __read_mostly;
-
struct cpumask watchdog_cpumask __read_mostly;
unsigned long *watchdog_cpumask_bits = cpumask_bits(_cpumask);
@@ -162,6 +160,8 @@ static void lockup_detector_update_enable(void)
int __read_mostly sysctl_softlockup_all_cpu_backtrace;
#endif
+static struct cpumask watchdog_allowed_mask __read_mostly;
+
/* Global variables, exported for sysctl */
unsigned int __read_mostly softlockup_panic =
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE;
Re: [PATCH mlx5-next v1 05/11] net/mlx5: Register mlx5 devices to auxiliary virtual bus
On Thu, Nov 05, 2020 at 05:09:48PM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 05, 2020 at 12:59:20PM -0800, Saeed Mahameed wrote:
>
> > 2. you can always load a driver without its underlying device existed.
> > for example, you can load a pci device driver/module and it will load
> > and wait for pci devices to pop up, the subsysetem infrastructure will
> > match between drivers and devices and probe them.
>
> Yes, this works fine with this design
>
> > struct aux_driver mlx5_vpda_aux_driver {
> >
> > .name = "vdpa",
> >/* match this driver with mlx5_core devices */
> > .id_table = {"mlx5_core"},
> > .ops {
> > /* called before probe on actual aux mlx5_core device */
> >.is_supported(struct aux_device);
>
> This means module auto loading is impossible, we can't tell to load
> the module until we load the module to call the is_supported code ..
Right, and if we can, it will be violation of everything we know in
driver model, because the call "is_supported" will need to be called
for every registered driver without any relation to existed devices.
And mlx5_rescan_drivers() came as a need to overcome LAG and eswitch
craziness in everything related to their reprobe flows. Once they will
be changed to work like normal drivers, we will be able to simplify it.
So let's talk offline to see how can we improve mlx5_core even more
after this series is merged.
Thanks
>
> Jason
[PATCH v4 2/2] f2fs: fix compat F2FS_IOC_{MOVE,GARBAGE_COLLECT}_RANGE
Eric reported a ioctl bug in below link:
https://lore.kernel.org/linux-f2fs-devel/20201103032234.GB2875@sol.localdomain/
That said, on some 32-bit architectures, u64 has only 32-bit alignment,
notably i386 and x86_32, so that size of struct f2fs_gc_range compiled
in x86_32 is 20 bytes, however the size in x86_64 is 24 bytes, binary
compiled in x86_32 can not call F2FS_IOC_GARBAGE_COLLECT_RANGE successfully
due to mismatched value of ioctl command in between binary and f2fs
module, similarly, F2FS_IOC_MOVE_RANGE will fail too.
In this patch we introduce two ioctls for compatibility of above special
32-bit binary:
- F2FS_IOC32_GARBAGE_COLLECT_RANGE
- F2FS_IOC32_MOVE_RANGE
Reported-by: Eric Biggers
Signed-off-by: Chao Yu
---
v4:
- add Reported-by tag
- avoid redundant codes for cleanup
- move compat definitions to .c
fs/f2fs/file.c | 127 +++--
1 file changed, 101 insertions(+), 26 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 22ae8ae0072f..1464a8d8e969 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -2480,26 +2480,19 @@ static int f2fs_ioc_gc(struct file *filp, unsigned long
arg)
return ret;
}
-static int f2fs_ioc_gc_range(struct file *filp, unsigned long arg)
+static int __f2fs_ioc_gc_range(struct file *filp, struct f2fs_gc_range *range)
{
- struct inode *inode = file_inode(filp);
- struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- struct f2fs_gc_range range;
+ struct f2fs_sb_info *sbi = F2FS_I_SB(file_inode(filp));
u64 end;
int ret;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
-
- if (copy_from_user(, (struct f2fs_gc_range __user *)arg,
- sizeof(range)))
- return -EFAULT;
-
if (f2fs_readonly(sbi->sb))
return -EROFS;
- end = range.start + range.len;
- if (end < range.start || range.start < MAIN_BLKADDR(sbi) ||
+ end = range->start + range->len;
+ if (end < range->start || range->start < MAIN_BLKADDR(sbi) ||
end >= MAX_BLKADDR(sbi))
return -EINVAL;
@@ -2508,7 +2501,7 @@ static int f2fs_ioc_gc_range(struct file *filp, unsigned
long arg)
return ret;
do_more:
- if (!range.sync) {
+ if (!range->sync) {
if (!down_write_trylock(>gc_lock)) {
ret = -EBUSY;
goto out;
@@ -2517,20 +2510,30 @@ static int f2fs_ioc_gc_range(struct file *filp,
unsigned long arg)
down_write(>gc_lock);
}
- ret = f2fs_gc(sbi, range.sync, true, GET_SEGNO(sbi, range.start));
+ ret = f2fs_gc(sbi, range->sync, true, GET_SEGNO(sbi, range->start));
if (ret) {
if (ret == -EBUSY)
ret = -EAGAIN;
goto out;
}
- range.start += BLKS_PER_SEC(sbi);
- if (range.start <= end)
+ range->start += BLKS_PER_SEC(sbi);
+ if (range->start <= end)
goto do_more;
out:
mnt_drop_write_file(filp);
return ret;
}
+static int f2fs_ioc_gc_range(struct file *filp, unsigned long arg)
+{
+ struct f2fs_gc_range range;
+
+ if (copy_from_user(, (struct f2fs_gc_range __user *)arg,
+ sizeof(range)))
+ return -EFAULT;
+ return __f2fs_ioc_gc_range(filp, );
+}
+
static int f2fs_ioc_write_checkpoint(struct file *filp, unsigned long arg)
{
struct inode *inode = file_inode(filp);
@@ -2867,9 +2870,9 @@ static int f2fs_move_file_range(struct file *file_in,
loff_t pos_in,
return ret;
}
-static int f2fs_ioc_move_range(struct file *filp, unsigned long arg)
+static int __f2fs_ioc_move_range(struct file *filp,
+ struct f2fs_move_range *range)
{
- struct f2fs_move_range range;
struct fd dst;
int err;
@@ -2877,11 +2880,7 @@ static int f2fs_ioc_move_range(struct file *filp,
unsigned long arg)
!(filp->f_mode & FMODE_WRITE))
return -EBADF;
- if (copy_from_user(, (struct f2fs_move_range __user *)arg,
- sizeof(range)))
- return -EFAULT;
-
- dst = fdget(range.dst_fd);
+ dst = fdget(range->dst_fd);
if (!dst.file)
return -EBADF;
@@ -2894,8 +2893,8 @@ static int f2fs_ioc_move_range(struct file *filp,
unsigned long arg)
if (err)
goto err_out;
- err = f2fs_move_file_range(filp, range.pos_in, dst.file,
- range.pos_out, range.len);
+ err = f2fs_move_file_range(filp, range->pos_in, dst.file,
+ range->pos_out, range->len);
mnt_drop_write_file(filp);
err_out:
@@ -2903,6 +2902,16 @@ static int
Re: [PATCH] usb: Use IS_ERR_OR_NULL() instead of IS_ERR()
On Fri, Nov 06, 2020 at 11:31:18AM +0800, Wang Qing wrote: > __usb_find_phy may return NULL, so we should use IS_ERR_OR_NULL() Again with the subject line, "USB: phy: ..." And are you sure this function can return NULL? thanks, greg k-h
Re: [PATCH] riscv: uaccess: fix __put_kernel_nofault()
On Mon, Nov 2, 2020 at 1:01 PM Changbin Du wrote:
>
> The copy_from_kernel_nofault() is broken on riscv because the 'dst' and
> 'src' are mistakenly reversed in __put_kernel_nofault() macro.
>
> copy_to_kernel_nofault:
> ...
> 0xffe0003159b8 <+30>:sd a4,0(a1) # a1 aka 'src'
>
> Fixes: d464118cdc ("riscv: implement __get_kernel_nofault and
> __put_user_nofault")
> Signed-off-by: Changbin Du
> Cc: Christoph Hellwig
> ---
> arch/riscv/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/uaccess.h
> b/arch/riscv/include/asm/uaccess.h
> index c47e6b35c551..824b2c9da75b 100644
> --- a/arch/riscv/include/asm/uaccess.h
> +++ b/arch/riscv/include/asm/uaccess.h
> @@ -476,7 +476,7 @@ do {
> \
> do { \
> long __kr_err; \
> \
> - __put_user_nocheck(*((type *)(dst)), (type *)(src), __kr_err); \
> + __put_user_nocheck(*((type *)(src)), (type *)(dst), __kr_err); \
> if (unlikely(__kr_err)) \
> goto err_label; \
> } while (0)
> --
> 2.17.1
>
>
Looks good to me.
Tested-by: Anup Patel
Reviewed-by: Anup Patel
@Palmer Dabbelt , This patch fixes jump label implementation in
Linux-5.10-rc2. In general, this patch fixes all kernel instruction
patching related features. Can you take this for Linux-5.10-rcX ??
Regards,
Anup
Re: [PATCH] usb: Assign NULL to phy that may be returned
On Fri, Nov 06, 2020 at 11:15:55AM +0800, Wang Qing wrote:
> Assign initial values to local variables that may be returned
>
> Signed-off-by: Wang Qing
Your subject, and body of text, seem to have 2 "odd" characters in it,
please fix up.
Also, your subject and changelog body here are identical, please be much
more verbose in the body explaining why you are doing something, not
just what you are doing.
And your subject line should also match other patches for this file, and
have "usb: phy: ..." in the beginning.
> ---
> drivers/usb/phy/phy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
> index b47285f..de21967
> --- a/drivers/usb/phy/phy.c
> +++ b/drivers/usb/phy/phy.c
> @@ -59,7 +59,7 @@ static struct usb_phy *__usb_find_phy(struct list_head
> *list,
>
> static struct usb_phy *__of_usb_find_phy(struct device_node *node)
> {
> - struct usb_phy *phy;
> + struct usb_phy *phy = NULL;
Why isn't the compiler complaining about this today? Are you sure this
is needed?
thanks,
greg k-h
[PATCH v2 2/2] KVM: x86: emulate wait-for-SIPI and SIPI-VMExit
From: Yadong Qi
Background: We have a lightweight HV, it needs INIT-VMExit and
SIPI-VMExit to wake-up APs for guests since it do not monitor
the Local APIC. But currently virtual wait-for-SIPI(WFS) state
is not supported in nVMX, so when running on top of KVM, the L1
HV cannot receive the INIT-VMExit and SIPI-VMExit which cause
the L2 guest cannot wake up the APs.
According to Intel SDM Chapter 25.2 Other Causes of VM Exits,
SIPIs cause VM exits when a logical processor is in
wait-for-SIPI state.
In this patch:
1. introduce SIPI exit reason,
2. introduce wait-for-SIPI state for nVMX,
3. advertise wait-for-SIPI support to guest.
When L1 hypervisor is not monitoring Local APIC, L0 need to emulate
INIT-VMExit and SIPI-VMExit to L1 to emulate INIT-SIPI-SIPI for
L2. L2 LAPIC write would be traped by L0 Hypervisor(KVM), L0 should
emulate the INIT/SIPI vmexit to L1 hypervisor to set proper state
for L2's vcpu state.
Handle procdure:
Source vCPU:
L2 write LAPIC.ICR(INIT).
L0 trap LAPIC.ICR write(INIT): inject a latched INIT event to target
vCPU.
Target vCPU:
L0 emulate an INIT VMExit to L1 if is guest mode.
L1 set guest VMCS, guest_activity_state=WAIT_SIPI, vmresume.
L0 set vcpu.mp_state to INIT_RECEIVED if (vmcs12.guest_activity_state
== WAIT_SIPI).
Source vCPU:
L2 write LAPIC.ICR(SIPI).
L0 trap LAPIC.ICR write(INIT): inject a latched SIPI event to traget
vCPU.
Target vCPU:
L0 emulate an SIPI VMExit to L1 if (vcpu.mp_state == INIT_RECEIVED).
L1 set CS:IP, guest_activity_state=ACTIVE, vmresume.
L0 resume to L2.
L2 start-up.
Signed-off-by: Yadong Qi
Message-Id: <20200922052343.84388-1-yadong...@intel.com>
Signed-off-by: Paolo Bonzini
---
v1->v2:
* sync_vmcs02_to_vmcs12(): set vmcs12->guest_activity_state to WAIT_SIPI
if vcpu's mp_state is INIT_RECEIVED state.
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/include/uapi/asm/vmx.h | 2 ++
arch/x86/kvm/vmx/nested.c | 55 -
3 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index f8ba5289ecb0..38ca445a8429 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -113,6 +113,7 @@
#define VMX_MISC_PREEMPTION_TIMER_RATE_MASK0x001f
#define VMX_MISC_SAVE_EFER_LMA 0x0020
#define VMX_MISC_ACTIVITY_HLT 0x0040
+#define VMX_MISC_ACTIVITY_WAIT_SIPI0x0100
#define VMX_MISC_ZERO_LEN_INS 0x4000
#define VMX_MISC_MSR_LIST_MULTIPLIER 512
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index b8ff9e8ac0d5..ada955c5ebb6 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -32,6 +32,7 @@
#define EXIT_REASON_EXTERNAL_INTERRUPT 1
#define EXIT_REASON_TRIPLE_FAULT2
#define EXIT_REASON_INIT_SIGNAL3
+#define EXIT_REASON_SIPI_SIGNAL 4
#define EXIT_REASON_INTERRUPT_WINDOW7
#define EXIT_REASON_NMI_WINDOW 8
@@ -94,6 +95,7 @@
{ EXIT_REASON_EXTERNAL_INTERRUPT,"EXTERNAL_INTERRUPT" }, \
{ EXIT_REASON_TRIPLE_FAULT, "TRIPLE_FAULT" }, \
{ EXIT_REASON_INIT_SIGNAL, "INIT_SIGNAL" }, \
+ { EXIT_REASON_SIPI_SIGNAL, "SIPI_SIGNAL" }, \
{ EXIT_REASON_INTERRUPT_WINDOW, "INTERRUPT_WINDOW" }, \
{ EXIT_REASON_NMI_WINDOW,"NMI_WINDOW" }, \
{ EXIT_REASON_TASK_SWITCH, "TASK_SWITCH" }, \
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 89af692deb7e..6dc9017289ba 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2952,7 +2952,8 @@ static int nested_vmx_check_vmcs_link_ptr(struct kvm_vcpu
*vcpu,
static int nested_check_guest_non_reg_state(struct vmcs12 *vmcs12)
{
if (CC(vmcs12->guest_activity_state != GUEST_ACTIVITY_ACTIVE &&
- vmcs12->guest_activity_state != GUEST_ACTIVITY_HLT))
+ vmcs12->guest_activity_state != GUEST_ACTIVITY_HLT &&
+ vmcs12->guest_activity_state != GUEST_ACTIVITY_WAIT_SIPI))
return -EINVAL;
return 0;
@@ -3559,19 +3560,29 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool
launch)
*/
nested_cache_shadow_vmcs12(vcpu, vmcs12);
- /*
-* If we're entering a halted L2 vcpu and the L2 vcpu won't be
-* awakened by event injection or by an NMI-window VM-exit or
-* by an interrupt-window VM-exit, halt the vcpu.
-*/
- if ((vmcs12->guest_activity_state == GUEST_ACTIVITY_HLT) &&
- !(vmcs12->vm_entry_intr_info_field & INTR_INFO_VALID_MASK) &&
- !(vmcs12->cpu_based_vm_exec_control & CPU_BASED_NMI_WINDOW_EXITING)
&&
- !((vmcs12->cpu_based_vm_exec_control &
CPU_BASED_INTR_WINDOW_EXITING) &&
- (vmcs12->guest_rflags & X86_EFLAGS_IF))) {
[PATCH] regulator: core: don't disable regulator if is_enabled return error.
In regulator_late_cleanup when is_enabled failed, don't try to disable
the regulator since it would likely to fail too and causing confusing
error messages.
Signed-off-by: Pi-Hsun Shih
---
This is encountered while using drivers/regulator/cros-ec-regulator.c.
Since the driver controls the regulator through ChromeOS EC host
commands, it is not available when doing suspend / resume.
But since the regulator_late_cleanup is delayed to 30 seconds after
boot, it is possible that the regulator_late_cleanup is run during
suspend / resume, which cause the is_enabled call to fail, and printing
out some confusing error messages later when trying to disable the
regulator and fail.
This commit attempts to address part of this issue by not trying to
disable the regulator if the is_enabled call failed.
---
drivers/regulator/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index a5ad553da8cd..70168f2a53ed 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5843,13 +5843,14 @@ static int regulator_late_cleanup(struct device *dev,
void *data)
if (rdev->use_count)
goto unlock;
- /* If we can't read the status assume it's on. */
+ /* If we can't read the status assume it's always on. */
if (ops->is_enabled)
enabled = ops->is_enabled(rdev);
else
enabled = 1;
- if (!enabled)
+ /* But if reading the status failed, assume that it's off. */
+ if (enabled <= 0)
goto unlock;
if (have_full_constraints()) {
base-commit: 521b619acdc8f1f5acdac15b84f81fd9515b2aff
--
2.29.1.341.ge80a0c044ae-goog
Re: [PATCH v2] tracing: Add register read and write tracing support
On Thu, Nov 05, 2020 at 06:56:26PM -0800, Prasad Sodagudi wrote:
> Add register read/write operations tracing support.
> ftrace events helps to trace register read and write
> location details of memory mapped IO registers.
This sentance does not parse for me, can you please rework it?
> These trace logs helps to debug un clocked access
> of peripherals.
"un clocked"? What does that mean?
And you do have 72 columns to fill, please use it :)
>
> Signed-off-by: Prasad Sodagudi
> ---
> arch/arm64/include/asm/io.h| 9
> arch/arm64/kernel/image-vars.h | 8 +++
You are only adding it for arm64, why not add the generic support first,
and then add it for all "major" arches afterwards?
> include/linux/iorw.h | 38 +++
> include/trace/events/rwio.h| 51
> ++
> kernel/trace/Kconfig | 11 +
> kernel/trace/Makefile | 1 +
> kernel/trace/trace_readwrite.c | 31 +
> 7 files changed, 149 insertions(+)
> create mode 100644 include/linux/iorw.h
> create mode 100644 include/trace/events/rwio.h
> create mode 100644 kernel/trace/trace_readwrite.c
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index fd172c4..bcfc65c 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -9,6 +9,7 @@
> #define __ASM_IO_H
>
> #include
> +#include
> #include
>
> #include
> @@ -24,24 +25,28 @@
> #define __raw_writeb __raw_writeb
> static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> {
> + log_write_io(addr);
> asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
Why are you not logging the value here, and everywhere else? You need
to document why that is somewhere, as it's the most obvious question you
will get.
thanks,
greg k-h
RE: [PATCH] KVM: x86: emulate wait-for-SIPI and SIPI-VMExit
> There is a problem in this patch, in that this change is incorrect:
>
> >
> > @@ -2847,7 +2847,8 @@ void kvm_apic_accept_events(struct kvm_vcpu
> *vcpu)
> > */
> > if (kvm_vcpu_latch_init(vcpu)) {
> > WARN_ON_ONCE(vcpu->arch.mp_state ==
> KVM_MP_STATE_INIT_RECEIVED);
> > - if (test_bit(KVM_APIC_SIPI, >pending_events))
> > + if (test_bit(KVM_APIC_SIPI, >pending_events) &&
> > + !is_guest_mode(vcpu))
> > clear_bit(KVM_APIC_SIPI, >pending_events);
> > return;
> > }
>
> Here you're not trying to process a latched INIT; you just want to delay the
> processing of the SIPI until check_nested_events.
>
> The change does have a correct part in it. In particular,
> vmx_apic_init_signal_blocked should have been
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index
> 47b8357b9751..64339121a4f0 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -7558,7 +7558,7 @@ static void enable_smi_window(struct kvm_vcpu
> *vcpu)
>
> static bool vmx_apic_init_signal_blocked(struct kvm_vcpu *vcpu)
> {
> - return to_vmx(vcpu)->nested.vmxon;
> + return to_vmx(vcpu)->nested.vmxon && !is_guest_mode(vcpu);
> }
>
> static void vmx_migrate_timers(struct kvm_vcpu *vcpu)
>
> to only latch INIT signals in root mode. However, SIPI must be cleared
> unconditionally on SVM; the "!is_guest_mode" test in that case is incorrect.
>
> The right way to do it is to call check_nested_events from
> kvm_apic_accept_events. This will cause an INIT or SIPI vmexit, as required.
> There is some extra complication to read pending_events
> *before* kvm_apic_accept_events and not steal from the guest any INIT or SIPI
> that is sent after kvm_apic_accept_events returns.
>
> Thanks to your test case, I will test a patch and send it.
>
Thanks very much, Paolo.
BTW, I noticed another issue in sync_vmcs02_to_vmcs12():
vmcs12->guest_activity_state is not set properly when mp_state is INIT_RECEIVED.
I will correct it and send v2 of Patch 2/2.
Re: [PATCH 4/4] dt-bindings: bus: Convert ACONNECT doc to json-schema
Move ACONNECT documentation to YAML format.
Signed-off-by: Sameer Pujar
---
.../bindings/bus/nvidia,tegra210-aconnect.txt | 44 ---
.../bindings/bus/nvidia,tegra210-aconnect.yaml | 86 ++
2 files changed, 86 insertions(+), 44 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
create mode 100644
Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
...
diff --git
a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
new file mode 100644
index 000..f0161bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/nvidia,tegra210-aconnect.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra ACONNECT Bus
+
+description: |
+ The Tegra ACONNECT bus is an AXI switch which is used to connnect various
+ components inside the Audio Processing Engine (APE). All CPU accesses to
+ the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All
+ devices accessed via the ACONNNECT are described by child-nodes.
+
...
+
+patternProperties:
+ "^dma-controller(@[0-9a-f]+)?$":
+$ref: /schemas/dma/nvidia,tegra210-adma.yaml#
+ "^interrupt-controller(@[0-9a-f]+)?$":
+$ref: /schemas/interrupt-controller/arm,gic.yaml#
+ "^ahub(@[0-9a-f]+)?$":
+$ref: /schemas/sound/nvidia,tegra210-ahub.yaml#
These all get applied already since they match on compatible strings. So
having them here means the schema is applied twice. There's maybe some
value to this if it's always going to be these 3 nodes.
1) May be this could be dropped with "additionalProperties = true", but
that allows any arbitary property to be added for the device. Without
this 'make dtbs_check' complains about not matching properties in DT files.
2) These may not be the final list of nodes this device can have. In
future if any new device support gets added under this, above needs to
be updated. But it will be limited number of devices.
So is [2] fine or you would suggest [1] would be good enough?
Also, the unit-addresses shouldn't be optional.
I'd just do:
"@[0-9a-f]+$":
type: object
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+aconnect@702c {
+compatible = "nvidia,tegra210-aconnect";
+clocks = <_car TEGRA210_CLK_APE>,
+ <_car TEGRA210_CLK_APB2APE>;
+clock-names = "ape", "apb2ape";
+power-domains = <_audio>;
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges = <0x702c 0x702c 0x0004>;
+
+// Child device nodes follow ...
+};
+
+...
--
2.7.4
Re: [PATCH v1 16/18] efi: Update implementation of add_links() to create fwnode links
On Thu, Nov 05, 2020 at 03:27:52PM -0800, Saravana Kannan wrote: > On Thu, Nov 5, 2020 at 1:42 AM Greg Kroah-Hartman > wrote: > > > > On Wed, Nov 04, 2020 at 03:23:53PM -0800, Saravana Kannan wrote: > > > The semantics of add_links() has changed from creating device link > > > between devices to creating fwnode links between fwnodes. So, update the > > > implementation of add_links() to match the new semantics. > > > > > > Signed-off-by: Saravana Kannan > > > --- > > > drivers/firmware/efi/efi-init.c | 23 ++- > > > 1 file changed, 2 insertions(+), 21 deletions(-) > > > > > > diff --git a/drivers/firmware/efi/efi-init.c > > > b/drivers/firmware/efi/efi-init.c > > > index b148f1459fb3..c0c3d4c3837a 100644 > > > --- a/drivers/firmware/efi/efi-init.c > > > +++ b/drivers/firmware/efi/efi-init.c > > > @@ -316,11 +316,10 @@ static struct device_node > > > *find_pci_overlap_node(void) > > > * resource reservation conflict on the memory window that the efifb > > > * framebuffer steals from the PCIe host bridge. > > > */ > > > -static int efifb_add_links(const struct fwnode_handle *fwnode, > > > +static int efifb_add_links(struct fwnode_handle *fwnode, > > > struct device *dev) > > > > So you are fixing the build warning you added a few patches ago here? > > Please fix up the function signatures when you made that change, not > > here later on. > > I'm trying not to have a mega patcht that changes a lot of code. > > I guess I can drop this "const" diff from this patch and then merge it > with the earlier patch that removes the const. But still leave the > rest of the changes in this patch as is. Does that work for you? Yes, that's fine, you just can't add build warnings along the way. thanks, greg k-h
[PATCH] net: udp: remove redundant initialization in udp_send_skb
From: Menglong Dong The initialization for 'err' with 0 is redundant and can be removed, as it is updated by ip_send_skb and not used before that. Signed-off-by: Menglong Dong --- net/ipv4/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index ca04a8a..6953688 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -874,7 +874,7 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, struct sock *sk = skb->sk; struct inet_sock *inet = inet_sk(sk); struct udphdr *uh; - int err = 0; + int err; int is_udplite = IS_UDPLITE(sk); int offset = skb_transport_offset(skb); int len = skb->len - offset; -- 2.7.4
Re: [PATCH bpf-next 4/5] bpf: load and verify kernel module BTFs
On Thu, Nov 05, 2020 at 09:51:09PM -0800, Andrii Nakryiko wrote:
> Add kernel module listener that will load/validate and unload module BTF.
> Module BTFs gets ID generated for them, which makes it possible to iterate
> them with existing BTF iteration API. They are given their respective module's
> names, which will get reported through GET_OBJ_INFO API. They are also marked
> as in-kernel BTFs for tooling to distinguish them from user-provided BTFs.
>
> Also, similarly to vmlinux BTF, kernel module BTFs are exposed through
> sysfs as /sys/kernel/btf/. This is convenient for user-space
> tools to inspect module BTF contents and dump their types with existing tools:
>
> [vmuser@archvm bpf]$ ls -la /sys/kernel/btf
> total 0
> drwxr-xr-x 2 root root 0 Nov 4 19:46 .
> drwxr-xr-x 13 root root 0 Nov 4 19:46 ..
>
> ...
>
> -r--r--r-- 1 root root 888 Nov 4 19:46 irqbypass
> -r--r--r-- 1 root root 100225 Nov 4 19:46 kvm
> -r--r--r-- 1 root root 35401 Nov 4 19:46 kvm_intel
> -r--r--r-- 1 root root 120 Nov 4 19:46 pcspkr
> -r--r--r-- 1 root root 399 Nov 4 19:46 serio_raw
> -r--r--r-- 1 root root 4094095 Nov 4 19:46 vmlinux
>
> Signed-off-by: Andrii Nakryiko
> ---
> Documentation/ABI/testing/sysfs-kernel-btf | 8 +
> include/linux/bpf.h| 2 +
> include/linux/module.h | 4 +
> kernel/bpf/btf.c | 193 +
> kernel/bpf/sysfs_btf.c | 2 +-
> kernel/module.c| 32
> 6 files changed, 240 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-kernel-btf
> b/Documentation/ABI/testing/sysfs-kernel-btf
> index 2c9744b2cd59..fe96efdc9b6c 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-btf
> +++ b/Documentation/ABI/testing/sysfs-kernel-btf
> @@ -15,3 +15,11 @@ Description:
> information with description of all internal kernel types. See
> Documentation/bpf/btf.rst for detailed description of format
> itself.
> +
> +What:/sys/kernel/btf/
> +Date:Nov 2020
> +KernelVersion: 5.11
> +Contact: b...@vger.kernel.org
> +Description:
> + Read-only binary attribute exposing kernel module's BTF type
> + information as an add-on to the kernel's BTF
> (/sys/kernel/btf/vmlinux).
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 2fffd30e13ac..3cb89cd7177b 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -36,9 +36,11 @@ struct seq_operations;
> struct bpf_iter_aux_info;
> struct bpf_local_storage;
> struct bpf_local_storage_map;
> +struct kobject;
>
> extern struct idr btf_idr;
> extern spinlock_t btf_idr_lock;
> +extern struct kobject *btf_kobj;
>
> typedef int (*bpf_iter_init_seq_priv_t)(void *private_data,
> struct bpf_iter_aux_info *aux);
> diff --git a/include/linux/module.h b/include/linux/module.h
> index a29187f7c360..20fce258ffba 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -475,6 +475,10 @@ struct module {
> unsigned int num_bpf_raw_events;
> struct bpf_raw_event_map *bpf_raw_events;
> #endif
> +#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> + unsigned int btf_data_size;
> + void *btf_data;
> +#endif
> #ifdef CONFIG_JUMP_LABEL
> struct jump_entry *jump_entries;
> unsigned int num_jump_entries;
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 09f1483934d2..fe639ffae361 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
>
> /* BTF (BPF Type Format) is the meta data format which describes
> @@ -4488,6 +4490,75 @@ struct btf *btf_parse_vmlinux(void)
> return ERR_PTR(err);
> }
>
> +static struct btf *btf_parse_module(const char *module_name, const void
> *data, unsigned int data_size)
> +{
> + struct btf_verifier_env *env = NULL;
> + struct bpf_verifier_log *log;
> + struct btf *btf = NULL, *base_btf;
> + int err;
> +
> + base_btf = bpf_get_btf_vmlinux();
> + if (IS_ERR(base_btf))
> + return base_btf;
> + if (!base_btf)
> + return ERR_PTR(-EINVAL);
> +
> + env = kzalloc(sizeof(*env), GFP_KERNEL | __GFP_NOWARN);
> + if (!env)
> + return ERR_PTR(-ENOMEM);
> +
> + log = >log;
> + log->level = BPF_LOG_KERNEL;
> +
> + btf = kzalloc(sizeof(*btf), GFP_KERNEL | __GFP_NOWARN);
> + if (!btf) {
> + err = -ENOMEM;
> + goto errout;
> + }
> + env->btf = btf;
> +
> + btf->base_btf = base_btf;
> + btf->start_id = base_btf->nr_types;
> + btf->start_str_off = base_btf->hdr.str_len;
> + btf->kernel_btf = true;
> + snprintf(btf->name, sizeof(btf->name), "%s", module_name);
> +
> + btf->data = kvmalloc(data_size, GFP_KERNEL |
[PATCH] net: udp: remove redundant initialization in udp_dump_one
From: Menglong Dong
The initialization for 'err' with '-EINVAL' is redundant and
can be removed, as it is updated soon and not used.
Signed-off-by: Menglong Dong
---
net/ipv4/udp_diag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index 1dbece3..b2cee9a 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -30,7 +30,7 @@ static int udp_dump_one(struct udp_table *tbl,
const struct inet_diag_req_v2 *req)
{
struct sk_buff *in_skb = cb->skb;
- int err = -EINVAL;
+ int err;
struct sock *sk = NULL;
struct sk_buff *rep;
struct net *net = sock_net(in_skb->sk);
--
2.7.4
[PATCH] net: udp: remove redundant initialization in udp_gro_complete
From: Menglong Dong
The initialization for 'err' with '-ENOSYS' is redundant and
can be removed, as it is updated soon and not used.
Signed-off-by: Menglong Dong
---
net/ipv4/udp_offload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index b8b1fde..65860f8 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -554,7 +554,7 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
{
__be16 newlen = htons(skb->len - nhoff);
struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
- int err = -ENOSYS;
+ int err;
struct sock *sk;
uh->len = newlen;
--
2.7.4
[PATCH] net: ipv4: remove redundant initialization in inet_rtm_deladdr
From: Menglong Dong The initialization for 'err' with '-EINVAL' is redundant and can be removed, as it is updated soon. Signed-off-by: Menglong Dong --- net/ipv4/devinet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index 123a6d3..847cb18 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -651,7 +651,7 @@ static int inet_rtm_deladdr(struct sk_buff *skb, struct nlmsghdr *nlh, struct ifaddrmsg *ifm; struct in_ifaddr *ifa; - int err = -EINVAL; + int err; ASSERT_RTNL(); -- 2.7.4
Re: [PATCH v2] proc: Provide details on indirect branch speculation
Hi Anand, On Fri, 6 Nov 2020 13:10:43 +1100 Anand K Mistry wrote: > > Similar to speculation store bypass, show information about the indirect > branch speculation mode of a task in /proc/$pid/status. > > Signed-off-by: Anand K Mistry > --- > > Changes in v2: > - Remove underscores from field name to workaround documentation issue I replaced the previous version in linux-next with this today. It fixes the htmldocs warning from yesterday, thanks. -- Cheers, Stephen Rothwell pgpyqJ7Icbn40.pgp Description: OpenPGP digital signature
[PATCH] perf: remove duplicate check on fwnode
fwnode is checked IS_ERR_OR_NULL in following check by is_of_node() or is_acpi_device_node(), remove duplicate check. Signed-off-by: Wang Qing --- drivers/perf/arm_dsu_pmu.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c index 98e68ed..0459a34 --- a/drivers/perf/arm_dsu_pmu.c +++ b/drivers/perf/arm_dsu_pmu.c @@ -716,9 +716,6 @@ static int dsu_pmu_device_probe(struct platform_device *pdev) if (IS_ERR(dsu_pmu)) return PTR_ERR(dsu_pmu); - if (IS_ERR_OR_NULL(fwnode)) - return -ENOENT; - if (is_of_node(fwnode)) rc = dsu_pmu_dt_get_cpus(>dev, _pmu->associated_cpus); else if (is_acpi_device_node(fwnode)) -- 2.7.4
Re: [PATCH] usb/mos7720: process deferred urbs in a workqueue
On Thu, 05 Nov 2020, Johan Hovold wrote:
On Wed, Nov 04, 2020 at 04:13:07PM -0800, Davidlohr Bueso wrote:
Also, but not strictly related to this. What do you think of deferring all
work in write_parport_reg_nonblock() unconditionally? I'd like to avoid
that mutex_trylock() because eventually I'll be re-adding a warn in the
locking code, but that would also simplify the code done here in the
nonblocking irq write. I'm not at all familiar with parport, but I would
think that restore_state context would not care.
Sounds good to me. As long as the state is restored before submitting
further requests we should be fine. That would even allow getting rid of
write_parport_reg_nonblock() as you can restore the state using
synchronous calls from the worker thread. Should simplify things quite a
bit.
What about something like the below (probably buggy)? I avoided messing with
the completion in the work callback, like what prologue/epilogue does for all
other synchronous calls, because when releasing we sync the work anyway and we
need to account for scenarios where the work is scheduled but yet not running,
so it would not be the best fit. And this also makes the flush_work() always
wait for both writes, otherwise I was having the thread locklessly busy-wait
on a flag that was set until both write_parport_reg_nonblock() calls returned
before the flush such that all potential scheduled work was observed. Unless
I missed something, the cleanup is considerable.
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index 5a5d2a95070e..8a9408b94cb0 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -79,14 +79,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define DCR_INIT_VAL 0x0c /* SLCTIN, nINIT */
#define ECR_INIT_VAL 0x00 /* SPP mode */
-struct urbtracker {
- struct mos7715_parport *mos_parport;
- struct list_headurblist_entry;
- struct kref ref_count;
- struct urb *urb;
- struct usb_ctrlrequest *setup;
-};
-
enum mos7715_pp_modes {
SPP = 0<<5,
PS2 = 1<<5, /* moschip calls this 'NIBBLE' mode */
@@ -96,12 +88,9 @@ enum mos7715_pp_modes {
struct mos7715_parport {
struct parport *pp; /* back to containing struct */
struct kref ref_count; /* to instance of this struct */
- struct list_headdeferred_urbs; /* list deferred async urbs */
- struct list_headactive_urbs; /* list async urbs in flight */
- spinlock_t listlock; /* protects list access */
boolmsg_pending; /* usb sync call pending */
struct completion syncmsg_compl; /* usb sync call completed */
- struct tasklet_struct urb_tasklet; /* for sending deferred urbs */
+ struct work_struct work; /* restore deferred writes */
struct usb_serial *serial; /* back to containing struct */
__u8shadowECR; /* parallel port regs... */
__u8shadowDCR;
@@ -265,172 +254,6 @@ static void destroy_mos_parport(struct kref *kref)
kfree(mos_parport);
}
-static void destroy_urbtracker(struct kref *kref)
-{
- struct urbtracker *urbtrack =
- container_of(kref, struct urbtracker, ref_count);
- struct mos7715_parport *mos_parport = urbtrack->mos_parport;
-
- usb_free_urb(urbtrack->urb);
- kfree(urbtrack->setup);
- kfree(urbtrack);
- kref_put(_parport->ref_count, destroy_mos_parport);
-}
-
-/*
- * This runs as a tasklet when sending an urb in a non-blocking parallel
- * port callback had to be deferred because the disconnect mutex could not be
- * obtained at the time.
- */
-static void send_deferred_urbs(struct tasklet_struct *t)
-{
- int ret_val;
- unsigned long flags;
- struct mos7715_parport *mos_parport = from_tasklet(mos_parport, t,
- urb_tasklet);
- struct urbtracker *urbtrack, *tmp;
- struct list_head *cursor, *next;
- struct device *dev;
-
- /* if release function ran, game over */
- if (unlikely(mos_parport->serial == NULL))
- return;
-
- dev = _parport->serial->dev->dev;
-
- /* try again to get the mutex */
- if (!mutex_trylock(_parport->serial->disc_mutex)) {
- dev_dbg(dev, "%s: rescheduling tasklet\n", __func__);
- tasklet_schedule(_parport->urb_tasklet);
- return;
- }
-
- /* if device disconnected, game over */
- if (unlikely(mos_parport->serial->disconnected)) {
- mutex_unlock(_parport->serial->disc_mutex);
- return;
- }
-
- spin_lock_irqsave(_parport->listlock, flags);
- if (list_empty(_parport->deferred_urbs)) {
- spin_unlock_irqrestore(_parport->listlock, flags);
-
